Why (and How) to Kill JavaScript
JavaScript.
I suspect most people reading this article have heard that term before. JavaScript is an optional standard feature used by Web pages. It's a programming language designed to enable client-side scripting; basically, this means that, if JavaScript is supported and enabled on your Web browser (which it usually is), any time you visit a Web page, that page may direct you to programs, selected by the author of the Web page, which are then immediately, silently executed in your browser. JavaScript is not the only form of client-side scripting; some other examples from the past are ActionScript (which is used by Flash objects) and Java (via the Java browser plugin). However, in recent years, these other forms of client-side scripting have been phased out in favor of one standard: JavaScript.
The main use of JavaScript is client-side scripting, but since it is a fully-featured language, it has also been co-opted for other uses, such as server-side software, browser extensions, and even theming within desktop environments such as GNOME. This article is wholly unconcerned with these other uses, so while the term "JavaScript" may be used alone from here on out, please understand that it is in reference exclusively to JavaScript as a client-side scripting language.
Client-side scripting is highly convenient for website designers. With client-side scripting, you can make a Web browser do anything, even if the W3C hasn't come up with a standard to do that thing yet. For example, long before the <video> tag was added to the HTML standard, many websites used Flash objects, utilizing ActionScript code, to make it possible for a user to stream a video right in their browser, rather than having to download the video before opening it in a desktop video player. So most people see no problem with it; it seems like nothing more than a very nice convenience that makes the Web better, nicer-looking, more advanced, and more interactive.
However, this model also has several downsides, and I'm not the first to notice. In 2013, for example, Leaseweb posted an article titled "10 very good reasons to stop using JavaScript". The Free Software Foundation has also weighed in on this issue through Richard Stallman's essay, "The JavaScript Trap", which laments the fact that the system causes users to unknowingly execute proprietary software on their machines. And one interesting page called, "Everyone has JavaScript, right?", shows a flowchart pointing out that JavaScript is not 100% reliable, and a fallback that doesn't require JavaScript is needed.
Still, it's quite rare for people to argue that client-side scripting should be eliminated outright. That's what I intend to do with this article. I hope to demonstrate, as thoroughly as possible, why JavaScript, and indeed any client-side scripting, is so thoroughly fundamentally flawed that it should be deprecated, phased out, and ultimately eliminated entirely; and a conscientious effort should be made to keep client-side scripting from ever showing its face again. I have three key points to raise: inefficiency, poor usability, and poor security.
JavaScript is Inefficient
When I say that JavaScript is inefficient, there are a couple of things I am referring to. Let's start with the most obvious point: JavaScript is an interpreted programming language. Interpreted languages are always slower than their compiled counterparts, and as a result, any JavaScript program is pretty much guaranteed to perform more poorly than what the browser would have done without JavaScript. This may not be that big of a deal on your latest-generation desktop computer, or even your latest-generation laptop or your latest-generation smartphone. But it certainly is a big deal on older or cheaper systems, which many users have. So one effect of JavaScript is to make the lives of many people, especially those who are too poor to invest in expensive latest-generation hardware, or who may even have to use a netbook from a decade ago, much more difficult.
There's also a more subtle effect of this performance loss: waste of electricity. Regardless of how fast your computer is, making it work harder makes it eat more electricity. So JavaScript code is both increasing energy costs and contributing to climate change. You can see this for yourself by measuring how long your laptop battery lasts with and without JavaScript turned on in your browser.
Of course, this is compounded by the fact that every JavaScript program is custom-built for individual websites, which leads me to the other way that JavaScript is inefficient: it causes many people to reinvent the wheel, and often by people who are not even particularly skilled programmers. Not only does this make JavaScript programs even slower, it results in a great deal of lost productivity as people keep on coding the exact same behaviors over and over again. In fact, it's worse than that, because a lot of websites insist on using JavaScript where standard HTML and CSS would be sufficient, meaning that they are wasting time writing less efficient code that does exactly the same thing the browser is already designed to do.
JavaScript Causes Poor Usability
This might go counter to popular opinion, but I would argue that JavaScript "enhancements" actually hinder usability. The inefficiency of JavaScript is partly to blame for this; there have been many occasions when a website required JavaScript that I have waited inordinate periods of time for the code to finish loading. The most egregious example is a popular weather website which requires extremely heavy JavaScript for the "mobile" version of the site, which on my cheap smartphone (back when I had a smartphone) would usually take several minutes to load. But even on my much faster desktop computer, I've had excessive wait times in other things.
But that's only part of the story. Use of JavaScript to reinvent the wheel can easily also result in ways of interacting with the website that are confusing, inconvenient, or break the Web browser. Perhaps the trend with JavaScript I dislike the most is what is commonly referred to as "infinite scrolling", where everything is put on one page progressively by JavaScript. The idea of "infinite scrolling" is to prevent you from having to click on links to open pages and give the illusion that there's no end to what you're looking at, but that very minor cosmetic concern has a few substantial costs. Firstly, with "infinite scrolling", it's impossible to skip to a later page; all you can do is scroll, scroll, scroll for hours on end and hope you eventually make it to the section you're looking for. Secondly, this behavior is one of many JavaScript behaviors that are notorious for breaking the "back" button on the user's browser. This means if you happen to navigate away from the page for any reason, perhaps because you accidentally clicked a link, tough luck: you have to start from the top and scroll through that all over again, all for the sake of a pointless illusion designed to make people procrastinate more.
Infinite scrolling may be one of the most egregious examples of JavaScript that makes things more inconvenient, but it's not alone. You know those annoying pop-ups we used to get? Yeah, that was caused by JavaScript. Annoying ads that play videos and flood your speakers with noise you don't want to hear? Yeah, that would be JavaScript. JavaScript also breaks sometimes, leaving you with buttons that don't do anything; typically, this will be because the page failed to load completely. Or perhaps you have to wait several seconds for the page to finish loading all of its JavaScript crap before you can do what you want to do. The list goes on and on.
But by far the worst part of JavaScript's usability is not one that most people would think of: accessibility. Yes, when you have no problem seeing, it can be easy to forget that blind people exist, and that those blind people use computers. But they do, and JavaScript code is notorious for getting in the way of screen readers and other accessibility tools that blind people depend on. Accessibility can also be a problem for those who choose to run their machines in text mode (i.e. the command line); yes, they do exist, though they're not especially prolific these days. But when a website depends on JavaScript, text-based browsers, like Lynx and Elinks, simply cannot display it.
JavaScript Hurts Security
Security is a concern most people seem wholly unconcerned with. Most people use the same password over and over again, choose weak passwords, and generally throw caution at the wind, choosing to be reactive when a security breach happens rather than proactively preventing security breaches from happening in the first place. However, security is a very real concern, and client-side scripting of any kind is inherently a potential security problem, no matter how carefully you go about it.
Do you remember all that advice you got about never opening untrusted attachments, or even untrusted emails? The reason for this advice is to prevent execution of malicious code on your system. Now, some of this involves bad email client behavior, where Microsoft Outlook used to make it easy to dress executable attachments as mere documents, and would happily just open executable files with a double-click. But many exploitations instead involved using legitimate Microsoft Word (.doc) documents which executed harmful code via Microsoft Word's "macro" feature. This was a client-side scripting feature designed to make documents more convenient by executing certain code, silently, any time the document was opened. Sound familiar?
Yes, it's the same principle as JavaScript, and JavaScript is no stranger to malicious behavior, either. There have been many cases in the past of websites containing malicious JavaScript which would cause infections on any computers that made the mistake of navigating to them. The approach Web browser developers take is to put JavaScript code in a sandbox, but this is very much a cat-and-mouse game that is impossible to win; with a turing-complete programming language like JavaScript, there is always a risk of malicious code.
In fact, malicious JavaScript code is not just an occasional thing; it's everywhere. That isn't to say that Trojan Horse scripts are rampant; they aren't. But many websites intentionally implement other malicious functionality. Most notably, JavaScript is the most powerful spyware tool in the world right now. Many websites routinely use JavaScript to report back to the website's operator on your activity, and JavaScript is also used to substantially enhance "fingerprinting", a technique for uniquely identifying users, taking away any anonymity you thought you had.
Now, in truth, any software can be used to do malicious things. That's not a problem in and of itself; software has to have that capability to be useful. The problem with JavaScript is that this isn't software you choose; this is software that someone else chooses on your behalf and updates without your knowledge or consent. If you don't have a chance to intervene, to make sure the code is trustworthy or check for malicious features, as is the case with JavaScript, then it is much easier for bad actors to slip in malicious features. In the case of JavaScript, this can even be done by third-parties; this particular type of vulnerability is known as "cross-site scripting", or "XSS" for short.
The Solution
Now, you may be thinking, "Okay, but how could it possibly be feasible to have a Web without JavaScript?"
If you maintain a website, please see my article, "Fantastic Modern Website Design (No JavaScript Required)", which explains the general principles behind JavaScript-free modern website design.
As a user, I recommend turning JavaScript off. Yes, right now. Actually go to some of the sites you frequent; you will be surprised at how much of the Web actually works without all that JavaScript code, and even at how much better it works. In fact, there is a Wired article about the experience titled, "I Turned Off JavaScript for a Whole Week and It Was Glorious".
Please consider thanking website maintainers when their websites work without JavaScript. The more people express appreciation for JavaScript-free support, the more website maintainers will continue to provide that support. Thanking website maintainers for good JavaScript-free support is possibly the best way people who are not website maintainers can encourage those who are to move toward a JavaScript-free ecosystem.
Some websites fail to work without JavaScript. For information on how to deal with this, see my article, "Workarounds for JavaScript Requirements".
There are some roadblocks at first. But in the long-term, turning off JavaScript, or at least using it as little as possible, makes the experience of browsing the Web glorious. You will never want to go back to a scripted Web ever again.
