
React 16 - markthethomas
https://facebook.github.io/react/blog/2017/09/26/react-v16.0.html
======
Androider
5 minute real-world performance test: I just upgraded a relatively large
(200K+ LOC) app that performs server side rendering of charts from React 15.6
to 16.0. Render time dropped from ~50ms to ~15ms. The previous version was
already optimized and precompiled (e.g. none of the process.env performance
penalties were applicable).

Very impressive improvement for a drop-in upgrade! Especially considering the
previous version was not considered slow at all given the complexity.

~~~
polskibus
Can you tell what app is it? I'm looking for an app that can do server side
chart rendering if necessary.

~~~
cies
I'd go with SVG charts (SVG is well supported -
[http://caniuse.com/#feat=svg](http://caniuse.com/#feat=svg))

[http://mediatemple.net/blog/tips/svg-charting-
libraries](http://mediatemple.net/blog/tips/svg-charting-libraries)

------
spicyj
We're really excited about this release. I also wrote about how we made the
rewrite happen on our Facebook engineering blog:
[https://news.ycombinator.com/item?id=15339825](https://news.ycombinator.com/item?id=15339825).

Happy to answer questions if y'all have any. :)

~~~
outside1234
Are there plans to relicense React Native to MIT without a Patent timebomb as
well?

~~~
mihular
But does MIT license really solve all patent issues? FB could still enforce
patents regardless of license if I understood it properly.

~~~
mlsarecmg
Everyone can, that's precisely why they gave you a grant previously. Now that
it's gone due to the outcry it's in the same, vague playing field that all
other libraries are in. Every project you have ever written infringes on
someones IP. The only thing that matters is that lawyers that previously got
cold feet can now relax. We had a project for instance that was canceled, now
it's being green-lit thanks to the MIT license.

~~~
TimTheTinker
Actually, there is an (albeit so far untested) implicit patent grant in all-
permissive licenses like the MIT. So removing the explicit one-way, revokable
patent grant actually implicitly provides a better patent grant.

~~~
mihular
I'd really like to see that written black on white,though.

~~~
TimTheTinker
The fact that MIT and BSD licensed code (implicit patent impunity) can be re-
licensed under the Apache license (explicit patent impunity) is enough
evidence for me.

Reference:
[http://apache.org/legal/resolved.html#category-a](http://apache.org/legal/resolved.html#category-a)

~~~
ec109685
What does re-licensed mean? You can’t take mit licensed code and slap a Apache
License on it.

~~~
TimTheTinker
You can create a derivative work and license that under Apache.

~~~
ec109685
Not if it uses copyrighted MIT licensed code.

------
orb_yt
Lovely. The file size reductions are quite surprising.

Removing the need to wrap sibling elements in a single parent element is a
welcome change.

I'd be interested in hearing some use cases for using the Portal API.

Lastly, the new licensing announced last week was fantastic news. I commented
on last weeks thread, but I want to extend another round of compliments to
Facebook and the React community as a whole for prompting this change. _Props_
to them.

~~~
humblebee
We use portals quite a bit in our application and they always are a pain to
test. This is what excites me the most about React supporting them natively.
Hopefully this means that enzymejs will be able to easily walk down and
seamlessly jump into a different part of the DOM without having to use
references to adjust.

Portals are helpful when using content overflow in modals. For example, we
have a modal which contains a form and that form has an autocomplete text box.
When we render the autocomplete part, we need to render it outside of the
modal, otherwise the overflow policy blocks the contents and does not allow
the autocomplete are to appear over / outside of the modal.

The use of portals also make it easier to support screen readers through the
aria tags by allowing the application to quickly block the background of the
application and allow the screen reader to focus on the content presented to
the user.

~~~
danield9tqh
This does worry me a bit though. There is probably a reason they are difficult
to test, because they go against the React DOM pattern of a component only
having control over the DOM nodes inside it. Call me a purist but this seems
like a deviation from React's functional roots and going against the very
problem React was trying to solve in the first place.

~~~
danabramov
The feature is mostly intended for rendering into nodes _not_ managed by
React. Such as a document child that is sibling to the application root.

------
alexquez
I'm impressed by how accessible Facebook makes open source tech. It's always
top notch but documented in a way that allows regular devs the opportunity to
use it in their own apps.

Smaller size and easier to use is a big win. Going with the MIT license puts a
real bow on this release. Thank you to the React team.

~~~
jbreckmckye
It is very good, but I wonder what their intentions are. Is it to help hire
talent?

~~~
matmo
Assuming you're referring to the licensing part, it's probably because they've
gotten a lot of public backlash for their previous licensing scheme that has
caused some to avoid React altogether.

~~~
jbreckmckye
No, I mean - open sourcing their software. I don't know what their goal is as
a company.

~~~
gt2
Sometimes to attract talent, sometimes to brings free work to a project.

Other times it's lock in for related technologies (current or future plans).

Some have speculated that it's a legal trick, like the problem everyone was
insinuating with the React license before the recent change.

Anyone else have reasons I'm missing?

~~~
aickin
Three other (somewhat related) reasons I’ve heard stated by FB folks:

1\. Makes it easier to identify talent out in the world that they want to go
after.

2\. Raises the technical reputation of Facebook, making it easier to get
candidates to say yes.

3\. Makes it easier to ramp new employees up on Facebook’s stack if they are
already familiar with a lot of it from open source.

------
hitekker
Great release but forcing the capturing of errors seems to violate the JS
value of forgiveness. Worse, this "forcing" actually seems to _hinder_
debugging.

For example, I have one component that throws an exception. Previously, React
would print the stack trace in console and carry on. Now, it destroys the
entire DOM, spews three times as many errors, without even letting me see what
the visual result was of that error.

To debug, I need to write a componentDidCatch method in the parent class of
the erroring class, because the root componentDidCatch error handler can't
reconstruct the DOM, because of that one sub-sub-sub-sub-sub-child state
error.

Even after writing all this new code, React still removes the erroring element
from the DOM, leaving ambiguous what its impact was on the end-user
experience.

Does anyone else feel that the new version of React is fault-intolerant?

While I do enjoy Java, I would argue that Null-Pointer-Exception hell does not
belong in JS scripting.

~~~
raquo
Everyone with a legacy codebase will probably update their components to
extend a common class that handles errors in some very generic way without
propagating them up the tree.

I'm not sure how I feel about this change, but at least there's an escape
hatch.

~~~
superplussed
Do you mean wrapping all components with a HOC?

~~~
raquo
No, I mean ES6 class inheritance:

class MyButton extends MyBaseComponent {

    
    
      // Render a button

}

Class MyBaseComponent extends React.Component {

    
    
      // Include error handling lifecycle hook here
    
    }

------
Kwastie
Even though React 16 is almost a complete rewrite, it's amazing how they kept
an almost complete compatible api between releases.

Congrats on shipping!

~~~
colemorrison
Yes yes, this is incredibly impressive. Very smart as well for ease of getting
people to adopt the new version. I was fearing that I'd have to redo who knows
how much just to use 16.

------
unohoo
2 awesome things about this release: 1) No need to wrap siblings in an
enclosing element - upgrade is worth it just for this change alone (j/k)

2) I'm surprised no one has mentioned it so far -- but this release uses the
new fiber architecture - I saw the video presentation about fiber and think it
could really help in terms of performance

~~~
ec109685
What aspect of performance?

------
debaserab2
Portals seem like a great idea. It seems like it eliminates one of the major
use cases (imo) for inlined styles: rendering child components deep within the
DOM when visually the component doesn't appear that it should be that deep
(e.g., rendering a global level modal that in the DOM might be appear in a
deeply nested div). That always wreaked havoc with stylesheet selectors and is
one of the reasons I started moving towards injected inline styles.

Overall reduction of container elements is a huge plus. I'll be happy if I can
start thinning out the giant christmas tree that react tends to create, even
if it's not a huge performance gain, this will improve debugging immensely.

------
mhd
So, what's the current ES5, non-Babel/Webpack/Rollup/Brunch/etc story of
React? When I first tested it, all you had to include was two Javascript files
and you could go, and if you were foregoing JSX it was even easier.

These days it seems you need to download half the internet for even the most
trivial uses, never mind using the half-finished ersatz JS du jour. And yes, I
know that it gets compiled to a tiny thing worth of the IOCCC for the end
user, but sometimes even us programmers want an easy setup. It seems the only
framework that still has a good story regarding that is Mithril…

~~~
danabramov
It's exactly the same as it always have been. See the doc:

[https://facebook.github.io/react/docs/react-without-
es6.html](https://facebook.github.io/react/docs/react-without-es6.html)

[https://facebook.github.io/react/docs/react-without-
jsx.html](https://facebook.github.io/react/docs/react-without-jsx.html)

~~~
spicyj
In particular: you just need these script tags:

    
    
      <script crossorigin src="https://unpkg.com/react@16/umd/react.development.js"></script>
      <script crossorigin src="https://unpkg.com/react-dom@16/umd/react-dom.development.js"></script>

------
a13n
So much good stuff in here. Perf wins, in both bytes down the wire and render
time. I've been wanting to return sibling elements from render for _years_!

Crazy to see such a robust, mature framework still improving so much. Can't
wait to upgrade!

------
supernintendo
Really excited about Portals. I work on a web app which was originally built
with Spine.js (an MVC framework similar to Backbone). We've long moved on to
React and Redux but have a few old views that have yet to be ported over.
Portals seems like a nice way to refactor by incrementally replacing
controller + template logic with components.

I'm also glad to see the switch to MIT license if only to put this patents
controversy behind us. Now curious to see what happens with GraphQL...

~~~
qaq
How exactly does it put patent controversy behind us? Before you had limited
patent grant now you have none

~~~
brlewis
Because now it's exactly like every other piece of open source software, so
lawyers can stop debating whether it's better or worse than an implicit grant.

~~~
qaq
Like every other piece of OS software that is known to be covered by patents

~~~
brlewis
Just because software is not known to be covered by patents doesn't mean you
don't have to worry about software patents.

------
slaymaker1907
I'm super excited for pseudo-components. This should make it much easier to
use CSS constructs like flexbox and the new grid system since they don't like
nested DOM tags.

I tried to make a set of React components that worked like a table (with rows
and columns) using CSS grid in React 15, but it was nearly impossible to do.
For the record, the reason I didn't just use a table was because the grid
system allows for more expressive sizing of columns than plain tables.

------
fortythirteen
The big news it that they removed the PATENTS.md file that made it nearly
impossible to use for anyone concerned with protecting their IP. Good on them
for making right with the open source community.

~~~
abiox
i wonder: if you don't have a contractual relationship preventing it, can't fb
revoke your permission to use their patents at-will? if so, has removing the
patent grant actually changed anything?

~~~
teraflop
It's actually the other way around, as I understand it. This is one area in
which patent law and copyright law differ noticeably.

Due to the way implied patent licenses work, if Facebook distributes React
without explicit restrictions or conditions, they're automatically granting a
license to any patents that are _inherently_ infringed by React itself. This
is a pretty well-established area of US patent law, see e.g.
[https://www.wilmerhale.com/pages/publicationsandnewsdetail.a...](https://www.wilmerhale.com/pages/publicationsandnewsdetail.aspx?NewsPubId=95535)

~~~
abiox
afaik no component of react is covered by a fb patent, so a fb patent
revocation wouldn't impact one's use of react.

if fb actually wanted to prevent someone from using react, they could just
revoke the copyright grant.

~~~
spicyj
The LICENSE file is a grant that Facebook can't revoke even if it wanted to.

------
fairview14
Thank you FB React team. Along with the new license I can't be happier to see
your good work and improvements on React.

Before the license change I was looking around for other options, but now I
can continue to enjoy front-end development with this awesome library for at
least a few years more. For me this definitely helps fighting JS fatigue not
having to change to another framework.

------
SlyShy
Impressive improvements in this version and very heartening to see performance
improve in addition to the new APIs.

Multiple render return types and portals both solve some annoying situations
that can come up.

~~~
stefantheard
Not to mention the decreased size! This is a really really great upgrade.

------
skrebbel
Small nitpick: the reduced file size appears to be, in part, due to depending
on Map and Set. Polyfilling these will, in turn, increase file size so there's
no real file size impact in practice. IMO the blog post could've been more
honest about that.

Fantastic release nevertheless!

~~~
spicyj
This wasn't actually the reason for the reduction, but it is something we
weren't acutely accounting for since we already have Map+Set polyfills in our
apps and expect most other users to as well. We'll see if we can recommend a
smaller polyfill that isn't as large.

~~~
skrebbel
Awesome! I must admit I never really saw the added value of Map and Set given
the size increase - for most purposes objects and arrays work fine in
practice.

I strongly doubt I'm the only one there.

------
3131s
If I were to cave in and learn React, can someone recommend an existing
project that would serve as good learning material?

~~~
truekojo
This repo has been quite helpful pour moi...

[https://github.com/gothinkster/react-redux-realworld-
example...](https://github.com/gothinkster/react-redux-realworld-example-app)

~~~
gt2
Looks good but can any React experts comment as to

\- whether or not this really uses best practices?

\- leverages React to the fullest?

~~~
acemarke
Those are both pretty broad questions. Skimming through the code, I'd say it's
a reasonable example of a React+Redux codebase. I don't think I could say it
"leverages React to the fullest", because it's unclear exactly what that
means, and this is not an overly complex sample application. But, it does
serve as a useful example of something more "real" than yet another TodoMVC
clone.

------
petetnt
Congrats for shipping this for everybody involved! 16 has been a long time
coming and I super happy for all the new features it brings us. Error
boundaries! Fragments! Even better SSR! And so much more.

------
tootie
If I'm building a site where SEO is paramount, am I safe using React and SSR?
I'd kinda like to, but my inclination is to stick with a traditional server
page approach.

~~~
andrewingram
SEO-wise there's no difference other than performance. But it was possible to
build high-performance SSR sites with React 15, and with React 16 it's even
easier.

The more important thing to decide is whether the development model of React
is suitable for your needs.

~~~
emilecantin
We're actually doing this right now with tylio.com. We get pretty high scores
(95+) on the various test tools (Pagespeed, Lighthouse, etc.) using React 15.
Our biggest remaining issues right now are First Meaningful Paint and Time to
Interactive, and I expect React 16 to help a lot in that aspect (streaming
render + simplified rehydrate), can't wait to test it!

------
scottfr
This is interesting

> Instead of ignoring unrecognized HTML and SVG attributes, React will now
> pass them through to the DOM.

Does that mean we can start using "class" instead of "className"?

~~~
syntor
I always assumed `class` was a keyword, which is why then went with
`className` instead.

~~~
sorahn
both `className` and `htmlFor` are what the actual DOM uses. [1][2]

[1]: [https://developer.mozilla.org/en-
US/docs/Web/API/Element/cla...](https://developer.mozilla.org/en-
US/docs/Web/API/Element/className)

[2]: [https://developer.mozilla.org/en-
US/docs/Web/API/HTMLLabelEl...](https://developer.mozilla.org/en-
US/docs/Web/API/HTMLLabelElement/htmlFor)

------
MatthewPhillips
Just for clarification, React 16 does _not_ support streaming, at least not in
any way that is meaningful. React 16 has an API that gives you a Readable
stream, but this stream doesn't provide HTML in chunks. It provides it all-at-
once exactly like renderToString does.

What you _really_ want with streaming is whenever rendering is blocked by
something asynchronous, like a database request, that whatever HTML is
finished can be flushed out. React _could_ support real streaming in the
future, but would likely require some new API.

Anyways, the sentence from the article "start sending bytes to the client
faster" isn't factually true, it doesn't send it out any faster than
renderToString would.

~~~
spicyj
You don't need to wait for the CPU time of all components to complete before
the first bytes are available. When we render an HTML element, we now emit the
opening tag before processing the children. People have seen benefits in
practice from this.

Our new architecture makes it easier to implement the type of async data
fetching you describe and we'd like to add it in the future.

~~~
MatthewPhillips
If rendering blocks the CPU to such a degree that this helps get bytes out
faster, then you have a much bigger issue to deal with.

~~~
abiox
this seems like hasty generalization.

------
wereHamster

        We've added support for returning strings, too:
        […]
        See the full list of supported return types.
    
    

Why not express that with… ehm… proper types?!? You know… like those used by
Flow or TypeScript.

~~~
acdlite
Submit a PR :)

------
sharno
So, are there any plans to use ReasonML as the main React internal language in
the future? I knew that Messenger is 50% using ReasonML

------
iamcwu
Just wanted to add I noticed CRA (create-react-app) was just migrated to MIT
license!

------
_Codemonkeyism
Not a flamewar, starting a new project, VUE or React?

~~~
overcast
Vue is less complex, easy api, and easier to jump into. React is more complex,
bigger learning curve, but more featured. Vue has satisfied my needs for 99%
of projects.

~~~
tomelders
This really boggles my mind. Having looked very closely at both (and being a
react developer full time), I can not recognise this assessment. I just can't
see how people can claim that Vue is simpler or easier than React.

React is idiomatic javascript. Vue is it's own quirky thing that doesn't feel
anything at all like Javascript to me.

~~~
overcast
I'm not sure what feeling anything like JavaScript has to do with the
discussion. No one asked which framework is most like JavaScript. I don't
think JSX turning JavaScript into some weird XML/HTML hybrid feels like
JavaScript either. Sure you can use it without it, but why would you? Vue
works for me and others, whereas React works for you, and others. Let's just
keep working on our projects.

~~~
tomelders
Because the rest of your application is Javascript. Less cognitive burden when
you switch to working on different layers of your application.

~~~
irrational
Wait, do you really experience cognitive burden when switching between html,
js, and css? It surprises me if you do.

~~~
tomelders
I'm talking about switching between a context where there are first class
functions that can be easily passed around, to a context where there's some
archaic and magical, non idiomatic convention based on string based dependency
injection, or magical way of writing attributes.

------
mmgutz
Will existing create-react-app apps automatically get React 16 when they
update it?

~~~
danesparza
Should be as simple as 'yarn upgrade react'

~~~
Bahamut
Well, a little more than that since there's react-dom and various other deps
:)

------
RichardDudka
My shop has seen failure to black screen since migrating. Anyone else?

------
root_axis
Thanks for first-class async rendering, been a long while coming.

------
lechiffre10
Congrats to the facebook team. Awesome work!

------
_mb
Congratulations on the release. Well done!

------
foota
Amazing work, hats off to y'all.

------
zghst
Congrats team!

------
hazelnut
How does it compare to Marko? [https://github.com/marko-
js/marko](https://github.com/marko-js/marko)

~~~
awaywethrow
Your last four submissions are either about eBay (creators of Marko), or a
creation of Patrick Steele-Idem (one of the maintainers of Marko). So... you
tell us?

------
jimmy2020

      This release is MIT license release after they start losing in front of more real open source frameworks like vue. Better late than sorry facebook!

