3 ms·

In a way React has already had the same fate. It really astounds me that react-dom is >100KB big while the API-compatible Preact is something like 7KB. There a

In a way React has already had the same fate. It really astounds me that react-dom is >100KB big while the API-compatible Preact is something like 7KB. There are edge cases where you can't just drop it in directly as a replacement but you can very, very many times. Really makes me wonder what React is doing with that extra 93KB of JS, it's not actually even that fast compared to other frontend frameworks.

franciscop 3y ago
I wrote a jQuery (30kb) alternative called Umbrella JS (2.6kb) and based on my experience and if I had to guess, probably most of the rest of React's size is in compatibility stuff. Like making sure events work uniformly across browsers, I remember that making everything work with SVGs was also a big milestone, normalizing events (e.g. we have synthetic events which are basically React's events on top of the normal DOM events), etc. An astute/old fashion dev will realize that React's onChange actually behaves like `addEventListener('input')` and not really like `addEventListener('change')`, since the latter only triggers on blur and not on each keystroke. I strongly believe React team is shooting themselves on the foot by not making Error Boundaries into Hooks. If they did, someone could create a Preact 2.0 so to speak that is like React but purely functional (no classes). But since we don't have that, and error handling IS an important part of React, any react alternative would have to implement classes fully as well, which might retract many from even trying to create a React alternative (I don't think myself smart enough to do a React alternative properly, but I'd certainly tried if they did this).
- acemarke 3y ago
  There's actually a recent PR up for a `<Catch>` component: - https://github.com/facebook/react/pull/26854 https://github.com/facebook/react/pull/26854
- awayto 3y ago
  I wonder if error boundary components/functionality are an anti-pattern. They invite the developer to create components which expect to fail. Even basic hide/show logic is better than expecting devs to orchestrate unified error handling across the app.
  - solardev 3y ago
    What's wrong with components that expect to fail? Don't you need some way to notify users of predictable problems?
Uehreka 3y ago
OK, hold up, I’ve been hearing this line forever and I’m here to hold it to account: > the API-compatible Preact is something like 7KB Something is up here. Either Preact is not in fact API-compatible (in which case people should stop saying this), or the React devs are dummies who have never thought of Preact’s architecture or looked at its open source code (I rank this unlikely) or there’s somehow some other catch that no one talks about. Which is it? Why doesn’t React just use Preact’s architecture if it’s so lightweight? What is Preact actually giving up?
- Inviz 3y ago
  It's fully api compatible pre-fiber. in fact it has more apis in some regards.
  - tcpipchip 3y ago
    Hi Did have success on littlefs on stm32 ? On arduino ? Please, contact me tcpipchip@hotmail.com PS: sorry if I post here
    - Inviz 3y ago
      I did have some success with it. I used their generic config way to hook up fro block writing/erasing and implemented those parts in the os i was writing. However one thing I was not a fan of is that its IO is synchronous, so you have to use some sort of coroutines/multitasking unless you're ok with blocking
- gedy 3y ago
  From memory, Preact doesn't use synthetic events system like React and its runtime is much smaller. It can't be used generically like React can in mobile (React Native) or similar though because of this
- afavour 3y ago
  There are definitely differences here and there. One I can remember from a year or so ago is that Preact deprecated support for string refs while React still supports them (though the docs point out they intend to deprecate IIRC). Honestly to my mind the biggest thing is that bundle size just isn’t a priority for the React team. A sibling comment pointed out that React does a lot to correctly handle SVGs. Good to have, obviously, but what percentage of React users are making interactive SVGs? Probably not a whole lot. If they wanted to the React folks could break that out into a react-svg module or something and save some KB. But they don’t want to. To my mind React these days is the enterprise software of the frontend. It’s big, it’s bulky, but it does absolutely everything with a minimum of fuss. They have a one size fits all approach and they’re not willing to deviate from it.
strogonoff 3y ago
It’s often cheaper to couple things tightly. Abstractions and interfaces have costs. However, they also have benefits. Perhaps React and Preact is one such example. React is a tiny fully agnostic library that does components, props, hooks and all that jazz. You can use it anywhere, from DOM to CLI. To tie it to DOM, a separate library exists—named, unimaginatively, ReactDOM—and that’s where the 100KB heft comes in. Preact is the opposite: smaller, but coupled to DOM. The architecture probably doesn’t facilitate cool stuff like render components to embedded LCD[0], and even to do SSR you would have to add extra libraries. [0] https://github.com/doodlewind/react-ssd1306/blob/master/docs/tutorial.md https://github.com/doodlewind/react-ssd1306/blob/master/docs...
- acemarke 3y ago
  It's somewhere in between. React as a lib and architecture _is_ platform-agnostic. The core logic is defined in the `react-reconciler` package. It contains all the implementation of rendering components, diffing trees, managing state, and running effects, as well as all the "Suspense" implementation. However, the way `react-reconciler` works is that it's built _into_ each platform-specific renderer implementation. So, the size of `react-dom` is actually the size of `react-reconciler` + all the DOM-specific behavior. A quick check of https://bundlejs.com/?q=react-reconciler https://bundlejs.com/?q=react-reconciler suggests it's about 100K minified. https://bundlejs.com/?q=react-dom https://bundlejs.com/?q=react-dom is 138K, so that tells me that the DOM-specific logic is 38K.
