Developers! You probably don't need javascript to achieve 90% of your goals. It will just slow your page load speeds.
In such a scenario, I have to write code somewhere to provide the experience. If I am writing it on the server side I run into several issues.
It uses server resources. For example, let's say the user is looking at a large dataset. They want to sort/search/filter that dataset. Given that they already have the data in their client, it often makes sense to use their resources to sort/search/filter the data. This lightens the load on the server.
User actions suffer from latency talking to the server. Again, if the user already has all the data that they want, not talking to the server can often result in a better user experience. Imagine something like an incremental search. Such a thing might even be impossible to implement server side due to latency issues.
Implementing client side functionality in the server can add to software complexity. Things like keeping track of user state can be handled much more cleanly on the client side.
Very often it makes tremendous sense not to make a "web page" for something that needs a lot of user interaction. Instead you want a stand alone application that gets data (without presentation) from a server. Writing your application in javascript, running it in a browser, using HTML as a presentation layer and using HTTP as your communication protocol is not a stupid way of implementing such an application (and I say this having written these kinds of applications with a variety of different technologies).
If you are writing a web page that is intended to simply present data, then Javascript may very well be unnecessary. For me, though, this does not come anywhere close to 90% of my goals.
I totally agree, if you are thinking about maintaining user state on the server, you are probably doing it wrong, as you are violating REST. That's the nice thing about using dumb clients, is it forces you to think about application state changes using hypermedia, instead complex client side logic. I think this leads to clean APIs.
The 10% of your goals that you do not achieve without Javascript are essential to changing 'the web' from being a clunky to being a nice experience. The web without the least bit of Javascript is like a world without fire: you'll survive, but it won't be nearly as comfortable. Fire inevitably led to nuclear bombs, but we should certainly not disavow fire because of that. We should just be against the nukes.
If someone decides they don't want any salt, they should still be able eat the plain old boring soup. They'll get the nutrition they need. Maybe it won't taste quite as nice, but the primary function of the soup is still there. Plus your soup is more accessible to people on low sodium diets, and takes less time to prepare!
Why not a checkbox to turn off HTML? It would be just as "useful"...
I do need JS to achieve all my goals that can be achieved with JS. For those things that can be achieved without JS but often mistakenly involve it (hamburger menus, animations etc), I use plain markup and CSS3. But I'm not going to ruin the UX on mobiles, where in developing countries traffic still matters, just for some paranoid freaks' sake.
Language doesn't make Web slow and bulky. People do.
I'm just curious about how the web works and how modern sites use JavaScript.
Maybe I'm talking out my ass, since UX isn't my field, but I imagine that 90% of UX is "the application allows me to do the thing I'm using it for, it has logically layed out screens, and navigating between screens is fast and intuitive." I think hypermedia accounts for these concerns. Sure there are some annoyances, like "voting on a comment or article causes the screen to flash." It's a little jarring but everything still functions. You can sprinkle some JavaScript in, like on HN, to smooth that over.