Made withPreactClip

Preact Vs React JS

S

Stephen Blum

Creator on the Preact channel

Watch on YouTube ↗

11K viewsDec 26, 20239:33 runtime

Explore the key differences between Preact and React to determine the best framework for your next web application. This analysis investigates Preact's claims of being a faster, 3KB alternative to React, examining the actual minified file sizes and debunking common myths…

Chapters

#preact#clip#frontend

Preact vs. React: The Core Promise

Preact is positioned as a drop-in replacement for React with a focus on being a faster and smaller alternative. The primary goal is to address the common problem of React applications becoming slow and having a bulky payload, thereby improving the end-user experience.

Note
Preact aims to fix performance issues at the framework level, rather than requiring developers to heavily optimize their application code.

Investigating the "3KB Alternative" Claim

A significant claim made by Preact is its tiny 3-kilobyte footprint. However, a direct comparison of the latest minified library files shows a different story.

The minified JavaScript for Preact was found to be around 11 KB, not 3 KB.
When compared, Preact's minified and even uncompressed file sizes were slightly larger than React's.

Important
The claim of a 3KB size might be achieved through specific configurations like tree-shaking or by excluding core features, which are not representative of a typical out-of-the-box setup.

Key Technical Differences

Beyond size, Preact implements several key architectural changes to boost performance:

Virtual DOM: Preact features one of the fastest Virtual DOM implementations available. It uses a more targeted and less heavy-handed approach compared to React, which is a major source of its performance gains.
Synthetic Events: Preact removes React's synthetic event system. Instead, it uses the browser's native addEventListener for handling events. This simplifies the framework's internal logic and relies more on standard browser capabilities.
Core Features: To achieve a smaller base size, Preact excludes features like Hooks from its core library. Developers must import preact/hooks separately if they need this functionality, which can feel like "cheating" on the small bundle size promise.

Developer Experience (DX) Enhancements in Preact

Preact offers quality-of-life improvements that lead to writing less and more intuitive code:

HTML Attributes: You can use the standard class attribute for CSS classes, instead of React's className.
SVG Attributes: Preact supports native SVG attribute names (e.g., stroke-width), whereas React requires camelCase versions (e.g., strokeWidth).

Tip
These small changes reduce cognitive overhead and the number of extra steps required when translating HTML/SVG into JSX, leading to a faster development workflow.

When to Choose Preact

Improving Existing React Apps: If you have a slow React application, migrating to Preact can provide significant performance gains with a relatively straightforward migration path using the preact/compat layer.
New, Performance-Critical Projects: For new applications where a fast UI is a top priority, starting with Preact is a strong choice.

Final Verdict

Both Preact and React are powerful frameworks that share a similar component-based foundation. While Preact currently offers tangible performance and DX advantages, it's likely that React's core will continue to evolve and incorporate similar optimizations over time. For now, if you're prioritizing speed, Preact is an excellent choice.

Investigating Preact's 3KB File Size Claim

PreactJS is going to give us a lot more power and speed and performance compared to the standard ReactJS framework. The idea with Preact is that it's a lot faster and smaller. However, when I looked at the when I was looking at the minified file size before and after comparing React with Preact, they look the same. Am I missing something?

So this might be a little bit tricky to see. This is the Preact minified JavaScript and I'm going to compare that with the React minified JavaScript here. Looking between the two, they look very similar, right? Am I looking at it wrong? But also in general, that's not a whole lot of JavaScript, but it's more than 3 kilobytes. Even looking at the minified Gzip version of both libraries, they are basically the same size. And then if we unzip them and then we look at the uncompressed version, Preact actually ends up being a little bit bigger. Am I looking at this right? Like, what am I missing?

So I haven't yet been able to validate the 3 kilobyte claim here. Oh, 3 kilobyte alternative. Yeah, it's supposed to be just 3 kilobytes worth of JavaScript. I've not found that. I might be looking at it wrong. But the file I downloaded it, okay. And this is, I'm also checking here on the latest version. Even compared with the website that's actively using the module, it's still not... that's not 3 kilobytes. Yep, I'm looking at it right now. It says 11 kilobytes. That's, and it's a little bit bigger than React itself. What's going on?

The Virtual DOM Advantage

Well, here's the deal though. Even though we're not seeing the 3 kilobyte difference file size, we do have some improvements on the virtual DOM. Where React and other frameworks are going to be more heavy-handed with the virtual DOM, it seems like this Preact helps by using just the right amount. What this does is it helps because virtual DOM can help slow some things down if it's overused, but if you use it the right way, it can build a good experience. It claims says it's the fastest virtual DOM library out there, well, one of the okay, and they don't sacrifice portability, which is great, so it still works everywhere React would work with a few exceptions. So just looking at the example code here that they have, it's basically exactly React, just supposed to be a little bit faster.

Why React Can Be Slow and How Preact Solves It

There's a problem with ReactJS, a very common foundational problem of it is it's really easy to make your web app, your front-end development, go really slow. The whole point of React is supposed to help accelerate a larger team being able to work together on the same project, and it does that. However, the output ends up being a slow render and a bulky payload at the end of the day. This generates a poor user experience, especially on devices that need to spend extra compute where they might be on a battery or even desktop systems with beefy, like excellent hardware still have a hard time rendering out the UI anything written in React.

Now sure, there's some patterns that we could use that would allow us to help accelerate the end-user experience. However, React makes it way too easy to make this slow at the get-go, and then you'll have to spend a lot of extra effort optimizing. But there's another choice we have: Preact, which is... they just added a letter to it.

