How many users have JavaScript disabled? | Hacker News Reader

How many users have JavaScript disabled?

developer.yahoo.com

63 pointsbrandonkm73 comments

If you haven't got the experience, then yes, it's going to seem like two times the work. But I am a low vision user who disables JavaScript often because developers don't understand that jut because I stopped moving my mouse doesn't mean I want to see a popup definition of the word I hovered on which obscures my viewport. (I'm zoomed in now as I type this).

I'm saddend (and a little angry) at the number of developers here who absolutely insist it's so much extra work to build a site that doesn't require JavaScript. If you follow best practices, it's not a big deal. Web apps create, retrieve, update, and delete records. No matter how fancy your new startup's idea is, you have to realize that it's all the same task over and over again, and you can do that with simple web forms that don't require AJAX. A little unobtrusive JS to capture clicks, hide boring interfaces, and transform your dull non-JS interface can go a LONG way. Plus you can test that the underlying functionality of your site works very early.

I'm required by law (Section 508) to build accessible web sites at my day job. It's much easier to make Section 508 compliant websites without JS. Then we put the icing on the cake to satisfy the other 98% of our users.

(This is an academic point for me right now - I'm building an app in Facebook, and Facebook requires Javascript.)

It seems like your zoom software interacts badly with behaviour that's common on some websites. Disabling Javascript seems like a reasonable workaround, but not without cost. I'm curious - why are web developers the target of your aggravation, rather than the people who wrote your zoom software?

It seems to me that a lot of expensive accessibility software copes well with computing circa 1998. But then it hit a wall. Most of the advocacy and lobbying around this issue seems to focus on forcing most developers to adapt to the limitations of this accessibility software, rather than pressuring accessibility software vendors to provide software which (a) delivers innovation and utilizes advanced technology, as you'd expect in 2010 and (b) deals with common patterns in modern software development.

I am aggravated by the developers because developers are the ones who confuse interactions (clicks) with invitations to interact (hovers). When I move my mouse, my viewport moves. That's by design, as the mouse pointer can be placed near words so I can see it. Keeping the mouse pointer visible is important when you can't see it well.

Now imagine I'm surfing as a blind user, and I follow a link from HN, and my screen reader starts reading the page, only to be interrupted by a "take this survey" modal DIV. After a couple of times I'm turning off the JS, cos that's really annoying.

The people who make my zoom software make OSX (it's built into the operating system and it works amazingly well for me except for applications which fire events when I hover.

Following the principles of UJS and web standards makes it infinitely easier, in my experience, to develop web sites that work with screen readers and still use that advanced technology that everyone's gaga over. But if you can't write JS easily that works across multiple browsers, how do you ever expect assistive technology to be able to interpret it correctly? :)

The iPad doesn't have the concept of a hover, so websites pretty much have to work without it.

It'd be nice if Apple could turn around and kill the hover in Safari when somebody's using the zoom feature. It'd be even nicer if you could toggle this on and off right now (right Apple button, maybe?) because mouse hovering in the zoom application is obviously _not_ necessarily the same user action as mouse hovering without the zoom app.

"Take this survey" DIVs destroy usability for everybody :(

eh, from my experience the iPad does have "tap-to-hover" support which is pretty nice actually. Many hover-only events do work, even ones that haven't been written to support iOS-specific events. So they're doing something.

Just a note on this, you are taking issue with Javascript when in fact the issue is bad UX design.

No, I don't think I ever said JS was bad. I said I'm saddened by developers who use hovers, and by developers who think it's too hard to do non-JS versions of sites. I personally love using JS to improve the user experience. I think it's pretty damned cool because of the way I can use it to transform a very dull, cumbersome postback interface into something wonderful without nearly the effort that people claim it takes.

Yeah I am sorry, I was posting in response to the grandparent and somehow ended up replying to your post. This was in reference to the low vision individual who was arguing that hovers mess up their screen reader. I would delete the post but it would leave your comment hanging. So I will leave it, but it was not directed at you.

Speaking of webforms, how would you treat a webform that has a variable number of fields? The non-js way I've seen this treated is to have like 5 fields and then reload the page if they want more (i.e. multiple files uploads), but it seems like there's no non-icky way to do this sans JS.

I am open to suggestions :).

Recently, I had to implement that, and it came down to this: The multiple file upload functionality is an "icing" feature. We just set up the UI to upload one file at a time. Accessibility doesn't have to mean "it works the same". Reasonable alternatives are fine.

It obviously depends on 1) who your target audience is, and 2) what your website is.

