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

101–110 of 174 posts

Re: React v15.0

#101

Post by spicyj »

BinaryIdiot wrote: post #100
spicyj wrote: post #35

Earlier quoted context omitted.

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

I had no idea react used .innerHTML. That provides a significant performance drawback compared to other DOM APIs due to it requiring the browser to re-flow / re-render so much more. Glad you guys updated :)

We only used .innerHTML when creating new subtrees, which requires a reflow anyway when they're inserted. There are reasons that document.createElement is faster for us, but that's not one of them.

Re: React v15.0

#102

Post by mikegioia »

slewis wrote: post #94
mikegioia wrote: post #32

Earlier quoted context omitted.

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.

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.

Re: React v15.0

#103

Post by rattray »

_uhtu wrote: post #17
brotherjerky wrote: post #8

Great to see React continue to improve and streamline as new versions come out. They've managed to avoid the huge bloat that happens to frameworks as they age. Kudos.

The thing is, they have bloated out the library quite a bit. One of their early selling points was how much smaller the React library was than Angular/Ember. Now the size of react.min.js has ballooned up to 145.4kb, which is only 10kb short of Angular, and with addons it's even bigger. As someone who focuses heavily on small page size, that's a pretty harsh regression. Especially when compared to all the other VDom f…

I don't think this person should have been downvoted. This was not an inflammatory comment.

Re: React v15.0

#104

Post by Scarbutt »

adriancooney wrote: post #56
spicyj wrote: post #5

Earlier quoted context omitted.

+1 to this. High-quality code from @mwiencek right out of the gate, and he was super responsive to my comments when I asked for changes. We're really grateful for the contribution.

And thank YOU for your fantastic work on React.

Its no like he does it for free. (not saying it in a bad sense)

Re: React v15.0

#105

Post by ec109685 »

mikegioia wrote: post #102
slewis wrote: post #94

Earlier quoted context omitted.

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.

Re: React v15.0

#106

Post by gnagatomo »

_uhtu wrote: post #17
brotherjerky wrote: post #8

Great to see React continue to improve and streamline as new versions come out. They've managed to avoid the huge bloat that happens to frameworks as they age. Kudos.

The thing is, they have bloated out the library quite a bit. One of their early selling points was how much smaller the React library was than Angular/Ember. Now the size of react.min.js has ballooned up to 145.4kb, which is only 10kb short of Angular, and with addons it's even bigger. As someone who focuses heavily on small page size, that's a pretty harsh regression. Especially when compared to all the other VDom f…

I remember quite the opposite, by 2013 people were quite concerned about react size (can't exactly remember it's size, but I think it was somewhere close to how it is nowadays or larger)

Re: React v15.0

#107

Post by BinaryIdiot »

spicyj wrote: post #101
BinaryIdiot wrote: post #100

Earlier quoted context omitted.

I had no idea react used .innerHTML. That provides a significant performance drawback compared to other DOM APIs due to it requiring the browser to re-flow / re-render so much more. Glad you guys updated :)

We only used .innerHTML when creating new subtrees, which requires a reflow anyway when they're inserted. There are reasons that document.createElement is faster for us, but that's not one of them.

Even inserting new subtrees should be significantly faster via appendChild() versus innerHTML. The browser has to do a whole heck of a lot more when you don't build the nodes first.

I'm curious though. I'll have to check out the source to see how it works in React now. You know, when I find some free time :)

Re: React v15.0

#108

Post by spicyj »

BinaryIdiot wrote: post #107
spicyj wrote: post #101

Earlier quoted context omitted.

We only used .innerHTML when creating new subtrees, which requires a reflow anyway when they're inserted. There are reasons that document.createElement is faster for us, but that's not one of them.

Even inserting new subtrees should be significantly faster via appendChild() versus innerHTML. The browser has to do a whole heck of a lot more when you don't build the nodes first. I'm curious though. I'll have to check out the source to see how it works in React now. You know, when I find some free time :)

Yeah, you'd think that it would be a lot faster to avoid serializing and parsing everything, but it turns out to be not much difference. Not sure why.

Re: React v15.0

#109

Post by swhipple »

rwjwjuwjudf wrote: post #51
interlocutor wrote: post #48

Earlier quoted context omitted.

If React doesn't have any patents then Facebook could solve this issue by removing the "grant" or by removing the strong retaliation clause from the "grant". I am not a lawyer either, but I think the idea of implicit grant is compatible with common sense.

The link you gave doesn't use the word implicit and actually says: > Wherever possible, make sure you have an explicit license to any necessary patents held by the licensor. Then it goes on to distinguish between weak and strong grants. I think you mean weak, not implicit. AFAICT, there isn't an implicit grant with patent law, because the default is that you're infringing without an explicit grant.

The link in the original post was about strong vs weak retaliation clauses in an explicit license, but the parent is also talking about implicit patent licenses, which do have some case law and opinions surrounding them in the United States [1].

The theory behind implicit patent licenses is that the licensee (often the buyer) will have some idea about which rights they have to the thing they are licensing, absent any other agreement. For a software license like the 3-clause BSD, this means that if they are licensing the software from the holder of the patent, they can reasonably expect to not subsequently be sued for infringing on the patent while following the terms of the license.

Omitting any kind of patent mention from your product's license, and later claiming infringement for reasonably expected use, would look subversive and generally be unconvincing.

[1] http://en.swpat.org/wiki/Implicit_patent_licence#USA

Re: React v15.0

#110

Post by forrestthewoods »

kough wrote: post #53
bshimmin wrote: post #3

The referenced pull request for removing the s ( https://github.com/facebook/react/pull/5753 ) is terrific - a real paragon of open-source professionalism.

I must be getting jaded - my first thought was that you were being sarcastic, so I was really pleasantly surprised when I browsed through. You're right, this is actually fantastic.

Same! I kept reading and re-reading trying to find who did something offensive.
Post reply on HN