Hacker News Reader

Comment by _uhtu | Hacker News Reader

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.

View on HN

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.

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

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.

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.

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?

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.

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.

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.

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

Couldn't browsers keep a map of js-file-hash to cached AST?

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.

1gb isn't huge on the desktop, especially if the cache expired LRU.

I don't think any of this concerns desktops anyway.

It's not just parsing, it's evaluating all the code statement by statement, and the result of that is hard to cache.

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

The time to parse and execute the js matters too

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.

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.

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.

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.

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.

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

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.

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.

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

That's a good point, and they've also been my concerns with using them too, which I overlooked with my comment.

I love cdnjs.com but check out npmcdn.com

I see your point. Indeed this does not sound very good. I don’t know enough about Relay or their plans so I can’t really say much.

Nevertheless it is an ecosystem precisely because you get to pick the pieces you need. For comparison, Redux + Redux Thunk is about 3kb. Immutable is not required either. Of course your app code would have to include data fetching logic which would make it much larger. But those are all tradeoffs you have the power to make.

I agree it's about picking and choosing the right things, but as I think we've both mentioned elsewhere, an audit and explanation of what contributes to file-size in these libraries would be super useful, for a few reasons:

* It helps us justify to our bosses why a 350kb library is needed instead of a 3kb one.

* It helps us understand the overall picture of JavaScript today, what kind of problems we're having to solve that could eventually be better solved by browsers themselves.

* It just makes me more comfortable in my decision to send a lot of JavaScript over the wire.

Without such an explanation, we're essentially taking it on faith that these libraries are written by people who value good quality lean code.

Relay was built to address concerns that our developers faced with managing data in complex apps. Needing to reimplement solutions to the same complex problems (error handling, request coordination, caching, etc) could take time away from focusing on building products. Relay helps to solve these common cases, and it sounds from your comments above ("my productivity has skyrocketed") that you've seen the benefits too - great to hear!

> Without such an explanation, we're essentially taking it on faith that these libraries are written by people who value good quality lean code.

We built something that works for us, balancing feature set, runtime performance, maintainability, code size, etc. We're continually focusing on performance - see https://github.com/facebook/relay/blob/master/meta/meeting-n... for more about what we're focusing on - but so far file size has not been the most impactful thing to work on.

As far as understanding Relay's functionality, we've covered the more obvious aspects in talks (http://facebook.github.io/relay/docs/videos.html) and in a conceptual overview (http://facebook.github.io/relay/docs/thinking-in-graphql.htm...). But an analogy to React is probably simplest. React converts declarative UI descriptions into imperative updates on the DOM. Relay is superficially similar - it converts declarative data descriptions into imperative calls - except that there is no DOM for data, so Relay also implements the query representation, object graph for cached data, networking, mutation queuing & rollback, etc.

We're also giving a tech talk about Relay internals (https://relaytechtalk.splashthat.com/) which may be of interest.

People should stop looking for a silver bullet. If you are using react + relay, you must be building a very complex solution, where the overhead for such abstractions is justified.

If you are at a point where your task doesn't justify these abstractions - don't use them.

Find the right tool for your job.

I've found that the benefits in terms of developer experience, and being able to build good UI quickly, start accumulating almost immediately, even on tiny projects.

My initial reservations about the amount of boilerplate in setting up Relay, were in large part due to the server-side half of the equation. Since switching to building my backend in a different language (now using Elixir with absinthe, rather than node and graphql-js) I've found my productivity has skyrocketed.

At this point the overhead in terms of file-size (and the still pending support for server-rendering) are the only things giving me pause for thought.

Would it be possible to split those libraries in smaller modules? For example Preact (https://github.com/developit/preact) has the same basic API of React but it's just 3kb because a lot of features are stripped away in optional modules. Also, using preact-compat you could replace it as-is* in your bundle right now.

Depends if I need the features in those optional modules. An app is essentially made up from architectural modules (frameworks, alongside anything else that you use everywhere), and then specific pieces of functionality (with dependencies that are used less frequently).

If the bulk of your bundle size comes from page-specific functionality, then you can easily benefit from code-splitting and tree-shaking techniques. But those techniques won't help you at all when it's your core architecture that are enormous, because every single page on your site depends on it.

For React you kind of have to use the minified file size, because the dev file size is SHOCK FULL of dev-only validation and error messages and other logic that is made to be minified away. The prod build isn't even close to the same code.

With that said React + ReactDOM is 180kbish unminified.

I can't find Relay's size as a single file. Is it really over 800kb?

React unminified is ~660kb.

You're totally right. I downloaded the latest release earlier and looked at the file size, and did it again right now, and you're correct.

I still can't figure out where the hell I saw the smaller numbers earlier. I must have been drunk.

I'll need to do a webpack report to get the actual numbers out.

However, my dev build is 9mb, my production build is 1mb. So when i'm talking about baseline filesize for a React + Relay project, I am talking about production builds. Not all of this 1mb comes from those two libs, but they contribute very heavily towards it.

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

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.

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.

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

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

It's a 3-4K React-ish library. Pretty impressed with it so far, but it does lack the dev tools, event normalization, etc.

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.

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/

2. https://code.jquery.com/

3. https://webpack.github.io/docs/library-and-externals.html

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>

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");

Such style of dependency declaration creates unnecessary dependencies on remote sites, which are hard to fix when dependency is broken.

That's essentially what people are doing already with script tags, except they're not declaring their dependencies anywhere.

Better idea would be to reference it via cryptographic signature. Then you could host your own copy of lodash for example, but still benefit if a client already has it downloaded from a different site.

Subresource Integrity is the standard for that https://www.w3.org/TR/SRI/

Do you know if this allows consolidation of multiple copies of the same resource from different hosts?

I don't know. At a guess such optimization would be beyond the scope of the standard - hence up to each vendor/browser/user-agent.

Not currently, because it conflicts with CSP. See https://news.ycombinator.com/item?id=10311020

I thought there was a proposal in the works for adding checksums on script tags. Something like:

Which would allow the browser to use cached copies of files even if from different domains. Not sure where I saw that.

You are thinking of the integrity="" attribute that's part of SRI: https://developer.mozilla.org/en-US/docs/Web/Security/Subres...

That attribute is meant to verify resource contents. The strategy of using it as a cache ID is still being discussed, but last I looked into it, there were some cache poisoning concerns.

You might find this thread useful: https://news.ycombinator.com/item?id=10311020

Great, thanks for that info!

There's a Firefox plugin that does (parts of) this: https://github.com/Synzvato/decentraleyes

Libraries on CDNs have drawbacks as well, like the additional dns-roundtrip.

I think what's needed is a heuristic webpack-loader, where you can specify both a self-hosted URL and a cdn-URL. It could work like this:

* Load the CDN version and fallback back to the self-hosted version, if it doesn't exist or takes too long. * In certain cases (probability, origin of request, etc.) load the self-hosted version first, but load the CDN in the background, so it get's cached.

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.

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.

Reply on news.ycombinator.com