If the target is HN type people I'm guessing the number of non-Javascript goes up.

If the website is pure information, why not provide it even to people who telnet to port 80?

But if the website is a rich interactive application, even if it could fall back on simple form submissions, I'd say it's fair that non-JS users sees a "This requires Javascript" message.

(my answer is very different if the "interactive application" was powered with something vendor/platform-specific)

I'm a NoScript user and generally only whitelist JS on sites I use all the time and trust. I'm not overly paranoid about security, but the experience on the web with NoScript is far superior than without it in my opinion. What drives me absolutely insane is when a website is 100% useless unless JS is whitelisted. That instantly gets put on my list of sites to never ever go to again.

Doesn't that depend on what the website is trying to achieve? Clearly there are plenty of sites out there whose functionality is necessarily dependant on JS. As long as they make clear that this is the case and what the website is supposed to do, is it all that bad if a website becomes otherwise useless without JS?

It's the sites that shouldn't depend on JS that irritate me. Sites that load completely static content, dynamically. Newspapers where you get a blank layout instead of an article. They're more common than you think. I don't mind temporarily whitelisting a site to play with some cool thing but if it's something that shouldn't require javascript at all, let alone need to degrade gracefully, I often just go somewhere else.

And then there's sites like this: http://partiallystapled.com/~gxti/trash/2010/10/09-javascrip...

There are very few sites with a relevant content that are really "necessarily dependant on JS." The worse the content is, or the more amateurish it is, the more probable is that the creator thinks that the "cool menus" are a good substitute for content. It was always so. MARQUEE and BLINK of 1996.

You can almost recognize who's mostly in charge for some site:

-- needs JavaScript only to bring me to another page: some bad "programmer" whose best achievement was that he learned JS.

-- needs Flash only to bring me to another page: some "decision maker" who wants "dynamic" or a "programmer" whose best achievement was that he learned Flash.

- needs a magnifying glass to read the text set in 5 pt font: some "designer" who doesn't care for the text anyway. But look how good colors he selected. And everybody has the same screen resolution as it's on his computer, got it?

-- needs a magnifying glass to read the text, the menus are half JS behind images, half Flash: you tell me, but there's higher chance it's made by a West European guy.

etc.

Yes, it does depend on what the site is trying to achieve. I should have been more clear and said that I can't stand when I am brought to a blank browser (not even a "You need javascript enabled" message). I guess it's not so much that I'm anti-javascript as I am completely anti-stupid web design.

I use NoScript mainly due to the prevalence of XSS attacks. If a website doesn't require me to enable javascript, even a trusted website, I wont. All it does is open you up to XSS attacks. Lets not forget that google, facebook, twitter, paypal, hotmail, yahoo and countless other big name websites have all fallen prey to these flaws, and will continue to fall prey to them.

I'm willing to open up to a very unlikely XSS attack in exchange of a better user experience.

Do you know many people who say: "I won't run C applications because they are vulnerable to buffer overflows."

I'm one of those who browse without JavaScript and Flash and for me that IS a better experience. Try it once and see how much better signal to noise ratio is. I also like the additional benefit of having much less chance to be attacked through the browser.

And I also use Opera, exactly because I can enable using the built in browser settings both JS and Flash only for a few sites where I need it (like youtube).

I have just checked again: I don't have JS turned on for HN. It just works.

Really? It does not work with noscript. I get a blank page when I attempt to vote.

You're right. The vote is counted, so I consider that as "works." The result is certainly ugly, but I'd name that a "minor display issue" as I can hit "back."

Of course it would be nice if that "back" step wouldn't be needed.

Yes, that is very annoying. It should just send you back to the page you were already on and to the position on the page where the comment you clicked is.

You could probably also do some clever trick with checkboxes, the css3 :checked pseudo class, and background images to make it work without javascript and without page refreshes. Browser support isn't going to be great atm though.

