Is it Now Acceptable to Require JavaScript?
mondaybynoon.com
mondaybynoon.com
The only reason it wasn't acceptable to require Javascript many years ago is because each implementation was so different that it was impossible to guarantee cross-compatibility. If you used JS, it would almost certainly mean that you would render your site useless to a significant group of your users.
Those times are over; Javascript is so consistent across browsers that it's extremely rare to see cross-browser issues unless you're on the cutting edge of web development. And those implementations are converging, so these problems are quickly going from rare to nonexistent.
So the answer is yes, it's acceptable.
Most of those issues have gone away. It's still better to have a slightly degraded user experience for your non-javascript users, rather than a complete site failure, but it's not nearly as important as it was in 1997.
Popups are largely handled by every major browser having popup blocking that works reliably enough.
Malicious code is what the ad-supported internet runs on. The only thing they can hit is your already-public data - the use of that data is the only thing that can be construed as malicious.
I would suggest that a company look at their web analytical and make that decision. I know that for most of my clients their trends show less than 1% for JavaScript disabled. This, weighed against maintaining a degrading site programming model, to support 1%, did not make economic sense, given that those dollars could be used for multilingual translation, (a far larger segment).
This is really a question that is best answered by looking at your sites trends. For us it made more economic sense to do a JavaScript detect and if they did not have it enabled pop a page suggesting FF, Safari or Chrome.
If you do take this approach, remember to be a good scientist by making sure you respect the control aspect of the scientific method. Specifically, if you already require JavaScript for your site, you should not even venture to extrapolate an answer, even if you think you're going about it in a reasonable way.
I recently had a conversation (although it was less like a conversation and more like a few frustrated, snarky comments from me) with a developer who claimed that 99% of his users browsed his page with at least 1024 pixels. Even ignoring for the moment the issue of screen width not being the same as the size of the browser window on the screen, I asked why he would expect otherwise from users of a web site which required that kind of width before it begins to invoke frustrating things like horizontal scrolling.
Or you have IE6 users.
You couldn't pick two or three or n browsers with 99% marketshare and make sure your website worked in them? I don't believe the browser market has been so fragmented in the last ten years that this was infeasible.
One objection used to be that requiring javascript locked out disabled (particularly blind) users. Has that changed? Does anyone know the state of screen-reading browsers these days?
No, you couldn't. Back then, the web was split between two major browsers: IE and Netscape. However, the feature set of what was supported in JS was not only completely different among the two, but also completely different among different minor versions of the two. Things that worked on Netscape 6.x would be broken on 6.(x+1), and work again in 6.(x+2), although with a different calling convention. It was mind-numbingly frustrating, and I don't think it would have been humanly possible to write JS that supported all minor iterations of each browser and maintained any sort of complex functionality.
By contrast, in 2006, I wrote a JS library that worked on IE6, Firefox 1.0+, and some early version of Safari. It has worked ever since, among dozens of versions of those browsers. That's the difference.
(Edit: I'm struggling to remember what version Netscape was around 10 years ago; the version number above might be wrong.)
If you want to use the power of these APIs to give your users something great by today's standards (think Google Maps, etc), yes I'd say requiring Javascript is acceptable.
My general policy is: if I'm linked to an article, I should be able to read it without enabling JS. If I'm linked to a video, I should be able to watch it only enabling the Flash plugin. If these assumptions are violated I become offended and I usually press Back, unless I have a very good reason to need to see that content.
I am not offended by web applications which require Javascript, as long as they're linked to by a source I trust.
I won't enable Javascript for domains which I know only serve ads. I also won't enable Javascript if I think I'm on a "sketchy" page -- a page which I believe might have malicious code.
[1] http://entertainment.slashdot.org/comments.pl?sid=629659&...
I'm using NoScript since I barely escaped from being infected by quite sophisticated malware few years ago.
Innocent site (local public transport) had had injected single malicious line into its content management system (most probably after untargeted "fishing for vulnerabilities" botnet scan). This one line was JavaScript include which in turn triggered series of jumps to servers all over the world (mostly China and Russia).
In the process, multiple layers of heavily obfuscated JS code were both loading hidden frames loaded with ads (presumably for click / impressions fraud) and trying to load hidden PDF embeds which contained a payload of hidden executables for infecting your local computer (exploiting Acrobat Reader security holes).
I only found out because Acrobat is such huge resource hog that I noticed and managed to kill it in a task manager before it finished loading.
I was using up-to-date Firefox and up-to-date antivirus AND I had disabled Acrobat plugin.
Upon inspection, malicious code appeared to be cross-platform and multi-target, using vendor specific JS extension. I remember besides Acrobat it was also targeting Silverlight (and this was in time when it was very new technology).
The list goes on and on, sure you can do most of these without javascript, but by that point I've moved on and blacklisted your site.
Is it better to be overly secure, or underly secure?
You do realize that due to a patent ruling a few years ago, these days almost all Flash content is placed after load with JavaScript to circumvent ActiveX's click-to-interact restriction. How often are you able to enable only Flash to view your content?
Users who disable javascript are responsible for dealing with the problems caused by lack of javascript.
As for why it's false, I think it's obvious. You can turn off javascript with the click of a user-friendly UI button, whereas programming ability is a much harder to attain skill.
The question that remains in my mind is… is it still acceptable to CamelCase javascript?
edit: oh, you probably mean the language name. Again, JavaScript is the correct formatting, even if it looks silly to most eyes.
This depends on what you're building. For websites, you are absolutely correct. For web applications, however, it is acceptable to use JavaScript for every jot & tittle. Take, for instance, 280 Slides; there is no graceful degradation for an application of that complexity & power. You either use it or you don't.
Fuck everything about that idea. And fuck web "application" which consider it cool to screw with my middle clics.
1) the percentage of users that have JS disabled
2) the cost associated with developing a non-JS version of your site
3) the revenue you stand to lose if you require JS
4) the aesthetic/functional impact on the user experience for non-JS users
Put all of that together and you'll have your answer. For me, it's not worth maintaining two version of what I build.
I'd love to serve up the site in a way that lets any screen reader or NoScript user see the site as it is intended, but the costs are too high for the relative gains.
It's insanely trivial to do, and just seems polite.
For instance, in a couple of my projects, we aimed at a small subset of users (autistic and/or adults with disabilities in this case) who would have a good reason to have JS disabled (fewer issues without JS when using some screen readers, for instance). For this reason our app uses no JS unless absolutely neccessary - and in those cases we do checks for users to transparently skip the sections of the site that need it.
A social network or something probably doesn't need that, but us sysadmins love our terminals, and its surprisingly easy to make an application very usable in lynx.
Some of the comments on that article make me want to cry.
However I think it's not acceptable for ordinary web pages. You don't need JS to show text, images and links.
If you use progressive enhancement it's easy to have basic non-JS version working, and you don't have to sacrifice any features for JS users.
The effort it took me to make this site gracefully degrade was completely not worth it, even though it wasn't THAT difficult for this site. However, my client actually only wanted it to work "on the iPhone".
Furthermore, now with plans for Google to expose native hardware APIs in their mobile browser via JavaScript, how do you gracefully degrade access to the camera or accelerometer?
Finally, on desktop browsing experiences, this argument won't even be around soon, mainly because the current battle is native versus browser (engine) not JS versus non-JS. We are building apps in the browser that are giving us native desktop functionality. You simply cannot do this at the level that people expect (in regards to user experience) nor functionality without JavaScript.
That many sites in the 2002-2006 period were built ONLY in Flash wipes away any guilt you could have about using JavaScript.
(Of course, if you have certain audiences or need to meet legal accessibility standards, that's a different ballgame, and if you don't meet the requirements, another developer/company will.)
Trying to implement something like GMail without javascript would just be a waste of time. It makes sense to talk about building sites focused on static content and simple forms without a dependence on javascript but the new breed of web applications require javascript. To dismiss them as "poorly implemented" is put dogma before practice.
You're so wrong even google disagrees with you...
> but the new breed of web applications require javascript.
That simply isn't the case. Unless you're johnny and you can't code, maybe.
Yes, I'm aware of the HTML-only version. No, gmail wouldn't matter if it didn't leverage javascript to build a client that competes with, and in some ways surpasses, desktop mail clients.
Apps are moving off the desktop and onto the web thanks to the new HTML standards and modern javascript environments. To talk about "degrading" these gracefully is to live in the past. These aren't "sites" - they're applications.
Accessibility used to be a decent argument (at least to those of us who cared) but it isn't any more. I say that as a co-author of WCAG2.
1a) Screen readers (e.g. JAWS) don't support JavaScript properly 1b) Only very modern screen readers support JavaScript properly (JAWS 10+) 2) Upgrading screen readers is expensive 3) People with disabilities statistically have lower incomes
QED we can't expect disabled users to have JavaScript.
To address the points:
1a was true a long time ago, but modern screen readers do support JavaScript and things like ARIA.
1b is somewhat true but that proves it's a technology rather than an "accessibility" problem, the screen readers weren't implementing JavaScript rather than it being an actually accessibility issue. As such WCAG2 made the decision to treat it as such.
2 and 3 are somewhat true, however many people with disabilities have access to non-profit, state or federal programs that support them with technology. Also free, open source projects like NVDA are increasingly advanced.
But for desktop browsers, I don't even really think about it anymore.
I don't think I'd build a web app targeted at iPhone/Android without using JavaScript. If you want to make your web app feel anything like a native app, it's pretty much essential.
If you want the visually impaired to be able to use your site, you should make a noscript version with as much functionality as you can. (Side benefit: That's going to make SEO a lot easier, too.)
If you have to service everybody, the answer is a flat "no". Doing otherwise is irresponsible, however understandable. If you don't, take the 0.1% user hit (assuming some mobile devices here) and require it and save yourself a lot of trouble.
I think the difference is that before, javascript was more of an "addon" feature to web pages, where now we are now able to create things with javascript that just aren't possible with static HTML only, or are far more usable, responsive, etc.
The only two things I'm concerned about are mobile platforms that don't have a complete JS interpreter, which presumably will be less of a problem in the near future, and accessibility for screen readers.