Ask HN: Is the web ready to require JavaScript?
7 comments
The web is human-accessible content hosted at stable linkable URLs. If you send fragments of ad hoc data and rely on just one piece of code that might be able to reassemble them into something usable on a couple out of all browsers, that's not a useful contribution to the web, it's merely a client/server app which tunnels yet another nondisclosed protocol over HTTP. Somehow we ended up with a new crop of devs who don't see how terrible client/server was (your data is trapped in a silo, there's only one app capable of doing anything with it, it sucks, and you can't fix it) or why the web was such an improvement, so they're abandoning it and we're all going to take a huge step backwards.
I think the web can still be human-accessible content hosted at stable linkable URLs. But now the question is, can we require the user-agent to support JavaScript in order to show the content, like we already require it to support HTML.
If your documents are complete (no js-generated extra requests to get actual content) but your default rendering is flaky without trusting your js, I consider that shoddy work but not an existential threat to the web.
Less than 1% has JavaScript turned off. The answer to your question is the same as to if a website should support Netscape 3.
I would say the answer depends on what the target audience is, what kind of site it is, and how much time it will save.
I would say the answer depends on what the target audience is, what kind of site it is, and how much time it will save.
Right, when I was with Marriott we did extensive research of the subject. The numbers just don't add up. Now that I am on my own, I recommend to my clients that they take full advantage of the tools at hand. Butchering the development model to support less that 1% (it was a little higher when I was there around 1.5%) just cannot be justified. Further it is cheaper to build a clean modern code base and then route the non-JS traffic to a site built independent of the modern code base that supports non-JS client. The reality was that the business case could not be made to even spend the development effort to build out a non-JS site. It would have literally been cheaper to send ever non-JS user a new computer with a modern browser, than it would have been to spend the development effort to build the site. Graceful degradation to non-JS creates more complexity and increases the overall effort, when quantified that money is almost always better spent on a better returning effort like an IOS app or further features on the JS enabled site. Now days it is hard to make the numbers work to support a non-JS site. Personally, even if I had no other features to implement, I would spend the money saved from removing the complexity of graceful degradation, on color blind testing, site reader software testing for the blind or internationalization. All of which have better business cases than non-JS support.
While I am on the subject my group (the web) made the business case that having JSP and Javascript was redundant and added to the complexity and therefore the cost of development and maintenance. We where able to successfully transition away from back-end web frameworks two a pure JS/HTML/CSS front end. In doing so we where able to simplify our development model, which increased our defect resolution time as well as our new feature development time.
While I am on the subject my group (the web) made the business case that having JSP and Javascript was redundant and added to the complexity and therefore the cost of development and maintenance. We where able to successfully transition away from back-end web frameworks two a pure JS/HTML/CSS front end. In doing so we where able to simplify our development model, which increased our defect resolution time as well as our new feature development time.
I think it's funny how many commenters assume that people whose user agents don't support JavaScript are "relics" or need "a new computer with a modern browser". In my experience, people who use NoScript, for example, are much better equipped (technologically, etc.) than those who don't.
That said, people whose user agents don't support JavaScript get a big fat warning message after they log in to any of the web apps I've recently worked on.
That said, people whose user agents don't support JavaScript get a big fat warning message after they log in to any of the web apps I've recently worked on.
I wouldn't mind (and do intend to, even for a school website) having so much javascript on a page that it looks different, even broken without it, but I wouldn't load the content with javascript like Twitter do, that's too far (and may well always be). Mostly because I want to support screenreaders, or curl/wget.
In either case, your app should be written as a service which can be access by many different "clients" if necessary. Then you can go all hog wild with a WebGL version of your app, and someone else (an intern) can come in later and write a Web 1.0 version of the client-side.
Please, if you're able to make the call, do not require JavaScript in the browser. Fall back gracefully and make the UI work without any JS.
Why? I'm not sure I understand your view.
what kind of browser nowadays don't support javascript? I don't know about you but the idea just sounds totally foreign to me. I'm too busy worrying about what HTML5 features modern browsers support :P.
Well the main issue isn't that browsers don't support Javascript, but that some people disable running scripts or have plugins like noscript that disallow scripting.
Even with the disables ones added in, the business case is just not there: http://developer.yahoo.com/blogs/ydn/posts/2010/10/how-many-...
[deleted]
not to mention I can't even imagine the user experience drawbacks. your website would just suck in comparison to any competitor.
Curl doesn't support JavaScript. Neither does wget.
If I'm on a netbook, tablet, or phone, your JavaScript will chew my battery. I don't want that.
I don't trust you. Don't take it personally; I don't trust most websites. I haven't signed your key, and you haven't signed mine. I am not okay with letting you execute code on my machine.
Your JavaScript sucks. Again, don't take it personally; it's a tricky and frustrating language with lots of pitfalls. However, you messed up, and now your script is busy-looping or eating bandwidth with endless AJAX. I'm blacklisting your script until you fix it.
These are just off the top of my head, BTW.
Edit: Spelling.
If I'm on a netbook, tablet, or phone, your JavaScript will chew my battery. I don't want that.
I don't trust you. Don't take it personally; I don't trust most websites. I haven't signed your key, and you haven't signed mine. I am not okay with letting you execute code on my machine.
Your JavaScript sucks. Again, don't take it personally; it's a tricky and frustrating language with lots of pitfalls. However, you messed up, and now your script is busy-looping or eating bandwidth with endless AJAX. I'm blacklisting your script until you fix it.
These are just off the top of my head, BTW.
Edit: Spelling.
You represent < 2% of the market, you examples do not represent the majority of most sites customer or user base. As such business should make decisions based on the demographics of their users. The reality is their is a finite amount of capital businesses have to spend on software efforts, as such they have to prioritize their spending based on the most amount of impact for their money. Further, they have to compete with the usability and features of their competitors so their is pressure to adopt more modern practices to provide software that users become accustom to as industry norm.
Okay, fine, here's a better example. People with disabilities. Is your JavaScript ADA-compliant? Is it business-savvy to ignore your legal requirements towards them?
Yes, A good toolkit like Dojo not only is WAI and A11Y compliant, but it exceeds the abilities of web 1.0 framworks, instead of having things like high contrast plugins for browsers they are baked right into the toolkit and are activated based on browser meta data. Part of my consultancy is web accessibility modernization through JavaScript toolkits. Web 1.0 frameworks, as of today, cannot comply with the upcoming legislation, but the larger JavaScript toolkits are already there and have the most complete implementations available. Further the current set of laws only require that a screen reader such as JAWS works on a site which JavaScript has no bearing on, we do tons and tons of JAWS testing in my organization. The future of the web is being increasingly implemented in JavaScript toolkits, the shift has already happened, as such the toolkits are starting to surpass the offerings that are available in the old server side frameworks. Because they are increasingly getting developer mind share. Accessibility is one of those areas that they are way out in front on. http://dojotoolkit.org/reference-guide/dijit/a11y/statement....
People aren't using good toolkits. People are open-coding everything. You might have gotten it right, but Joe JS Developer isn't.
Have you considered slimming down your walls of text? You seem to be using lots of words to say "no u," and it's tempting me to draw parallels between the simplicity of the JS-less Web and the relative complications of the JS-ful Web.
Have you considered slimming down your walls of text? You seem to be using lots of words to say "no u," and it's tempting me to draw parallels between the simplicity of the JS-less Web and the relative complications of the JS-ful Web.
But now, people I work with are making the claim that JavaScript can become a forced requirement for all future websites. In this world, if you're without JavaScript, you might only get a minimal, unstyled skeleton page via HTTP, so that search engines can index the URL and social sites can share it. Or even a blank page, if those things are handle by APIs.
The majority of the UI is then to be implemented with Backbone/Spine, Underscore templates and similar technologies. It will be fully HTML5 compliant, elegant and accessible, but it just won't work without JavaScript.
My question is, do you think the web is ready for this transition? Are there compelling reasons, other than just "historical principles", for this not to happen? Can we consider JavaScriptless users an increasingly ignoreable relic like IE6 users? Are there other key points to consider - are we throwing out some baby with the bath water?