Depending on your needs, the benefits of the smaller package might not be clear. React certainly has an immense ecosystem and new features coming out all the time that Preact may or may not maintain parody with.
First, I want to note there is no "100% compatibility". I think it's a misleading claim and personally I wish Preact was a bit clearer in its marketing. Preact doesn't support some React features released more than half a year ago and, as far as I can tell, intentionally doesn't implement support for some cases we consider important (for example, handling of nested keys). You probably won't bump into them on the first day of your app development, but when you do, they can lead to very confusing bugs.
Preact implements some of the newer React features (e.g. portals and modern context API) outside the main library but that comes with compromises. For example, portals implemented outside of Preact won't "respect" the mounting order of the component tree, like they do in React. This can also lead to surprises and incorrect code. And there are many small things like this that come out of Preact intentionally choosing to limit its core library scope. That's not to say Preact's approach isn't valid, but that I think there is a certain power in designing these features to work cohesively together.
I've also heard people say they find certain value in the level of testing React receives. Any crash or a regression in core logic gets discovered pretty quickly because we get million reports from Facebook users and can bisect them to a specific change. So every release is battle-tested, and I think React users appreciate that certainty. Similarly, thanks to error boundaries in React 16 you can make your app much more resilient to crashes (which is a common problem in single-page apps) and recover from them gracefully.
"Preact is super fast" is often repeated as a fact but I encourage you to take a medium-sized React app and replace React with Preact (both pure and compat—they're different!), and compare the performance yourself. Preact is lighter on the network, but in terms of interaction speed there are many things React does to optimize the performance of real-world apps that Preact doesn't. Benchmarks that render a thousand of rows or TodoMVC apps often fail to capture what happens in real codebases. It depends on what kind of interactions you're optimizing for, and how much product code you have. Also, don't forget that pure Preact and Preact Compat (which you probably intend to use) have different performance characteristics.
With React, our goal is to evolve the component model by adding features that cohesively work together. In the recent releases we've added support for fragments (returning multiple components from render), error boundaries (writing fault-resilient components), portals (declaratively rendering to a subtree), modern context API (efficiently passing values deeply down the tree), and more. All these features naturally work with each other because they are implemented in a single library and intentionally designed to work well with each other.
We're also working on fundamentally new capabilities related to more responsive interactions and data fetching (reactjs.org/blog/2018/03/01/sneak-...). I really encourage you to watch my talk because it's hard to believe without seeing :-). But I think this vision is pretty interesting and I'm excited to see these features getting closer to shipping.
Personally, I would probably choose Preact for a use case like embedded widget, but I'd probably pick React for an app I intend to maintain and grow. Your perspective is probably different and that's cool--I just wanted to share mine since you asked.
Really well explained, I intend to make a large app that I need to maintain eventually, I think I'll go with React then, although I want to try Preact for other apps. Thanks for your well detailed explanation :D
Many folks are choosing Preact for apps so I encourage you to try both and see what works well for your use case. I just described my (biased) perspective on this.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Depending on your needs, the benefits of the smaller package might not be clear. React certainly has an immense ecosystem and new features coming out all the time that Preact may or may not maintain parody with.
Perhaps, @dan_abramov or @_developit or others have some thoughts?
Disclaimer: I work on React :-)
First, I want to note there is no "100% compatibility". I think it's a misleading claim and personally I wish Preact was a bit clearer in its marketing. Preact doesn't support some React features released more than half a year ago and, as far as I can tell, intentionally doesn't implement support for some cases we consider important (for example, handling of nested keys). You probably won't bump into them on the first day of your app development, but when you do, they can lead to very confusing bugs.
Preact implements some of the newer React features (e.g. portals and modern context API) outside the main library but that comes with compromises. For example, portals implemented outside of Preact won't "respect" the mounting order of the component tree, like they do in React. This can also lead to surprises and incorrect code. And there are many small things like this that come out of Preact intentionally choosing to limit its core library scope. That's not to say Preact's approach isn't valid, but that I think there is a certain power in designing these features to work cohesively together.
I've also heard people say they find certain value in the level of testing React receives. Any crash or a regression in core logic gets discovered pretty quickly because we get million reports from Facebook users and can bisect them to a specific change. So every release is battle-tested, and I think React users appreciate that certainty. Similarly, thanks to error boundaries in React 16 you can make your app much more resilient to crashes (which is a common problem in single-page apps) and recover from them gracefully.
"Preact is super fast" is often repeated as a fact but I encourage you to take a medium-sized React app and replace React with Preact (both pure and compat—they're different!), and compare the performance yourself. Preact is lighter on the network, but in terms of interaction speed there are many things React does to optimize the performance of real-world apps that Preact doesn't. Benchmarks that render a thousand of rows or TodoMVC apps often fail to capture what happens in real codebases. It depends on what kind of interactions you're optimizing for, and how much product code you have. Also, don't forget that pure Preact and Preact Compat (which you probably intend to use) have different performance characteristics.
With React, our goal is to evolve the component model by adding features that cohesively work together. In the recent releases we've added support for fragments (returning multiple components from render), error boundaries (writing fault-resilient components), portals (declaratively rendering to a subtree), modern context API (efficiently passing values deeply down the tree), and more. All these features naturally work with each other because they are implemented in a single library and intentionally designed to work well with each other.
We're also working on fundamentally new capabilities related to more responsive interactions and data fetching (reactjs.org/blog/2018/03/01/sneak-...). I really encourage you to watch my talk because it's hard to believe without seeing :-). But I think this vision is pretty interesting and I'm excited to see these features getting closer to shipping.
Personally, I would probably choose Preact for a use case like embedded widget, but I'd probably pick React for an app I intend to maintain and grow. Your perspective is probably different and that's cool--I just wanted to share mine since you asked.
Well put!
Really well explained, I intend to make a large app that I need to maintain eventually, I think I'll go with React then, although I want to try Preact for other apps. Thanks for your well detailed explanation :D
Many folks are choosing Preact for apps so I encourage you to try both and see what works well for your use case. I just described my (biased) perspective on this.