21 ms·

Is there a reason why the file size has exploded? react.min.js is now 145.4kb. For comparioson, angular.min.js is 155.2kb. One of React's biggest selling point

by coltonv 11y ago

Is there a reason why the file size has exploded? react.min.js is now 145.4kb. For comparioson, angular.min.js is 155.2kb. One of React's biggest selling points was that it was much smaller than Angular/Ember/Backbone etc, but I'm not sure that argument can be leveraged anymore. I think React is a culmination of some great ideas, but in my view this is a big step back. Especially since Angular/Ember/etc. offer a lot more tools out of the box. I don't intend to tell anyone here that React is a bad framework because it's not, but I think it should be a big priority to tighten down the file size. When React is big pretty much all their selling points go out the window. Perhaps they can split files up so you can just import the APIs you want. I wonder how much that would help with the bloat. I feel like some of the smaller VDOM frameworks like Cycle/Mithril/Riot are a lot more appealing now, since they focus on small file size and low bloat.

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
- 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
lisivka 11y ago
It is time to deploy common JS libraries out of band, like native libraries. Download them once, precompile them once, and then use precompiled version at any site, which requires it.
- tlrobinson 11y ago
  That's basically the purpose of public CDN-hosted JavaScript, like cdnjs [1] and what most major JS libraries do [2]. However, I think this is becoming less common with the increasing popularity of module bundlers like webpack. It's still possible with webpack [3], but it's not as easy as a 'npm i react' and 'import React from "react";'. That said, a module bundler could easily automatically swap out local modules for modules hosted on CDNs in production builds (with fallbacks in case the CDN is down). I'm a little surprised this doesn't seem to exist yet, at least for webpack. 1. https://cdnjs.com/ https://cdnjs.com/ 2. https://code.jquery.com/ https://code.jquery.com/ 3. https://webpack.github.io/docs/library-and-externals.html https://webpack.github.io/docs/library-and-externals.html
  - lisivka 11y ago
    I mean, we need <library> tag in addition to <script> tag, which we already have. e.g. <library name="react" version="^5.0"><script src="https://cdn/react-5.0.8.js"></script></library> https://cdn/react-5.0.8.js"></script></library>
- tomphoolery 11y ago
  It would be kind of nice if you could import modules directly from HTTP sources, like Go. For example: import _ from package 'github.com/lodash/lodash/tree/4.8.2'; import $ from package 'jquery.com/version/2.2.0'; Your browser would make the OOB requests and cache the results in a shared directory, which any JS code that's running locally can use. This way, HTTP requests for 3rd-party components shared across websites aren't repeated over and over again for the same libraries. And it could even be extended to CSS: @import package("github.com/twbs/bootstrap/tree/3.3.6");
  - 11y ago
Silhouette 11y ago
When React is big pretty much all their selling points go out the window. I strongly disagree. If React's API were to get all big and complicated, that would be a concern. The tight scope and clean interface are definitely selling points for React compared to many larger (in scope and interface) frameworks and rendering libraries. But I really don't care about the file size, as it's far too small to be anything but noise in almost any web app where it's worth using a tool like React at all, and it's going to matter less anyway as JS build tools get more sophisticated and connection speeds increase over time.
- vcarl 11y ago
  Additionally, React is intended for highly complex, highly interactive applications, time-to-content is less important than on, say, a news reader. It might take 2 or 3 seconds to get the first page, but once you're there your interactions will be quick. Even if you do code splitting, well-bundled code will have a "commons" chunk, so fetching a new page won't redownload React and other large libraries.
  - Cshelton 11y ago
    Finally...had to go so many comments down to find someone making a logical point. People will complain about anything. As someone who has made a massive app with React, well over 1000 components, people literally complain about a 43kb gripped file size... Most likely none of these people have built a large application with React and use it for stuff that a static site would be good for. Then they complain about loading time and rendering time... Also, on an app people ACTUALLY use and often...the files are cached anyway. The front/web/JS doesn't have a fatigue problem...it has a chronic bitching for no reason problem. Reacts benefits from a declarative api and such far out weigh file size...the people who complain about file size don't understand that and never will...again...probably because they haven't written anything used in production by real users ever. /rant
cloudjacker 11y ago
Can you elaborate why anyone should care? Is this related to the bandwidth costs you incur in aggregate? I guess I too would be mad after converting all of my image assets into vector and CSS3 concoctions only to have my site size foiled by a dependency. But in reality one image is much larger than this.
- Veratyr 11y ago
  On mobile and in most of the world where fast internet isn't ubiquitous, cutting down on the size of your page can make your users' experience much better. It's hard to do that when your dependencies get bigger.
