Is JavaScript Doing Okay?

In many ways the world runs on JavaScript—for better or worse. How long can this paradigm last? Sure, one may write the source code for websites in other programming languages, but at some point, the interactive aspects of the website must be boiled down to JavaScript, as web browsers do not come with an interpreter or compiler for other languages.

Given the entrenched position of JavaScript and the complexity of introducing alternative language support in browsers, it is likely that JavaScript will remain the dominant language for client-side web development for many years to come. A possible scenario that I foresee is a gradual shift toward a more heterogeneous web development landscape, where JavaScript interoperates with other languages through technologies like WebAssembly, rather than a complete displacement of JavaScript.

May we ever see a day when web browsers or their engines can run code in other languages straight out of the box? Again, I wouldn’t hold my breath on it, but one can dream.

Meanwhile, the world has seen the likes of TypeScript, CoffeeScript, and Elm integrated into repositories, all of which can be transpiled into JavaScript. Even so, introducing a transpiler into the proverbial pipeline comes with its costs, such as excessive build-time woes. With TypeScript, in particular, may come a certain degree of navel-gazing, uninhibited complexity, and verbosity, or what David Heinemeier Hansson referred to as “type gymnastics” in a blog post last year, where he announced that TypeScript would be removed from an upcoming release of Turbo 8. On the topic of TypeScript, he went on to say: “Things that should be easy become hard, and things that are hard become any.” Yikes!

Notably, ECMAScript, the standard upon which JavaScript is based, continues to evolve. Many features that developers previously sought in other languages are being incorporated into JavaScript, making it more powerful and versatile. Just in recent years, a handful of people have been formulating a case to add static type syntax, which would be treated as comments in JavaScript engines.

“With Types as Comments, developers can remove a build step from their apps, keeping TypeScript and Flow codebases aligned with JavaScript,” the proposal reads.

I’m skeptical that the inclusion of these static types would result in many downstream optimizations on the side of the JavaScript interpreter. After all, these static types in the linked proposal are erased. If I had to guess, they’re more like type hints in Python—very helpful for communicating intent among programmers when followed, but, in contrast to a language like Rust or Swift, utterly toothless when the rubber hits the road. (I haven’t read the entire proposal, nor have I extensively tested a local clone of it, so take my remarks with a grain of salt.)

While JavaScript is likely to remain a cornerstone of web development for the foreseeable future, the increasing adoption of the aforementioned WebAssembly and the development of new tools and standards point towards a more polyglottal future for web development. Not to mention, despite WebAssembly’s expanding set of features, I currently only see its use cases to be most meaningful for performance-critical sections of websites rather than most aspects of interactivity. (Keep in mind that this is only one person’s perspective on the constantly shifting, ever-idiosyncratic landscape of web development.)

Achieving a world where browsers can natively execute a wide range of programming languages out of the box will require significant changes to web standards and browser implementations. For now, the combination of JavaScript, WebAssembly, and advanced build tools seems to be the practical compromise that may allow the web to chug along without unforced catastrophe.