JavaScript Disabled: Should I Care?(halls-of-valhalla.org)
halls-of-valhalla.org
JavaScript Disabled: Should I Care?
http://halls-of-valhalla.org/beta/articles/javascript-disabled-should-i-care,49/
15 comments
Nothing frustrates me more than opening a link to a news article or some other text-based medium, seeing all of the text render normally, and then getting redirected to a page telling me to enable Javascript.
I'd like people to start more readily differenciating between web apps and documents (dynamic or not). I think we're at the point where it's obvious that there is a difference between the two and it's just as obvious requiring JS for web apps is completely acceptable.
I think you are getting at an important distinction, but you're confused about what it actually is. The important question is, "What is the goal of this site? What is the best way to still meet that goal without JS?"
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.
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.
So look at the middle-ground in terms of functionality, then. If a feature cannot be provided without JS, then don't provide it to those who don't have JS and move on. If the feature is not critical to other parts of the app, don't make those other parts depend on it.
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 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
The problem is keeping your code DRY when you have a mixture of two languages and execution environments. Inevitably you will have to choose which frameworks you want to use , picking two heavyweight frameworks for client and server will inevitably mean that they fight for control of your application if you want to use both to the fullest because each provides their own router and templating etc. So you need to decide which is going to drive your application.
>heavyweight frameworks for client and server will inevitably mean that they fight for control of your application
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.
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.
Well, treat each feature the same way, really. Offering a less comfortable but still functional experience is precisely what "progressive enhancement" is about. I agree that for many projects, at some point, there is functionality that can't be reasonably made accessible without JS, given the constraints of the project. I do think that many people seem to be too quick to go there. I don't think we have any major disagreement.
[deleted]
I mostly agree, but would add that there seems to be a tendency to try and build a "full client-side application" out of things that needn't be one, which I think is a subtly different mistake than the one you were describing - which I would describe as "building a regular website as if it were a full client-side application".
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.
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).
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 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.
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.
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.
That is a miniscule number of websites though.
That is a miniscule number of websites though.
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.
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.
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.
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's rather rude to just show a white screen
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.
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.
"Why might JavaScript be unavailable even to users who have not disabled it?"
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.
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.
So true. I can understand that some sites cannot possibly provide any useful functionality without JS (e.g. Trello), but am extremely annoyed when I find simple news sites loading a ton of assets from various CDNs - in many cases, I cannot even read the article if I am forced to use an older browser like IE8 or a slow internet connection.
Yes, exactly. Funny thing is, with a terrible connection like the one I currently have, gmail is the sort of app I don't expect to work at all.. except that it does because it has a very powerful html-only (a la 1998-webmail) interface.
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.
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.
The latter is an argument against using any asset external to the page, CSS, images, anything. Unless you are looking at a network timeline in your mobile browser you don't really know what is taking so long to load.
A lot of assets don't get substantially in the way of most of the page's functionality when they are slow to load.
The whole starting point of this discussion was limited 3G bandwidth. Anything going through that pipe is necessarily holding up other stuff from loading. Potentially important other stuff.
I'll grant that this makes it an argument against those things. I don't see that it's an equally strong argument. In any case, you have to weigh the costs and benefits.
It's not an argument against using any of those assets. It's an argument against depending on them for your website to be usable.
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.
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.
I use Noscript and will usually enable JS at least temporarily for the main domain and a CDNA but often balk at a list of 10 TLDs that the page needs to load (particularly tracking and advertising sites). Sometimes I try to find the necessary ones and others I just move on.
"Why do some users choose to disable Javascript?"
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.
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.
One consideration remains: what shows up on the screen before JS goes to work. Otherwise you should probably fade in the contents as they're loading.
As always, depends what you're building. I work on a web app used by a small group of customers to do very valuable things, where requiring JS is a no-brainer. You probably shouldn't require it to show a simple news article or blog post, though.
Or if I put on my tin foil hat, I think the position of most content websites is that if you are consuming their content, but blocking javascript (and therefore their ads and trackers) then they actually want you to have a bad experience and not come back (they can't make any money off you).
...which is why I prefer extensions like AdBlock, Privacy Badger, etc. to disabling JavaScript: they cut out ad/tracker cruft without destroying my experience.
To be fair here's the opposite view: http://tomdale.net/2013/09/progressive-enhancement-is-dead/
Really great read. One interesting point:
"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.
"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.
Considering the number of javascript client/single web page apps out there, not having javascript is simply not an option. Because of the nature of the sites I've been building, there is no point to using if you don't enable javascript.
"Because of the nature of the sites I've been building, there is no point to using if you don't enable javascript."
That may well be the case, but I think people are too quick to conclude that.
That may well be the case, but I think people are too quick to conclude that.
Perhaps someone could run a directory of these sites there is no point in using? Then we can all be happier.
Yes, all those <form post/> base games were soooo much fun.
The article calls out <noscript> messages as a bad practice, but as someone who routinely runs without javascript enabled, I much prefer webpages to explicitly point out that the issue is on my end, not theirs (rather than, e.g., a white screen of death).
Needing noscript where you shouldn't is a bad practice. Lacking noscript where it's needed is breakage.
I think sacrificing functionality for 99% of users to accommodate 1% is sheer bloody mindedness.
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.
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 author provides a fully general argument for supporting IE 5, Lynx, semantic HTML, lack of minification, testing with the website readers for blind people, and internationalizing immediately.
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 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.
GOV.UK ran some stats on who wasn't running JavaScript and why:
https://gds.blog.gov.uk/2013/10/21/how-many-people-are-missi...
https://gds.blog.gov.uk/2013/10/21/how-many-people-are-missi...
For document-based websites, I go JS-free. My blog works without JS (except for comments, because they're from disqus and I'm lazy). And for public facing document websites it's usually possible to cache everything so it'll be REALLY fast.
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.
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.
I work on a web app that is half and half when it comes to depending on JS. The site started as MVC PHP app that was all server-side but over the years JS was added to do client-side validation and other UI/UX enhancements. In part because the customers asked for them and because something would have been extremely tedious and frustrating without JS+AJAX.
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.
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 agree that a news website does not need to have JS-required pages for 99.999%+ of their content.
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'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'.
You can still show ads with JS disabled at least some of the ads systems I have used have <noscript> tags following the JS include to show something still if JS is disabled. It's far less targeted for sure which in turn leads to less revenue from them. And I think it's fair for a free resource (This does not hold for news sites behind a paywall) to require JS so that they can make money off ads to in turn support the free viewing.
An alternate view is: If your site requires javascript (or cookies or registration) we don't use it. There are plenty of sites that work better with javascript, but are still fully or mostly functional without it. This is where you will find those of us who choose not to allow sites to run javacript in our browser. As an example, nytimes requires registration. The registration page is the extent of my interaction with their site. I turned to theguardian many years ago, and, while I value nytimes, I wouldn't be able to quantify any meaningful difference between the two.
I've always considered disabling javascript or using something like adblock to be bad form. Ads are annoying, but they're paying for the content I'm consuming.
This is a whole new discussion in itself, but I was shocked when I disabled AdBlock for a website I frequent and like, just to see that flashbanners that make the whole websites background (ie. whitespace I use to navigate) clickable still exist.
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.
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.
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.