No, do not turn on JavaScript

Over the past months I've been becoming more and more privacy-conscious (or paranoid some may say), which has led to me installing more and more privacy-related extensions. I have been using uBlock Origin for a while now, mainly viewing it as an ad blocker, although more recently I've starting seeing it more and more as an enhancer of my online experience, blocking trackers and unnecessary JavaScript and making my online experience smoother.

At some point I saw my privacy-conscious CS teacher use something similar to uMatrix (perhaps he was using uMatrix, but I am not touching software abandoned for 5 years from a kilometer away), so I searched a bit and found that the most similar thing to it was NoScript.

Reviewing websites' <noscript> usability

One thing I can say about NoScript is that it raised my awareness about the degree that some websites use 3rd-party JavaScript scripts. By that I mean scripts not hosted in the same domain as the website, a subdomain or a similarly-named domain (I have yet to figure out why one might prefer this over the others). Today, I will check on some websites that rely way too much on JavaScript, even when not necessary.

Wikidot: https://www.wikidot.com/

I have spent a considerable part of this year's summer reading articles from the SCP Wiki, and I have to say that I never thought that what essentially is large part a static content hosting service could be so bloated. Some SCP articles utilize JavaScript in a way that is central to the article itself and can't be avoided, with the most prominent example perhaps being SCP-3125 (if you wanna read the article, please read the other article from the Antimemetics Division Hub as suggested).

Let's choose an article that contains elements that most other SCP articles utilize, while also not containing any JavaScript on its page source. I chose to go with SCP-729-J (content warning: profanity), a joke article that is a personal favourite of mine.

After messing with NoScript, I found that all Wikidot needs to function is unblock the current domain and a Cloudfront domain from which JavaScript code is fetched on runtime (for me it was d3g0gp89917ko0.cloudfront.net). Stuff will still be blocked, but it seems to mostly be either font files, or data brokers.

Wikidot uses JavaScript for the following in-article elements:

Furthermore, without JavaScript enabled, the "Create account" and "Sign in" buttons do not work, even if both then open a new tab to another URL (we will be seeing this later too). The footer buttons for viewing the page source, history, etc. are unusable, but I will let that pass, since I don't expect a website to unnecessary send data most users will probably not need and it makes more sense to make them available on demand, using JavaScript.

The discussion page of the article doesn't work without whitelisting the aforementioned domains. While that kind of makes sense, since discussion pages are split in tabs and the data seem to be fetched on demand (judging by the slight delay when jumping to another tab), but I believe the same approach could be achieved by using a URL somewhat like https://domain/discussion-page/tab-number, rendering everything server-side and making the tab numbers link to the respective URLs, while, in order to prevent unnecessary data transfers, using a JavaScript script (assuming JavaScript in enabled) that fetches the data from an API and updates the pages dynamically.

Lastly, something that bothers me with Wikidot is that the page revision number can be seen, even without JavaScript, but the "last edited" datetime doesn't. I believe that might be due to timezones, but then again, I delt with the same issue on this very website by displaying my articles' creation datetimes to UTC, which is what a no-JS user sees. If they have JavaScript enabled, a small script converts them to your own timezone.

Let me showcase this here, just to show to you how much of a trivial task this is. Below this paragraph, the article's creation time should appear, in UTC, if you have JavaScript disabled, and in your local time zone, if you have enabled it.

Substack: https://substack.com/

Putting Substack's other problems aside, if you go to any Substack blog with JavaScript disabled, you will be greeted with a footer, saying that "This site requires JavaScript to run correctly. Please turn on JavaScript or unblock scripts".

The reason they want you to enable JavaScript is because, like Wikidot, they utilized it for things that could be easily achieved without JavaScript.

Let's take a look at the Substack home page as seen today. On the top right, there's a search bar that doesn't work without JavaScript and doesn't even submit itself to the right place: it submits itself using a query string with a search parameter and from there it redirects to /search/search_value. That page doesn't work either without JavaScript.

Below that are two buttons: one to "Start your Substack" (a.k.a. sign-up) and one to sign in. Neither of these work without JavaScript, yet the sign-up button sends to /onboarding (I don't know why an anchor element here wouldn't work; someone please enlighten me) and a sign-in page that opens as an in-page popup (the no-JS apporach would be to have a separate page for that and redirect people there with a link. If you still want a popup when JavaScript is enabled, an <iframe> element could be used).

Above the main content section, again, a division with some text and two buttons that require JavaScript to function and both redirect you to other pages. As a matter of fact, the first of the two buttons is the same sign-up button as before.

