[sebmarkbage]

Parse time is the new bottleneck of modern client-side web apps. Of course React on its own isn't going to move the needle but if other libraries follow along it just might. With better, more expressive error messages without paying the cost at scale.

[atdt]

If you can show me even a contrived example of a React app where the presence or absence of three kilobytes of debug messages makes a measurable difference to performance, I will be very impressed (and humbled).

[yazaddaruvala]

To me its not about the 3KB, thats negligible. Its more the precedent.

It is a strong statement that React cares strongly about my page weight, even as small as 3KB. At least the implied message it sends me:

1. I really should care about my page weight too.

2. React must really need every KB it currently uses. And if not, it will soon optimize away the bloat.

[untog]

I'm not so sure I agree there. Not that React isn't fantastic, but I remember a recent release adding support for SVG elements. If I don't use any, it would be great to strip out that functionality - React is not a small library. Alternatives like Preact show that you can have a core set of functionality at a much smaller size.

With the prevalence of npm and mini-libraries I'd be interested to see if the size of React could be cut down and put into optional components.

[Klathmon]

Have there been any efforts to have tree shaking work with react?

It's not a magic bullet, but it can go a long way in helping remove a ton of unused-for-your-use-case code in your production build.

[lhorie]

I don't think tree shaking would help much. Speaking as an author of one of those mini-virtual-dom libraries, from my experience/research, the choices of features to support are usually tightly integrated for performance reasons.

For tree shaking to work, it must be possible to statically infer that some code is not part of the dependency graph of your application. Something like SVG support requires extensions to the virtual dom node structure that the renderer's visitor looks at, so it's quite difficult to make it into a hook and not lose performance to various overheads. It's also worth mentioning that over-modularizing can get boilerplatey (e.g. https://github.com/paldepind/snabbdom#inline-example)

[douche]

Saving a handful of kb on a JS library quickly gets shot to hell when you have to load up sixteen analytics trackers, an auto-playing video, and a bevy of unoptimized ad images.

There is lower-hanging, bigger-buck-for-your-bang, fruit if you're trying to fight page bloat.

[Klathmon]

And React can't prevent any of those. React can only change React code, so they optimize it as best as they can, and leave the "user" of React to optimize everything else in their own app.