bubtubgub 11y ago
You sound like you don't actually know anything about react... I have never heard anyone promote react based on file size, and angular does not provide 'a lot' more tools out of the box. React is better than angular pretty much in every single respect.
deleted 11y ago
[deleted]
Kiro 11y ago
> When React is big pretty much all their selling points go out the window You can't be serious. React's selling point for me is that it enables me to write web apps in a whole new way. Coming from an Angular background it's amazing how much cleaner, better and more pleasant it is to work with React. To bring up file size as the main selling point is just ridiculous.
christophilus 11y ago
In my opinion, I don't think size is the big selling point for React. It's the simplicity and clarity of the programming model that it enables. For me, being able to write most of my code functionally (pure functions, immutable data) is a big win. That said, I've been tinkering with this project on the side: https://github.com/developit/preact https://github.com/developit/preact It's a 3-4K React-ish library. Pretty impressed with it so far, but it does lack the dev tools, event normalization, etc.

by coltonv 11y ago

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
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

lisivka 11y ago

It is time to deploy common JS libraries out of band, like native libraries. Download them once, precompile them once, and then use precompiled version at any site, which requires it.

tlrobinson 11y ago
That's basically the purpose of public CDN-hosted JavaScript, like cdnjs [1] and what most major JS libraries do [2]. However, I think this is becoming less common with the increasing popularity of module bundlers like webpack. It's still possible with webpack [3], but it's not as easy as a 'npm i react' and 'import React from "react";'. That said, a module bundler could easily automatically swap out local modules for modules hosted on CDNs in production builds (with fallbacks in case the CDN is down). I'm a little surprised this doesn't seem to exist yet, at least for webpack. 1. https://cdnjs.com/ https://cdnjs.com/ 2. https://code.jquery.com/ https://code.jquery.com/ 3. https://webpack.github.io/docs/library-and-externals.html https://webpack.github.io/docs/library-and-externals.html
- lisivka 11y ago
  I mean, we need <library> tag in addition to <script> tag, which we already have. e.g. <library name="react" version="^5.0"><script src="https://cdn/react-5.0.8.js"></script></library> https://cdn/react-5.0.8.js"></script></library>
tomphoolery 11y ago
It would be kind of nice if you could import modules directly from HTTP sources, like Go. For example: import _ from package 'github.com/lodash/lodash/tree/4.8.2'; import $ from package 'jquery.com/version/2.2.0'; Your browser would make the OOB requests and cache the results in a shared directory, which any JS code that's running locally can use. This way, HTTP requests for 3rd-party components shared across websites aren't repeated over and over again for the same libraries. And it could even be extended to CSS: @import package("github.com/twbs/bootstrap/tree/3.3.6");
- 11y ago

Silhouette 11y ago

When React is big pretty much all their selling points go out the window. I strongly disagree. If React's API were to get all big and complicated, that would be a concern. The tight scope and clean interface are definitely selling points for React compared to many larger (in scope and interface) frameworks and rendering libraries. But I really don't care about the file size, as it's far too small to be anything but noise in almost any web app where it's worth using a tool like React at all, and it's going to matter less anyway as JS build tools get more sophisticated and connection speeds increase over time.

vcarl 11y ago
Additionally, React is intended for highly complex, highly interactive applications, time-to-content is less important than on, say, a news reader. It might take 2 or 3 seconds to get the first page, but once you're there your interactions will be quick. Even if you do code splitting, well-bundled code will have a "commons" chunk, so fetching a new page won't redownload React and other large libraries.
- Cshelton 11y ago
  Finally...had to go so many comments down to find someone making a logical point. People will complain about anything. As someone who has made a massive app with React, well over 1000 components, people literally complain about a 43kb gripped file size... Most likely none of these people have built a large application with React and use it for stuff that a static site would be good for. Then they complain about loading time and rendering time... Also, on an app people ACTUALLY use and often...the files are cached anyway. The front/web/JS doesn't have a fatigue problem...it has a chronic bitching for no reason problem. Reacts benefits from a declarative api and such far out weigh file size...the people who complain about file size don't understand that and never will...again...probably because they haven't written anything used in production by real users ever. /rant

cloudjacker 11y ago

Can you elaborate why anyone should care? Is this related to the bandwidth costs you incur in aggregate? I guess I too would be mad after converting all of my image assets into vector and CSS3 concoctions only to have my site size foiled by a dependency. But in reality one image is much larger than this.

Veratyr 11y ago
On mobile and in most of the world where fast internet isn't ubiquitous, cutting down on the size of your page can make your users' experience much better. It's hard to do that when your dependencies get bigger.

bubtubgub 11y ago

You sound like you don't actually know anything about react... I have never heard anyone promote react based on file size, and angular does not provide 'a lot' more tools out of the box. React is better than angular pretty much in every single respect.

deleted 11y ago

[deleted]

Kiro 11y ago

> When React is big pretty much all their selling points go out the window You can't be serious. React's selling point for me is that it enables me to write web apps in a whole new way. Coming from an Angular background it's amazing how much cleaner, better and more pleasant it is to work with React. To bring up file size as the main selling point is just ridiculous.

christophilus 11y ago

In my opinion, I don't think size is the big selling point for React. It's the simplicity and clarity of the programming model that it enables. For me, being able to write most of my code functionally (pure functions, immutable data) is a big win. That said, I've been tinkering with this project on the side: https://github.com/developit/preact https://github.com/developit/preact It's a 3-4K React-ish library. Pretty impressed with it so far, but it does lack the dev tools, event normalization, etc.