The JS Party podcast just had a fun episode where they debated this classic question by splitting into two groups of two. Each group was assigned a “side” of this debate, and then let loose to debate it. I don’t think anybody can listen to a show like this and not be totally flooded with thoughts! Here are mine.
- This is one of those holy war arguments that has raged on for years. Perhaps that’s because people are seeking an answer that applies to the entire web, and the web is too big to pin this broad of an answer to.
- The question itself worth a look. Why are we talking about hamstringing our sites in this particular way? Should our websites work without HTML? Should our websites work without databases? Perhaps we focus on JavaScript the most because JavaScript has become the largest bottleneck of web performance (even more so than the network!) and we experience failed JavaScript more so than any other type of web failure (except, perhaps, entire sites not loading) (or icons fonts, jeez).
- I enjoyed all the stumbling around the terminology of “web apps” and “web sites” (web things!). This is such a weird one. It’s so easy to picture the difference in your head: it’s like facebook versus a blog! But when you start trying to define it exactly, it gets really murky really quickly and the distinction loses any value, if it had any to start with. Here’s more on that.
- Accessibility is certainly involved in all conversation about the web, but it probably can’t be broadly applied here. There is a notion that assistive tech doesn’t run JavaScript — so a site that requires JavaScript to use it is a 100% fail for those users. Best I know, that’s entirely not the case anymore. We can debate to death the role of JavaScript in accessibility problems, but just because a particular site requires JavaScript to run doesn’t by itself render the site inaccessible.
- It’s easy enough to flip off JavaScript, browse around the web, find broken things, and chinflip them for this apparent failure. The failure being that this site, or a feature on the site, could have been architected to work without JavaScript. Rule of least power. This is tricky. It’s easy not to care about a person who has intentionally disabled a part of their web browser and still wants everything to work. I straight up don’t care about that. But the resiliency part is more interesting. If you do build a part of a site to work without JavaScript, it will work both before and after the JavaScript executes, which is pretty great.
- The concept of building functional content and features without JavaScript and enhancing the experience with JavaScript is called progressive enhancement. I’m both a fan and careful not to insist that everything on earth is always to be built that way (see top bullet point). There are situations where progressive enhancement both increases and reduces technical debt. The only wide brush I’d use here is to say that it’s worth doing until the debt is too high.
- There is an in-between moment with progressive enhancement. If a feature is functional without JavaScript, that means it’s likely you are deferring the loading of that JavaScript for the performance benefit. But it does eventually need to be downloaded and executed. What happens during that time? There is a performance and UX cost there. Best case, it’s negligible. Worst case, you break the feature during this in-between time.
- I find it more interesting to debate this kind of thing on a site-by-site and feature-by-feature basis. Application holotypes might be an interesting way to scope it. They often turned to Slack as an example which is a perfect choice. How would you build a 20-author movie review site? How you would architect a social and media-heavy site like Dribbble? How do you build dropdown navigation? What about a one-page brochure site where the client wants parallax? How about an airline app that needs a native mobile app as well? And of course, it makes you think about sites you work on yourself. Does CodePen run on the right set of technologies? Does CSS-Tricks?
- If a site is “client-side rendered” (CSR), that means JavaScript is doing the data fetching and creating the DOM and all that. If we’re talking about websites “working” or not with or without JavaScript, a site that is client-side rendered will 100% fail without JavaScript. It is sort of the opposite of “server-side rendered” (SSR) in which the document comes down as HTML right from the server. SSR is almost certainly faster for a first-loading experience. CSR, typically, is faster to move around the site after loading (think “single page app,” or SPA).
- It’s not just SSR vs. CSR — there is a whole spectrum. It’s more and more common to see sites try to take advantage of the best of both worlds. For example, Next/Nuxt/Gatsby, or Ember’s fastboot.
- Service workers are JavaScript. Web workers are JavaScript. Some of the fancy resilience and performance features of the web are powered by the same technology that causes the grief we debate about.
website? why website needs js in the first place? to submit form without reloading whole page? that’s it, if there’s no js website can be still fully functional, just a bit more ugly
admin panel for that website though while still possible to build without js probably isn’t worth spending time to assure that as UX improvements are juts too big to ignore them
I’m going to say no. Focus on making your website accessible, performant, secure, and usable, and use JavaScript to achieve that (especially for accessibility).
By definition, a website that requires Javascript to be “usable” is not accessible to people not running JS, for a variety of reasons. It was disabled, it was running on an outdated browser, the connection was too slow to load the massive script it needed, etc.
Accessible doesn’t mean it has to deliver the intended experience and content to assistive technologies, it means anyone (with disabilities or not, screen reader or not), should be able to access it.
In this case, it’s not just JS. CSS can make a website inaccessible too (for example, you have an inline style that hides everything until the CSS is loaded and make the element appear. If the CSS never loads, your website is not accessible).
While we should certainly strive to make our projects as functional as reasonable without the use of JavaScript, I think we’re far past the point where ever “it depends on the project” is a good response.
JavaScript (in particular async requests) have dramatically transformed the standard user experience. Users now expect seamless transitions, they anticipate a form button like ‘save’ to auto-update and not refresh the page. An actual pop-up window would be blocked and if not would be jarring – but a modal? Expected.
Certainly some of these experiences can be replicated to some degree or another with CSS, but JavaScript also provides a level of accessibility support that CSS-only solutions cannot yet adequately reproduce.
I don’t do it for every project, but for projects where I know JavaScript is essential I always have a
<noscript>
that very bluntly informs the user that JS must be enabled to interact with the service. Saves me a lot of headaches filtering questions from customers who disabled JavaScript because their bosses sister’s nephew told them it was a security risk.I’m not familiar with users disabling JS. It feels like the wrong approach. If performance and privacy are the issue, then there are better ways (e.g., tracking protection) than to disable JS completely.
Huge scripts are indeed an issue, but on the other hand, if a site’s JS code is small (< 100 KB transferred), then it’s not a problem, I think.
I don’t worry about that. If a web page is implemented in such a way that it requires external CSS and JS to work, than that’s fine. If those resources fail to load and/or execute, the page will break, of course. It’s the job of the web developer to try to prevent that from happening (or at least make it less likely).
Follow up article from Jens Oliver Meiert with some usage data.
I was going to say “no”, but the more I think about it, the answer is “yes”. Not because I think there’s a desperate need to support users who refuse to use JS (there’s even an argument that could be made that a not-insignificant amount are wannabe hackers, but I’ll ignore that).
The reason I think you should build your website so that it works without JS is that it will help you focus on, learn and implement existing web technologies, rather than lazily using JS alternatives.
Too often I’ve seen web devs go straight to JS, even when vanilla HTML5 would do the same job. It’s fine to use JS if there’s a good reason, but ignorance of your options is not one of them.
So yes, build your website to work without JS — it will make you a better developer.
I’ve never really understood why this is a debate in the first place. Should a website work without CSS? Sure…but why? Should a house work without windows or running water? If it’s accessibility that’s a concern, JS can improve that experience, not hinder it.
JS is a web technology and a part of the stack, why is it a question whether it should be relied upon for the very role it plays? What ELSE would we use to achieve the benefits that JS provides?
Progressive enhancement is key. This means the major or key aspects of your site should function when javascript is disabled OR a script error occurs. For instance your shopping cart should always work: why would you leave the checkout vulnerable in these cases?
Too often I find that a site is broken because of a scripting error or some dependency that is absent because of Ad blockers for example, or the browser used is not up to date enough for your scripts. So maybe not everything needs a noscript backup but you should evaluate if the main aspect your site is used for still works.
I think it depends on the project requirements including the accessibility requirements.
In some projects like the ones with users located in certain African countries, paradoxically, the use of JS is the best solution to solve big technological accessibility challenges. The users on those countries may have reasonably advanced/modern devices but the mobile data –which is their predominant data source– is freaking expensive. In those scenarios employing JS usually is the most effective way to cope with that.
I browse the web without JavaScript turned on and it’s an amazing place. I don’t get ads. I don’t get annoying pop ups trying to appeal to my giving nature by not blocking ads. I use Brave and, hopefully, it will block all those horrible tracking pixels that attempt to work with a tag. Most of the time, the FED who implemented it didn’t do it right anyway. If I come across a site that doesn’t work without JavaScript, guess what, I never needed to visit that site anyway. Social media is toxic. Media itself is toxic. I don’t tip when I get bad service. I’m not going to tip a site owners who content is completely worthless and the ads take more time loading than the time I spend reading the article. I love when a site is completely usable with JS turned off, though rare. When talking about menu’s, people who disable JavaScript are looking for information so just expand the entire menu. Respect people’s browsing behavior. Take that extra 30 minutes to make your sad “web app” work the right way; the way the web was intended to work. I should be able to browse the web using Lynx.
I said YES!
Nowadays, I saw people to use JS do things that would do with CSS (example, fadeIn), I think it’s crazy because everybody is learning only JS. We’ve forgotten about semantic, accessibility, performance, etc… but other side, I read articles like that, it’s important to discussion development ecosystem.
Years ago, websites should works without CSS, today we’re discussions about CSS-in-JS or “what are the best js framework”…
I like to start out by making pages readable/useable and accessible with just HTML5 before adding CSS and JS. Less is more. I only add the CSS that is necessary and the JS that is absolutely necessary to meet the requirements. HLTM5 can and should be doing the bulk of the work on any well designed page. There’s a lot of garish junk out there.