Hacker News Reader

Comment by nikivi | Hacker News Reader

I wish React removed all the compatibility code it has with Internet Explorer and the likes and worked on minimising the weight. Also the synthetic events reactivity system seems a bit outdated.

https://www.solidjs.com is quite awesome but lacks the React ecosystem.

View on HN

We plan to do this in a close follow up release! Automatic batching was one important step, because it starts to treat native events the same as events that goes through the synthetic event system. The rest will be a bigger breaking change for some folks though, so we didn't want to include it in this release, which is focused on giving users a smooth upgrade to start using concurrent features.

this is where they drop support for IE

https://reactjs.org/blog/2022/03/08/react-18-upgrade-guide.h...

https://packagephobia.com/result?p=react actually shows React 18.0.0 to be larger in size than 17.0.2 (despite the removal of support for IE)

That’s the size of the folder and its dependencies in node_modules, not the size of what gets sent over the network. You’re looking for Bundlephobia [1].

react itself is also tiny; it only adds 2.5kb to your bundle size [2] (a 300b reduction from v17). react-dom is the much larger dependency, although as of right now Bundlephobia errors out when trying to analyze the newest version [2].

EDIT: they’ve got react-dom@18.0.0 working now and it’s indeed slightly bigger than the previous version: 41.7kb vs 39.4kb.

[1] https://bundlephobia.com

[2] https://bundlephobia.com/package/react@18.0.0

[3] https://bundlephobia.com/package/react-dom@18.0.0

We've announced removal of IE support but we haven't actually removed the related code. We will likely do that in React 19 together with other breaking changes to the React DOM bindings. I wouldn't expect this to dramatically cut the size. Overall, we tend to focus on changes that increase the performance of the application holistically (see https://twitter.com/reactjs/status/1508847169905864707 and next several tweets) rather than focus solely on the bundle size of React itself (which is fixed and becomes a smaller % as the app grows). But we've definitely accumulated some cruft we'd like to drop sooner rather than later.

Andrew Clark suggested recently that chunks of the event system may be removed in the next major:

https://twitter.com/acdlite/status/1505378980878331909

Yeah, the size of React still bugs me when Preact shows you can do 90% of the same stuff with a tiny fraction of the code.

More like 99%. React's rendering and diffing is more performant though.

React is pretty terrible in terms of both performance and size compared to something a bit closer to the platform like lit.dev

That's an interesting claim.

While it's a far-cry from a realistic test (few people are creating 1000 rows), React seems to be less performant across the board: https://krausest.github.io/js-framework-benchmark/2022/table...

I actually might be wrong.

I remember danabramov claiming more than once on twitter to people praising preact's bundle size, that it also came with a performance cost when it came to diffing and rendering because React had much more code to handle the many edge cases where preact would hit walls.

They are dropping IE support with this version

Shoot. You’re right. Here’s the quote from a preview release:

“In this release, React is dropping support for Internet Explorer, which is going out of support on June 15, 2022. We’re making this change now because new features introduced in React 18 are built using modern browser features such as microtasks which cannot be adequately polyfilled in IE.

If you need to support Internet Explorer we recommend you stay with React 17.”

(Shoot because I have to support IE still.)

What is their use case for microtasks?

I think the automatic batching uses them to commit the changes at the end of the current task.

https://reactjs.org/blog/2022/03/29/react-v18.html#new-featu...

If so, I wonder wether Vue.js automatic batching would benefit from using microtasks

Oof... Very interested where your requirement to still support IE comes from. That is unfortunate.

Not him but we have internal tools that use an access client that calls into an IE webview.

It's hell and I hope we can drop this system sooner rather than later.

Very similar to worble.

We have one app left that a handful of customers still use in a mode that requires Java applets. Yes, you read that right. We’ve been trying to sunset that feature for a long time but I don’t think a date has been decided yet. If it has it’s probably at least a year in the future.

Some of the fun of the enterprise software world. I’ve wanted to drop it for years. And our JS bundle would shrink a ton without it. One day.

Not the OP, but we have an IE support requirement that comes from the NHS. They do actually seem to have Chrome available on their machines these days, but they didn't when we signed the contract and lots of their users still use IE11 so we'll be continuing to support it at least until the June deadline.

They'll almost certainly be on LTSC windows which I think means they can continue to use IE11 with security updates beyond the deadline, but we might be able to persuade them to drop the requirement on us at that point.

If it weren't for 3rd party libraries I wouldn't actually mind supporting IE11 too much. It's no IE6. But not being to upgrade libs is a problem!

You’re right that IE 11 isn’t too bad. The other day I was looking around and discovered it supported web sockets. It does have some surprisingly new stuff you think would be missing.

But my main pain point is some relatively simple JavaScript syntax that’s missing. () => {} is a big one. Support for fetch is another.

If it had support for those two things I bet a huge chunk of my shimming and polyfills could be avoided. I can work around other things. But those two just feel too fundamental at this point.

There would be other benefits. Obviously IE 11 is a joke in JS execution speed compared to other browsers, but what would you expect from something that old.

For me: 0.5% of our customers use it, which means as soon as we break IE we get a flood of customer support inquiries. Since we're B2B, the end users using our product often aren't the ones choosing their browser so we can't tell them to just use Chrome.

...really hope that 0.5% drops to zero in June

> (Shoot because I have to support IE still.)

Some of MS' own webapps don't even support IE anymore...

Which is the ultimate irony. MS dropped support, we haven’t.

Doesn‘t Preact do that? (in regards to the Synthetic Event System)

Reply on news.ycombinator.com