Some thoughts about your (our) site needing Javascript

April 30, 2022

Yesterday, I mentioned that our support site uses a little bit of Javascript to inject site-wide navigation on all the pages. In a comment, msi noted:

But then, that also means that people who block JavaScript don't get to see the navigation bar, which kind of defeats the point of the entire site, I guess.

On the one hand, I feel this. I block essentially all Javascript myself, so I had to add a specific exemption for our support site, and I'm always happy to read about the various catalogs of reasons to avoid Javascript beyond that people have it blocked (for example, via). But on the other hand, when one of my co-workers decided to use Javascript to insert this navigation, I didn't even really consider raising objections, for two reasons that combine together.

First, our support website is what I call an inward facing website, one aimed only at our limited number of users instead of a broad worldwide audience. One of the effects of this is that generally speaking, we can assume that people are coming to it from a good network environment and with reasonably capable clients, where they probably aren't suffering from any number of issues that can affect delivering and running our Javascript. This means that if you aren't running our Javascript it's mostly likely a deliberate choice on your part, as it is for me in my normal browser environment.

Second, the reality today is that voluntarily choosing not to run Javascript leaves you with all sorts of problems in general; our site not having general navigation working is the least of your issues. Anyone who voluntarily disables Javascript rapidly becomes an expert in dealing with Javascript related problems. Such people are expert enough to look at our support site and sort out the navigation problem. They're also very uncommon for exactly this reason; it's hard work to live in a web world that lacks Javascript. My co-workers are unlikely to be sympathetic to an argument that we should go significantly out of our way (for example to a scheme where we have to pre-process all the HTML pages) in order to accommodate such people.

The (unfortunate) reality of life is that Javascript working is the default, by a huge margin, and when it doesn't work many people can fix the problem with a page refresh. For a small scale, low effort website this makes it hard to argue against small amounts of simple Javascript that do basic things. I feel that you pretty much have to make an argument based on the principle of it, rather than the practicality, and this is only a winning argument with people who are already sympathetic, which most people aren't.

If you have a site that serves a wide range of user needs around the world (whether it's large or small), then all of the standard arguments against relying on Javascript apply and it would be great if you avoided it unless you absolutely have to have it (I'll certainly be happy). If your audience is unusual, you may also have good reason to avoid Javascript. But otherwise, it's a hard argument, especially for what are essentially extras.

(Although I haven't checked recently, I think you can mostly navigate through our support site without needing our navigation bar. Most or all of the pages are linked, directly or indirectly, from the main page's normal content, which doesn't require any Javascript to see. There would be a much better argument to be had if people wanted to rely on Javascript even for main content, because that would be much more dangerous.)


Comments on this page:

If you can live with its limited layout options you could use an <iframe> to pull the navigation into each page while requiring neither a build step nor Javascript.

By Michael at 2022-05-01 03:18:33:

Your final sentence parenthetical is actually the most important IMO. There are times when Javascript provides significant enough added value versus cost to make perfect sense. Your internal support website might be such a case precisely because, as you say, the cost is rather low, so the value doesn't have to be very high to offset the cost. (Presumably, it's also relatively trusted among the intended audience.)

And then there are other websites that are meant for public consumption, contain mostly static content, and work in such a way that with Javascript disabled the pages appear empty. There isn't even a message along the lines of "this page needs Javascript to display". Yes, I have come across those in real life, even relatively recently.

I'm one of the people who choose to disable Javascript by default (and set up as restrictive a policy for the Javascript that I do allow as I can get away with), and I also keep arguing for graceful degredation. Okay, so I don't have full navigation facilities if I don't allow Javascript to run? Well, that's my choice, and at least I can still read the page I ended up on by other means (found it through a search engine, someone sent a link, whatever) and normal links work so I can at least click on those and get to where it's intended to take me.

I've got pretty good at telling when the problem is that I have disabled Javascript, and I even have a script to start a brand new, temporary, fresh browser session with no customization and delete it when I close that browser window, for the times when I need something to just work right now or even just to see whether the problem is some overly restrictive policy or setting somewhere in my normal browser profile. But pages that appear completely blank just because Javascript is disabled still trip me up from time to time.

By msi at 2022-05-01 09:28:05:

The reason I don't use JavaScript and keep my content strictly static is not, by the way, that I'm against the idea of a dynamic, distributed medium. I guess, everyone who has ever seen Doug Engelbart's 1968 demo of NLS (aka The Mother of All Demos) will realize that the system presented there was conceptually way ahead of what the later WWW had to offer roughly up into the early 2000s.

But then, HTML, CSS, and JS are among the worst imaginable things to use as building blocks for that kind of thing. I mean, HTML and CSS aren't even all that great for static documents. So, it's probably no wonder that, for the most part, the present-day Web is a grotesque anti-realization of Engelbart's vision. (This certainly isn't merely a technical problem, though.)

Given all that, it's arguably better to use the Web as a rather static medium and accept the limitations coming with that.

One rather painful disadvantage of this approach, however, is that – as far as I know – it doesn't offer any even half-way convenient method for users to control how content is displayed on their devices (except for zooming). But then, the light/dark mode switches a lot of sites offer really aren't much of an improvement over that.

Written on 30 April 2022.
« Our positive experience with having our support site be basic HTML
Using Linux's libvirt for my virtualization needs has been okay »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Sat Apr 30 21:46:41 2022
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.