28 ms·

React v15.0

695 points by clessg 11y ago

zactato 11y ago
Has Facebook removed the potentially dangerous patent restrictions? https://news.ycombinator.com/item?id=8985541 https://news.ycombinator.com/item?id=8985541
- spicyj 11y ago
  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/b8ba8c83f318b84e42933f6928f231dc0918f864 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.
  - interlocutor 11y ago
    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 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.
    - spicyj 11y ago
      > 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.
      - interlocutor 11y ago
        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.
        rwjwjuwjudf 11y ago
        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.
        swhipple 11y ago
        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 http://en.swpat.org/wiki/Implicit_patent_licence#USA
- abritinthebay 11y ago
  Yes, a year ago. They weren't potentially dangerous in the first place really but they updated them after the feedback to be much more explicit and literally no-one appears to have issue with it anymore.
  - ergo14 11y ago
    What about google, did they started using react?
- morgante 11y ago
  It's really depressing that every single thread about React has to beat this confused dead horse.
  - ergo14 11y ago
    The "grant" text suddenly disappeared from the source code? I'd say it is depressing that people don't care.
joshmanders 11y ago
As a recent converter from Angular to React, I'm so excited for this release. Great job Dan & React Core Team!
- zxcvcxz 11y ago
  Angular two lost me.
  - joshmanders 11y ago
    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 any prior experience in React. I was both impressed and giddy. The next day I merged that reactify branch into my develop branch, and continued on. I feel that React does components better. I feel that Angular 1.5's introduction of the component sugar over top directives and even components in Angular 2.x just felt shoehorned in as an afterthought. I couldn't even spend a day trying to figure out how to componantize this app in Angular 2.x let alone 1.5. Now I'm head deep in learning as much about the ecosystem as I can, Redux, Relay, GraphQL, all that good stuff. I've officially ditched Angular for the React ecosystem.
    - Bahamut 11y ago
      Sounds like that is credit to both Angular and React for facilitating largely library/framework agnostic code. I should mention that Angular 2 is quite a work in progress currently - even though it has the beta label, it still is very much far from production ready IMO. Components in Angular 2 are largely well conceived, excepting the interactions with inputs and outputs and how they interact between reusable components. React was cited by an Angular team member to me as being vastly easier to use when it comes to intercomponent communication currently - I trust the Angular team will eventually get it right, but for now there are certainly some holes.
    - 11y ago
bshimmin 11y ago
The referenced pull request for removing the <span>s (https://github.com/facebook/react/pull/5753 https://github.com/facebook/react/pull/5753) is terrific - a real paragon of open-source professionalism.
- joshmanders 11y ago
  Agreed. I'm really impressed by the professionalism shown by all members of the React ecosystem. Just the other day I had noticed a org member of the reactjs org (houses react-router, redux, etc) who was acting very unprofessional and expressed that it was a turn off seeing official members of the org basically telling a issue reporter/discussion was "annoying them" and Ryan Florence stepped up and said he was not tolerating that and even reached out to me on Twitter apologizing and saying that they do not condone such tones.
  - bubtubgub 11y ago
    The react community is great, in stark contrast to the angular community.
  - jfhollingworth 11y ago
    Out of interest, do you have a link to the github issue?
  - t81798112 11y ago
    "professionalism", "reached out to me"? When will this blathering in open source stop?
  - automathematics 11y ago
    That community specifically has been rude to me too. Eager to see that change for the better!
- spicyj 11y ago
  +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.
brotherjerky 11y ago
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.
- coltonv 11y ago
  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 frameworks like Riot/Mithril/Cycle which are all much much smaller and achieve about as much (in my opinion).
  - spicyj 11y ago
    (Replied to your top-level comment at https://news.ycombinator.com/item?id=11451283. https://news.ycombinator.com/item?id=11451283.)
  - rattray 11y ago
    I don't think this person should have been downvoted. This was not an inflammatory comment.
  - gnagatomo 11y ago
    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)
nailer 11y ago
> There were a number of large changes to our interactions with the DOM. One of the most noticeable changes is that we no longer set the data-reactid attribute for each DOM node. Nice. I currently use another functional reactive virtual DOM data binding mechanism and the data attributes everywhere was one of the things that didn't appeal about react. Since react is getting crazy network effects from community I might check it out for my next project.
calcsam 11y ago
In ReactConf, Ben Alpert noted that there would be a ~10% performance improvement from v15.0. Is that still true?
- spicyj 11y ago
  Haven't benchmarked again, but it should be. This came from the document.createElement and reactid changes (and some associated internal refactors).
  - Silhouette 11y ago
    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.
    - spicyj 11y ago
      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.
      - Silhouette 11y ago
        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.
abengoam 11y ago
Great news about the support for all the SVG tags and attributes. Now I can get rid of ugly dangerouslySetInnerHTML hacks for unsupported elements :)
coltonv 11y ago
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 more tools out of the box. I don't intend to tell anyone here that React is a bad framework because it's not, but I think it should be a big priority to tighten down the file size. When React is big pretty much all their selling points go out the window. Perhaps they can split files up so you can just import the APIs you want. I wonder how much that would help with the bloat. I feel like some of the smaller VDOM frameworks like Cycle/Mithril/Riot are a lot more appealing now, since they focus on small file size and low bloat.
- spicyj 11y ago
  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.
  - danabramov 11y ago
    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 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.
