Managing our focus during development can be a challenge. Here's a common scenario: we're in the middle of working on user.ts when we find ourselves thinking: "I really need to go change this other thing in login.ts". But it's rarely a good idea to interrupt ourselves during a complex change. We have a lot of context in our heads that we don't want to lose.

This post lists four TypeScript features that we recommend you avoid. Depending on your circumstances, there may be good reasons to use them, but we think that avoiding them is a good default.

When explaining a technology, we have to decide how to approach its shortcomings. There might be mistakes in its design, or it might have usability problems, or it might be unreliable. How do we approach these and how much emphasis do we place on them?

Recently, our Cypress tests started hanging silently. This post explains the cause: because of a subtle part of TypeScript's language design, some circular data structures were invisible in the code, which caused a serialization error, which Cypress handled incorrectly. If we don't understand the subtleties of our tools, bugs like this can be inscrutable; but if we learn the subtleties, they can be quick, if annoying, speed bumps.

This is a story about how we used io-ts to save React useReducer state for later. Saved state may be restored months later, in a different browser, while both the React code and the data used by the reducer have continued to change over time. The solution described here is in production on the site you're looking at. First, a short description of the application itself:

TypeScript is very good. We ported our frontend and backend to it with no regrets. We have a much smaller test suite than we ever could've had in a dynamic language. All of this is great. Still, there are downsides to TypeScript, and we should be honest about them too.

We ported our React frontend from JavaScript to TypeScript, then did the same for our Ruby backend. It was a success; large classes of mistakes became impossible. You might wonder whether we could have achieved these results with full test coverage instead.

We ported our React frontend from JavaScript to TypeScript, but left the backend in Ruby. Eventually, we ported the backend to TypeScript too.

The beta version of Execute Program was written in Ruby and JavaScript. Then we ported all of it to TypeScript in multiple steps. This is the story of the frontend port, which was the first step.

The SQL language is old, strange, and important. We'll take those in reverse order: