Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

React v15.0

facebook.github.io

Post reply on HN
Print view View original

31–40 of 174 posts

Re: React v15.0

#31

Post by stephenhuey »

joshmanders wrote: post #10
zxcvcxz wrote: 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 recommend you look into Aurelia which was created by a member of the Angular team who believed Angular 2 was on the wrong track. Aurelia could serve as a replacement for Angular, and you can use it with React if you want to. Yesterday the Aurelia blog mentioned how their View Engine Pipeline can use React and Angular components all together in Aurelia:

http://blog.durandal.io/2016/04/06/aurelia-on-net-rocks/

Re: React v15.0

#32

Post by mikegioia »

danabramov wrote: post #24
spicyj wrote: post #21

Earlier quoted context omitted.

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…

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.

Re: React v15.0

#33

Post by nevir »

There's a bit of irony here, but in a good way: Switching back to DOM APIs (e.g. document.createElement) was a performance boost.

('cause the browser vendors have done a ton of awesome work speeding up DOM APIs in recent years)

Re: React v15.0

#34

Post by spicyj »

interlocutor wrote: post #30
spicyj wrote: post #9

Earlier quoted context omitted.

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…

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

I'm not a lawyer. My understanding is that this is hypothetically possible but stands on shaky legal ground and has no legal precedent. Whether or not an implicit grant exists seems to depend on who you ask. This is apparently why GPLv3 includes an explicit grant.

It could also be that there aren't any patents that cover React. I don't personally know of any that do.

Re: React v15.0

#35

Post by spicyj »

nevir wrote: post #33

There's a bit of irony here, but in a good way: Switching back to DOM APIs (e.g. document.createElement) was a performance boost . ('cause the browser vendors have done a ton of awesome work speeding up DOM APIs in recent years)

I'm not sure how this is ironic? We were using one DOM API (.innerHTML) before; now we're using a different one.

Re: React v15.0

#36

Post by rabelrabel »

React 14.x was built with babel 5.x. React 15.x is compiled with babel 6.x. Must user jsx code now be compiled with babel 6.x to be compatible with React 15.x?

Re: React v15.0

#37

Post by tomphoolery »

mikegioia wrote: post #32
danabramov wrote: post #24

Earlier quoted context omitted.

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…

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?

Re: React v15.0

#38

Post by Silhouette »

spicyj wrote: post #29
Silhouette wrote: post #28

Earlier quoted context omitted.

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.

OK, thanks. It doesn't seem to be a huge difference or anything, just enough to be a bit noticeable in some pages we're staring at for a disturbing number of hours per week at the moment, so I was curious. Compared to things like implementing shouldComponentUpdate in the right places, the change is tiny.
Post reply on HN