But isn't that just artificially limiting yourself for no real reason? The no-JavaScript argument seems like IE6 repeating itself - intentionally dumbing down the capabilities at hand for a select few - except in this case (vs IE 6 in the aughts) it really is significantly "the few."
It might seem technically silly for me to have tons of parallax scrolling and DOM manipulation on my blog, but who cares?
I agree that decisions like this have the capacity to disrupt business in certain cases, but I don't see it being something that important in most businesses.
Edit: I'm taking a strong view here for certain, but I wonder who, outside an audience this technically literate, actually disables JS? True, the CDN argument is a good one, but in that case I assume most of my other static assets would be blocked as well.
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.
It's not just "the few" that browse with javascript disabled, though. It's also about making sure you play nice with assistive technology, that your content is visible to search engines, that you haven't broken URLs and browser history...
With HTML5, it's possible to do all this in a single page app. But it's a lot of work that you might not do or might get wrong, that you get for free when you treat web pages like web pages.
Certainly you're free to have huge globs of Javascript and CSS, but very many people have slow limited Internet connections and you're making life a (teeny tiny) bit worse for those people.
The important part of your blog is probably the text. We have hundreds of years of design iteration in the presentation of text and it's just weird to ignore all that.
It might seem technically silly for me to have tons of parallax scrolling and DOM manipulation on my blog, but who cares?
I agree that decisions like this have the capacity to disrupt business in certain cases, but I don't see it being something that important in most businesses.
Edit: I'm taking a strong view here for certain, but I wonder who, outside an audience this technically literate, actually disables JS? True, the CDN argument is a good one, but in that case I assume most of my other static assets would be blocked as well.