I would expect that it can be reasonably easy fix (a few lines on the right places) to simply deliver some sane content as the result of the vote HTML query.

Shouldn't the referrer tag from the query be enough?

> Do you know many people who say: "I won't run C applications because they are vulnerable to buffer overflows."

Unless your C program takes in input from advertisers and posts from people on the internet, I don't think that's a valid comparison.

Also, you say "very unlikely" but these attacks happen all the time. Most of them don't make the news, but they're pretty much an every day affair.

You've made the mistake of thinking that turning on javascript gives you a better user experience. On most websites, it degrades the experience. On those where I see no worthwhile improvement, I don't enable it. It's a judgement call.

Very few websites give you a substantial improvement in user experience by enabling javascript.

That's 2% I could do without, no problem.

Explain that to a potential investor. "We snubbed 2% of our potential user base because we were too lazy to make sure that our site degrades gracefully." From the article, that's _6 million_ of Yahoo!'s 300M+ user base.

I really don't understand what's the big deal about making sure your site works without JS, it's just some extra work that you're going to have to do anyway later down the line (and it will be more complex then).

We were too lazy to spend at least twice the time creating the product.

Shorter version: 2x more work does not justify 2%

It's potentially a lot of extra work. If your site's UI is heavy on the AJAX, a non-JS option basically means writing a completely separate UI.

Explain to an investor, "We don't have features X, Y, and Z, which our competitors have, because we were spending time maintaining the non-JS version for 2% of our user base.".

Also, non-Javascript Luddism may correlate with other forms of Luddism. For example, non-eCommerce Luddism or non-ads-clicking Luddism. So it might be that you're doing all that work for people who are not going to benefit your bottom line as much as the typical user.

It's something each business probably has to measure for itself, but the people saying, "I don't see what the big deal is," just aren't looking hard enough.

I don't think Luddites are savvy enough to figure out how to disable JavaScript, and most of the people who disable JavaScript are probably at the opposite end of the spectrum: people who know the privacy and security risks of JavaScript, and who would rather a website be obviously broken on the first visit than have it be subversively annoying and ad-laden.

If an e-commerce site won't let me get to their product list and see prices without cookies and Javascript, I won't buy from them if there are alternatives. There's no real justification for making a simple online store 100% AJAX for even the most basic features, so the sites that do that don't get my money. (They probably don't do to well from an SEO perspective, either.)

Blogs that require cookies and JavaScript before they'll show their content are obviously more concerned with spamming me than being of use to me, so they also get closed immediately.

If your web page is a simple marketing site, blog, or e-store, then I completely agree.

But if your web page is a complex application, having to support no-JS either shuts you out from from a huge set of interface tools, or forces you to maintain two interfaces in tandem. To me, 2% doesn't justify that, particularly when you can just politely inform the user that their browser has a significant feature disabled, and inform them how they can remedy the situation so that your site works.

Even if your users have JavaScript enabled, they still need to download and run it before using your complex application.

Consider GMail. How awesome would it be if you didn't have to wait for its "Loading..." progress bar? It takes 2-4 seconds for that to go away on my computer. If you design for progressive enhancement, you can interact immediately and when JS is ready, it simply enhances what's already there. If done right, it's all the same interface.

If you don't mind waiting, your users may not agree: Google and Amazon both have noted significant losses in revenue at page delays much shorter than 2 seconds.

> Consider GMail. How awesome would it be if you didn't have to wait for its "Loading..." progress bar?

Well, taking a look at "Basic HTML view"... considerably less awesome.

My point was that Google solves this problem the wrong way.

Instead of making two interfaces, they should make one interface. If JavaScript hasn't loaded yet (or if it's disabled), the majority of the interface can still be available immediately.

JavaScript should always add to the experience. It doesn't make sense to show GMail's Chat widget until JS is loaded-- but it really doesn't make sense to show nothing at all until the Chat JS downloads and runs!

You should be able to show the message list right away. You can start scanning your messages immediately. You can click normal links and submit forms.

Bonus for JS enabled users: a few seconds later the links, buttons, etc. all get hooked up to JavaScript. The Chat widget appears. By the time you click, things may even happen all AJAXy-- and it appeared to load instantly by loading JS in the background.

Now that's awesome.

