Live data from Hacker News

React v15.0

facebook.github.io

21–30 of 174 posts

Re: React v15.0

#21
post #19

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…

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.

Re: React v15.0

#22
post #6

Earlier quoted context omitted.

Angular two lost me.

Yeah I wasn't too thrilled with Angular 2.x either. I had always been watching React and liking it, but I had no experience with it. So one day I decided to give it a whirl and see how far I could get converting the Angular 1.5 app I had already started and get it to the equivalent state in React. Long story short, I took 40+ hours of Angular 1.5 code and converted it to React code in a single 8 hour work day without…

Could you share more about the experience? I'm building a dashboard for a realtime web system and React seems to be a solid choice to keep things simple and tidy.

Re: React v15.0

#23
post #19

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…

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.

Re: React v15.0

#24
post #21
post #19

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…

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

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.

Re: React v15.0

#25
post #19

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…

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.

Re: React v15.0

#26
post #23
post #19

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…

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

Re: React v15.0

#27
post #6

Earlier quoted context omitted.

Angular two lost me.

Yeah I wasn't too thrilled with Angular 2.x either. I had always been watching React and liking it, but I had no experience with it. So one day I decided to give it a whirl and see how far I could get converting the Angular 1.5 app I had already started and get it to the equivalent state in React. Long story short, I took 40+ hours of Angular 1.5 code and converted it to React code in a single 8 hour work day without…

> I took 40+ hours of Angular 1.5 code and converted it to React code in a single 8 hour work day

That doesn't seem like a fair comparison considering that when you first wrote that code, you probably had to figure out things unrelated to whatever framework you were using and didn't have to deal with that aspect when porting to React.

For example, if I rewrote a Django app in Pyramid, it wouldn't take as long as writing the original app even with the overhead of learning Pyramid, because I've already figured out the functional aspects of the app.

Generally speaking, learning frameworks isn't the hard part of writing an app, unless the app is trivial.

Re: React v15.0

#28
post #13
post #12

In ReactConf, Ben Alpert noted that there would be a ~10% performance improvement from v15.0. Is that still true?

Haven't benchmarked again, but it should be. This came from the document.createElement and reactid changes (and some associated internal refactors).

Am I correct in assuming that you're only talking about the production build being faster?

Going from 0.14.8 to 15.0 RC2 there seemed (subjectively) to be a noticeable increase in lag in some pages we're working on with a moderately large amount of content being rendered (things like tables or SVGs with a few thousand elements) when using development builds. However, looking at the changelog and how many new warnings seem to be included now, it doesn't seem unreasonable that those would slow things down a little overall even with the other changes.

As long as those aren't going to affect production, or if there were some final changes that have gone in now but weren't in RC2, it's not a big deal. However, if the React experts wouldn't expect a net slow-down even in a dev build, maybe we should look into it a bit more.

Re: React v15.0

#29
post #13

Earlier quoted context omitted.

Haven't benchmarked again, but it should be. This came from the document.createElement and reactid changes (and some associated internal refactors).

Am I correct in assuming that you're only talking about the production build being faster? Going from 0.14.8 to 15.0 RC2 there seemed (subjectively) to be a noticeable increase in lag in some pages we're working on with a moderately large amount of content being rendered (things like tables or SVGs with a few thousand elements) when using development builds. However, looking at the changelog and how many new warnings…

That's possible. We haven't done much optimization on the dev build but I was planning to look for low-hanging fruit soon to see if there are any significant improvements we can make. I wouldn't have expected 15.0 to be much different from 0.14 though.

Re: React v15.0

#30
post #9
post #7

Has Facebook removed the potentially dangerous patent restrictions? https://news.ycombinator.com/item?id=8985541

We updated the patent grant to be less restrictive in response to community feedback about a year ago (several months after the discussion you linked): https://github.com/facebook/react/commit/b8ba8c83f318b84e429... Since that change I've heard few complaints, and I know for a fact that several large companies who were previously unwilling to use it are now content with the language.

I noticed you italicized the word grant. In reality the "grant" isn't granting; it is taking away. Let me explain:

If React didn't have an explicit "grant" there would be an implicit grant. Is the explicit grant better than an implicit grant? It isn't because the explicit grant has what is known as a strong retaliation clause.

More info on weak vs strong retaliation clauses: http://www.rosenlaw.com/lj9.htm

React's patent "grant" gives you a license to React's patents. This sounds like a good thing, however, the "grant" has a "strong retaliation clause" which says that if you make any sort of patent claim against Facebook this patent grant automatically terminates.

Which means Facebook can now sue you for patent infringement for using React. You may think this is no worse than not having a patent grant at all. But that's not the case. If React didn't have an explicit patent grant then there would be an implicit grant which does not have any retaliation clauses, and cannot be revoked.

If you work for a software company and your company has patents then keep in mind that by using React you are giving Facebook a free license to your entire patent portfolio.

Post reply on HN