When designing a website with javascript, what is the need to test the website with javascript turned off? I’ve read this a few times, that a website should work when javascript is not available on the browser (for some reason). Who does this, on what percentage, and why?
I understand there are some security concerns, and tools like NoScript disable scripting… but you do expect dynamic sites to break if you cripple the browser, it’s normal. Why would a javascript programmer worry about these corner cases?
My computer at work is old and utterly rubbish. Any time it comes across jQuery, particularly those rotating images but plenty of other things as well, it completely freezes for at least a minute and sometimes five. So apart from a handful of sites where I need JS for them to work properly and fully, and where I know that they haven’t got any nasty resource-hogging bloat that is going to kill my computer, I generally browse with JS turned off. I’m sure I’m not the only person who does this.
Also consider that mobile devices may have more limited support for JS (or, where there’s an option, people may disable JS to preserve battery life, because too much client-side processing absolutely hammers the battery), and search engines have quite limited JS capabilities so may struggle to index your site if you require JS to access parts of the site.
I accept that there are some things that I may not be able to do without JS and that’s fine, but equally I expect that basic functions that can easily be delivered purely through HTML+CSS will be, and that I won’t be blocked from accessing those basic elements of a site.[/font]
Mainly I surf with JS disabled for various reasons and within the UK it is a legal requirement that commissioned websites can still have core functionally without client-side scripting within ‘reasonable adjustment’.
A web author should apply Separation of Concerns and Progressive Enhancement theories. The browser can be used to disable/enable JS, some people don’t have the option.
I suspect many people here have either adblockers or selective script blocking within their browser either native or addons. Whether or not they use it is their discretion but I guess its well over 95% even if it were 1% the small percentages of big numbers are also big numbers!
I have it turned off for any site that either uses huge JavaScript code for minor results or where the scripts are generally broken and cause the page not to work. This means that most of Google is on my JavaScript off list as well as all repositories for jQuery and other frameworks.
As noted above, there are various reasons why people may have JS turned off. (I tend to disable it when traveling to conserve bandwidth.) Sometimes, heavy JS is just plain annoying and makes a page inaccessible. Often natural browser bahaviors are messed up by too much JS, like tabbing, and I’ll turn it off to make the page easier to navigate. Also consider blind folks with screen readers who can’t avail themselves of all the JS functionality—so it’s important to make sure they have access to some kind of content.
The bottom line is: users can turn off JS, or may not have access to it in the first place, so you can’t assume they have it. Thus, a good design will take into account that it may not exist, and make the JS strictly an enhancement layer. That’s just basic good practice in web design—progressive enhancement and all that. It’s not like PHP, where you have control over the server and thus know that PHP can run.
It really depends on the app/site. A lot of web apps I build don’t make sense without the presence of js so I don’t worry about it. It’s a regular site when there’s no need for js to function there’s… no need for js.
It can be a nice enhancement, even if it’s not “needed”. The sad thing is when even basic content is not available without JS. I see that a lot, and it’s kind of incredible that people do that, IMHO—not just for accessibility reasons, but even in terms of SEO.
Not quite as common but something I have seen is web pages where the JavaScript is so badly written that it only works in some browsers (possibly only the one the author used at the time they wrote it) and the only way to interact with the page at all without trying to guess which browser it works with is to turn JavaScript off.
And what happens now that CSS is taking steps forward in client-side processing, including demanding tasks like animations etc? In fact because CSS is faster for animations, JS may be used less for that kind of stuff in the future.
JS can be used to query the client browser’s capabilities and adjust the HTML accordingly (e.g. Modernizr) to load only the appropriate content (saving bandwidth and CPU power). CSS by itself is not very good at this so we may end up hurting performance without JS.
So, disabling JS for better performance may not be a good idea in some cases, more so in the future.
[font=verdana]We’re on IE8. I’m not an expert on the fancy stuff, but I get the impression that to get CSS animations working in IE8 requires the use of Javascript, so it isn’t really a whole lot different. If CSS can make it run with a lower processor load than jQuery then that’s great. But it’s going to be a long time before that is commonplace out there on the wild web.
JS can be used to query the client browser’s capabilities and adjust the HTML accordingly (e.g. Modernizr) to load only the appropriate content (saving bandwidth and CPU power). CSS by itself is not very good at this so we may end up hurting performance without JS.
So, disabling JS for better performance may not be a good idea in some cases, more so in the future.
Interesting idea, but realistically, how many people are using Javascript to benefit low-power users? The overwhelming majority of JS out there is being used to say “Look, isn’t it so cool that I can do this”, and in a heck of a lot of cases the author doesn’t have a clue why it might not be a good idea or why there might be a better way of doing it.
There may be times when having JS turned off makes a site run slower, but since I started turning it off for general browsing, I’ve not yet come across a page that completely killed the computer, whereas before it was a regular occurrence.[/font]
I have it always turned off for security reasons, using NoScript. And I only activate if I trust the site AND really need it for full functionality (and I get totally annoyed, when a page is not even basically readable without JS turned on).
Less than 5% of the visitors of my website have JS turned off, but I don’t want to keep 4-5% of potential customers out, so the complete site is designed to be viewable without JS.
I always have JS turned on, i want to enjoy fully the websites im on, its hard to believe that some users have it turned off. Indeed some codes are hard on the PC and even freezes your browser sometimes, but that`s thanks to bad coders i guess.
Yes, I suspect one of the reasons we sometimes surf with JavaScript disabled is so we can enjoy websites without getting the effects of badly implemented JS as has been one consensus - see various posts above. Several times it has prevented me from being attacked from some random compromised sites that had miscreants interfering.
It is to be expected many of the people on SPF will be tech-savy so will know some dangers of badly written scripts and possibly be more aware that they can control their surfing experience a little via browser settings or addons, with regards to adverts and client-side scripts, etc. Though of course the majority of mainstream browser obviously have simple defences to selectively block JavaScript as default, e.g. pop-up-blockers, in place regardless of whether the user is aware of scripting.
I’d agree with Stevie over that fact; on weak machines or slow connections sloppy and excessive/unnecessary overuse of JavaScript can seriously cripple page loading attempts/times - seen that far too many times, I’ve even got the t-shirt.
One of the main culprits for sites that don’t work properly because of badly written JavaScript are the varios sites belonging to Google. From the look of their JavaScript code the staff they employ to write the JavaScript have no JavaScript knowledge whatsoever and just patch together whatever badly written pieces of code that they find that look like they might work. I guess it does work for people who haven’t touched any of their browser settings but as soon as you make even the slightest change to how your browser is configured their scripts break. They also break if you use a browser other than one of the three that they specifically test for in their 17th Century browser detection scripts (which were definitely obsolete by the 18th Century).
Anyway, the average web user is most likely to get annoyed at specific scripts and either turn JavaScript off completely for all sites (since it isn’t so obvious that you can actually do it on a site by site basis) or they will install an extension into their browser that blocks specific JavaScript functionality (an early example was popup blockers) so that even with JavaScript enabled the entire script in the page may not work.
I have never seen any statistics on how many people block part of JavaScript in web pages but who don’t have it completely blocked.
Also consider blind folks with screen readers who can’t avail themselves of all the JS functionality—so it’s important to make sure they have access to some kind of content.
They can avail themselves of almost all JS functionality.
The biggest issues facing AT (accessibility technology) and JS are these:
AT is usually not nicely free or cheap like browsers are, so upgrading AT isn’t like upgrading a browser-- it often costs mooooola. So unlike with browsers, it may be more likely that users with AT are using old AT. However it would also be true that old AT requires old browsers, so if you know you’re serving a particularly high number of general AT users, then likely that’s where your higher-than-normal percentage of IE6 is really coming from. I think developers just have to draw a line somewhere and decide what they will support, but less flippantly than they do with non-AT users still sitting on IE6.
The new interaction thingies every dev and his dog want to do often require the building of widgets. A widget in poes-speak is something you build out of silly HTML (like divs and spans) in order to create something which does not actually exist in HTML. Basically, HTML is a markup language designed for documents, and therefore is missing a lot when it comes to building applications. AT is trying to keep up with these widgets but it’s hard when most of the things built are completely custom.
ARIA is one answer to the not-so-custom parts of widgets. A lot of widgets are recreating the same basic application thingies: modal dialog windows, form selection sliders, progress bars and boxes that update via message protocols or push notifications. So you can label a lot of these creations with ARIA to give some meaning to the browsers’ accessibility layers which helps a lot. But there are places where the spec hasn’t settled, the browsers don’t or mis-understand some states, or the AT has not kept up.
Lots of devs don’t bother, for example, testing that lightboxy Javascript modal window with a keyboard. They get their panties in a twist when they realise the user can actually just keep tabbing around on the page below (and while a sighted AT user or regular keyboard user would realise something went wrong, a full screen reader user would not. The page would seem normal and the dialog they clicked would just seem like a link that didn’t do anything).[/ot]
Back to the topic:
The percentages are getting low enough that, if you are not getting a hundred bazillion gazillion pathilizillion users per second (like Google, facewaste, amazon etc get), that 2% will never make a business case for you or your clients. What the percentage of permanently disabled-javascript users is, will not make you change how you build or how you test. Even knowing why probably won’t, because the other 99.999999% of users have JS on because they have no clue anyway. Chances are, those people don’t really know the difference between a browser and teh interwebs anyway. Those who’ve answered in this thread are possibly all your JS-off users (plus me).
The (main) reason to test your site (and maybe also application) with Javascript off is to make sure you’re not writing garbage in the first place. To see that you aren’t actually replacing built-in browser and OS functions with never-quite-as-good Javascript. You replaced a <select> with a <span> and Javascripted it into a fake-select that now matches the Design Guru’s colour scheme? Great, but now you have to add in the accessibility roles by hand (usually passed on by the browser to AT automatically for you), all the multiple device interactions the OS did for you (like, can we type a single letter and jump to that option? Do arrows work? Tab? Spacebar? What about touch devices, speech-to-text, and whatever other device someone’s computer supports?). Frankly, I expect anyone calling themselves a good developer to have tested all sorts of things when they make a decision like this. Most devs seem to be doing it lightly, without thinking: Hey I heard jQuery’s got this form thing so we can make pretty forms now and make those graphics weenies happy! Yay! No second thoughts, no testing, because being a developer for some people means copy-pasta.
Most Javascript implementations of OS and browser things are poor imitations. The exception to this is sometimes a very well-built (and therefore necessarily large!) framework may have been created by folks as good as the developers of OSes like OSX or Windows. They are usually UI gurus and hardware junkies. Or they used to work for browser or OS vendors. Or they will very soon
Are you replacing perfectly-good working HTML+HTTP for your forms? Turning Javascript off and testing shows you that you did, indeed, do such a silly thing, instead of doing Hijax (building in the defaults that have worked for over a decade and then using Javascript to hijack and change those defaults).
Are you replacing Berners-Lee-Approved-Hyperlinks with something else for the lulz?. Think long and hard about why the benefits of replacing default browser behaviour are just so freaking awesome you can’t refuse. Then think about your backup plan for when it breaks. Build defensively. Assume your clients are attackers. Assume your Javascript is filled with bugs. Assume some browser out there hates you.
Does your page suddenly load three times as fast with Javascript turned off? That’s a big sign right there you’re wasting too much time requesting things, loading too much, using one of those single-line-of-codes-which-call-3rd-and-4th-parties-with-millions-of-lines-of-code and probably edging into territory better left to HTML and CSS.
Is your page completely blank and 100% or 90% useless without Javascript? If so, you are either
recreating something like GoogleDocs
or
Javascripting way too much. Possibly also relying way too much on someone else’s servers if most of your JS is for displaying ads, spacewaste Like buttons and ShareThis junk.
I’m constantly amazed at how empty many web pages are (web pages who are presented as DOCUMENTS, not applications, like say, news sites) when Javascript is off. No comments, no videos, no pictures (and blissfully no ads).
The other big reason to test your page without Javascript is to be fully aware of the experience anyone visiting will get when $hit Goes Horribly Wrong. Don’t kid yourself: if you’re importing code from another server (facewaste code, jquery, google, ads) you’re not only a target for any hacks (on those other servers, not necessarily you at all), you’re also a victim of any screwups on their end. When they update that script you import, you’re allowing them “update access” to Your Stuff.
I understand there are some security concerns, and tools like NoScript disable scripting… but you do expect dynamic sites to break if you cripple the browser, it’s normal. Why would a javascript programmer worry about these corner cases?
It’s not that a full-blown web application is not expected to die horribly when Javascript malfunctions. Nobody expects to see anything at all if you’re trying to access a GoogleDoc without JS. Nobody expects Twitter to work without JS (even though the basic principle of it would work just fine with old-fashioned HTTP and HTML and a huge-a$$ server group).
Users of plugins like NoScript can selectively block scripts by domain, subdomain, etc. Sites who are, for example, built with dependence on Google AdWords (where if the AdWords don’t run, none of the site scripts run either) may be broken because someone is blocking one external thing (NoScript specifically works around this, but I wouldn’t expect all blockers to do this).
Always ask yourself: are you building a basecamp? Are you making a real APPLICATION? Is what you’re building on the scale of, say, a mail client? Live collaborative document editor? Audio or video editor? Drawing on the screen to turn your tablet PC into a real drawing tablet? Is it expected to be able to reach deep into the device its viewed on and use its stuff like the camera or the filesystem? Answer that question honestly, and then think about how you’ll do your backup plan. If you b0rk a script, where you will send users until you fix it? What will they still be able to do?
When people say “You should test your site with Javascript off”, it’s hopefully part of a bunch of shoulds. You should also test your Javascript broken. Break it. Break stuff on your page. Let half of it load… what do you get?
Make your grandma use your page/app/thing and see how long it takes her to break it.
Testing with JS off is just something a good, consciencious developer does. They also test with images off, CSS off, with an imitation of butt-slow internets, with crappy colours for colourblindness, on multiple input and output devices… it’s just part of that Stuff Good/Excellent Developers Do. Not necessarily because 4 people on SitePoint forums block it. That’s a silly reason. The reason to do it is because testing your site instead of assumptions is good.
See, there’s usually a pretty big difference between users who want to “experience” or “enjoy” a website, and people who are visiting a site to Get Stuff Done. If I’m trying to get something done, rather than trying to be entertained, I don’t want shiny uselessness slowing me down.
If I’m on the web for relaxation and want to “enjoy” a website, that’s a whole different ballgame. Then I want everything to run.
I’ve never turned off JavaScript unless I feel like testing a site or determining practicality of scrapping. I work for a newspaper and I can tell you straight that none of our main sites function without JavaScript. Maybe sad but it is a reality. Doesn’t seem to impact our ad sales or audience otherwise we would hear about it. For most things the web is a privilege. Being a privilege means it doesn’t have to work for everyone. I mean if you are using an out of date browser or choose not to use JavaScript, fine but there are consequences. People can say all they want about this being “bad development” but fact of the matter is people making these decisions wok for some of the largest companies around. Bad developers or not I would be happy succumbing to these “bad practices” and working for some of the top companies in the industry. At the end of the day it is all about the dollar anyway. Again, we an’t going to kill anyone. I’m just really done fighting about these things. To many of the big players have already made an obvious stance. So I’m going to conserve my energy for other things. At least when it comes to work performed at my day job. That is the way I’ve been now for a little over the year. Some battles just aren’t worth fighting.
You don’t know that for sure. There are many sites that convey critical info, like disaster warnings. Imagine if that info was only served by JS … and the site was under heavy load because of a spike in traffic … and the content was not loading properly because of all the unnecessary server calls … or the user could only access the site with assistive technology that couldn’t read the JS-controlled content …
There’s no good reason to abandon the basics of the web just to offer up a fancier experience (which I doubt most people want anyway. As poes said, it’s usually getting something done, or getting some info, that is the goal.) It may be that many users have already determined that your newspaper site is not a good place for them to go for news because it’s inaccessible … so you’d be largely unaware that a potential audience has gone somewhere else. The national news service I use works well with JS off, yet it’s a nice looking site.
(plus me).