But what about features that _need_ JS to work? Should they be in the interface until the JS loads and they work? Then when I try to use them in the first few seconds, they're broken. If they're added afterwards, they just pop into existence...

I don't mind waiting the second or two.

No. Those features should not be in the HTML markup if they are bonuses that require JavaScript. At least, they must be hidden until its script loads. But you shouldn't have to hide everything.

I'm pretty happy browsers don't show a big "Loading..." message until everything is loaded instead of painting the page as soon as possible. Shouldn't we be avoiding that too?

The bulk of that interface can be progressively enhanced.

For example, the message list and side navigation can be normal links. When JS comes along, they get actions (show this view, show this message) that override the default actions of those links (navigate to the page /message_view?id=foo).

If you try to use them in those first few seconds, they act as normal links-- they aren't broken, they just weren't enhanced yet. You can start using the page faster.

I agree with you and the posters below that you can't develop two versions. But I'd like to point out that "it doesn't work because JS is disabled" versus "it's not pretty because JS is disabled" are two different things, and they are not mutually exclusive. There are a slew of sites that work without JS even though they depend on it for "fancy" stuff. Plus you don't have to support two different sites in tandem, it's not exactly 100% more work. For example, instead of an AJAX call (which returns content), display the content in a new page, i.e. Slashdot's comment system -- when JS is turned off, clicking on a comment opens it up in a new page.

You're overlooking a lot of powerful applications that need SOMEthing to work client-side. Markup.io, recently featured here, is not the sort of application that can post-through to another page to fix. One could argue that it might also work with Flash, or ActiveX, but I'm only even mentioning them to head off somebody else from doing so, as that's hardly a solution.

I suppose it could be implemented as an Applet, but what's important is that Markup.io is exactly the sort of thing that Javascript exists for, really. And yes, disabling JS will break it, completely, and yes, I think that's perfectly forgivable.

On the whole, I agree that my blog should degrade, and data-entry type applications should work as well, but saying that everything should is completely overlooking an entire category of application for which it's perfectly acceptable, in my opinion.

Ok, good point. My problem is sites where it is reasonable to expect them to work without JS, but end up not working at all. I would never expect a specialized site like Markup.io or asteroids-on-a-page (forgot the name) to work without JS. News sites, portals, blogs, shopping sites, etc, are all fair game for no JS (like you said).

By the way, not sure if you're the author of Markup.io, but it's pretty cool.

Oh, no I'm not even remotely connected to it, it was just the first example that came to mind.

It is pretty cool though.

Markup.io isn't actually a part of the world-wide web of linked semantic documents. Its content is inaccessible (even for viewing) unless you blindly trust its code. It rightfully deserves to be a browser plugin, it's just cleverly smuggling itself into everyone else's content because there are no good portable extension mechanisms for browsers.

> because there are no good portable extension mechanisms for browsers.

...which is why JS is filling that gap. :)

Try explaining to a potential investor: "We lost the market because we were busy making sure the last 2% of potential customers could use the site".

2%? Is that supposed to sound significant? I'm sure Yahoo would be doing fine, give or take 6 million users.

"I really don't understand what's the big deal about making sure your site works without JS"

It's worth reminding ourselves that the business and technical constraints of different web applications vary widely and so strategies will also vary widely.

For example, if you are building a greenfield app and your purpose is to try to search for a product/market fit, it generally doesn't make sense to optimize for the 2% of non-js users yet. You haven't yet found a steady source of revenue meaning that (1) you probably can't afford the extra effort and (2) your app's features are likely going to change drastically.

Tell that to facebook (http://i.imgur.com/9FdJa.png) :-).

The problem with bending over backwards for non-js is that you double your dev cycles (no AJAX, need regular forms for everything), lose dynamic menus (want to duplicate those?), lose a ton of instrumentation you may be doing, etc.

I think it's perfectly fine to say "non-js means you have a read-only experience". Even facebook doesn't go that far -- you can't even log in without js enabled! (And they're definitely in the camp of 2% * 500M).

What will people do who have js disabled? They'll get a tech friend to help, because that disabling was probably a misconfiguration :).

At some point you have to prioritize your time to work on the features that help 95% of your users.

