The Irony of TypeScript and React

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

Comments

[John Peters]

This article makes no proper foundation for its claims.

Typescript is just annotation for developers that love intellisense. It compiles to pure JavaScript.

It invented async await, arrow functions, classes etc. years before JavaScript adopted it.

Almost all 95% of any public JavaScript library already has type definitions ready. This means 95% of all JavaScript packages are compatible with Typescript without having one line of Typescript in them!

JSX is nice, but has no pertinence to Typescript other than Typescript does JSX too.

Don't feel bad though because even JavaScript Kings like Eric Elliot go into huge long Typescript rants writing articles that claim substantial findings that are based on nothingness.

Typescript is only a developer preference for great IDE support. That's it, because Typescript vaporizes at run time.

[Braden Snell]

Thanks for the comment! I suppose the point made here is that having type definitions is insufficient. The libraries which work the best with TypeScript are the ones with APIs that are easy to statically analyze. React is one of those libraries which is ironic because React isn't written in TypeScript. Even more ironic is the fact that Angular is written in TypeScript yet its TypeScript developer experience with its template language is far less polished than React's. This just serves to underline the point that great TypeScript support isn't about writing something in TypeScript - its about API design.

[John Peters]

" I suppose the point made here is that having type definitions is insufficient"

Insufficient for what?

"The libraries which work the best with TypeScript are the ones with APIs that are easy to statically analyze"

Ok that's a fair point, and the reason is that IDE intellisense works best with annotations. Without it, any auto-completion is just a guess. But as mentioned before in the end it's all JavaScript so run time concerns are not a consideration.

"Angular is written in TypeScript yet its TypeScript developer experience with its template language is far less polished than React's"

This is an architectural decision of Angular, it has nothing to do with Typescript itself. Typescript wasn't the cause of Angular's 'less than polished nature'. I do agree that Angular can do a lot to improve their experience such as the NGModule nonsense.

Anybody claiming that any language is a better choice when the design of the program is rotten is making false claims.

[Braden Snell]

Anybody claiming that any language is a better choice when the design of the program is rotten is making false claims.

Absolutely! Its Angular's template language API that makes it hard to statically analyze. I certainly wouldn't characterize that as a shortcoming of TypeScript. The point is building libraries with great TypeScript support is more about API design rather than if they're written in TypeScript or not.

[John Peters]

Absolutely! Its Angular's template language API that makes it hard to statically analyze.

Hard for whom, what, when, where?

The point is building libraries with great TypeScript support is more about API design

Agreed, when self discovery of an API is provided via intellisense, everybody wins. And they win as they type in the "." because intellisense pops up the suggestions along with the comments. What's not to love about that?