
React v15.0 - clessg
https://facebook.github.io/react/blog/2016/04/07/react-v15.html
======
bshimmin
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
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.

~~~
jfhollingworth
Out of interest, do you have a link to the github issue?

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

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

~~~
tomphoolery
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 websites aren't repeated over
and over again for the same libraries. And it could even be extended to CSS:

    
    
        @import package("github.com/twbs/bootstrap/tree/3.3.6");

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

~~~
moreati
Subresource Integrity is the standard for that
[https://www.w3.org/TR/SRI/](https://www.w3.org/TR/SRI/)

~~~
et1337
Do you know if this allows consolidation of multiple copies of the same
resource from different hosts?

~~~
woogley
Not currently, because it conflicts with CSP. See
[https://news.ycombinator.com/item?id=10311020](https://news.ycombinator.com/item?id=10311020)

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

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

~~~
DrJokepu
What is exactly your problem with TSX? I've been using TSX for a while so
maybe I can help. The only thing that TypeScript really adds to JSX is
component parameter validation, which is quite neat to be honest.

~~~
petilon
TypeScript also validates the expressions that supply the values. And if you
use Visual Studio you get intellisense and validation for HTML, and
intellisense and instant validation of your javascript expressions. These
benefits are awesome, and by the way, all this is independent of React. You
can use TSX just as a templating library using UIBuilder, see:
[https://github.com/wisercoder/uibuilder](https://github.com/wisercoder/uibuilder)

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

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

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

~~~
zxcvcxz
Angular two lost me.

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

~~~
cname
> 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
writing the original app even with the overhead of learning Pyramid, because
I've already figured out the functional aspects of the app.

Generally speaking, learning frameworks isn't the hard part of writing an app,
unless the app is trivial.

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

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

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

~~~
BinaryIdiot
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
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
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 :)

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

~~~
esailija
The native API calls such as createElement are pretty expensive (in V8 it's
like 10 function calls to finally reach the target C++ function) and you are
making a lot more such calls when not using innerHTML.

~~~
spicyj
Interesting, thanks. I had heard that calls from JS to C++ were cheap but
calls from C++ to JS (such as if Array.prototype.map was implemented natively)
were expensive.

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

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

------
brotherjerky
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
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
(Replied to your top-level comment at
[https://news.ycombinator.com/item?id=11451283.](https://news.ycombinator.com/item?id=11451283.))

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

~~~
spicyj
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.)

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

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

~~~
spicyj
Haven't benchmarked again, but it should be. This came from the
document.createElement and reactid changes (and some associated internal
refactors).

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

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

~~~
divmain
No direct implications. But it should provide solid ground for libraries like
Victory.
[https://github.com/FormidableLabs/Victory](https://github.com/FormidableLabs/Victory)

~~~
n0us
Wow, this is an awesome library. Thanks for sharing this.

------
zactato
Has Facebook removed the potentially dangerous patent restrictions?

[https://news.ycombinator.com/item?id=8985541](https://news.ycombinator.com/item?id=8985541)

~~~
spicyj
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...](https://github.com/facebook/react/commit/b8ba8c83f318b84e42933f6928f231dc0918f864)

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

~~~
nkw
>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](https://patents.google.com/patent/US20160092096A1/en)
"a method performed by one or more computing devices including defining a
hierarchical structure for a user interface (UI) that includes defining one or
more layers of the hierarchical structure, adding one or more objects at each
layer, and specifying one or more relationships among particular objects"

[https://patents.google.com/patent/US20160091953A1/en](https://patents.google.com/patent/US20160091953A1/en)
"Adjusting mobile device state based on user intentions and/or identity"

[https://patents.google.com/patent/US20150277691A1/en](https://patents.google.com/patent/US20150277691A1/en)
"In one embodiment, as a user is scrolling through a first series of content
items and reaches the nth content items from the first series of content
items, display a visual indication that there are additional content items
from the first series of content items existing after the nth content item."

[https://patents.google.com/patent/US20150113066A1/en](https://patents.google.com/patent/US20150113066A1/en)
"A communications system including one or more alert gates and an alert
controller. Each alert gate is configured to detect a different type of alert
feed corresponding to a particular kind of alert. The alert controller is
connected to the alert gates and operable to receive detected alerts from the
alert gates and to deliver the detected alerts to a user of the communications
system."

[https://patents.google.com/patent/US20160086219A1/en](https://patents.google.com/patent/US20160086219A1/en)
"methods and systems that allows for improved user navigation within a group
of content items."

I actually had no idea Facebook's patent portfolio was so broad. There are
countless more:
[https://patents.google.com/?q=G06F3%2f048&assignee=Facebook+...](https://patents.google.com/?q=G06F3%2f048&assignee=Facebook+Inc)

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

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

~~~
swhipple
Even the text of some are pretty much as expected. It seems that they have a
patent on single page applications (SPAs) to-a-T [1], elaborating that an
application may use mechanisms like XHR and append an identifier to the
fragment portion of the URL to keep history.

Even if I subscribed to the idea that this was without prior art on the web in
2009, equivalent functionality already existed in desktop applications. To
claim that it is a novel invention because it now works on a web page is
disheartening. It's exactly this kind of behavior--claiming new ownership
based on each abstraction--that leads to restrictions in some countries on
patents which can only exist in software.

[1]
[https://www.google.com/patents/US20110055314](https://www.google.com/patents/US20110055314)

------
kriro
Interesting renaming choice. ReactPerf.getWasted()

:D

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

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

------
qudat
Is the `key` prop still required?

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

