4 ms·

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 pai

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.
- slewis 11y ago
  Couldn't browsers keep a map of js-file-hash to cached AST?
  - mikegioia 11y ago
    I think it suffers from the same problem as other asset caching. Think of all the sites you visit and how much JS they load. 1000 websites with 1MB of JS will hit 1GB of storage.
    - ec109685 11y ago
      1gb isn't huge on the desktop, especially if the cache expired LRU.
      - esailija 11y ago
        I don't think any of this concerns desktops anyway.
  - mbrock 11y ago
    It's not just parsing, it's evaluating all the code statement by statement, and the result of that is hard to cache.
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]

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.
slewis 11y ago
Couldn't browsers keep a map of js-file-hash to cached AST?
- mikegioia 11y ago
  I think it suffers from the same problem as other asset caching. Think of all the sites you visit and how much JS they load. 1000 websites with 1MB of JS will hit 1GB of storage.
  - ec109685 11y ago
    1gb isn't huge on the desktop, especially if the cache expired LRU.
    - esailija 11y ago
      I don't think any of this concerns desktops anyway.
- mbrock 11y ago
  It's not just parsing, it's evaluating all the code statement by statement, and the result of that is hard to cache.

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]