We use Javascript every day. Most people who browse the web don’t even know it’s running. However, there is a segment of web users that come to a page that is just downright broken. If they’re lucky, they might get some piece of information left by a developer inside a <noscript> tag that informs them that they are out of luck. It might read something like:
“Sorry, but your browser doesn’t support Javascript.”
Deep inside that soft little jelly heart of the user, they feel like it actually reads:
“You suck. This site doesn’t care about you......go away.”
With the rising popularity of Javascript frameworks, I’ve been anxious about how our users will interact with Javascript. Lately, I’ve been writing more Javascript than I know what to do with. I’ve been exploring ‘vanilla’ Javascript and have discovered how utterly fragile it is. One line, one misplaced semicolon, one wrong var, and it all unravels.
The worst part is that for a user, there’s no error message or indication that Javascript has crashed and burned. They are just left with a problematic scenario where that intended functionality is broken. “Click”.....nothing. “Click” again….nothing.
Ok, so we can include error handling and do our best to make things still work when the script doesn’t do what we intended, but what about the user who has Javascript disabled? Is anything helpful rendered? Is your site or app still usable in the absence of Javascript?
Remember Murphy’s Law reminds us that everything that can fill, will fail. Javascript will fail. So, let’s be wise and plan for it.
The core component of every site is HTML. That’s what we write and build the web on. Yes, there are other languages we use every day (CSS, JS, PHP, Ruby, Python, etc), but when you boil it down, in the end HTML is the ultimate requirement.
The fundamental features of your site or web application should be functional in the absence of Javascript. I’d rather eat a bland meal than forego eating simply because a specific seasoning is unavailable. Your users want to be able to consume your content and interact with your app even in the absence of web seasoning.
I don’t believe a <noscript> fallback is enough. If your entire interaction is based on Javascript, I hope you’ve planned for the scenario where Javascript fails.
Don’t mis-interpret this post. I do love Javascript. Furthermore, we all love a meal that’s been seasoned well, but no sane person would (or should) eat a meal of salt and pepper. Javascript is an incredibly helpful tool. It can add a layer of depth and interaction that you just can’t achieve with HTML and CSS. Remember, that the goal with Javascript should be to exist as an additive element and not a baseline requirement. It’s a wonderful seasoning, but not a meal.
Jeremy Keith gave a presentation talk that inspired this post. I’ve been thinking about this for a while, but Jeremy provided the kick in the pants I needed to actually write this article. Watch his Coldfront Conference talk on Resilience on the Web (46:55). You’ll be glad you did.
Need help, advice or a speaker for your event? I’d love to connect and help you build novel solutions with design.