aledalgrande 3y ago
Seeing Preact mentioned, just wanted to give a shoutout to one of the authors, Marvin, an ex colleague. Absolutely amazing dev and person.

franciscop 3y ago

I wrote a jQuery (30kb) alternative called Umbrella JS (2.6kb) and based on my experience and if I had to guess, probably most of the rest of React's size is in compatibility stuff. Like making sure events work uniformly across browsers, I remember that making everything work with SVGs was also a big milestone, normalizing events (e.g. we have synthetic events which are basically React's events on top of the normal DOM events), etc. An astute/old fashion dev will realize that React's onChange actually behaves like `addEventListener('input')` and not really like `addEventListener('change')`, since the latter only triggers on blur and not on each keystroke. I strongly believe React team is shooting themselves on the foot by not making Error Boundaries into Hooks. If they did, someone could create a Preact 2.0 so to speak that is like React but purely functional (no classes). But since we don't have that, and error handling IS an important part of React, any react alternative would have to implement classes fully as well, which might retract many from even trying to create a React alternative (I don't think myself smart enough to do a React alternative properly, but I'd certainly tried if they did this).

acemarke 3y ago
There's actually a recent PR up for a `<Catch>` component: - https://github.com/facebook/react/pull/26854 https://github.com/facebook/react/pull/26854
awayto 3y ago
I wonder if error boundary components/functionality are an anti-pattern. They invite the developer to create components which expect to fail. Even basic hide/show logic is better than expecting devs to orchestrate unified error handling across the app.
- solardev 3y ago
  What's wrong with components that expect to fail? Don't you need some way to notify users of predictable problems?

Uehreka 3y ago

OK, hold up, I’ve been hearing this line forever and I’m here to hold it to account: > the API-compatible Preact is something like 7KB Something is up here. Either Preact is not in fact API-compatible (in which case people should stop saying this), or the React devs are dummies who have never thought of Preact’s architecture or looked at its open source code (I rank this unlikely) or there’s somehow some other catch that no one talks about. Which is it? Why doesn’t React just use Preact’s architecture if it’s so lightweight? What is Preact actually giving up?

Inviz 3y ago
It's fully api compatible pre-fiber. in fact it has more apis in some regards.
- tcpipchip 3y ago
  Hi Did have success on littlefs on stm32 ? On arduino ? Please, contact me tcpipchip@hotmail.com PS: sorry if I post here
  - Inviz 3y ago
    I did have some success with it. I used their generic config way to hook up fro block writing/erasing and implemented those parts in the os i was writing. However one thing I was not a fan of is that its IO is synchronous, so you have to use some sort of coroutines/multitasking unless you're ok with blocking
gedy 3y ago
From memory, Preact doesn't use synthetic events system like React and its runtime is much smaller. It can't be used generically like React can in mobile (React Native) or similar though because of this
afavour 3y ago
There are definitely differences here and there. One I can remember from a year or so ago is that Preact deprecated support for string refs while React still supports them (though the docs point out they intend to deprecate IIRC). Honestly to my mind the biggest thing is that bundle size just isn’t a priority for the React team. A sibling comment pointed out that React does a lot to correctly handle SVGs. Good to have, obviously, but what percentage of React users are making interactive SVGs? Probably not a whole lot. If they wanted to the React folks could break that out into a react-svg module or something and save some KB. But they don’t want to. To my mind React these days is the enterprise software of the frontend. It’s big, it’s bulky, but it does absolutely everything with a minimum of fuss. They have a one size fits all approach and they’re not willing to deviate from it.

strogonoff 3y ago

It’s often cheaper to couple things tightly. Abstractions and interfaces have costs. However, they also have benefits. Perhaps React and Preact is one such example. React is a tiny fully agnostic library that does components, props, hooks and all that jazz. You can use it anywhere, from DOM to CLI. To tie it to DOM, a separate library exists—named, unimaginatively, ReactDOM—and that’s where the 100KB heft comes in. Preact is the opposite: smaller, but coupled to DOM. The architecture probably doesn’t facilitate cool stuff like render components to embedded LCD[0], and even to do SSR you would have to add extra libraries. [0] https://github.com/doodlewind/react-ssd1306/blob/master/docs/tutorial.md https://github.com/doodlewind/react-ssd1306/blob/master/docs...

acemarke 3y ago
It's somewhere in between. React as a lib and architecture _is_ platform-agnostic. The core logic is defined in the `react-reconciler` package. It contains all the implementation of rendering components, diffing trees, managing state, and running effects, as well as all the "Suspense" implementation. However, the way `react-reconciler` works is that it's built _into_ each platform-specific renderer implementation. So, the size of `react-dom` is actually the size of `react-reconciler` + all the DOM-specific behavior. A quick check of https://bundlejs.com/?q=react-reconciler https://bundlejs.com/?q=react-reconciler suggests it's about 100K minified. https://bundlejs.com/?q=react-dom https://bundlejs.com/?q=react-dom is 138K, so that tells me that the DOM-specific logic is 38K.

aledalgrande 3y ago

Seeing Preact mentioned, just wanted to give a shoutout to one of the authors, Marvin, an ex colleague. Absolutely amazing dev and person.