nevir 11y ago
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)
- spicyj 11y ago
  I'm not sure how this is ironic? We were using one DOM API (.innerHTML) before; now we're using a different one.
  - akst 11y ago
    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-servos-only-garbage-collector/ https://blog.mozilla.org/research/2014/08/26/javascript-serv...
  - BinaryIdiot 11y ago
    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 :)
    - spicyj 11y ago
      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.
      - BinaryIdiot 11y ago
        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 :)
rabelrabel 11y ago
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?
- spicyj 11y ago
  Nope, it shouldn't affect you at all. (Otherwise it would have been noted in the blog post -- that should have all the info you need to upgrade.)
ndreckshage 11y ago
Really nice work with all this! Great blog post on update
kuon 11y ago
If you are using typescript, you should read: https://github.com/Microsoft/TypeScript/issues/7270 https://github.com/Microsoft/TypeScript/issues/7270 TLD'R: React 15.0 broke TSX in typescript but the workaround is easy.
- spicyj 11y ago
  We didn't realize this would break. We're looking at cutting a 15.0.1 that puts React.__spread back with a warning.
  - lmm 11y ago
    I realise it's a lot of work, but as more and more downstream projects come to depend on React, having a "community build" that would build those against your RCs and run some integration tests would be a great way to improve reliability of the overall ecosystem.
- technion 11y ago
  Seems to still work in my small codebase, but I get a series of type warnings. Typings still has 0.14 tagged as the latest - I'm guessing we need an update there too?
- deadbeef404 11y ago
  Also note, if anyone is using "reactify" and has used the spread operator in JSX, as 15.0.0 removed React.__spread, your build will break. (Reactify uses the deprecated react-tools which uses React.__spread.)
  - danabramov 11y ago
    Yeah. Putting a warning should solve the problem because people will start complaining to the transform vendors about this and hopefully they will deprecate their transforms or use Babel internally.
- erichocean 11y ago
  FWIW I used TypeScript in anger with React, and hated it so much I rewrote all the React code in regular JavaScript. TypeScript and React, IMO, are a poor fit. To be clear: I do like TypeScript and use it almost exclusively on the server, so this isn't a case of me "not liking TypeScript". It's the combination of the two. Basically, all of the stuff I did to keep TypeScript happy when using React was worthless overhead and brought nothing but pain, warping the codebase horribly. The JavaScript version with React was smaller, lighter, and had way less cognitive overhead. YMMV.
rjurney 11y ago
Can anyone say what this SVG support means for d3.js integration?
- nsonnad 11y ago
  It will likely strengthen the case for having react manage the DOM while d3 takes care of any fancy math you need, like computing the d attribute for a <path> in a line chart. Previously there were some SVG elements that simply couldn't be expressed in React and so you had to either push that DOM management onto d3 or dangerouslySetInnerHTML
- agnokapathetic 11y ago
  I've been using https://github.com/Olical/react-faux-dom 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');
- divmain 11y ago
  No direct implications. But it should provide solid ground for libraries like Victory. https://github.com/FormidableLabs/Victory https://github.com/FormidableLabs/Victory
  - 11y ago
HorizonXP 11y ago
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!
- borge 11y ago
  React made frontend much more enjoyale to me too, it's so quick to build nice things in it :)
CalmStorm 11y ago
I just tried the new release. The data-reactid is indeed gone when rendering on the client side. But on the server side, the html string generate by ReactDOMServer.renderToString still has data-reactid. Is it because client side can validate the server result and decide if it needs to re-render the page?
- spicyj 11y ago
  Not quite -- it's so that the client can know which node is which. (When rendering on the client, it can just store a direct reference to each created node.)
deleted 11y ago
[deleted]
testerxxx 11y ago
-,-
- deleted 11y ago
  [deleted]
qudat 11y ago
Is the `key` prop still required?
- spicyj 11y ago
  Yes, it is. React uses it to track identity of components in a list; it's significant especially when reordering children and affects both which DOM nodes get reused as well as whether this.state is preserved.
