a blog by Boris Cherny

Data Fetching on the Web Still Sucks

It’s 2021, and data fetching on the web still sucks. This is crazy!

If you’re building a web app at scale you have plenty of options for data fetching, transport, caching, and management:


Public Opinion

I don’t usually write about politics, but today was a weird day.

Thousands of people gathered outside the Capitol building in Washington DC today, some of them going into the building, some with guns. A woman got shot. All of this in response to Donald Trump’s remark:


React+TypeScript: Use unions of objects for props

When typing React component props using TypeScript, I often see code that makes use of optional and nullable fields:

type Props = {
  href?: string
  onClick?: () => void
  text: string

function Button(props: Props) {
  if ('href' in props) {
    return <a className="Button" href={props.href}>{props.text}</a>
  if ('onClick' in props) {
    return <button className="Button" onClick={props.onClick}>
  throw ReferenceError(
    'You must pass either href or onClick to <Button />'

let a = <Button text="Click me" href="" />
let b = <Button text="Click me" onClick={() => {}} />

// OK. Should be an error
let c = <Button
  text="Click me"
  onClick={() => {}} />

// OK. Throws an error at runtime
let d = <Button text="Click me" />

In this example, Button is a React component that takes a prop text, and either an href or onClick prop controlling what happens when you press the button. Either href or onClick might be defined, and we throw a runtime exception if neither of them are defined.


On Contagion

If you have a tree with a node that has a property P, and all of its parents also need to have property P, then P is contagious.

When can that happen?


13 Tips for Writing a Technical Book

I spent the last year and a half writing my first technical book for O’Reilly (Programming TypeScript). I’d never written a technical book before. In fact, prior to the 300-page book, the longest thing I’d written was a 20-something-page paper in college.

Why’d I write the book? I love TypeScript, and I didn’t see any great resource out there that explained not just the language and build system features, but went deeper to explain why things were designed the way they were, how the different parts of the language fit together, how that compares to other languages out there, and how it all looks in practice. Those are the sorts of things you can only learn through lots of research and practice, and that was sorely missing from the handful of relatively brief and practical TypeScript guides out there today.


On Derived State

Derived state for frontend applications comes up a lot. State B depends on State A, so after you update A, by the time you read B you want it to be updated based on the latest value of A. There’s a bunch of ways to model this, involving different tradeoffs:

  • Do you treat derived data and non-derived data the same?
  • Should users interact with the two the same way?
  • Do you re-compute dependent data in a lazy or eager way?
  • How much control do you need over re-computing derived data?

A popular solution is selector libraries like Reselect. The way they work is:


JavaScript in 2017: Year in Review, Predictions for 2018

2017 has been a wild year for JavaScript and frontend development. A new version of the language was released, GraphQL was announced, compile-to-JavaScript languages were rolled out by the dozen, React became the default frontend framework, and more. Here’s a rundown of 2017 trends, and my predictions for 2018:

The Rise of Compiled Languages on the Frontend

Language-to-language compilers let you do things like compile JavaScript to TypeScript (I think there will be a lot more interesting work in this space!), TypeScript to Flow, Flow to TypeScript, TypeScript to Reason, SQL to TypeScript, JavaScript to Go, and Go to JavaScript, to mention a few.


Angular 1: 8 Lessons For Designing JavaScript Frameworks

I’ve used Angular 1 at my last couple of day jobs, and have gradually grown to be grumpy about it. At the time when it was released (2010), the framework had some really cool ideas baked in: automatic Model → View syncing (unlike Backbone), automatic View → Model syncing (like Knockout), observing arbitrary expressions, a built-in dependency injector, a neat filter syntax. All of this was pretty revolutionary; the framework took some time to learn, but once you did, you were suddenly really, really productive.

In the seven years since, Angular’s Big Ideas have been battle tested by thousands of engineers. Through this testing gauntlet, a lot of problems with its Big Ideas emerged and Angular 1 has since been supplanted by Angular 2. So as sort of a post mortem, I wanted to put my thoughts about where Angular 1 failed down on paper, to inform my own framework designs as well as others’ designs.


Options in TypeScript

If you wrote in Scala or Haskell before you tried TypeScript, you may have found yourself wondering: Where are the Options at?

For those not familiar, here is an excellent introduction to Scala’s Option type. At a high level, Option is an abstraction over null that gives useful semantics around running functions over possibly-null values. It implements a monad, a functor, and some other structures, but that’s not important for this post.


The Best Frontend JavaScript Interview Questions (written by a Frontend Engineer)

I was at a Free Code Camp meetup in San Francisco a few days ago (for those not familiar, Free Code Camp is a group of people who get together to learn JavaScript and web development), and someone getting ready for frontend dev job interviews asked for JavaScript questions to practice. After a bit of Googling, I couldn’t find any lists I could point her to and say “if you can do these, you can land a job”. Some came pretty close, some were silly, but all were either incomplete or asked questions that people don’t actually ask in real life.

So, based on my experiences on both sides of the interview table, here goes. These are a sampling of questions I’ve asked and been asked when hiring frontend engineers. Keep in mind that some places (like Google) focus more on designing efficient algorithms, so if you want to work there you should practice past CodeJam problems in addition to the stuff below. If you have a question that belongs in one of these lists (or I’ve made a mistake somewhere), shoot me an email.