The Next Browser Language
However, there are some fair criticisms of TypeScript. Usually they boil down to performance and soundness. What’s important to note is that both of these criticisms are not unknown to the TypeScript team. These issues are due to explicit trade-offs that the TypeScript team made when they began development. In my view, these trade-offs were the correct ones to make at the time to effectively execute.
With that said, performance is arguably the most commonly cited issue with TypeScript. TypeScript is implemented in itself and that implementation is quite complex. The type system at this point is practically a mini programming language. This leads to quite slow type-checking times.
The second issue is soundness. This is less of a commonly cited issue
and more something grumbled about by programming language
nerds. Basically, because TypeScript has various escape hatches like
allowJs config option, the
any type, and intersection types,
the type system cannot ensure that the code is type-safe. Put bluntly,
you can write TypeScript and get runtime bugs. On top of this,
TypeScript lacks type inference beyond very simple cases. You have to
explicitly annotate types in a lot of places.
Again, both of these were the result of calculated
trade-offs. Bootstrapping the compiler was essential for dogfooding
TypeScript. The developers had to understand how TypeScript felt as a
language. More specifically, they had to experience writing a large
codebase. And rejecting soundness meant that developers could
incrementally adopt TypeScript in existing JS codebases. It also meant
that developers could escape the frustration of types with a single
This is worth an entire essay of its own, but TypeScript is probably the first language to be purely about developer-experience and not about semantics. The language did not add any runtime constructs. It did not affect performance. Instead it added a type system, and more importantly, it taught a community that did not use types, that did not have high quality tooling3, that did not have a culture of correctness, to adopt these values. That is an incredible feat.
The Next Browser Language
All of this is to say that TypeScript made some trade-offs 10 years ago that had a massive effect on the language. And now, with that time passed, I think it’s time for new languages with a new set of trade-offs. Specifically, I want a language that has soundness, that has type inference, and that has quick compilation speeds.
Why do I want this? Well first, I want this because I like writing languages that have sound and relatively simple type systems4. I want a language that works well in the browser and works within the existing web ecosystem. Too often languages that compile to WebAssembly attempt to ignore the rest of the web ecosystem. They want to build pixel based native UI in the browser. I think that’s a wonderful goal, but it is not my goal. I want to use this language to build normal, everyday websites. I don’t want a pure functional language and I do want a language that has conventional C-style syntax (sorry Elm!). And I want a language that exemplifies my ideas in tooling for tooling.
That said, I’m not ruling out the possibility that ReScript is the correct path forward. I need to give it another shot, as my experiences are a few years out of date. Perhaps with the split from OCaml, the language has sufficiently evolved into a good front-end option.
Hopefully with this model, computationally intensive programs like machine learning models, video games, and rendering software can be written with relative ease.
be made visible in the language. I’d want explicit integer and float
types, and perhaps an explicit indexing type like Rust’s
way if the code were to be compiled to WebAssembly, it could take
advantage of WebAssembly’s fixed width integers. Perhaps another
possibility is to create a subset of the language that compiles nicely
down to Wasm, that restricts dynamic features such as closures or
garbage collection. To interact with that subset, you’d need another
unsafe-style block, perhaps a
strict block, or alternatively the
subset could interact with the outer code with a
block. These are all hypotheticals but I believe they’re worth
The language will probably be implemented in Rust. This is mostly because I’m a fan of Rust and I believe the combination of algebraic data types, relatively fast code, limited but available mutability, and decent libraries is a good fit for a compiler.
If WebAssembly evolves sufficiently such that the performance is close to native, I would consider bootstrapping the compiler with a subset of the language that compiles to fast WebAssembly. But a Rust compiler would probably be more than sufficient for quite a few years.
If you’ve noticed, the Type Safety and WebAssembly sections are essentially taking ideas from systems languages such as unsafety and hardware acceleration, and applying them to a browser based language. This is by design. Some of the most interesting programming languages work is being done at the systems level. All I wish is that these ideas make it into the browser.
I’ve titled this post “The Next Browser Language”, but I want to be clear, it’s not a singular language. My hope is that there will be multiple languages that attempt these ideas and more. My goal here is more to inspire some people to keep innovating in the browser languages space. As for my personal attempt, I’m still sketching out this language. I’ve been playing around with an implementation called vicuna, but it’s still very very early.
Feel free to email me at firstname.lastname@example.org with any thoughts or feedback!
Which I know is popular among various groups online, but I need more than a vague notion of minimalism as a reason. ↩︎
Nor does that seem to be their goal, in fairness. ↩︎
Recall that TypeScript came out in 2012. Babel and Webpack came out in 2014. ↩︎
Okay type systems are almost never simple, but at least simpler than TypeScript’s type system. ↩︎