Linode, Amazon, and Google all absolutely use JavaScript. Tom isn't saying that they use JavaScript on the server, he is suggesting that JavaScript is involved with their website despite using a different language on the server.
Look, saying "client-side JS apps are damn fast" is a vague statement.
What we are talking about here is the architecture of a client-side application in any language. If you can ship application code to a local runtime, then that application code will always be able to respond to user interaction faster than fetching the results of a UI interaction (like a click) from partway across the globe.
The benefits of Client-side JavaScript applications do not come directly from JavaScript. They come from the architecture you can build when treating the Browser as a runtime for applications.
Progressive enhancement (beyond very small apps) is a challenge to maintain, since UI state needs to be shared between a server runtime and client runtime. I don't think there is disagreement that a pure server-rendered app or a pure client-rendered application would be simpler.
And your comments about shitty execution of web pages and apps could apply to any shitty app. They have nothing to do with client-side JavaScript applications. I expect a better argument than "I once saw a webpage that sucked".
> Progressive enhancement (beyond very small apps) is a challenge to maintain, since UI state needs to be shared between a server runtime and client runtime.
It does? Why? The server is handling the data to be rendered either way, and as I say in response to another comment, rendering the data is as simple as:
res.end(render(template, data))
> And your comments about shitty execution of web pages and apps could apply to any shitty app. They have nothing to do with client-side JavaScript applications. I expect a better argument than "I once saw a webpage that sucked".
The argument is "you are VC-funded, and taking a 1mil+ dollars to build the Next Big (S|P)aaS. You are spending tons of money on A/B testing, designers, mockups, UI specialists, and your page does not even load for the lowest common denominator - and easiest to manage (static HTML) users of the web?"
My experiences may be biased, but most startups I work with have target audiences that do not include tin-foil hatted JavaScript disabling individuals.
To the contrary, for them investing any energy in servicing this minority would be a mistake.
I suspect their exists some subset of startups were this may be reversed. But they are absolutely in the minority.
(including GMail, and probably others). All of which are big names that can and do work ENTIRELY without JavaScript.
Gmail has an html/css only interface that uses no javascript. I use it every day, and everything just works. Additionally, on my device it's much snappier even with full page refreshes. This rebuts the original assertion that "All modern websites, even server-rendered ones, need JavaScript.".
This is an entirely different frontend that was added years after Gmail launched. The interface that most of us use absolutely won't function without JavaScript.
Adding a pure html view to a mature, profitable application to appeal to a niche audience probably makes sense. Building it that way from the start probably doesn't.
Look, saying "client-side JS apps are damn fast" is a vague statement.
What we are talking about here is the architecture of a client-side application in any language. If you can ship application code to a local runtime, then that application code will always be able to respond to user interaction faster than fetching the results of a UI interaction (like a click) from partway across the globe.
The benefits of Client-side JavaScript applications do not come directly from JavaScript. They come from the architecture you can build when treating the Browser as a runtime for applications.
Progressive enhancement (beyond very small apps) is a challenge to maintain, since UI state needs to be shared between a server runtime and client runtime. I don't think there is disagreement that a pure server-rendered app or a pure client-rendered application would be simpler.
And your comments about shitty execution of web pages and apps could apply to any shitty app. They have nothing to do with client-side JavaScript applications. I expect a better argument than "I once saw a webpage that sucked".