Tradeoffs of Preact and React

Preact is an implementation of React’s core APIs in a very small library. In this post I’m going to give some personal thoughts on the trade-offs of using it compared to React based on my experience as an individual contributor and a front-end lead for a small team of developers.

Functionality

Performance

• Having less code makes everything which processes that code run or start faster. For developers this includes build times, test execution times, continuous integration cycle times and how long it takes the application to load in development. Fast cycle times make for happier and more productive developers. For end users, it affects how long it takes the application to load in their browser, particularly on lower-end devices and slower networks.

  Choosing small libraries, such as Preact, or avoiding dependencies entirely (eg. by using APIs built into browsers), can help with this.

• As a developer, you can get a deep understanding of how Preact works in a small amount of time. In my experience having a deep understanding of a platform can be very useful when problems arise, or when you encounter a performance issue and need to optimize. If you want to find out how an API in Preact really works, it is typically much quicker to answer that question than for React.

• Preact is less weighed down by the need to preserve 100% compatibility with existing code. Since the project started after React, it had the advantage of being able to avoid including some legacy or deprecated features.

Documentation and ecosystem

• React has very good documentation. It explains now just what the APIs are and how to use them, but also how to solve various problems in idiomatic ways. Much of the documentation, especially the conceptual material, is also applicable to Preact. If a new developer joins your team and has not used Preact before, it may not be obvious that they can benefit from this wealth of material.

• React has extensive built-in runtime checks for incorrect usage of APIs. Preact has some checks for common issues in its preact/debug package, but nowhere near as many as React. This means that with React, it is more likely that a runtime warning saves you debugging time by alerting you to a problem. I highly recommend using static analysis tools (eg. ESLint, or a type checker such as TypeScript) but these are even more valuable for Preact than React.

• React has a large ecosystem of tools. Most of the tools which rely on static analysis of code can be very easily made to work with Preact, these include syntax highlighting, type checking (TypeScript), linting (ESLint), transpilation (Babel, TypeScript). The default configuration however usually assumes React, so a small amount of additional configuration may be required.

  Tooling which requires runtime interaction with the library, such as the React DevTools, typically requires more work for Preact to support.

• Significant new features generally come to React first. The latest version of Preact, v10, has support for modern features such as fragments, hooks, the new context API. However these came to Preact some months or more after they appeared in React.

Recommendations

• If you or your team are new to React, I would suggest reading the React documentation and using React directly. At this point, your main concern should be getting a good conceptual understanding of how to use it and getting something running with minimal distractions.

• If you are building an interactive widget to be loaded into existing HTML pages, then Preact may be a good fit as it can load very quickly and will not significantly impact the overall page’s download time.