Browsertech Digest: “We should stop using JavaScript”

Crockford on JavaScript

In this short video, Douglas Crockford argues that it’s time for the software industry to move on from JavaScript.

The message is notable coming from Crockford. His 2008 book JavaScript: The Good Parts was among the first to champion the idea that JavaScript can, with some self-restraint, be used to engineer maintainable applications. (He also created JSON.)

In the video, Crockford’s message is that as an industry, we’ve fallen into a trap of incrementalism and complacency:

It used to be that we’d get new computer languages about every generation. […] And then it kind of stopped. There are still people developing languages, but nobody cares.

Crockford’s core gripe, if I can paraphrase it, is that we are crushing ourselves with the accumulated complexity we’ve piled on top of bad foundations, and it’s hindering our ability to build.

In my view it’s not that we’ve stopped caring, but that the web as a platform has eaten up other platforms faster than other languages have become viable within the web platform.

The movement of application software onto the web as a platform might end up being the sort of generational inflection point that catapults us past JavaScript.

That’s not to say that JavaScript is going away.

Generally, the best programming language for a given program depends on where the complexity in the program lies.

In browser-based applications, the complexity has traditionally been in managing UI state. Modern JavaScript is decent enough at this that languages focused on addressing UI complexity like Elm, Dart, and ReScript are relegated to “cult favorite” status.

But as increasingly complex software targets the browser, developers are wrangling codebases where UI is not the dominant source of complexity, like CAD tools and scientific data visualization.

It’s these developers who start to hit walls with JavaScript’s fundamental design, like:

• Performance. Although modern JavaScript interpreters go to great lengths to run unoptimized code impressively fast, the language itself doesn’t give developers many levers for optimizing hot-path code.
• Object lifecycle management. Creating objects that manage non-memory resources becomes a tangled mess of destructor callbacks, because the language lacks the features that would enable the RAII pattern common in C++ and Rust.
• Limited standard library. JavaScript has only a handful of built-in data structures. When working on something where asymptotic complexity matters, it’s a hurdle not to have canonical implementations of standard CS 101 collections like queues and ordered maps.

Notably, none of these are walls you’ll hit if you’re writing a blog or e-commerce site, which is why JavaScript isn’t going away. But I don’t take it as a given that just because browsers are becoming the dominant platform for applications, JavaScript will be the dominant language for complex application software.

Other stuff

I wrote a guest post over at Latent Space recapping our AI×UX event a few weeks back.

As announced yesterday by Apple, Mac users will be able to add web apps directly to their dock from Safari. When launched from the dock, apps have a more native-feeling UI, with all browser chrome hidden except the forward/back buttons.

Wasmer announced WASIX, which extends standard WASI for more coverage of POSIX, including Berkeley sockets and threads.

Felt blogged about how they replaced DOM-based event propagation with their own event handling when they switched from SVG to canvas.

WebAssembly is eating the database one UDF at a time, according to dylibso’s blog. Dominique and Steve wrote about Wasm’s potential as a polyglot UDF runtime for databases.

This rant about REST is a bit into the weeds but I found it cathartic and you might too.

Until next time,