On the main content section, the posts' "like" and "comment" buttons don't work (I doubt there is a way for them to work without JavaScript). There is also a dropdown menu for picking between "for-you" posts and posts from people one is following. That also doesn't work because apparently it is impossible to make a pure-CSS clickable dropdown menu. I don't know whether that's what annoys me the most or the fact that the dropdown buttons don't even dynamically load content into the page. The "for-you" option takes you back to /, while the "following" takes you to /home/base/subscribed.

Lastly, on the left, we have "Home", "Subscriptions", "Chat", "Activity", "Explore", "Profile" and "Create" buttons. Out of them, only the "Home" and "Explore" buttons seem to work, redirect you to the respective pages. The others are basically that sign-in button we discussed earlier.

One here might claim that this is all acceptable, since Substack simply didn't want to handle any logic server-side, for its own reasons (additional complexity, resource overhead, etc). However, I believe this argument is invalid for two reasons:

Firstly, Substack does in fact use server-side logic. If you are in their home page, the "Home" button I previously mentioned doesn't have a href property, even when JavaScript is turned off. The same happens with the "Explore" button, which implies that at least some logic is handled server-side.

Secondly, that is no excuse for using clickable links as buttons and using JavaScript for things that can be easily done using CSS. Yes, some client-side JavaScript for Substack is inevitable for things like "liking" a post or infinite scroll, but as I just showed, for everything else it is almost unacceptable.

"How to enable JavaScript in your browser"

Enter https://enable-javascript.com. The website was first snapshotted by the Internet Archive in the summer of 2010, and, as it can be seen, has barely changed ever since. Before I begin going more in-depth about it, I really love how, for a website that says that "JavaScript, [..] makes web pages functional [..] and if disabled [..], the content or the functionality of the web page can be limited or unavailable", they have gone out of their way to give each one of the website's localizations its own URL path (/ru for Russian, etc.), instead of doing it the lazy way and using JavaScript to fetch the translations from somewhere else using a button's onclick property. It is as if you don't need JavaScript for trivial things, like navigating to a different URL when clicking on a button...

Jokes aside, it is clear that the website hasn't been significantly updated in a while. The outdated browsers icons and the presence of Internet Explorer give that away, and a snapshot from 2016 proves it. The only part of this website that keeps getting updated is a "Supporters" section, but, by looking at snapshots year-by-year, we can see their number has declined.

At this point, it is pretty much clear what the scope of this website is. Someone made a simple website back in 2010 to show to other people how to enable JavaScript on their browsers. Others websites starting linking to it and, by 2016, as seen by the corresponding snapshot, other websites had come in contact with them, asking to be added to the supporters section (in exchange for an appropriate sum of money I assume), as a part of a SEO trick, which continues to this day.

Why all this?

Per HTTP Archive's State of JavaScript, at the start of 2012, the median size of external JavaScript scripts was 133kB for desktop and 74kB for mobile. Today, that has risen to ~760kB and ~690kB respectively, a 470% increase for desktop and 820% increase for mobile users. Yes, websites today are more complex compared to back then, but do most websites really need that much JavaScript, or is most of it just third-party JavaScript? By taking a look at the two aforementioned sites, we proved that, while some JavaScript is necessart, it was also used for things that could be easily implemented with plain HTML and CSS.

According to the same source, an average desktop won't have any issues handling all this JavaScript and it will all be executed in under a second. However, on a mobile, the media pages takes 3.7 seconds to load, with the 75th percentile taking as long as 8.2s and the 90th as much as 14.9s. By using Google's PageSpeed Insights (you will figure it out) for those aforementioned domains and this website (which is nothing but static HTML and CSS, apart from the aforementioned timezone localization script), it takes 5 seconds on Wikidot and 9 on Substack for anything to appear on the user's screen with a throttled 4G connection. Mine takes 0.8s. Obviously, these other sites are more complex than a static website, but anything above 3 seconds is purely unacceptable for me.

What you can do

As a user, install uBlock Origin and use Firefox, since Chrome no longer supports it. I don't think that the average user would need NoScript, since it makes a big number of websites purely unusable, and uBlock Origin has block lists for pretty much anything that could slow down your browser. On the other hand, if you don't mind having to play "whitelist the correct domain", you might as well install NoScript, even temporarily, so that you can see whether it suits you.

If you are a web developer, try to rely more on non-JS features to accomplish your work and don't do whatever Wikidot and Substack are doing. If you need to use JavaScript for a core feature of your website, use a <noscript> tag. Describe in detail the reason your site needs JavaScript (don't say anything generic like "This site requires JavaScript to run correctly"), and do not link to the Enable JavaScript website, since that will only make them and their sponsors, not you, more money.