On the Responsibility That Comes With Good JavaScript Support
Published on March 26, 2020 (↻ May 10, 2023), filed under Development (RSS feed for all categories).
According to the data we have, the classic idea of making sure websites and apps work—function and display acceptably—without JavaScript being enabled is dead. (How we would arrive at this conclusion I explained in more detail in “Must Work Without JavaScript” as well as in colspan=15 of my German column for heise Developer.)
When we look only at support requirements for web developers, this was the end of the story: JavaScript is supported almost everywhere, pretty much no one can’t or doesn’t run it, no need to do extra work for when it’s disabled, fin. It’s not, however, when we employ a broader look at JavaScript and its misuses.
JavaScript Abuse and Its Consequences
Prior reasoning led to doubt whether sites and apps would truly not need to work without JavaScript anymore. (I love feedback, but you help me and other authors by sharing it clearly and constructively. I like to take your thoughts seriously and if it’s just anger it makes it difficult to respond, let alone learn from each other.)
The responses showed that there is great concern about how JavaScript is being used, with issues going from security to privacy to accessibility to performance. This concern about how JavaScript was employed led to the following kind of argument:
- P
- There are many problems with how JavaScript is being used.
- C
- Therefore, it’s important that JavaScript can be disabled.
This argument is understandable. Alas, it’s not a very good argument because the conclusion doesn’t follow from the premise. It’s equally “logical” to come up with this one (which matches how I had silently treated the matter):
- P
- There are many problems with how JavaScript is being used.
- C
- Therefore, it’s important to use JavaScript more responsibly.
As you can tell, this perspective, drawing a different conclusion, shifts responsibility and gives the option to assert that JavaScript support is strong enough not to warrant a demand to have sites and apps work without it. It’s not in the premise where we had found disagreement, but in the different “conclusions.”
The second argument does indeed not say that JavaScript quality, security, privacy, accessibility, or performance were unimportant or irrelevant, simply because it’s possible to assume JavaScript support. Seeing that in the argument put forth in “Must Work Without JavaScript” is much like this precious fallacy:
- P
- The winger didn’t make an assist.
- C
- Therefore, he took over the captain’s armband.
Now, all this logical fooling around builds up to a point:
There are many problems with how JavaScript is being used, and it’s important to use JavaScript more responsibly.
Responsible JavaScript
What does that mean?
On a high level, in my mind, the following:
- Security: JavaScript should be used in a secure manner.
- Privacy: JavaScript should be used in a manner respectful of users’ privacy.
- Accessibility: JavaScript should be used in a way that is accessible.
- Performance: JavaScript should be used as to be fast.
What does this mean specifically?
A detailed treatise is not the point of this article, but pointers may be found here:
- Secure JavaScript:
- Respectful JavaScript:
- Accessible JavaScript:
- Fast JavaScript:
When this is all given, I’m convinced that there be fewer concerns around not providing no-JavaScript fallbacks, because fewer people would feel pushed to disable JavaScript.
What site owners, developers, and users prioritize and decide to do, and when, that’s a different story, however. Different levels of craftsmanship and different user needs will probably accompany us for forever. Yet even irresponsible JavaScript does not mean that JavaScript support cannot, or must not, be assumed. Sites and apps must really not “work without JavaScript.” But they, and we, really should use JavaScript more responsibly.
Many thanks to Hannes Schluchtmann for reviewing this post.
About Me
I’m Jens (long: Jens Oliver Meiert), and I’m a frontend engineering leader and tech author/publisher. I’ve worked as a technical lead for companies like Google and as an engineering manager for companies like Miro, I’m a contributor to several web standards, and I write and review books for O’Reilly and Frontend Dogma.
I love trying things, not only in web development (and engineering management), but also in other areas like philosophy. Here on meiert.com I share some of my experiences and views. (Be critical, interpret charitably, and give feedback.)
Read More
Maybe of interest to you, too:
- Next: The Frameworks Paradox
- Previous: Highlights From “The Crowd” (Gustave Le Bon)
- More under Development
- More from 2020
- Most popular posts
Looking for a way to comment? Comments have been disabled, unfortunately.
Get a good look at web development? Try WebGlossary.info—and The Web Development Glossary 3K. With explanations and definitions for thousands of terms of web development, web design, and related fields, building on Wikipedia as well as MDN Web Docs. Available at Apple Books, Kobo, Google Play Books, and Leanpub.