kriro 11y ago
Interesting renaming choice. ReactPerf.getWasted() :D
- danabramov 11y ago
  Yeah I was hesitant about this one. At least it will be consistent with other methods (we’ll add getInclusive(), getExclusive() etc).

695 points by clessg 11y ago

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

spicyj 11y ago
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/b8ba8c83f318b84e42933f6928f231dc0918f864 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.
- interlocutor 11y ago
  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 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.
  - spicyj 11y ago
    > 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.
    - interlocutor 11y ago
      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.
      - rwjwjuwjudf 11y ago
        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.
        swhipple 11y ago
        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 http://en.swpat.org/wiki/Implicit_patent_licence#USA
abritinthebay 11y ago
Yes, a year ago. They weren't potentially dangerous in the first place really but they updated them after the feedback to be much more explicit and literally no-one appears to have issue with it anymore.
- ergo14 11y ago
  What about google, did they started using react?
morgante 11y ago
It's really depressing that every single thread about React has to beat this confused dead horse.
- ergo14 11y ago
  The "grant" text suddenly disappeared from the source code? I'd say it is depressing that people don't care.

joshmanders 11y ago

As a recent converter from Angular to React, I'm so excited for this release. Great job Dan & React Core Team!

zxcvcxz 11y ago
Angular two lost me.
- joshmanders 11y ago
  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 any prior experience in React. I was both impressed and giddy. The next day I merged that reactify branch into my develop branch, and continued on. I feel that React does components better. I feel that Angular 1.5's introduction of the component sugar over top directives and even components in Angular 2.x just felt shoehorned in as an afterthought. I couldn't even spend a day trying to figure out how to componantize this app in Angular 2.x let alone 1.5. Now I'm head deep in learning as much about the ecosystem as I can, Redux, Relay, GraphQL, all that good stuff. I've officially ditched Angular for the React ecosystem.
  - Bahamut 11y ago
    Sounds like that is credit to both Angular and React for facilitating largely library/framework agnostic code. I should mention that Angular 2 is quite a work in progress currently - even though it has the beta label, it still is very much far from production ready IMO. Components in Angular 2 are largely well conceived, excepting the interactions with inputs and outputs and how they interact between reusable components. React was cited by an Angular team member to me as being vastly easier to use when it comes to intercomponent communication currently - I trust the Angular team will eventually get it right, but for now there are certainly some holes.
  - 11y ago

bshimmin 11y ago

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

joshmanders 11y ago
Agreed. I'm really impressed by the professionalism shown by all members of the React ecosystem. Just the other day I had noticed a org member of the reactjs org (houses react-router, redux, etc) who was acting very unprofessional and expressed that it was a turn off seeing official members of the org basically telling a issue reporter/discussion was "annoying them" and Ryan Florence stepped up and said he was not tolerating that and even reached out to me on Twitter apologizing and saying that they do not condone such tones.
- bubtubgub 11y ago
  The react community is great, in stark contrast to the angular community.
- jfhollingworth 11y ago
  Out of interest, do you have a link to the github issue?
- t81798112 11y ago
  "professionalism", "reached out to me"? When will this blathering in open source stop?
- automathematics 11y ago
  That community specifically has been rude to me too. Eager to see that change for the better!
spicyj 11y ago
+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.

brotherjerky 11y ago

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.

coltonv 11y ago
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 frameworks like Riot/Mithril/Cycle which are all much much smaller and achieve about as much (in my opinion).
- spicyj 11y ago
  (Replied to your top-level comment at https://news.ycombinator.com/item?id=11451283. https://news.ycombinator.com/item?id=11451283.)
- rattray 11y ago
  I don't think this person should have been downvoted. This was not an inflammatory comment.
- gnagatomo 11y ago
  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)

nailer 11y ago

> There were a number of large changes to our interactions with the DOM. One of the most noticeable changes is that we no longer set the data-reactid attribute for each DOM node. Nice. I currently use another functional reactive virtual DOM data binding mechanism and the data attributes everywhere was one of the things that didn't appeal about react. Since react is getting crazy network effects from community I might check it out for my next project.

calcsam 11y ago

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

spicyj 11y ago
Haven't benchmarked again, but it should be. This came from the document.createElement and reactid changes (and some associated internal refactors).
- Silhouette 11y ago
  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.
  - spicyj 11y ago
    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.
    - Silhouette 11y ago
      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.

abengoam 11y ago

Great news about the support for all the SVG tags and attributes. Now I can get rid of ugly dangerouslySetInnerHTML hacks for unsupported elements :)

