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

51–60 of 174 posts

Re: React v15.0

#51

Post by rwjwjuwjudf »

interlocutor wrote: post #48
spicyj wrote: 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.

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.

Re: React v15.0

#52

Post by lisivka »

tomphoolery wrote: post #43
lisivka wrote: 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…

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

Re: React v15.0

#53

Post by kough »

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.

Re: React v15.0

#54

Post by HorizonXP »

Amazing. Honestly, React made me love developing for the web again. It's a huge component of our software, and is what allows us to move so rapidly.

Really happy to see the SVG support, and the continued fast-paced development of React. Onwards!

Re: React v15.0

#55

Post by danabramov »

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.

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.

Re: React v15.0

#56

Post by adriancooney »

spicyj wrote: post #5
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.

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

Re: React v15.0

#57

Post by dustingetz »

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…

The time to parse and execute the js matters too

Re: React v15.0

#58

Post by tyleregeto »

lisivka wrote: post #23
_uhtu wrote: 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.

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.

Re: React v15.0

#59

Post by danabramov »

_uhtu wrote: post #49
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…

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

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.

Re: React v15.0

#60

Post by agnokapathetic »

rjurney wrote: post #41

Can anyone say what this SVG support means for d3.js integration?

I've been using https://github.com/Olical/react-faux-dom with d3 without issue. The project lists the following caveats:

   It's great for...

   - Static D3 components or other such libraries (things like Backbone should work too!)
   - D3 components with simple state and event interaction, like tooltips on charts
   - D3 components such as progress bars that can be animated using react-motion, for example

   It's not so great for...

   - Physics based D3 components or anything using a lot of DOM mutation and state
   - Linked to the previous one, brushing and filtering of selections using the built in stateful D3 tools
   - Essentially: Anything with a lot of DOM mutation from timers, events or internal state will be hard to useation from timers, events or internal state will be hard to use
But I've mutated state in an onMouseOver event, redrawn and it's buttery smooth.

  node
    .on("mouseover", (d) => window.requestAnimationFrame(() => this.setState({selectedElementId: d.id})))
    .on("mouseout", (d) => window.requestAnimationFrame(() => this.setState({selectedElementId: 0})))
  
  node.filter((d) => d.id === this.state.selectedElementId)
    .select("text")
    .style("text-decoration", "underline")
    .style("font-weight", 'bold');
Post reply on HN