Facebook caters for non js people by directing them to the cut down mobile version of the site. Which is not a perfect solution, but it is much much better than simply telling them to go away.

The problem with bending over backwards for non-js is that you double your dev cycles

I would think you are being generous. A marked advantage of JS based RIA is rapid time to market, it is a simpler development model that provides superior usability when done correctly. The old page post model is a considerably slower development model. Hence all the server side frameworks, people have been trying to crack that nut, in the page post model, since someone bolted up CGI POST to a script and spit out some dynamic HTML.

It might not be laziness that you don't support that 2%. It costs real time and money to add and support fallback content and functionality. There could be better uses of that time and money that create more value for the business...which is something your investors should understand.

Explain that to a potential investor.

We snubbed 2% of our potential user base and reinvested the money we saved in increasing the conversion rate of the 98%. Further we are going to use some of that money to chase additional revenue streams. If we exploit all available revenue models and hit a wall with upping the conversion rate, we will look at creating a separate none JS version of the site with reduced functionality, so that the two distinctive development models are not intertwined therefore reducing out maintenance burden.

The follow-up question is "Why users disable JS?".

How many do it unintentional because they think JS is Java(applets ...), or the browser does not support it.

I'm also wondering how many people change the advanced JS settings in the browser (do browser other than Firefox even support them?).

I'm one of those 2% for different reasons(open for discussion): - it blocks 90% of ads, because most banners are JS driven - I consider JS as a privacy and security vulnerability - disabled JS saves bandwidth

It never takes more than 2 seconds to get an idea if a page does work without JS, and another 2 seconds to decide if it is worth it to enable JS.

I'd reckon that most of them are FOSS weenies and/or security paranoid. At least, that's the common thread among my peers who disable JS as a matter of principle. They are proud of it, and they are happy to find a reason (like requiring JS) to snub your web app.

Then there are the NoScript people, who are willing to whitelist your site to allow JS if they think there is value in it. These people skew the numbers but are pretty reasonable when it comes to turning JS on.

I'm one of those NoScript users. Most sites get temporary permissions if they actually need them for something I want to do, trusted sites get whitelisted if I visit them often enough.

Pretty much all of the attacks against Mozilla that might have actually affected me have been mitigated to some extent by NoScript, so it's pretty useful.

Paranoid is assuming attackers are out to get you. I just assume attackers are abusing automation and out to get everyone, because we have already seen that happen several times, and there's no reason to believe javascript sandboxes are suddenly flawless despite their disappointing history.

I also have scripting off because I tend to be curious about the diligence and talent of the authors at a site.

FFS, use Adblock You are so fuckin wrong, JS is not a security vulnerability it's a programing language.

Wikipedia: JavaScript is an implementation of the ECMAScript language standard and is typically used to enable programmatic access to computational objects within a host environment.

If you want real privacy, then why not just disable cookies? ohhh your login won't work... well then just disable your internet connection then.

Disabling JS wastes bandwidth because you can't do partial page replacements. OMG so much stupidity.

Edit: So many downvoting trolls. Edit #2: Even more trolls who can't even leave a reply.

Your post was poorly reasoned, and quoting Wikipedia was frivolous. Furthermore, it was written in a way that's grating for many people, regardless of your (poorly reasoned) points, because it

a) reinforces the notion that you didn't care enough about your message to spend 15 seconds longer on it to write it properly, a feeling which already existed in readers' minds because of the presence of your (poorly reasoned) points, and

b) requires readers to spend longer parsing your comment before being able to comprehend the (poorly reasoned) points you were attempting to make.

The comment I was replying to was even more poorly reasoned. And I actually written a larger post regarding this.

I'm one of those 2% for different reasons(open for discussion): - it blocks 90% of ads, because most banners are JS driven ... disabled JS saves bandwidth

These are my usual reasons. I've run into a lot of sites with orders of magnitude more ads, fluff, formatting scripts, etc. than they have content (e.g. thereifixedit and related sites typically take me a full minute to load with JavaScript and often under a second without). I don't make much effort to block ads that don't make the page load much slower.

