Ben Sangster, staff software engineer at e-commerce company Etsy, recently announced the completion of Etsy’s migration from React v15.6 to Preact 10. Going beyond the difference in library size, Sangster argued that adopting Preact lowered the risk associated with migrating Etsy’s large codebase. As Preact was already used by Etsy’s front-end team, migrating to Preact for seller-facing pages would avoid maintaining a fragmented stack.
Sangster described Etsy’s migrating away from React to Preact in the following terms:
We migrated all of the React v15.6 code at Etsy to use Preact. It was a huge win, and the migration was significantly easier (with far fewer rewrites or refactors of old code) than going to v16 would have been. The Preact team was amazing through the whole process.
[…] It was so seamless that I was able to put the migration behind a flag and literally use the exact same client with one bundle that used React v15.6 and one bundle that used Preact. We ramped up slowly and could track library-specific errors in Sentry using the flag.
In an accompanying blog post, Sangster explained in detail the three reasons that led to migrating parts of Etsy’s codebase to Preact instead of the latest version of React.
First, adopting Preact reduced the risk of migration the most. Developers have welcomed React 16’s new features (e.g., error boundaries, fragments, portal, better error stack traces, custom DOM attributes, hooks in React 16.8). While the React 16.0 documentation mentions few breaking changes in exchange for those new features, some developers reported migration pains. Usage of React.PropTypes or React.createClass, and depending on pre-React 16’s internals are typical migration pain points. While errors or warnings in the console will help in many cases, updating dependencies may be tedious. Discord’s Michael Greer said:
But not all package errors are so easily discovered, and herein lies the real pain.
We ran into an error which took us 2 days to track down to a library, and you may find the same.
The routing library, a key dependency of many web applications, may also cause migration pains. Sangster explained that, overall, Preact presented a better migration risk profile:
- Preact is API compatible with React, which means that we are not making any changes by using Preact which would be incompatible with migrating to React at a later date.
- The migration to Preact v10.4.2 would be significantly easier and require far fewer steps to complete, due to Preact’s emphasis on compatibility with both React v15 and React v16. […] there are a number of code updates we won’t have to make if we move to Preact. We should do them anyways, but the process will be slow and require refactoring a fair amount of code in somewhat tricky places.
- There do not seem to be any major obstacles from a developer tooling perspective to adopting Preact.
Second, Etsy’s Front-End Systems team was already using Preact. Using Preact everywhere in Etsy was likely to make developer life easier. Sangster said:
[…] ensuring that we use only one Preact / React library for all of Etsy would greatly reduce developer difficulty over time. Among other things, having to support/test in React and Preact for tools like the Web Toolkit would add a lot of overhead for that team and others working on shared tooling and architecture.
Third, Preact’s bundle size (Preact v10.4.5 is 4KB) is six times smaller than React’s (React v16.13.1 is 38.5KB when adding react and react-dom).
Developers often strive to reduce the JavaScript shipped by web pages. As a matter of fact, JavaScript scripts need to be downloaded from the network, parsed, and executed. Latency (time to interactive), memory and CPU usage generally increase with the amount of JavaScript. On low-end mobile devices, the heavier consumption profile may reduce battery life.
Sangster’s migration announcement tweet attracted the attention of many developers. To Dr. Axel Rauschmayer who enquired about the hurdles present in React 16 that Preact didn’t have, Sangster answered:
We have a lot of oooooold code that’s unowned and a lot of old libraries — including a number checked into the codebase and manually modified to work with React v15. Upgrading to React 16 caused some API issues (esp. Portals/legacy Context/refs) that would require lots of work.
Instead, we migrated to Preact and could refactor that code in place to the most modern stuff available — it made a lot of stuff way easier to think about, rather than some components/libraries which would have to get upgraded in lockstep.
Sangster’s blog post contains many additional technical details that contribute to its reasoning. Preact self-describes as a fast 3kB alternative to React with the same modern API. Preact is open sourced under the MIT license.