Live data from Hacker News

React v15.0

facebook.github.io

91–100 of 174 posts

Re: React v15.0

#91
post #27

Earlier quoted context omitted.

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

That goes without saying....

I took it as a statement of "someone new to the framework, can quickly rewrite their old code" if they came from Angular.

Which is an important metric.

When I converted a Backbone app to Angular, it took 3x as long simply because of the amount of ceremony and process that I had to go through to do things the idiomatic Angular way.

React on the other hand, as a view layer, is so dead simple that you can internalize its workings within hours of study. The complexity with React comes with everything else---Redux, React-Router, GraphQL, CSS in React, etc.

None of that stuff is defined as part of the React framework itself, but that's the only way you can make a "fair comparison" to Angular which is a full-stack framework.

Re: React v15.0

#92
post #35
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.

I think document.createElement could of been prone to memory leaks, as dom objects cannot be freed on the C++ side if it's still accessible from JS, which can be difficult to judge sometimes

https://blog.mozilla.org/research/2014/08/26/javascript-serv...

Re: React v15.0

#94

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.

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

Re: React v15.0

#95
post #50

Earlier quoted context omitted.

>It could also be that there aren't any patents that cover React. If that is the case, why have this controversial patent clause at all? I haven't read them all, but Facebook seems to have a number of patents which at first glance are so broad they could apply to react: https://patents.google.com/patent/US20160092096A1/en "a method performed by one or more computing devices including defining a hierarchical structure…

That list of patents reads like an Onion article. Is there a joke I'm missing here?

> Is there a joke I'm missing here?

other than the unmitigated absurdity that is the patent system these days?

Re: React v15.0

#96
post #23

Earlier quoted context omitted.

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.

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

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.

Re: React v15.0

#97
post #7

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

It's really depressing that every single thread about React has to beat this confused dead horse.

Re: React v15.0

#98
post #50

Earlier quoted context omitted.

>It could also be that there aren't any patents that cover React. If that is the case, why have this controversial patent clause at all? I haven't read them all, but Facebook seems to have a number of patents which at first glance are so broad they could apply to react: https://patents.google.com/patent/US20160092096A1/en "a method performed by one or more computing devices including defining a hierarchical structure…

That list of patents reads like an Onion article. Is there a joke I'm missing here?

Did you also read the patent's text, or just their title and high-level description?

Re: React v15.0

#99
post #34

Earlier quoted context omitted.

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

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.

If there was such a thing as an "implicit" grant, then there would never be patent infringement cases.

Re: React v15.0

#100
post #35
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.

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 :)
Post reply on HN