NoScript has 74,459,688 downloads so far (https://addons.mozilla.org/en-US/firefox/addon/722/). You'd have to do some calculations with this to get closer to a real user number, though ;)

I'd wager that the average NoScript user has at least two machines, so the total number of NoScript users is probably less than 2.7 million. (http://blog.brandonbloom.name/2010/06/noscript-add-on-instal...)

I'm also guessing the majority of NoScript users have exceptions whitelisted for many trusted sites, given how many sites are completely useless without JS.

Yes, and I happen to have Yahoo! sites on my whitelist, which tells me that their stat is not reliable. The actual percent of users who block JavaScript may be higher, given selective blocking, as provided by Opera and Firefox's NoScript.

If your website relies on JavaScript to work, then you're excluding people who can't use JavaScript. Disabled people with screen readers.

If you don't cater for those people, put some money aside for lawyers.

I'm not sure why this was downvoted. While his remark about lawyering up may be overkill (unless you work for a federal agency and have to abide by Section 508 rules), his point about excluding those who rely on screen readers is dead on.

I've found that one of the major complaints that blind users have is that it's a total bitch to work with dynamically updating pages. If more developers paid attention to web accessibility, a lot of the major problems to disabled folks would be greatly alleviated.

http://en.wikipedia.org/wiki/Web_Accessibility_Initiative http://en.wikipedia.org/wiki/Web_Content_Accessibility_Guide... http://en.wikipedia.org/wiki/Section_508_Amendment_to_the_Re...

I say this as a visually impaired developer with several blind friends and family. To me, web accessibility is serious business.

This is a straw man argument that is not grounded in fact:

http://www.dojotoolkit.org/reference-guide/dijit-a11y-statem...

I have built many sites with the specific criteria that it work with JAWS. I do not use Server Side web frameworks and my UI logic is implemented entirely in JavaScript. I am an authority in the usability and accessibility field and am hired as such by many of the big boys. JavaScript has nothing to do with accessibility and in fact can be used to increase usability for the disabled. People confuse JavaScript with bad UX design that hinders accessibility.

You'll forgive me if I listen to a combination of common sense, and the guy who said "I say this as a visually impaired developer with several blind friends and family" instead of the guy with a vested interest.

Sure I will forgive you, but I will also note that again this is a case of blaming Javascript for bad UX design. The evidence is in his post. I just highlighted it.

Could the argument be made that the minority who surf with Javascript disabled don't necessarily have to be catered to, since they will enable Javascript if they trust the site or find it useful?

There may be lots of reasons to disable javascript or not have it available at all such as security policies, bandwidth restrictions, limited hardware devices or other things you haven't anticipated.

I think it depends on what content you're providing and which users you want to reach.

I've seen text-only blogs that involve javascript in their visual design and cannot be read without it. I've also seen websites where the site navigation links are rendered by javascript. In both cases the sites are inaccessible to non-javascript users.

In my opinion if you can provide the same content without requiring active scripting, you should. If you're providing an interactive experience that can't be achieved without scripting at least be aware that you're limiting your user base. Even if users have scripting available but disabled by choice, they may decide that your content is not worth enabling scripting for.

I'm also concerned that technical users who disable javascript by choice might not frequent a site like "yahoo" as much as non-technical users. I'm curious if a more neutral but still popular site would have a larger percentage of non-javascript visitors.

Very good response, I agree that the base functionality should exist without Javascript, and I would assume that most who disable it are willing to forego bells and whistles, but will still use your site if the basics work. This also ties into best practices of having Javascript which degrades properly.

"Could the argument be made that the minority who surf with Javascript disabled don't necessarily have to be catered to, since they will enable Javascript if they trust the site or find it useful?"

That's certainly true for me. I don't care that a site requires scripting, but I do care when there's nothing to indicate that I'd be better off if I allowed javascript.

This is especially true for sites that let a user begin some set of actions (write a lengthy comment, or fill out a multi-step form), and then simply fail at the end because scripting is disabled.

It is trivial to add a "This site requires JavaScript" message. Leaving it out says you either don't give a shit or don't know what you're doing.

But how many of those 6 million are bots and scripts like mechanize scraping the site?

From the article:

"We took a combination of access logs and beacon data (previously included in the page) and filtered out all of the automated requests, leaving us with a set of requests we could confirm were sent by actual users."

Reply on news.ycombinator.com