If you want to play a role in shaping the future of Crank, then I’d be very happy to have you.
In short, I felt like I was forced into writing a framework because, up to that point, I had been using React happily, but I was increasingly frustrated by the latest APIs and how each of them seemed to take a little bit of my ability to reason about components away from me. I knew I wanted to continue using JSX, and I had been experimenting a lot with generators and async generators, and it suddenly hit me that I could write stateful components with generators and I really just followed this idea to its logical conclusion.
JAXenter: What kind of project would profit from using your framework instead of React?
Brian Kim: Greenfield projects! If you’re starting something new and want to be on the frontier and play a role in shaping the future of Crank, then I’d be very happy to have you. There’s enough different with React that I don’t think you could just convert a React app in production to Crank easily, though I’m curious if there are codemod solutions for this in the future. One thing I would warn React developers about, though, is that I’ve noticed that React developers are putting more and more logic into hooks. This is an extreme form of vendor lock-in, in the sense that hooks cannot be called outside of React. The more hooks you use, the harder it will be to migrate in the future.
JAXenter: You specifically say that the Suspense API in React was a tipping point for you. What was it that you did not like about it?
Brian Kim: There were a couple of things that I did not like about Suspense:
- The mechanism: Suspense requires components to throw promises like you would throw errors to indicate asynchrony. I know that this might change, but it’s how React and library maintainers assume it will work as of today. I don’t think it’s a sound mechanism because it means all async calls require caching, which can be tricky to work with. Cache invalidation is one of the two hard problems of computer science, and to ask people to have a cache for all their async calls seems like a big ask to me and opens developers up to a whole class of stale cache bugs.
- async/await syntax: When I finally got async components working, I was surprised at how natural it felt, while React developers were constantly saying virtual DOM and promises don’t match. Every day, as beginners learn React, one of their big questions is: How do I use async/await syntax? There’s no good answer, because it almost seems like React goes out of its way to make using async/await hard. For instance, the useEffect hook requires the callback to return a function, so you couldn’t make the callback asynchronous.