

JavaScript Disabled: Should I Care? - lemonberry
http://halls-of-valhalla.org/beta/articles/javascript-disabled-should-i-care,49/

======
eric_bullington
I think it's critical here to distinguish between full client-side application
(e.g., gmail) and an informational web site (e.g., a news site, a blog, or
code documentation). It's a bad idea to require Javascript for the latter, but
it's equally silly to try to build a fully-responsive client application using
no Javascript, or progressive enhancement.

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.

~~~
dllthomas
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".

~~~
themartorana
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.

~~~
agwa
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.

~~~
seanp2k2
> 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).

~~~
dllthomas
_" 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.

------
dubcanada
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.

------
scrollaway
"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.

~~~
serve_yay
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.

~~~
dllthomas
A lot of assets don't get substantially in the way of most of the page's
functionality when they are slow to load.

~~~
serve_yay
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.

~~~
dllthomas
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.

------
matteodepalo
To be fair here's the opposite view: [http://tomdale.net/2013/09/progressive-
enhancement-is-dead/](http://tomdale.net/2013/09/progressive-enhancement-is-
dead/)

~~~
ianlevesque
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.

------
joelanman
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-missing-out-
on-javascript-enhancement/)

------
lcampbell
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).

~~~
drvortex
Honest Question: What circumstances force you to browse without Javascript?

It feels a little like running a car constantly in first gear. It is going to
be a guaranteed sub-optimal experience.

~~~
cgar
Security, privacy, and bandwidth.

------
TheAceOfHearts
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.

------
ised
"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.

------
joshstrange
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.

~~~
mbell
> 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'.

~~~
joshstrange
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.

------
erkose
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.

------
hawkice
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.

------
drabiega
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.

~~~
MildlySerious
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.

------
serve_yay
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.

~~~
jdjb
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).

~~~
candu
...which is why I prefer extensions like AdBlock, Privacy Badger, etc. to
disabling JavaScript: they cut out ad/tracker cruft without destroying my
experience.

------
unclebunkers
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.

~~~
adricnet
Perhaps someone could run a directory of these sites there is no point in
using? Then we can all be happier.

~~~
unclebunkers
Yes, all those <form post/> base games were soooo much fun.

------
EGreg
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.

