The Irony of TypeScript and React

Braden Snell — Wed, 15 Jul 2020 11:29:59 +0000

React proves libraries don't have to be written in TypeScript to be good at TypeScript.

Angular. Ember. Svelte. Vue. TypeScript has been adopted by frontend frameworks with crushing inevitability. The ubiquitous (and often annoying) "Port this to TypeScript" GitHub issues, found in popular JavaScript repositories far and wide, reflect a real desire. Developers want the tooling benefits TypeScript-typed dependencies bring to their codebase. Not every library author has accepted the need to use TypeScript, but most have and more will. The notable exception to this emerging consensus is React, and the notable irony of this notable exception is the unmatched quality of React's TypeScript developer experience.

JSX

JSX was introduced to the world in 2013, when React was open-sourced. JSX takes code like this:

const element = <h1 id="hello">Hello</h1>;

And turns it into this:

const element = React.createElement("h1", { id: "hello" }, "Hello");

Its simple syntactic sugar for JavaScript. Anytime anything complex needs to be done developers must hop out of JSX land with a couple curly brackets {} and insert a JavaScript expression. Its simplicity and heavy reliance on JavaScript sets JSX apart. It also gives JSX a distinct advantage: tooling.

In 2015, TypeScript 1.6 was released and support for JSX was added to the compiler. With this release new possibilities ranging from statically validating props, to multi-file component symbol renaming, were given to TypeScript/React projects. By virtue of the close relationship between JSX and JavaScript, feature-rich tooling was relatively easy to add. Other view-describing languages have struggled to meet the bar set by TypeScript and JSX. Even Angular 2, which was written in TypeScript for TypeScript users, falls far short of React's JSX powered TypeScript experience.

The Challenge

The challenge TypeScript poses to library authors today isn't about converting an existing codebase to TypeScript. Instead the challenge is designing APIs that are statically analyzable. The custom template languages common in frontend frameworks today are an extreme example of APIs that are not easy to statically analyze, but they are far from the only example. There are libraries in the JavaScript ecosystem that (barring fundamental API changes) will likely never have great TypeScript support. TypeScript's complex brew of union types, mapped types, conditional types, and variadic types does make many patterns possible to express. Possible, however, doesn't always mean easy.

Clearly, the solution is not to simply (re)write a library in TypeScript, though that certainly helps. The path forward is difficult because it means accepting new limitations. An API with no type-safety requirements will always have more flexibility than one with type-safety requirements. But, constraints are good for innovation. Embracing the limitations TypeScript imposes often leads to the creation of far more simple APIs.

It's Ironic

Typically, a mess of complex generics is a bad idea in application code. For library code, however, the pain is generally worth the effort. Many times TypeScript support is an unasked-for burden placed upon folks building open source software in the JavaScript ecosystem. Welcome or not though, these requests reflect reality. In the end those libraries that embrace and conquer the challenges TypeScript offers will find success. Those that do not, will not reach their full potential. If you're building a new library in TypeScript, or converting an existing one to TypeScript you may wonder where to begin. Perhaps, start by thinking about the ironic truth React teaches us: libraries don't have to be written in TypeScript to be good at TypeScript.

Originally published at TypeHero.org

Introducing Type Hero

Braden Snell — Wed, 15 Jul 2020 11:29:43 +0000

Intelligent commentary on the TypeScript ecosystem and high quality, TypeScript-first tools.

Dear TypeScript World,

👋 Hi, I'm Braden and I'm launching Type Hero.

Microsoft released TypeScript 1.0 to the world in April 2014. I was working in a C# shop at the time and we were quick to adopt TypeScript for our frontend development. That early introduction to the language shaped my career in the ensuing years. I sought out opportunities to work with TypeScript. I applied for positions where I knew I could use the technology. Over the years, I've built some pretty cool stuff using the language ranging from web app frontends and backends to mobile apps. I've become intimately familiar with TypeScript's limitations and flaws. I've also seen first-hand the positive difference it makes when building applications large and small.

These years of experience have left me with a lot of strong opinions. Type Hero is a home for those opinions. Its also home to a growing group of open source projects designed to make building type safe applications a little easier. Type Hero won't be a personal blog. Just like the open source projects under the Type Hero name, I hope it eventually attracts thoughtful contributions from folks besides me. If you're looking for intelligent commentary on the TypeScript ecosystem and high quality, TypeScript-first tools look no further than Type Hero.

Enjoy reading!

Braden