coltonv 11y ago

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 more tools out of the box. I don't intend to tell anyone here that React is a bad framework because it's not, but I think it should be a big priority to tighten down the file size. When React is big pretty much all their selling points go out the window. Perhaps they can split files up so you can just import the APIs you want. I wonder how much that would help with the bloat. I feel like some of the smaller VDOM frameworks like Cycle/Mithril/Riot are a lot more appealing now, since they focus on small file size and low bloat.

spicyj 11y ago
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.
- danabramov 11y ago
  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 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.

nevir 11y ago

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)

spicyj 11y ago
I'm not sure how this is ironic? We were using one DOM API (.innerHTML) before; now we're using a different one.
- akst 11y ago
  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-servos-only-garbage-collector/ https://blog.mozilla.org/research/2014/08/26/javascript-serv...
- BinaryIdiot 11y ago
  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 :)
  - spicyj 11y ago
    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.
    - BinaryIdiot 11y ago
      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 :)

rabelrabel 11y ago

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?

spicyj 11y ago
Nope, it shouldn't affect you at all. (Otherwise it would have been noted in the blog post -- that should have all the info you need to upgrade.)

ndreckshage 11y ago

Really nice work with all this! Great blog post on update

kuon 11y ago

If you are using typescript, you should read: https://github.com/Microsoft/TypeScript/issues/7270 https://github.com/Microsoft/TypeScript/issues/7270 TLD'R: React 15.0 broke TSX in typescript but the workaround is easy.

spicyj 11y ago
We didn't realize this would break. We're looking at cutting a 15.0.1 that puts React.__spread back with a warning.
- lmm 11y ago
  I realise it's a lot of work, but as more and more downstream projects come to depend on React, having a "community build" that would build those against your RCs and run some integration tests would be a great way to improve reliability of the overall ecosystem.
technion 11y ago
Seems to still work in my small codebase, but I get a series of type warnings. Typings still has 0.14 tagged as the latest - I'm guessing we need an update there too?
deadbeef404 11y ago
Also note, if anyone is using "reactify" and has used the spread operator in JSX, as 15.0.0 removed React.__spread, your build will break. (Reactify uses the deprecated react-tools which uses React.__spread.)
- danabramov 11y ago
  Yeah. Putting a warning should solve the problem because people will start complaining to the transform vendors about this and hopefully they will deprecate their transforms or use Babel internally.
erichocean 11y ago
FWIW I used TypeScript in anger with React, and hated it so much I rewrote all the React code in regular JavaScript. TypeScript and React, IMO, are a poor fit. To be clear: I do like TypeScript and use it almost exclusively on the server, so this isn't a case of me "not liking TypeScript". It's the combination of the two. Basically, all of the stuff I did to keep TypeScript happy when using React was worthless overhead and brought nothing but pain, warping the codebase horribly. The JavaScript version with React was smaller, lighter, and had way less cognitive overhead. YMMV.

rjurney 11y ago

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

nsonnad 11y ago
It will likely strengthen the case for having react manage the DOM while d3 takes care of any fancy math you need, like computing the d attribute for a <path> in a line chart. Previously there were some SVG elements that simply couldn't be expressed in React and so you had to either push that DOM management onto d3 or dangerouslySetInnerHTML
agnokapathetic 11y ago
I've been using https://github.com/Olical/react-faux-dom 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');
divmain 11y ago
No direct implications. But it should provide solid ground for libraries like Victory. https://github.com/FormidableLabs/Victory https://github.com/FormidableLabs/Victory
- 11y ago

HorizonXP 11y ago

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!

borge 11y ago
React made frontend much more enjoyale to me too, it's so quick to build nice things in it :)

CalmStorm 11y ago

I just tried the new release. The data-reactid is indeed gone when rendering on the client side. But on the server side, the html string generate by ReactDOMServer.renderToString still has data-reactid. Is it because client side can validate the server result and decide if it needs to re-render the page?

spicyj 11y ago
Not quite -- it's so that the client can know which node is which. (When rendering on the client, it can just store a direct reference to each created node.)

deleted 11y ago

[deleted]

testerxxx 11y ago

-,-

deleted 11y ago
[deleted]

qudat 11y ago

Is the `key` prop still required?

spicyj 11y ago
Yes, it is. React uses it to track identity of components in a list; it's significant especially when reordering children and affects both which DOM nodes get reused as well as whether this.state is preserved.

kriro 11y ago

Interesting renaming choice. ReactPerf.getWasted() :D

danabramov 11y ago
Yeah I was hesitant about this one. At least it will be consistent with other methods (we’ll add getInclusive(), getExclusive() etc).