In 2017, I published the online book Robust Client-Side JavaScript – A Developer’s Guide. More than five years later, I think my advice is still valuable. JavaScript as a language has not changed much when it come to techniques for writing robust code.
At the moment I do not have the time for a substantial book update. In this post, I would like to describe how I regard the whole issue today and how I would restructure the book today.
Recently, yet another debate sparked over single page apps, client-side frameworks like React and client-side versus server-side rendering. The arguments are not new. During the last decade, I found criticism of the dominant client-side JavaScript usage necessary and worthwhile. Especially proponents of progressive enhancement challenged the JavaScript ecosystem. Yet the mainstream did not adapt patterns for robustness and performance. Web sites became slower, more fragile, error-prone, inaccessible and exclusive largely due to client-side JavaScript misuse.
There always has been a class of full-stack, “universal” JavaScript frameworks with a focus on speed and simplicity – think of Marko, Astro, Fresh or Qwik. They render HTML on the server and aim to ship the minimal necessary amount of JavaScript to the client. The client-side JavaScript then picks up where the server-side JavaScript left off, ideally without duplicating the server-side logic. More and more frameworks adapt such a workflow. But the mainstream is still dominated by React monoliths that comprises megabytes of client-side JavaScript.
Unfortunately, the chasm between the opposite sides of the debate grew wider. The groups are no longer listening and talking to each other, but mock and ridicule each other while talking to their in-group. Echo chambers in social media amplify this divisive discourse.
Certain posts from prominent JavaScript critics are filled with scathing polemic. They personally attack JavaScript project maintainers, calling them liars, fraudsters and grifters because they only recently have “discovered” the downsides of single page apps.
I am all for radical criticism, especially targeted at billion-dollar tech corporations and powerful project leaders who try to silence critics. We need to hold them accountable for tech that produces harmful, subpar web experiences. They deserve their decent share of “told you so”.
It is frustrating that influential people did not listen to the facts or did not deliver on their own promises. Will it help to call them fraudsters in the moment they start to acknowledge the facts? I believe vitriol makes the situation even more dire. I am disappointed that smart people who made valueable contributions to the web engage in mudslinging.
Only a few note that such a behavior may harm the developer community that is already toxic and exclusive:
I’ve been wailing on about SPA frameworks recently (like a lot of us have, probably because we’ve found more of our people over here) but just to be clear:
The world sucks right now. Get a job where you can. If React or Vue or Angular or Next or whatever gets you a job, then that is absolutely fantastic. If you are new in web dev and it introduces you to a love for the web, that is also fantastic.
You’re going to spend a lot of time as a web developer figuring out where web experiences are broken for humans and how your platform or tech choices affect that. That always has been and is always going to be true.
Sometimes this conversation can veer into the “sounding self righteous” lane which gives me the ick.
There’s a lot of fair criticism of React floating around at the mo. My one request is that people take care to separate “The React Community” from the people who just get paid to build things in React. I build stuff in React for money, but I do it as accessibly and consciously as I can. I know it’s far from ideal but that’s what we use. Switching to Not React isn’t really an option in an org of our size. So please avoid mud-slinging and name-calling, and keep the discussion civil.
I think the biggest takeaway is that you probably don’t need React; and if you really do, and you’re sure, make sure you’re aware of the drawbacks and have plans to mitigate them.
What a year, huh? – Captain, it’s February!
Anyway, where were we?
My 2017 book was an attempt to mediate between the different camps of the debate on client-side JavaScript usage. Much advice from JavaScript critics was and is abstract for the sole reason that you need a robust site architecture in the first place before writing any robust client-side JavaScript code. With my book, I wanted to teach patterns any developer who writes client-side JavaScript can apply in their daily work regardless of the framework used.
Around 2015 and 2016, several front-end developers wondered how to properly address JavaScript failure. What happens when a JavaScript enhancement fails? These essential and much needed discussions urged me to write a book on robust JavaScript.
Unfortunately, only a few developers and projects picked up the ideas and integrated them into their work. Preventing and dealing with failing JavaScript is still an afterthought for many projects, frameworks and libraries. We need to continuously explore how practical progressive enhancement in JavaScript looks like.
In 2017, I also wanted to emphasize that progressive enhancement is much more than server-side rendering. The discussion on progressive enhancement regarding JavaScript still revolves around server-side rendering versus client-side rendering. For good reason, but this is where progressive enhancement starts.
It is a first step to use a framework that renders fully-functional HTML documents on the server. A frameworks that understands your code, identifies client-side interactivity and figures out the least amount of JavaScript that needs to be shipped to the client.
It does not mean you are done with it. Adding client-side JavaScript should not be one monolithic enhancement step from 0 to 100, but many small deliberate and considerate steps. That is why it is called progressive enhancement.
So, where are we today? I welcome the new discussions on better web site architectures and sensible JavaScript usage. The industry is already shifting and new universal JavaScript frameworks are pushing the existing ecosystems.
My 2017 book concluded with Writing less JavaScript:
An important skill of a front-end developer is to know when not to solve a problem with client-side JavaScript. It is always more robust to solve a problem further down in the stack.
If all techniques and tools did not help you to write robust JavaScript, consider reducing the code complexity and the amount of code. In the last resort, reduce the usage of client-side JavaScript. Find simpler solutions that rely on HTML, CSS and server-side logic alone.
Today I would turn the reasoning upside down. Reducing client-side JavaScript is the most effective technique to prevent JavaScript failure. The most robust client-side JavaScript is the JavaScript that is never written, never shipped to the client and never executed. (Clever, huh?)
Apart from that, what techniques are essential today to write robust JavaScript?
I’ve mentioned TypeScript as a compile-to-JavaScript language in the book. Since 2017, TypeScript conquered the JavaScript world, superseded other compile-to-JavaScript languages and became a de-facto standard for a great share of libraries and frameworks.
TypeScript is the single tool that made my JavaScript significantly more robust in the last couple of years. It helps me to design cascades of operations that may fail and helps me to implement the success and error handling. Strict typing forces me to think twice and write cautious code.
With the goal of writing robust JavaScript in mind, we should utilize TypeScript as a static code checker for JavaScript – like ESLint.
TypeScript is also a language that is a superset of JavaScript. It is also a program that compiles (transpiles) this language to JavaScript. But you do not have to use these parts to get most benefits.
You can check plain JavaScript files with the TypeScript type checker. It understands plain JavaScript well enough to spot my lapses and lazy thinking. You can define types and add type annotations with JSDoc.
While there are benefits to write .ts files with TypeScript syntax, this is not necessary to get started. In several projects, I have hardly written any .ts file, but TypeScript is an essential development tool.
My advice is to install an editor like Visual Studio Code and start using TypeScript in your .js or .jsx or .vue or .svelte files today.
I understand that TypeScript adds a heavy burden for web developers who already struggle with JavaScript and its toolchains. (I guess that is, ehm, everyone here?) Fortunately, editors, libraries and frameworks make it easy to integrate typed code gradually so you can learn as you go.
My 2017 book featured several chapters on automated testing from a high-level perspective. Since then, I gained more experience on automatic testing of web sites in general and client-side JavaScript in particular.
In 2021, I published an extensive book on Testing Angular. It is the spiritual successor of Robust JavaScript.
The fact that the book deals with Angular is partly consequence, partly coincidence. I had been working on large Angular projects for clients who demanded (and could afford) technical robustness and understood test automation. Plus, Angular is built with testability in mind and the community values well-tested, robust code.
While the second book goes into all necessary details and Angular specifics, it was the big picture that inspired me. How can testing help us to make better web sites that do not let the user down, but empower them? How can we write better, more robust JavaScript through testing?
So eventually I wrote Testing Angular for the same reason I wrote Robust JavaScript: I wanted to explore and teach writing better web experiences. Preventing JavaScript failure is still my white whale.
Fortunately, testing tools improved since 2017 and both end-to-end testing as well as JavaScript unit and integration testing got more approachable and reliable. Today I put much more emphasis on automated testing to make JavaScript robust.
Angular is the “special occasion” framework in the JavaScript world. While jQuery is used on 81% and React is used on 8% of the web sites analyzed, Angular is suitable for heavy-weight corporate intranet applications with a restricted audience using desktop computers.
Especially JavaScript critics shake their head when Angular is mentioned. It ships larger amounts of client-side JavaScript than other frameworks. While it has rudimentary server-side rendering, it is not a practically viable default yet. Nonetheless, I think the Angular community listens to criticism and innovates.
Angular has some architectural advantages that allows it to evolve in order to improve the site’s robustness and thereby the user experience. The core of Angular is a compiler. Like the Svelte compiler, it transforms your high-level, declarative and human-readable code into low-level, imperative and concise code that is shipped to the browser.
The Angular team can optimize the compiler to produce more efficient and less code. In fact, the team recently rewrote the whole compiler and rendering engine. Thanks to the ahead-of-time compilation, there is dormant potential in Angular.
I am excited that the Angular ecosystem catches up with projects like Analog.js, a full-stack framework that compares itself to SvelteKit, Nuxt and Next.js. Although Angular will most likely stick with the single page application architecture, folks from the Angular community are building next-generation frameworks. For example, Miško Hevery, the creator of the original AngularJS framework and co-creator of Angular, now works on Qwik.
While I still deem it necessary to teach basic defensive coding techniques, one cannot talk about robust client-side JavaScript without discussing the whole web site architecture. I have done so in several blog posts, but not prominently in Robust JavaScript.
Client-side JavaScript affects performance and accessibility, and I have realized that these are essential aspects of robustness as well. If JavaScript is freezing a mobile browser for 20 seconds, the site is not usable, let alone robust. If a single page application breaks browser navigation features that users of assistive technologies rely on in particular, the site is not robust. And so on.
All things considered, I think we are in a crucial phase of turmoil. My hope is that the JavaScript community convenes in a respectful and productive way, takes criticism seriously and makes radical technical and social changes.