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).<p>Very impressive improvement for a drop-in upgrade! Especially considering the previous version was not considered slow at all given the complexity.
We're really excited about this release. I also wrote about how we made the rewrite happen on our Facebook engineering blog: <a href="https://news.ycombinator.com/item?id=15339825" rel="nofollow">https://news.ycombinator.com/item?id=15339825</a>.<p>Happy to answer questions if y'all have any. :)
Lovely. The file size reductions are quite surprising.<p>Removing the need to wrap sibling elements in a single parent element is a welcome change.<p>I'd be interested in hearing some use cases for using the Portal API.<p>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. <i>Props</i> to them.
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.<p>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.
Great release but forcing the capturing of errors seems to violate the JS value of forgiveness. Worse, this "forcing" actually seems to <i>hinder</i> debugging.<p>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.<p>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.<p>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.<p>Does anyone else feel that the new version of React is fault-intolerant?<p>While I do enjoy Java, I would argue that Null-Pointer-Exception hell does not belong in JS scripting.
Even though React 16 is almost a complete rewrite, it's amazing how they kept an almost complete compatible api between releases.<p>Congrats on shipping!
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)<p>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
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.<p>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.
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.<p>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…
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 <i>years</i>!<p>Crazy to see such a robust, mature framework still improving so much. Can't wait to upgrade!
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.<p>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...
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.<p>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.
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.
Thank you FB React team. Along with the new license I can't be happier to see your good work and improvements on React.<p>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.
Impressive improvements in this version and very heartening to see performance improve in addition to the new APIs.<p>Multiple render return types and portals both solve some annoying situations that can come up.
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.<p>Fantastic release nevertheless!
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.
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.
This is interesting<p>> Instead of ignoring unrecognized HTML and SVG attributes, React will now pass them through to the DOM.<p>Does that mean we can start using "class" instead of "className"?
Just for clarification, React 16 does <i>not</i> 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.<p>What you <i>really</i> 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 <i>could</i> support real streaming in the future, but would likely require some new API.<p>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.
<p><pre><code> We've added support for returning strings, too:
[…]
See the full list of supported return types.
</code></pre>
Why not express that with… ehm… proper types?!? You know… like those used by Flow or TypeScript.
How does it compare to Marko?
<a href="https://github.com/marko-js/marko" rel="nofollow">https://github.com/marko-js/marko</a>
<p><pre><code> 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!</code></pre>