JavaScript Disabled: Should I Care?
halls-of-valhalla.org
halls-of-valhalla.org
In several of my recent sites, there's been a main company site requiring no Javascript, but then a portal to one or more applications or services that requires Javascript.
In these cases, Javascript is taking the place of what before might have been Java applets, Flash apps, or Silverlight applications. But it's arguably more secure, fairly standardized, and "installed" by default.
And in the cases of full browser applications, I think it's silly to argue against requiring Javascript. You simply can't build a fully responsive client-side application using just HTTP calls and static HTML, no matter how performant the server side.
And I will absolutely continue to use <noscript> tags for browser apps that run on Javascript, since it's rather rude to just show a white screen with no indication of what the problem is to users.
For documents, the answer is probably "provide the information", and that can trivially be accomplished without JS.
For some excruciatingly dynamic web apps, the answer might be "use someone else's product" or even "it can't be done".
There is substantial middle ground, though.
This always seems to be a controversial discussion yet all it is about is a few well-understood rules:
- Manage your dependencies
- Don't break things on purpose because you don't like the user's setup
- Don't feel obligated to fully support platforms you have no desire of supporting
This is completely true, and I've found things to go best if I do one of two things:
1) Do a server side (template driven) app, using a server framework like Flask, ExpressJS, or else just Golang, with very light Javascript on the client, maybe using JQuery and Bootstrap for Javascript or else just pure Javascript. Minimal progressive enhancement.
2) Do a client-side app using a client framework like AngularJS or Backbone, or ReactJS, and build out a RESTful backend on the server side (or use Firebase or Parse.com). I even do authentication logic on the client now, since it's possible to do so securely. Not possible to use without Javascript.
In between these two extremes is a no man's land, particularly if you use big client and server frameworks (as you say pointed out). In my experience, such an approach can make it extremely difficult to build a coherent app structure.
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.
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.
That is a miniscule number of websites though.
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.
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).
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 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.
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.
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.
Exactly.
In the case of something like gmail, while many of the features cannot [practically] be implemented without Javascript, it is always important to have some fallback. Even a dumb, read-only, paginated-<ul> of your inbox is useful.
I could be on a strange browser, or behind a restrictive or badly implemented firewall. Even just a message saying what should have been on the page can serve as a reason to come back when a proper browser is available.
Put another way: given the noscript extension exists, you should probably give at least <i>some</i> reason for people to click the whitelist button.
Just have something there; the Meteor style of not caring and sending an empty <body> tag just makes your site look like a broken webserver.
We can design our sites using a technique called Progressive Enhancement.
Sounds to me like he just said you shouldn't do that, and then tells you to do it.
You don't create a website, and then provide an enhanced version for those with javascript enabled. Not unless you are building a website in 1995. You provide a normal version and a degraded version for those with missing parts.
The problem is Javascript is part of the browser, when you disable part of the browser. Stuff won't work... It's not up to the web developer to accommodate that. If someone has a virus on their computer, you don't build your website expecting ads to be placed on it. If someone has an extension that changes every word on the page that starts with v to cheese. You shouldn't rewrite your website to not use v words.
The paragraph makes only the one point of mixed-content but that is not the only possibility.
Another possibility is: javascript (or js dependency) is hosted on a CDN and the CDN is unavailable (down, blocked by company/state filters, ...).
Another could simply be that part of the js is broken for some reason and did not execute further (could be because part of the js is generated per-user in a dumb way and our user is little bobby tables, could be because of caching issues, could be a critical bug not caught in QA, ...).
Another reason is that loading assets could be extremely slow for the user and they will temporarily see the site in a broken state. I'm suffering from this myself currently - I'm out of the country on a massively throttled 3G. I'm closing a lot of sites before they finish loading their JS because I don't have all day. The type of speed I'm dealing with here exists in many parts of the world and it is unsafe (and extremely inconsiderate) to assume everyone will load all assets within seconds.
In the mean time, a bunch of blogs and wordpress-type sites will not load without their bazillion javascript files. Half of them from tracking sites, the other half from social sites (sigh).
A few more years down the line, this is how the "web 2.0" will be remembered: 3 different JS frameworks on the same site, a bazillion share buttons and simply generally more javascript being served than cheeseburgers in a macdonalds.
And that argument does apply to css and images. Obviously this does not apply to actual web apps but more to article-oriented HTML.
And yes, I do look at network timelines (I tether, sue me). The amount of sites that will hang until jquery is done loading because displaying their measly 50 lines of text requires a fancy animation they were too lazy to implement in css is pathetic.
"What I’ve found, counter-intuitively, is that apps that embrace JavaScript actually end up having less JavaScript."
The example given is the Boston Globe with over a half megabyte of JavaScript for essentially textual content. I think this is a great example of why people are still using NoScript in 2014.
https://gds.blog.gov.uk/2013/10/21/how-many-people-are-missi...
It feels a little like running a car constantly in first gear. It is going to be a guaranteed sub-optimal experience.
But if I'm making an actual application, it's a lot simpler to disregard users without JS. For example, I use angularjs, and if you take full advantage of it, you always just send the user the same index.html page and the server has a bunch of JSON API endpoints. Then you let the client-side router take over.
If you really want to support JS-free users on your application, you're probably better of making a separate limited version of your application instead of having multiple fallbacks in the same page.
Well, you could also ask why do some developers choose to write applications that retrieve HTML but do not process Javascript?
If I recall correctly, for a while the links and elinks browsers experimented with processing Javascript but eventually if I'm not mistaken the developer decided to drop it in future versions.
Why? I do not remember but I know that he did offer an explanation.
I have always thought Javascript generally benefits web developers more than users. And this is not a quality inherent of the language, but it has to do with how this particular language is used in practice.
When I download someone else's C code, compile and run it, I generally have a rough idea of what that code is going to do.
When a "modern web browser" (=not a text-only one) runs any and all Javascript from any web resource, I generally have no clue what that code is going to do. These browsers will automatically load resources from many sources other the one hosting the page to which the user navigates. They will make numerous connections to other addresses (to retrieve "third-party resources") instead of just one to the address the user specifies. Often the Javascript code is coming from a third party. Imagine a pop-up asking for permission each time the browser wants to run Javascript code from somewhere. In the early days of browsers, if I recall correctly, you could require the browser to do this (and the same goes for accepting cookies). I never considered this practical back then and it is certainly not a solution that would be practical today.
And today, when the company that writes the "modern web browser" assures me that it will protect me from malicious Javascript, I have no clue what the "modern web browser" itself is going to do to try to accomplish that. Because I cannot easily compile the "modern web browser" myself. It is not meant to be compiled by users. There is a large amount of implied trust.
It's somewhat like downloading random Windows applications one finds on the www, installing them and running them. Do you trust that Microsoft or some anti-virus company will protect you? That is a tall order.
Whereas if you merely refrain from downloading and installing such programs, if you refrain from blindly opening attachments in email, then you avoid that risk.
By not running Javascript, the user avoids the risk of malicious Javascript, and may even avoid the need for a "modern web browser"... and thereby the high complexity (=higher risk of insecurity) that comes with it. Keeping the user safe from malicious Javascript is a tall order for any browser to fill.
All that said, if I the user can get the information I want from the www without having to run Javascript and hence a "modern web browser", then I will always choose the non-Javascript option simply because _it is often faster and more efficient_, regardless of any possible security benefits.
Thankfully, I rarely need the "modern web browser", even for webmail. It is true that Javascript is frequently an impediment that stands between the user and fast and efficient computing but in my experience it is rarely a show stopper for the user who disables it.
To answer the OP's question: No, as a developer, I do not think you should care. Javascript is a fun language and people will pay you to write in it. For the Javascript developer, life is good. Carry on.
As time wore on entire components were built with JS making them unusable with out it. I have some co-workers who want to move all logic back to the server side or at least provide fallbacks for non-JS users but I strongly oppose this. We have parts of our app that use google maps that would be completely unusable without JS and those parts are arguably the most important and central parts of our app.
They want to approach it as "Lets make as many parts usable without JS as we can" while my opinion is "If parts of the app absolutely require JS and are heavily used parts then why waste our time worry about people with JS disabled". Especially since a lot of the server-side only parts of the app could be greatly enhanced with JS. I should also mention that this web app is NOT public facing and is only used by our call center (which we control the browser, newest chrome) and various groups of people using our software which so far all have JS enabled.
I agree that a news website does not need to have JS-required pages for 99.999%+ of their content. If they are taking the time to enhance their site with JS then I believe they probably also have the time (and financial incentive) to make their sites work without JS. Web apps on the hand are a different story. Once you have a significant number of users it might make sense to invest the time in making a fallback or slimed down version (I'm thinking Google/Facebook/etc) but for most companies I don't think supporting a JS-disabled web is a good use of time.
I've seen this idea a number of times in this thread, it's far from true. The majority of advertising systems require JS. Without advertising, the news site has no income. As a result the internal discussion is going to be more like 'why waste any time at all to support the ~1% of users who will never generate any revenue'.
I highly recommend discussing the actual cause of whether or not stuff like this gets done: is it worth the time? Saying you can use a technique to help out a very small portion of users, therefore you should, lacks the nuance that (we observe) people need to make these choices.
I wouldn't use half of those websites if it wasn't for AdBlock, so it's no loss for them. I'm trying not to punish the other half for that.
That may well be the case, but I think people are too quick to conclude that.