6 ms·

I don't think we've ever promoted React based on file size. Smaller files are better but people tend to overemphasize JS file size -- gzipped, this latest relea

by spicyj 11y ago

I don't think we've ever promoted React based on file size. Smaller files are better but people tend to overemphasize JS file size -- gzipped, this latest release is 43k which is comparable to the size of an image or two on most websites. (Also note that growing framework code can reduce your app code size overall; I don't want to make specific claims about React but at Facebook we often see code size increase when 10 people all try to avoid importing the same module and end up reimplementing 20% of it 10 times and increasing the overall size.) I haven't looked lately at the biggest contributors to React's file size. We're certainly willing to try to modularize more when it makes sense, but we do that more with an eye towards developer flexibility rather than runtime efficiency.

danabramov 11y ago
This release gained 3k gzipped (it was 39k), in large part due to complete SVG support. In this case I think it was worth it because this was a longstanding pain point. There may be some ways to drop some dead code that we haven't eliminated efficiently yet. Here is a recent example I found that drops 1kb: https://github.com/facebook/react/pull/6401 https://github.com/facebook/react/pull/6401 It would be cool if somebody in the community could spare some time to look into the biggest factors as well. We definitely want to have a good explanation for where those bytes are coming from. That is, what React gives you for them. I plan to write a high level overview of React internal implementation so I might as well look at relative size cost of different pieces of it as part of my exploration process. In any case don't forget 43k is less than many images.
- mikegioia 11y ago
  Just out of curiosity, why do you only consider gzipped size when determining bloat? Transmission size/time isn't the only factor, there's also the time it takes the JS engine to process the code. 43k gzipped is okay for the transmission, but the engine is still parsing/processing the unpacked version, no? 145k minified for a foundational library is not insignificant. jQuery 3.0 minified as a reference is ~86k.
  - tomphoolery 11y ago
    You're not wrong, it's just that the time it takes to transfer something across a network is usually slower and a lot less deterministic than processing something locally on your machine. While I'm pretty sure it takes longer to evaluate more code than less code, I would imagine that the time differential is negligible compared to the time savings you get from gzipping JS/CSS assets for transmission over a network. Otherwise, why would we gzip assets at all?
    - yxlx 11y ago
      Parent is not saying not to gzip. They're saying that more js takes more time to parse, regardless of compression. Iow, they are not talking about decompression overhead, they are talking about what happens after decompression.
    - mbrock 11y ago
      If you're aiming for a really snappy app, and you've made sure everything is fully cached, in a ServiceWorker even for totally instant loading, then JS parse/evaluation time becomes significant.
    - collinmanderson 11y ago
      Right, but you can use caching / service workers to solve the network time, but there's nothing you can do to speed up the initial javascript load time.
  - danabramov 11y ago
    Yeah, this is a good point. We do consider time-to-interaction an important metric (it is especially important for React Native), and indeed having less JS code to parse is going to give better results. I don't have a good answer other than that we definitely care about these metrics, and Facebook uses React more and more, so there will be more pressure on the team to improve them. We are not in a perfect place right now but we are not just brushing it off either. As I said in another comment, at least having a good explanation for these bytes is something we plan to do in the following couple of months. There are some other improvements to startup time that we are considering such as bundling to a flat file and removing some dynamic overhead (https://github.com/facebook/react/issues/6351 https://github.com/facebook/react/issues/6351). Also the plan is to have React go through significant changes this year (adding an incremental reconciler) so right now is not the best time to optimize the script size. But yeah, this is on our radar. Community help identifying specific issues is also very welcome.
- troncheadle 11y ago
  > I plan to write a high level overview of React internal implementation I would love this! I really like how you basically re implement redux in the first few videos of your EggHead Redux tutorial. It really took my understanding to another level.
- dustingetz 11y ago
  The time to parse and execute the js matters too
- crudbug 11y ago
  Somebody suggested having a micro-kernel approach to load modules onDemand in production, e.g. SVG, renderToString will further reduce the initial load time / size.
  - vcarl 11y ago
    There's interesting work happening with tree shaking, which allows you to do static analysis at compile time to remove unimported code. The new JS `import` syntax is specifically designed to enable this, so it's just a matter of time until tooling and libraries catch up.
- deleted 11y ago
  [deleted]
coltonv 11y ago
Perhaps the React team didn't themselves promote based on file size, But many people have in medium articles etc. I'm the kind of person who works very hard to keep my page size at a minimum, and there are definitely others like me. What do you think of the idea of splitting React up into several files, so you can only input what functionality you want? Do you think that's possible in Reacts code base? For reference, RxJS 5 does this, so you can import the operator flatMap only if you intend to use it.
- danabramov 11y ago
  React doesn't really have much of a public API surface. In Rx you can give up some operators but React doesn't have a similar concept. That said we will continue exploring how to drop some weight from React further down the road. This is not a priority right now because some large changes are coming relatively soon to React (work on incremental reconciler) so it would be unwise to focus on size optimization before a big refactoring. I think that we will be in better position to consider what can be removed or separated after we ship the incremental reconciler. Hopefully this will happen within a year. For now I don't have a good answer to this but I'll try to at least provide a summary of how large different pieces are when creating a high level technical overview of React next month.
jonahx 11y ago
as a fan of react, i think file size should be a bigger priority. for comparison, mithril is 7.8 gzipped. i don't see react getting that small, but i'm sure there's room for slimming down, perhaps signicantly.
- ash 11y ago
  By the way, those 7.8Kb of Mithril include stuff that React doesn't have: router, fetcher, promise implementation.
andrewingram 11y ago
I feel it's important to point out that React is now an ecosystem. Relay is comparable in size to React, then we throw Immutable into the mix, and so on. These are all dependencies that will be used on practically every page on a website, so cannot benefit from code-splitting techniques. It's certainly my experience that using React over a mess of jQuery and its plugins leads to smaller file-sizes when enhancing functionality on a single page, but when you're using React (with Relay, React Router etc) to build the entire site, you end up with enormous payloads. Let's ignore the gzip size for now, since there's more to file-size than just data over the wire. A production build of a simple React + Relay project (i.e. one that does practically nothing) is around 1mb in size. We can't reliably do server-side rendering with Relay yet, so this is 1mb that must be downloaded and executed before you can see and do anything at all. This is a bad place to be.
- andrewingram 11y ago
  I should add, that if there's a truly blessed CDN for these dependencies (cdnjs is the closest we have to that) that everyone uses, it puts us in a much better place. So we should actively be encouraging people to use them.
  - efdee 11y ago
    I'm very split on using these CDNs. I understand the advantage, but do I really want to make my site import Javascript from a third party source? Their downtime becomes my downtime, their security issues become my security issues, and I've now shared my visitor's usage patterns with a third party...
    - andrewingram 11y ago
      That's a good point, and they've also been my concerns with using them too, which I overlooked with my comment.
  - joshmanders 11y ago
    I love cdnjs.com but check out npmcdn.com

by spicyj 11y ago

danabramov 11y ago

This release gained 3k gzipped (it was 39k), in large part due to complete SVG support. In this case I think it was worth it because this was a longstanding pain point. There may be some ways to drop some dead code that we haven't eliminated efficiently yet. Here is a recent example I found that drops 1kb: https://github.com/facebook/react/pull/6401 https://github.com/facebook/react/pull/6401 It would be cool if somebody in the community could spare some time to look into the biggest factors as well. We definitely want to have a good explanation for where those bytes are coming from. That is, what React gives you for them. I plan to write a high level overview of React internal implementation so I might as well look at relative size cost of different pieces of it as part of my exploration process. In any case don't forget 43k is less than many images.

mikegioia 11y ago
Just out of curiosity, why do you only consider gzipped size when determining bloat? Transmission size/time isn't the only factor, there's also the time it takes the JS engine to process the code. 43k gzipped is okay for the transmission, but the engine is still parsing/processing the unpacked version, no? 145k minified for a foundational library is not insignificant. jQuery 3.0 minified as a reference is ~86k.
- tomphoolery 11y ago
  You're not wrong, it's just that the time it takes to transfer something across a network is usually slower and a lot less deterministic than processing something locally on your machine. While I'm pretty sure it takes longer to evaluate more code than less code, I would imagine that the time differential is negligible compared to the time savings you get from gzipping JS/CSS assets for transmission over a network. Otherwise, why would we gzip assets at all?
  - yxlx 11y ago
    Parent is not saying not to gzip. They're saying that more js takes more time to parse, regardless of compression. Iow, they are not talking about decompression overhead, they are talking about what happens after decompression.
  - mbrock 11y ago
    If you're aiming for a really snappy app, and you've made sure everything is fully cached, in a ServiceWorker even for totally instant loading, then JS parse/evaluation time becomes significant.
  - collinmanderson 11y ago
    Right, but you can use caching / service workers to solve the network time, but there's nothing you can do to speed up the initial javascript load time.
- danabramov 11y ago
  Yeah, this is a good point. We do consider time-to-interaction an important metric (it is especially important for React Native), and indeed having less JS code to parse is going to give better results. I don't have a good answer other than that we definitely care about these metrics, and Facebook uses React more and more, so there will be more pressure on the team to improve them. We are not in a perfect place right now but we are not just brushing it off either. As I said in another comment, at least having a good explanation for these bytes is something we plan to do in the following couple of months. There are some other improvements to startup time that we are considering such as bundling to a flat file and removing some dynamic overhead (https://github.com/facebook/react/issues/6351 https://github.com/facebook/react/issues/6351). Also the plan is to have React go through significant changes this year (adding an incremental reconciler) so right now is not the best time to optimize the script size. But yeah, this is on our radar. Community help identifying specific issues is also very welcome.
troncheadle 11y ago
> I plan to write a high level overview of React internal implementation I would love this! I really like how you basically re implement redux in the first few videos of your EggHead Redux tutorial. It really took my understanding to another level.
dustingetz 11y ago
The time to parse and execute the js matters too
crudbug 11y ago
Somebody suggested having a micro-kernel approach to load modules onDemand in production, e.g. SVG, renderToString will further reduce the initial load time / size.
- vcarl 11y ago
  There's interesting work happening with tree shaking, which allows you to do static analysis at compile time to remove unimported code. The new JS `import` syntax is specifically designed to enable this, so it's just a matter of time until tooling and libraries catch up.
deleted 11y ago
[deleted]

coltonv 11y ago

Perhaps the React team didn't themselves promote based on file size, But many people have in medium articles etc. I'm the kind of person who works very hard to keep my page size at a minimum, and there are definitely others like me. What do you think of the idea of splitting React up into several files, so you can only input what functionality you want? Do you think that's possible in Reacts code base? For reference, RxJS 5 does this, so you can import the operator flatMap only if you intend to use it.

danabramov 11y ago
React doesn't really have much of a public API surface. In Rx you can give up some operators but React doesn't have a similar concept. That said we will continue exploring how to drop some weight from React further down the road. This is not a priority right now because some large changes are coming relatively soon to React (work on incremental reconciler) so it would be unwise to focus on size optimization before a big refactoring. I think that we will be in better position to consider what can be removed or separated after we ship the incremental reconciler. Hopefully this will happen within a year. For now I don't have a good answer to this but I'll try to at least provide a summary of how large different pieces are when creating a high level technical overview of React next month.

jonahx 11y ago

as a fan of react, i think file size should be a bigger priority. for comparison, mithril is 7.8 gzipped. i don't see react getting that small, but i'm sure there's room for slimming down, perhaps signicantly.

ash 11y ago
By the way, those 7.8Kb of Mithril include stuff that React doesn't have: router, fetcher, promise implementation.

andrewingram 11y ago

I feel it's important to point out that React is now an ecosystem. Relay is comparable in size to React, then we throw Immutable into the mix, and so on. These are all dependencies that will be used on practically every page on a website, so cannot benefit from code-splitting techniques. It's certainly my experience that using React over a mess of jQuery and its plugins leads to smaller file-sizes when enhancing functionality on a single page, but when you're using React (with Relay, React Router etc) to build the entire site, you end up with enormous payloads. Let's ignore the gzip size for now, since there's more to file-size than just data over the wire. A production build of a simple React + Relay project (i.e. one that does practically nothing) is around 1mb in size. We can't reliably do server-side rendering with Relay yet, so this is 1mb that must be downloaded and executed before you can see and do anything at all. This is a bad place to be.

andrewingram 11y ago
I should add, that if there's a truly blessed CDN for these dependencies (cdnjs is the closest we have to that) that everyone uses, it puts us in a much better place. So we should actively be encouraging people to use them.
- efdee 11y ago
  I'm very split on using these CDNs. I understand the advantage, but do I really want to make my site import Javascript from a third party source? Their downtime becomes my downtime, their security issues become my security issues, and I've now shared my visitor's usage patterns with a third party...
  - andrewingram 11y ago
    That's a good point, and they've also been my concerns with using them too, which I overlooked with my comment.
- joshmanders 11y ago
  I love cdnjs.com but check out npmcdn.com