The idea behind Preact is to help us make things go a lot faster, just overall that speed performance and a good user experience. And this is where it makes sense to add the fixes. If you're going to have a problem with the slow framework like React, where they have a—they're oversubscribing on virtual DOM and the core implementation is slow because of the large file size, why don't we fix the framework rather than fixing the application to leverage the best it could leverage in terms of performance?

So that's where Preact comes in. The idea is that they wanted to make Preact super small, a low footprint, low profile, but also take out a lot of the challenges with the virtual virtual DOM here. So Preact helps you a lot by taking advantage of virtual DOM in the best way it can as it compared to, looks like, every other framework that leverages virtual DOM.

Core Similarities and Benefits of React/Preact

Why would you choose ReactJS as your application framework when you're building a web app? Well, it helps simplify larger projects as teams are able to work together in component-based infrastructure. It allows us to build better applications as a team. Additionally, there's a lot of simplification that goes into building with ReactJS directly rather than having to interact with native browser DOM APIs. Now, this is true for both React and Preact; they're basically providing that same value.

There's also a bonus using React with the ability, if you want to use React for content-based websites where you want search engines to be able to index all the values there for SEO purposes, you can have React rendered on the server side, which then gets delivered to the browser as text, which makes it a lot easier for the browser to read and index the data on your website.

Key Technical Difference: Synthetic Events

While React and Preact seem to be pretty much the same, Preact comes in with a boost in performance. It gives you better overall under-the-hood power in terms of its capability as it's optimized some of the shortcomings with React. Now, while it says performance and speed are definitely a part of the picture, which I can see the case—I haven't done any benchmarks—however, size, I did look at the size, and Preact, even though it says it's supposed to be smaller, is actually bigger than the standard React.

For example, I downloaded the minified version of ReactJS and PreactJS. You can see it's just a little bit bigger with Preact, even though it says it's supposed to be 3 kilobytes, it's actually 11, even when you have it in the form of an EcmaScript module. Otherwise, Preact is essentially just React because it's built... they're... it's built off of React. It's advertised that Preact is like a booster dose that aims to fix the bottlenecks that hamper performance. And when you're migrating to help boost the performance of your app, there's a compatibility layer that you can just bump right in immediately, which helps you migrate to Preact immediately.

The mainline difference between Preact and React under the hood is the synthetic events, which are a core part of React, that have been removed by Preact. And instead, they're leveraging the browser's event listeners. That should simplify things a bit more from a code perspective, right? Because now you have to write less code and you get to rely more on the browser itself, which... the browser is a nice framework as is. You might as well leverage as much as you can of it.

The "Gotcha" of Preact's Small Size

We're taking a look at PreactJS, which is an optimized version of React. There are some differences though. When looking through the codebase, we see that there are some interesting gotchas. It was advertised that Preact is 3 kilobytes compared to the React, which would be 10 kilobytes that I'm seeing. However, they're the same size. I'm looking, I've been looking at this, I've been looking at other options, and they are the same size. Now, maybe I suppose we could do some tree shaking of some sort or like maybe eliminating parts of this, but overall, this doesn't look like a whole lot of JavaScript. This is the entire library right here.

Something that they've described and how they've improved the whole footprint of Preact was that they've basically taken parts out of React, like hooks, which are not part of Preact. You have to import them separately, which, I don't know, it feels like cheating. It feels a little bit cheating because you have to start pulling in extra stuff that you might need, and then it kind of detracts from that whole idea of a smaller library footprint. However, there still is a benefit as Preact is described to be one of the quickest virtual DOM libraries available when rendering. So there's still that aspect to it. Now, there's no real reason that maybe React as a core library could go back and implement these advancements directly, which would be nice, and maybe they will or have already.

Developer Experience Improvements

There are more advantages with Preact as well. One of the nice things is that you don't have to do extra steps with React when you're building out your app. For example, with Preact, you can just leverage direct names and you don't have to retype up sort of create a different attribute name like className here. That's something you have to do extra for React, so Preact helps accelerate that, which is very nice. I much rather type less and have less code to deal with.

This goes true as well for SVG. We can see that it supports... Preact will support native SVG attribute styles or the naming structure, rather than React which requires the camel case. So in React, you have to go back and modify all these things when you're dealing with building out the HTML inside your app. You have to do these extra steps. Well, Preact doesn't, which is very nice.

Conclusion: Which Framework Should You Choose?

Overall, I'm looking more at React versus Preact here and I am seeing that they are basically the same with a few extra bonuses that you get with Preact and having a smaller code footprint in a few areas.

So whether you end up using Preact or React, you'll be leaning on a powerful framework that leverages the capability of providing a good user experience in applications. If you're looking at a way to... if you have an existing React app and you want it to improve the performance, it's very likely that you should take a look at Preact because you can get some extra gains there just by how it's implemented. There will be a few changes here and there, but there is a nice migration path. If you're getting started and you want to choose a new framework and you know that you're going to be building a more advanced UI, then Preact is probably a great place to start.

Of course, with React being a very popular library, we are going to see more of those innovations on performance improvements directly embedded into the core of React. So no matter which one you choose, you're probably on the right path. Since Preact and React provide the basic same foundation of functionality, basically the same, you will end up having no problem choosing one or the other. Might as well pick Preact right now, but it's possible in the future React will also have all those advancements baked in as a default as well.