Sites with minimal or no JavaScript are faster than sites with lots of JavaScript. The volume of JS is often so large, especially with frameworks, that it can take a long time both to transfer and to execute. I've noticed the difference to be significant on older computers or slower Internet connections, but it's even perceptible on new systems with fast Internet connections. Studies repeatedly show that ordinary users care about the speed of websites. I think this is a very good reason to shy away from making a "full client-side application" unless the benefits from that approach are significant.
> Sites with minimal or no javascript are faster than sites with lots of javascript.
Though experiment: Simple todo app. Would this be faster if, upon every interaction with the UI, the whole form was sent to the server to recalculate a new DOM to send back to the browser to download + re-render? It certainly seems like e.g. adding a row to a DataTable would be what most users would call "faster".
Also, consider how this app scales. Requiring that the server re-build a page for every user interaction is a lot more work for the server vs. sending a big blob of HTML + assets once (CDNJS and similar services also affect how this performs). Given how powerful even a low-end few-year-old smartphone in the US is these days, I doubt that it would be a better experience to make an app like todo rely on server-side processing.
I do agree that javascript isn't /always/ the right tool, but building a few smaller API back-end + JS app front-end things lately been pretty convincing for me that JS + AJAX + REST API is a better UX for lots of things vs submit-and-rebuild. Clicking a radio button or selecting something in a drop-down and having the page refresh as a result feels pretty lame in 2014.
EDIT: note that I was a pretty dedicated NoScript user for a few years, a few years ago. These days, Privoxy running a few AB+ lists filters out almost all of the junk that annoys me (I found the performance of AB+ to be unacceptable with dozens of tabs open at once).
"Clicking a radio button or selecting something in a drop-down and having the page refresh as a result feels pretty lame in 2014."
I find that's somewhat true until I'm sharing my todo list with others. Knowing that the rendered page represents a synchronous snapshot in time can be valuable, and is something that's often lost when moving to AJAX (though I certainly agree it doesn't have to be). Your point generally certainly holds - updates should be faster on a well-designed app, and ideally your JS will be cached.
I think a TODO app would be an instance where the benefits of a "full client-side application" may be significant enough to outweigh the downsides, for the good reasons you describe.
I was a bit imprecise in the portion of my comment that you quoted; it was mainly a response to the parent's assertion that there was no reason to hold back from using JavaScript, even on his/her blog.
Studies don't show that users care about the speed of websites - they show that users care about the ease, and therefore "perceived speed", by which they can achieve a goal.
A website with a quality interactive UX that adapts to user's needs, ideally with minimal interruption, is going to be substantially more efficient for the user.
This is especially true since the very nature of web requires communicating with remote servers in order to update and persist the user's state. Loading an entire webpage every time state changes is not just slower, it's also quite disruptive for the user.
Javascript's power comes down to the fact it offers AJAX and a way to manipulate the DOM on the fly. In addition to avoiding full-page reloads, it has the advantage that you can present the user with meaningful UI i.e. progress indicators and what-not.
> A website with a quality interactive UX that adapts to user's needs, ideally with minimal interruption, is going to be substantially more efficient for the user.
If that's the case, then the problem isn't JS, it's poor web development. Annoying? Absolutely!
However, this is not a problem that users can expect to resolve on their end by doing something so general as disabling Javascript.
I could disable images, or ignore CSS, and undoubtedly websites would load faster for me also. However, complaining to the web-page maintainer that the webpage functions poorly on my system would hardly make sense.
Javascript is not the problem; I can make equally terrible UX for websites with-out it - small fonts, animated GIFs, terrible (any) audio... crap content.
If users want to complain and be taken seriously then they should complain about the problem, not something orthogonal to the issue.
