It’s fundamentally about choosing features based on what can be done well versus done at all. Lots of server bloat is caused by loading our applications up with features that are not cheap resource-wise. If you think about the billions of calculations and the hundreds of millions of bytes you can ship from one machine, we should be able to do something like stackoverflow in one rack with room to spare.
15 years ago we could sustain 1/10th the traffic on 1/40th of the hardware of my current project, and the old one was badly architected. If we fixed that and added all the redundancy and telemetry of today they might just about cancel out. But factor in all the hardware improvements and this is not a good look.
Your average "web scale" cloud system with Node and lambdas and VMs and distributed databases galore feels slow and clunky as hell before it's even under load, to those of us who remember "bad" old LAMP stacks running on a 1U server.
Not that I want to go back to that, exactly, but our performance expectations have gotten really screwy.
[EDIT] or, hell, take "Web 2.0". Piles of code and frameworks and shadow DOMs and shit all chasing and touting "performance" while full-page-loading low-JS sites like Craigslist and Basic HTML Gmail (or HN) leave them in the dust. Know what those are doing? Handing HTML to the browser and letting it render it. No JS render step, no fetching JSON then passing it through Redux and then making twenty function calls to eventually modify a shadow DOM to later apply to the real one. The browser is fast. Your JS is what's fucking slow and eating all my memory.
I would argue JS is a lot faster than you think, and the sluggishness you feel is due to the massive number of files being downloaded. Dozens of JS libraries (think jQuery, Bootstrap, etc.), several CSS stylesheets, and a hundred images or more. If each one of those files is even a few kilobytes each, there is still a 10ms (or even 100ms) download time on each of them, and unfortunately its very common for these files to be downloaded sequentially. JS on its own is quite performant.
Whatever some benchmarks (probably involving handing control off to C or C++ as quickly as possible, like any interpreted language benchmark aiming to demonstrate its "blazing fast" speed) say, real world experience demonstrates the opposite. Web 2.0 "webapps" are slow as dripping molasses and eat memory like they own my whole machine. Input lags, "loading" bars galore for the simplest thing, and that's even when supposed geniuses at Google or wherever are involved. That's Javascript's fault, not HTML and CSS, since those demonstrably still work just fine and aren't that much more memory hungry than they were years ago.
[EDIT] to be fair to Javascript, there are few or no similarly-robust scripting languages that'd fair much better at half-assedly reimplementing features of their host environment (the browser, in this case). I dislike it for other reasons but it's not because it's slower than its peer languages. And I have plenty of complaints about HTML and CSS for modern "app development" since they've been ill-advisedly pressed into service for that purpose, but speed's not one of them—my browser renders a plain webpage in no time flat.
Whilst JS might be somewhat fast, you know what’s even faster?
Designing your application so that it doesn’t need it. If I never have to download, parse and execute the JS, I’m already way ahead. With better privacy to boot.
I understand the appeal of rendering websites on the serverside, in their entirety (HTML and CSS), before the response is returned to the user's browser, which is what would need to happen if we all decided to stop using JavaScript today. However, using JavaScript in the user's browser to compute things like dynamic construction of the UI, animations, etc. has its benefits. For one, using the user's machine via JavaScript leverages their CPU and reduces the CPU consumption of the server. This can save cost, and when done correctly provides an overall better user experience. Things like AJAX (or XMLHttpRequests) are also a blessing and vastly improve the usability of websites. I'm comfortably sitting on the fence - I agree JS is used too often for things that don't need to be done on the user's machine, and anything that can be done on the serverside easily should be done there, but there are times when it is useful. Because of that I disagree with disabling it or not using it entirely.
15 years ago we could sustain 1/10th the traffic on 1/40th of the hardware of my current project, and the old one was badly architected. If we fixed that and added all the redundancy and telemetry of today they might just about cancel out. But factor in all the hardware improvements and this is not a good look.