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.)

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, Add Comment.
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.