In this age of HTML5, CSS3, and anti-Flash it seems as though we may be slipping away from our roots. Or are we?
Back when standards were standards if you were building anything that didn’t have a fall back plan in place for a lack of JavaScript, you were doing it wrong. Yes it took more time and it took better planning but that’s the point. When you’re a professional you’re supposed to be doing it right, right?
The rise of (my) Web standards
Back when JavaScript was reborn, when its use began transforming into what we know and love today, the rules were still being written. I remember thinking about how I should approach learning this skill I knew would soon be essential. My first stop when teaching myself something is Google. Of course back in the day Google was still polluted with DHTML tutorial sites and wretched implementations. After reading countless tutorials comprised mostly of “copy and paste this snippet here and that snippet there” I knew it was time to hit the books.
It took about four seconds of poking around to realize that there was more than meets the eye when it came to JavaScript for me. I needed to learn about the DOM before I tried to manipulate it. If there’s one thing that drives me batty it’s the notion of ‘learning the framework instead of the language’ and this is no exception. JavaScript though, has a completely new layer to work with.
I won’t detail the issues I have behind learning a framework or platform as opposed to the language here, but it can be applied to every programming language, every markup language, CSS, and JavaScript as well. To sum it up: learning the framework gives the language a bad name. We’ll leave it at that and the rest for another article.
I grabbed myself a copy of DOM Scripting by Jeremy Keith and to this day I’m glad I did. DOM Scripting was instantaneously followed by Bulletproof Ajax, also published by Mr. Keith. If I had to choose two books as a suggestion to someone looking to learn proper JavaScript I think these two are it. There are of course subsequent, more advanced books that I’d also suggest, but these two works will help you to realize which blog posts are junk and which are gold.
The theory behind writing JavaScript, as I took it, can be taken from DOM Scripting:
Separate behavior from structure using unobtrusive JavaScript. Add dynamic effects with progressive enhancement. Ensure backwards-compatibility through graceful degradation.
I lived by those rules. I still do. But am I stuck in the past while everyone is moving forward?
The new Web
Has building a proper Web stack become old school? What I’ve been curious about lately surrounds the trend that requiring JavaScript for your Web app is something we hardly blink at. MobileMe has just recently relaunched with a new look:
Looks really great, but if you hit the page with a JavaScript-incapable browser it’s a bit different:
Back in the day we’d all have scoffed at such a thing, comparing it to a “This site looks best in IE6” badge straight out of the 1990s. What’s changed since then? Why is this now an acceptable practice? I understand that Apple is a progressive company, bringing the web in its best form to the largest population possible, and making it look great, but that’s my point. Is this new school of thought going to transform itself into common practice?
The entire point behind breaking away from closed platforms such as Flash (yes, it’s a closed platform no matter how much marketing gets put behind it) is to build a universally accessible Web. Devices are advancing, yes. Browsers are advancing, yes. But does that give us the liberty to put the fruits of our labor on a back burner now that we’ve reached some sort of plateau in the evolution of the browser?
I’m not dogging Apple
Apple isn’t the only one producing Web applications that show similar messages if you’re using a JavaScript incapable browser. In fact, other more popular platforms are doing it even worse:
There was a time, if I remember correctly, where Google Docs gave a notification similar to MobileMe as opposed to loading a non working pseudo interface that does nothing but confuse a visitor. Gmail still retains its fully functional JavaScript-less implementation, albeit behind a quick message notifying you what you’re in for:
Depending on your choice, you can end up at a really well put together version of Gmail:
To me, Gmail remains to be one of the best implemented modern Web applications because of this very attribute.
Where are we headed, really?
I’ve tried to wrap my head around these poorly implemented Web applications to find out the real inspiration behind them. Are companies rushing JavaScript dependent platforms out the door simply to get things live before the competition? Are metrics showing that supporting JavaScript simply doesn’t make fiscal sense? Are we to a point where leading Web companies care more about dollars and cents than users?
What about the Web applications themselves? We’re working with the most rich implementations of JavaScript we’ve ever seen. Many times, it doesn’t even make sense to offer a degraded version of an application simply because the desired feature is built within JavaScript from the ground up; there’s nothing else to show. This is not a bad thing. I’m concerned in particular for those applications that could in fact have a decent degraded version. Does it change the opinion we have behind the modern Web though? I’m speaking from a front end developer point of view here, a conversation between us professionals, not as users.
Do we need to move beyond this self-imposed requirement of providing a gracefully degraded version of our application? If so, would it not be a (short) matter of time before that school of thought trickles all the way down to the Coda Slider we plan to implement? In essence, what’s the difference? We’d all be thrilled if we could just make that AJAX request and call it a day without having to first build an alternate version, but is it the right thing to do as professionals?
The groundwork has been laid by some of the best thinkers in our industry, and neglecting to build a proper stack, to me, pushes all of that hard work aside in favor of (too) rapid deployment. If your metrics show a 99% JavaScript enabled audience, are you willing to forsake that 1%?
I’m not only concerned about that 1%, I’m (perhaps) more concerned about how it affects the overall implementation. Working from your degraded version is going to result in a much more stable environment upon which to build your behavioral layer. Skipping that valuable step can and probably will result in a less structurally sound document.
I have a tendency to remain loyal to influential circumstances that have shaped me as a professional, but I’m curious how (if?) these events are affecting other designers and developers, if at all. Do you continue to be curious about degraded versions of modern Web applications? I could be way off base in even thinking about things to this level, and if that’s it by all means feel free to call me out on it, but there’s something under my skin about what’s going on. Thoughts?
Comments
I’d would prefer to have 99% of my audience enjoy a great user experience at the expense of the 1% rather than 100% have a subpar experience. Certainly there are cases where you need to do everything you can to appease every target visitor, but at the end of the day, i’d rather be proud of something awesome and impressive.
Go JavaScript!
I am pretty sure this is my favorite article you have written today. So many good points that you hit on.
First off, I agree about DOM Scripting and Bulletproof AJAX. Both are incredible books that will help people understand what is going on under the hood. DOM Scripting was the first book that made it all really click for me – in terms of understanding the interaction with the dom (finding, altering, bubbling, propagation, etc).
Second, I agree that starting with the degraded version is always better to build on. I have worked on applications where they built the ‘enhanced’ version first, and it made the development and maintenance after the fact *very* frustrating.
Third, I will just quote you directly:
“Are we to a point where leading Web companies care more about dollars and cents than users?”
That’s the bigger question. I don’t necessarily look at Apple/Google sites as this shining example. Mostly I find them frustrating in many aspects. For them, I think it’s about dollars/cents/competition – not about accessibility for the user.
I could list other highlights, but I don’t want to repeat your entire post.
Very well said.
That’s just it. You can still build a progressively enriched site that gives *both* a great user experience. In my opinion, if you are thinking in the 99% versus 1%, then you are thinking about it backwards.
Progressive enrichment does just that. It makes sure the experience is incredible for the majority, while still making it usable for the rest. It’s a win/win. Anytime that other user wants a better experience, they can upgrade their browser.
I’m in the progressive enhancement camp. I do have some things on my site that require JavaScript, but they generally don’t have a meaningful alternative, and most of it has been for the purpose of exploring JavaScript and enhancing my trade. I try to go for the degraded form first, then build the JavaScript on top. I’ve done this with my image viewer and anchor scroller script that work on top of good standard HTML that works well without the JavaScript.
I do get frustrated with the number of sites that simply break when JavaScript s disabled. I use the NoScript add-on for security reasons so surf most sites with JavaScript disabled by default. I do like that it lets me selectively give exceptions for domains I trust. I will occasionally contact a site about the breakage with JavaScript disabled, but I’m sure you know the type of response that one generally gets.
There are few large companies that care more about users than dollars and cents. There’s only one that I recall reading about recently and unfortunately the name and industry of the company escapes me.
Both Google and Apple are about innovation. It would make sense that they would rush to release something; at least Google hangs the ol’ “Beta” or “Alpha” sign on about 90% of their products for the majority of the products’ lifecycle…though I’m not sure that makes it “ok” considering it is in fact for a large portion of the publically accessible lifecycle.
Is Apple using Sproutcore? Another in-house framework? Perhaps their frameworks and business rules need to focus on unobtrusive JavaScript rather than the richness.
Oh, and I agree with your personal feeling that unobtrusive JavaScript should be strived for. As you said, the groundwork was set by those in the industry, now that we have better and easier tools to get things to market doesn’t mean we should take them for granted and skip even more steps just because we can. I feel almost like many people getting involved in the JS side of things haven’t had the background learning experience, or have read DOM Scripting (which is currently sitting in front of me on my shelf – and in fact am loaning it to someone later today who wants to learn JavaScript).
Making sure a web site works without JavaScript is not a fruitless endeavor either, as Nate said, a site is easier to maintain if the ground work is done first. If a new smashingly awesome device comes out that trumps the “awesome wow factor” of the iPhone (use some imagination), which supports CSS3 and HTML5, and Flash out of the box beautifully, but has horrible JavaScript support – how would they view a majority of these pages? Would we developers scoff at this device and the “stupid users” who flocked to use it only to have a crippled device, or would we instead curse the heavens as we tried to accomodate for it if we didn’t already have a plan in place?
Can (most) screen readers take advantage of JavaScript? (Nope.) Can someone like Apple be sued because of this? (Yup.) Should we simply follow the market leaders blindly just because they’re cool and we want to emulate them? Well that’s up to us. It’s also up to our Project Managers and time constraints, but if we have the time and the ability to do so, I feel we should *always* strive for graceful degredation with unobtrusive JavaScript.
Alright. I’ll bite.
For web apps, it is absolutely acceptable to require JavaScript. The whole point of a web app is that it rivals a desktop app in terms of functionality. Good luck achieving that with just CSS. And to disable JS you really have to go looking for that option in your browser. Most users don’t even know what JavaScript is, let alone why they should or shouldn’t have it enabled.
In Google Chrome, you really have to dig to turn of JS. In fact, I’m not even sure it’s possible to shut off JS, without having the Web Developer extension installed. It seems that’s the route browser makers are heading, not letting users shoot themselves in the foot with an overwhelming number of settings. I mean, how do you disable JavaScript on an iPad? Is it possible? (That’s not a rhetorical question. I don’t have an iPad.)
I’ve heard edge cases where employee computers have JS disabled for people working at banks, because of some overbearing and paranoid IT department. But, the bank I use requires JavaScript to use their site. So I figure the language itself isn’t a security risk. 🙂
Now, for a web site, which basically exists to display content (but not be interacted with heavily), I’m not sure that JS should be required. In those cases, there’s usually not anything going on that’s so fancy a user must have JS.
Nowadays, I’d say that from an accessibility standpoint, it’s far more important that your sites + web apps work well with keyboard navigation, than worrying about if they work with JS turned off. Or, as I like to put it: “Video killed the radio star. Touch interaction killed :hover drop-downs.”
I should clarify: I’m not saying that to build a good web app, you *have* to use JavaScript. It’s not a magic bullet. Plenty of good (and bad) web apps have been built with (and without) JavaScript.
Just that, if you find yourself building an app where it makes sense to use JavaScript – It’s fine to require that the user have a browser capable of running it. Sure beats the alternative: Pay for some software suite. Install via CD. Keep track of updates. Rinse. Repeat. That’s the reason Google Docs is taking off while MS Office declines: Free. Less hassel. Brought to you by JavaScript™ 🙂
Oh, and I checked on the JS in Chrome. It’s impossible to disable. Period. Even with the Web Developer extension installed, JS cannot be disabled…
http://chrispederick.com/work/web-developer/chrome/faq/
You make some very good points. Very good. There is still that voice in the back of my head that says we are no better than we used to be with the ‘best viewed’ messages.
I fully agree that keyboard support need to be at the forefront. Most definitely.
The biggest problem I have with many apps, and it’s the same problem most of us have with Flash, is that it’s only there because a developer *can* use it – and not to actually enhance the user experience.
In these cases, I *want* to turn off my JavaScript. I’d rather interact statically than deal with a horrible interface. I can name a handful of these tools today.
So, I still consider it important that the foundation be baked in. The foundation is what gives you all of your necessary hooks to enrich the interface (form actions, URLs, classes, markup, etc). If you have all of that working at the core, it makes the enhancement that much easier.
I also see poor uses of JavaScript when people think JS first. They embed CSS information inside of their JS. They embed URL routing information inside of their JS. They embed HTML markup inside of their JS. All of these things violate keeping a clear separation of these layers. This is yet another reason I don’t like the JS first mentality. I don’t think you can keep a clear separation (or, I’d like to see examples), without actually building that core foundation.
My stance on this is dependent on my “web apps should always behave like websites” stance—I’m firmly *for* anything that is delivered in the browser looking and acting like a proper site, regardless of any rich functionality. That means semantic markup, deep linking, real hyperlinks (no span-with-onclick nonsense). Make your list sortable if you’d like to and if it makes your application more useful, but make sure your browser KNOWS it’s a list first.
A great thing about modern web frameworks is that it’s pretty difficult to build an app that *doesn’t* work with simple REST requests—that is, you have to be trying to do it wrong. So in most cases, no, there’s no excuse.
Regardless of where you fall on the Javascript fall-back issue, I think we can all agree on one thing:
ALL websites should be made ENTIRELY in Flash.
Great article Jonathan.
You make a great point: “You have to be trying to do it wrong”.
“Can (most) screen readers take advantage of JavaScript? (Nope.) Can someone like Apple be sued because of this? (Yup.)”
Can most screen readers users interact successfully with JavaScript features content developed with accessibility in mind? Definitely YES!
“Can someone like Apple be sued because of this? (Yup.)”
Highly unlikely if they make a genuine attempt to make the JavaScript based features of their web site or web application accessible to people with disabilities.
Note: this is not to say that public facing web sites don’t need to be usable when JavaScript is not supported. It is an argument for not requiring distributed web applications such as Google Docs be usable without Javascript.
Javascript is not inherently inaccessible, it’s the way it is used that causes the problem.
I think the developer has not always the choice to built a fully progressive enhanced site, in particular if its more than a “5 pager”…
I work in an ad agency and we have very short timings. Everything must be developed as fast as it could. And most of the clients don’t care about the 1% of the users which have an javascript disabled browser. And it is always much more extensive to built a fully progressive enhanced site, like it is much more extensive to built a fully accessible site…
Sure i try to do my best not to exclude anyone from the content (e.g. search enginges), but only to a given point… I would love to manipulate the clients views looking forward, left and right… 😉
Great article. I am a Flash Designer & Developer and on most projects when I ask for alternate content to what I am producing, all I get is an awkward silence.
To the argument that “clients don’t care about the 1%”: if that 1% is a million in lost revenues, they care. It’s our job as developer to care and educate clients.
HTML, CSS and JS are all about accessibility, graceful degradation and backward compatibility. Yet on most sites that is far from reality. Restricting access to information through a specific browser or having JS enabled is no better then requiring Flash. I am wiry that browsers are trying to replace Flash under the disguise of “open standards”.
[…] Is it Now Acceptable to Require JavaScript?Yes […]
Great article! And I think a very important point. I’m not in favor of shutting people out just because of no JavaScript or no Flash or no … I think a site should degrade gracefully and still be usable.
I can see though the point of requiring it for certain web apps. But I always enjoy it much more if a website still works without, both when I make them and when I use them.
I think it shows elegance.
I know that’s no argument.
Man, does this article touch a nerve!
I’m just developing my own design process. What works for me is “backwards” to the “standard” method, because I begin with as much content as possible and mark it up so that “raw” (X)HTML makes sense on its own. The CSS, graphics, and JavaScript are there to enhance the “message” in my opinion, so get added “progressively.”
FWIW my background is in designing and developing applications on IBM mainframes, where CSS, graphics, etc. were not available. Perhaps I am just being retrogressive?
P.S. I applaud Jerome’s comments…
[…] full post on Hacker News If you enjoyed this article, please consider sharing it! Tagged with: Acceptable […]
What would be the point of turning off or limiting javascript? this is what I don’t understand…
If you’re worried about people who’ve disabled javascript, your app is probably not for them anyway!
My Chromium (6.0.434.0) has such an option in Under the Hood > Content Settings > JavaScript.
@Nate:
This is not true. If you spend 30% of your resources building a site for 1% that has no javascript, then you have 30% fewer resources to improve your site for the other 99%
I’d have to say no, it is absolutely not acceptable for a website to require Javascript to function. Note that a website is not the same as a web application.
Obviously, there will be some things that can’t function without scripts. Those are web applications. Those are things you expect to be essentially one big script. That’s another thing entirely.
But about 98% of the sites I see requiring Javascript are requiring it for basic functionality – blog comments, images, even to display the page. Things that plain HTML was designed for and has been doing for ages. Some of those scripts do nothing but make the main page container visible. The only thing they’re using Javascript for is to poorly re-implement the functionality of basic HTML.
Especially today when HTML5 and CSS can do so much so well, if you need scripting to implement basic functionality of a website, you’re doing something very wrong. You might use it to add some nice feature, pretty it up a little, or make it a little more convenient, but you definitely don’t need it. What you need to display text, images, and other content on a page is HTML. What you need to make that content look nice is CSS. What you need to have comments on your blog is a server-side script to store and fetch them and a basic HTML form. Only complex applications need scripts.
I want to say those who require scripts to view their sites are lazy, but it probably takes more effort to implement in Javascript than in HTML. Even with JS enabled, your result will be less functional than with HTML. Screen readers and search engines can have trouble finding your content, which especially in the latter case means lost traffic. A Javascript link can’t be opened in a new window/tab by right-clicking it. A Javascript redirect can interfere with the browser’s back button. Javascript-based forms often can’t be resubmitted if the user’s connection fails. All of these things are handled perfectly by as little as one HTML tag.
I’m a web designer, but I’m also security-conscious. Javascript has been at the root of a huge number of browser exploits, and it can do all sorts of annoying and privacy-invading things by design. It’s used by a significant amount of annoying advertisements and scams. Security-wise it only makes sense to have JS disabled by default and enable it only when it’s truly needed. Why should I trust your random website with that kind of power? A lot of sites are just “requiring” it because their ads and tracking cookies won’t work without it.
Yes, in 2010 Javascript is a powerful tool. So are HTML and CSS. There’s no excuse to not use all of those tools correctly just because one can do all three jobs poorly. It’s like saying you don’t need a screwdriver or a can opener because you can use a hammer to pound in screws and smash open cans.
“You can still build a progressively enriched site that gives *both* a great user experience.”
Yes you can do that, but you have to code your site twice: one version with js, and one without. Just look at the gmail example: the version without js is a completely different app.
It’s not always possible to code on top of the html-only version.
Very well written article. However, it is such a pain reading you article in Nexus One since I can’t focus on the article only. The RED Monday by noon thing on left sidebar always moves over article. Does that count as a bad practice? I would say so, but with so little of reader using mobile reading your article. It is fine; I, one of minority, just have to accept that.
In short, I think it ends up with whether developer cares what users have experienced or not. Some dev might not think of a specific issue, but when it arises, choices they made after matter the most. 🙂
Too many programmers out there are too busy trying to get all their Javascript to work in the first place, let alone build their website or “app” to be degrading. When the focus is on building a snappy interface with Javascript and AJAX goodies, the concept of “what happens if they can’t handle this because they are using NoScript/an old phone/elinks” gets thrown to the bottom of the to-do list.
My biggest hate in the argument for mandating Javascript is this: Since you don’t control how the code and markup you send down the pipe is executed and parsed, the user’s browser, configuration and any extensions determines that, it’s pure blackmail and bribery to mandate anything since you lost any control on this decision and your holding the end user hostage until they comply with your demands because of your incompetence to degrade and suggest to them, instead of blackmail.
At the end of the day, if you want more people to use the site/service/app/whatever, make it handle under as many different configurations, browsers etc as you care about. Neglect the rest at your own peril.
Erratum: “you’re metrics”.
i’m also from the progressive enhancement camp, although i’m quite “new” to js (learned it by myself by analyzing js-code from websites about 3-4 years ago)
in the first place, i think it is not about “its too early” but more “its just not polite!”. i’m using noscript (which is btw the 2nd biggest addon for firefox with millions of users around the world!) as of security reasons and also because i just dont want to see moving, blinking and whatever effects wherever i go (its almost like animated gifs were some years ago…)
i like the js-less versions of pages and only enable js when i need it. but i often come across sites which just cant be used without js
just btw, noscript is the reason that keeps me bound with firefox. while other browsers (chrome) grow and everybody prefers it and tells to switch i just can’t as long as there is nothing equivalent to noscript for other browsers. not in 100 years!
being able to use pages without all the “beautiful” js-effects is something thats just the polite way in my opinion.
don’t misunderstand me, i like js and i also like some web-apps which heavily use js. im using such sites quite a lot and ive got quite a few exceptions in my noscript white-list.
i also think writhing js is really fun (at least when you use a good framework like MooTools), i really enjoy coding in js :3
what i don’t like is js everywhere, even where it just does not belongs!
there are things you can, should or must do with js, but there also are thing you can’t and/or mustn’t!
but many “web-designers” nowadays just cant understand this and totally OVERuse js (especially in the days of jQuery, which lets you do the strangest effects within seconds…)
building web-apps which requires js is ok if this is really needed. i know quite a few of them, just like http://colorschemedesigner.com/
but there are also sites which use js in a ridiculous way.
i’ve seen everything from missing functionality (which is ok up to some point), to missing stylesheet (which has been loaded with js, but the page itself didn’t have anything other that required js, lol), to pages which replaced links completely with some “stylish” buttons (and used location.href for all redirecting) up to completely destroyed designs because the js is intended to do that…
i have also seen pages where, from one day to the other, you couldn’t log in anymore because the login form was moved to some overlay which required js (it could have been done without js too btw…)
pages that could have looked perfect and didn’t even need js, not for critical parts at least, but they completely overdo it and destroy the site (when js is deactivated at least), thats what i often come across… its really a shame!
recently i also made some pages which requires js for some functionality, like watching the gallery and such. the rest works perfectly without js though. i’m also making a web-app which requires js in the first place because i need it to enhance the usability of that quite large application.
i’m doing that with mixed feelings, because i like it but i don’t really like to build something that requires js
but i have to move on myself and cant stay behind… thats what we all have to do…
but we can at least give our best to keep at least the most basic/critical functionalities of our sites useable without js and don’t overdo it! 😉
I think the 30% of time, 70% of time arguments do not make any sense. I have struggled with this question myself recently. I have built several javascript only applications and am not sure that was/is the best way to develop.
This part of your argument resonated the most with me …
“Working from your degraded version is going to result in a much more stable environment upon which to build your behavioral layer.”
For me that is and should be the reason to not require javascript because if forces a constraint on me that will in the end produce a much better much more maintainable application.
Answer: No, because then I have to allow script execution for that domain in NoScript, and that is annoying.
If you’re just going to look at the 99%/1% numbers, think about the assumptions you’re making:
– I assume that all new devices and avenues of web use will fully support JavaScript. (hint: we’ve seen this not to be true with mobile phones.)
– Similarly, I assume that my JavaScript will work better with unforeseen future devices than plain HTML.
– I assume that all browsers’ implementations of JavaScript on top of HTML will be as reliable as plain HTML.
– I assume that the 1% doesn’t include any important people — major customers, investors, etc.
– I assume that the users who enabled JavaScript for my website will always be willing to do so.
– Or, I assume that I or someone will always stay on top of this web content and update it as necessary for new devices, software, and other changes in how people use the web.
In the end, I think the decision comes down to internal goals that are part of our personality and aren’t going to change. Does it make you happy to aim for happiness for everyone or do you believe some people are not worth the cost of pleasing? Do you like to try to improve everyone’s life with your work or are you looking for creative ways to maximize your own profit and ROI? And sometimes: are you willing to sacrifice your own ideas and ethical choices if your client or boss wants you to?
I must admit that I haven’t actually put any time into a mobile version of the site due to some outside factors taking up a bit of my extra free time, but I absolutely plan on it, ASAP!
You can’t browse the web with a browser that doesn’t support HTML. Ludicrous concept, but… I think it makes the point.
Progress means expectations change. Adapt, or die.
I for one think javascript is going to be the future. Already I can create a whole webpage using just a script tag and manipulating DOM. With such development making javascript even better and better and being able to do things much easier simple html is being outrun by javascript. Before long I wouldn’t be surprised if we can eventually serve pages with only .js files. It might be a long time till then though.
[…] case and chances are this will never happen in real life. Also since some people start treating javascript as a requirement I wouldn’t worry to much about […]
I disagree with the underlying assumption (by some) that requiring Javascript is user-hostile. The premise, by my reasoning:
1. Comparisons to the early days of preferred-browser badges is not equitable. Back then, you could literally alienate 50% (or more) of your audience, and standards were poor at best. We tend to forget that modern implementations, as problematic as they might be, are a utopia of conformity compared to the wild-west of yesteryear. Javascript included.
2. Browsers were once paid-software, and I am not requiring anyone to purchase anything, nor to download a plugin. I don’t believe it is too much to ask of a user to make use of a free, included feature of their own software. Many users have no idea what Javascript is or does. Concern here is a bit developer-centric… these are the people most likely to know how to enable/disable whatever feature they want. They are free to do so as they choose.
3. The loudest argument I hear against reliance on Javascript is the theoretical device which doesn’t support it. I have yet to hear said device referred to by name, but it *could* be released tomorrow, for which I should preempt . I suppose I could also
shard all of my databases too in case I get Slashdotted.
In a market increasingly saturated with frameworks and WordPress-blog sites, it’s becoming increasingly difficult to differentiate yourself. As others have stated, speed is not a feature, it’s THE feature.
http://37signals.com/svn/posts/2280-speed-is-the-most-important-feature-if-your
The concerns with SEO are valid, but easily handled.
Nice article and something I ponder about all the time.
I’ve actually chosen to go the opposite route. I have a simple rule as it pertains to Javascript. I only will use it if it’s something I can live without that won’t hurt or hinder the user experience if it for some reason were turned off. Unless I can guarantee that it’s fully supported by 100% of a small restricted user base, like for example in my own personal web applications built specifically for personal and/or family use.
As an example of acceptable use of Javascript that won’t hinder user experience if it happened to be turned off, I think of things such as rollovers, image pre-loading, or something as simple as default text in a form field that magically disappears as it’s focused and maintains being gone if the user has actually entered something. And some of that even can be supplemented by other languages, like rollovers with CSS and even more now with HTML5 “placeholder text.”
Those things won’t break or significantly alter the user experience if by some chance the user were to have Javascript disabled. They certainly enhance it slightly but only for the better, never for the worse. If it’s turned off, you’re not missing anything.
I’ve never been a believer in relying on Javascript to do things dynamically that other languages do better either. Like for example creating a login script or using Javascript for front end form validation. That’s something to leave for the server side languages. It may require an extra HTTP request but you can’t turn it off, you can’t avoid or circumvent it and it gives you far more flexibility in which to handle the data and do something with it. So it’s never application critical and if it ever was, you’re doing something wrong.
The downside is I know there are things I’m missing out on, especially as it pertains to AJAX, which could be useful and/or beneficial to my applications but I feel that Javascript really is a language based off of bells and whistles that I may want to add but none of which I actually NEED to have. Although that appears to be changing now with HTML5 as it contains generic tags, like CANVAS, for example that don’t do anything without additional Javascript support but even then, you can live without that too or create equivalents in different ways that you’ve probably already been doing for years anyways.
I’d really prefer things to be different as there are definitely some negatives to this approach but for now I’ve never had to forsake the 1%er’s and I’ve managed to save the time of coding two applications versus the one, which I feel is most beneficial, among other positives. Until we see some drastic change in implementation and support (which I don’t see on the horizon), I’ll continue to revisit the question at hand. Unfortunately I won’t be surprised by my answer if it remains the same.
[…] Is it Now Acceptable to Require Javascript? and We Haven’t Forgotten About Accessibility Have We? (Monday By Noon) […]
[…] Is it Now Acceptable to Require Javascript? and We Haven’t Forgotten About Accessibility Have We? (Monday By Noon) […]
Nice discussion.
I agree that it’s annoying sometimes to have to cater to people who don’t allow javascript. I also agree that it’s annoying to have to still design websites for IE6…but that’s the lay of the land. It depends on who’s using your site.
I always take the percentage of people using the site on IE or without javascript and factor that into my budget, then I design the site the way it should be and spend that percentage of my QA budget on making it look good for IE and no scripters…
Just thought I’d throw in how I justify doing any work at all on it.
I liken it to continuing to support ie6. If we enable users to live in the stone age, they will. Why not give them a reason to come into the light of the modern age.
[…] Is it Now Acceptable to Require JavaScript?Jun 21, 2010 … It’s not a new trend, but it’s something I see more and more with bigger companies who pride themselves on building (upon) standards based, … […]