21 ms·
React 16
- SlyShy 9y agoImpressive 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 9y agoNot to mention the decreased size! This is a really really great upgrade.
- jamier1978 9y agosame here. Really good to see these types of updates going in along with the bigger things like fiber
- fortythirteen 9y agoThe 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.
- binthere 9y agoIt took really long and a lot of community effort for this change.
- deleted 9y ago[deleted]
- abiox 9y agoi 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 9y agoIt'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.aspx?NewsPubId=95535 https://www.wilmerhale.com/pages/publicationsandnewsdetail.a...
- abiox 9y agoafaik 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 9y agoThe LICENSE file is a grant that Facebook can't revoke even if it wanted to.
- qaq 9y agoHow does it help you?
- k__ 9y agoRemoving FUD to sleep better.
- _Codemonkeyism 9y agoNot a flamewar, starting a new project, VUE or React?
- beckler 9y agoThey're both pretty similar. I would say try working with both on something really small and see which one you like better.
- tomelders 9y agoVue.js is more of a DSL. React is just Javascript. I'd say they're two very different approaches. I'd recommend react over Vue any day of the week, to answer ops question. Vue.js is everything I hated about Angular. String based dependency injection, bizzare attibute syntax, highly opinionated. React is everything I love about javascript. Functional, fast, and with an easy to reason about API.
- wolco 9y agoIt's not as opinioned as you think. All of the reasons you listed for disliking are just one way of writing it in vue. If you love jsx and pure javascript you can use them as well. I learned react before vue and found it great compared to angular but lately I've been using vue. It is quickier and neater with the bizzare syntax and lighter overall. With the latest release I have the urge to go back.
- mediumdeviation 9y agoCounterpoint: React is no less opinionated, fast, or has less of a DSL than Vue. Opinionated: React is a library written for a language that is not JavaScript (the first prototype was written in OCaml). It demands immutability, which JS has no native support for. it wants you to use FP, but JS natively has little support for FP both in its standard library and syntax. FP only looks good in JS if you've never used a real FP language. DSL: JSX is a DSL - I can't remember the last time I've seen someone use && as a poor man's if statement, or ternary statements dozens of lines long until I started writing JSX. JSX is neither idiomatic JavaScript nor HTML. Fast: Performance benchmarks (which admitted are flawed as they can't capture real-world usage) show that React and Vue have similar rendering speeds. Vue's computed property dependency tracing means that a lot of the performance optimizations which require manual work to enable in React (manually memoize expensive computation, shouldComponentUpdate, PureComponent etc.) are handled automatically by the framework.
- spicyj 9y agoWe'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 9y agoAre there plans to relicense React Native to MIT without a Patent timebomb as well?
- tomkinson 9y agoMy understanding this was already done last week. I could be wrong. GraphQL however, not yet.
- vvanders 9y agoNot React Native, that still has the patent clause.
- yasserkaddour 9y agoGraphQL specification has been relicensed minutes ago to Open Web Foundation Agreement, graphql-js and relay to MIT. https://medium.com/@leeb/relicensing-the-graphql-specification-e7d07a52301b https://medium.com/@leeb/relicensing-the-graphql-specificati... https://news.ycombinator.com/item?id=15340528 https://news.ycombinator.com/item?id=15340528
- deleted 9y ago[deleted]
- deleted 9y ago[deleted]
- Dolores12 9y ago[edited]
- orb_yt 9y agoLovely. 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.
- ryanbertrand 9y agoWe use ad hoc portals for showing modals, flyout panels, popovers.
- audessuscest 9y agoDo you know where to find some usage examples ?
- captnasia 9y agoIf you go to the Portals documentation ( https://facebook.github.io/react/docs/portals.html https://facebook.github.io/react/docs/portals.html ) you can find some examples throughout.
- teraflop 9y agoBoth of the CodePen example links on that page are insidiously broken. The demos appear to work, but they don't actually demonstrate the claimed portal functionality at all: // These two containers are siblings in the DOM const appContainer = document.getElementById('app-container'); const modalContainer = document.getElementById('app-container'); Note that both variables refer to the same element.
- danabramov 9y agoSorry, there was so much to do in the release that some issues crept into the new docs. We'll fix them soon. :-)
- zghst 9y agoCongrats team!
- Kwastie 9y agoEven 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 9y agoYes 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.
- alexquez 9y agoI'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.
- deleted 9y ago[deleted]
- jbreckmckye 9y agoIt is very good, but I wonder what their intentions are. Is it to help hire talent?
- matmo 9y agoAssuming 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 9y agoNo, I mean - open sourcing their software. I don't know what their goal is as a company.
- gt2 9y agoSometimes 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 9y agoThree 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.
- a13n 9y agoSo 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!
- debaserab2 9y agoPortals 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.
- supernintendo 9y agoReally 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...
- tootie 9y agoI had a serious cringe reaction to seeing that term. I hope that the web 1.0 portal concept is sufficiently dead and buried that we can now rebrand "portal" to something useful.
- jamier1978 9y agoWe are in the same position, except with backbone instead of spine. Nice idea for a use case of portals.
- yasserkaddour 9y agoYeay! GraphQL specification has been relicensed minutes ago to Open Web Foundation Agreement, graphql-js and relay to MIT. Great stuff from Facebook today. https://medium.com/@leeb/relicensing-the-graphql-specification-e7d07a52301b https://medium.com/@leeb/relicensing-the-graphql-specificati... https://news.ycombinator.com/item?id=15340528 https://news.ycombinator.com/item?id=15340528
- qaq 9y agoHow exactly does it put patent controversy behind us? Before you had limited patent grant now you have none
- brlewis 9y agoBecause 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.
- tootie 9y agoIf 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 9y agoSEO-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 9y agoWe'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!
- benregenspan 9y agoBecause it is hard to know the implementation details of every search engine and what reasons different markup could result in a subtle difference in ranking, I think the best way of answering this question is looking at the markup differences between HTML produced via ReactDOM.renderToString() vs. some other solution. In versions of React prior to 16, some extra attributes were added to the markup, but besides that it looked basically identical to what you'd get using any other method. Now there is even less difference, so it's hard to imagine React SSR having significantly different SEO characteristics. But one caveat is that if you need to hydrate serverside-rendered React markup for clientside use, that will add at least some small performance penalty. And you will also want to pass in props data that matches as closely as possible between the client and server, which means that your base page will need to include some serialized version of the data that should be passed in as props to the component(s) you serverside-rendered and want to hydrate. If this is a large chunk of data, there could be negative SEO impact if it is placed above meaningful content in the page or if the time to download it delays complete load of the page.
- wereHamster 9y agoWe'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 9y agoSubmit a PR :)
- mmgutz 9y agoWill existing create-react-app apps automatically get React 16 when they update it?
- acemarke 9y agoNo, but because React is just another dependency in your package.json, you can easily update it via NPM or Yarn.
- danesparza 9y agoShould be as simple as 'yarn upgrade react'
- Bahamut 9y agoWell, a little more than that since there's react-dom and various other deps :)
- foota 9y agoAmazing work, hats off to y'all.
- root_axis 9y agoThanks for first-class async rendering, been a long while coming.
- MatthewPhillips 9y agoJust 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 9y agoYou 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 9y agoIf 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 9y agothis seems like hasty generalization.
- PKop 9y agoThis comes later when the mentioned async rendering feature is available right?
- sharno 9y agoSo, are there any plans to use ReasonML as the main React internal language in the future? I knew that Messenger is 50% using ReasonML
- slaymaker1907 9y agoI'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.
- unohoo 9y ago2 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 9y agoWhat aspect of performance?
- Androider 9y ago5 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.
- Ralfp 9y agoCould you compare your JS's bundle sizes before and after? I've heard that its little smaller, I've been wondering how much. Edit: I've got it in announcement: React is 5.3 kb (2.2 kb gzipped), down from 20.7 kb (6.9 kb gzipped). react-dom is 103.7 kb (32.6 kb gzipped), down from 141 kb (42.9 kb gzipped). react + react-dom is 109 kb (34.8 kb gzipped), down from 161.7 kb (49.8 kb gzipped 15kb shaved in production builds. Thats quite nice!
- realityking 9y agoUnfortunately pulling in the now required polyfills for ES6 Map and Set can add 40kb :/ (the 40kb are with core-js, will need to look for something smaller)
- danabramov 9y agoThey're only required if you target IE10 or lower.
- Bahamut 9y agoSome older versions of Safari as well I believe since Safari had shipped a broken implementation prior to becoming ES2015 compliant.
- danabramov 9y agoIf you have specific data about what was broken please share in an issue report so we can amend the docs if necessary. Thanks!
- hazelnut 9y agoHow does it compare to Marko? https://github.com/marko-js/marko https://github.com/marko-js/marko
- awaywethrow 9y agoYour 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?
- iamcwu 9y agoJust wanted to add I noticed CRA (create-react-app) was just migrated to MIT license!
- fairview14 9y agoThank 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.
- skrebbel 9y agoSmall 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!
- crucialfelix 9y agoI don't think you would need to polyfill Map: http://kangax.github.io/compat-table/es6/#test-Map http://kangax.github.io/compat-table/es6/#test-Map or Set: http://kangax.github.io/compat-table/es6/#test-Set http://kangax.github.io/compat-table/es6/#test-Set I will probably continue to transpile for the moment (till I can check everything). There is also polyfill.io which would only polyfill old browsers.
- danabramov 9y agoThe polyfilling is only necessary for IE10 and lower. Many people who are conscious about size don't support old browsers so that's a real win for them. You could also include polyfills conditionally by sniffing the user agent. I'm also fairly sure there exist smaller polyfills for Map and Set. We should probably look for them and suggest them instead.
- skrebbel 9y ago> You could also include polyfills conditionally by sniffing the user agent. That's a pretty good idea, actually. Thanks for the suggestion!
- spicyj 9y agoThis 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 9y agoAwesome! 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.
- petetnt 9y agoCongrats 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.
- lechiffre10 9y agoCongrats to the facebook team. Awesome work!
- scottfr 9y agoThis 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 9y agoI always assumed `class` was a keyword, which is why then went with `className` instead.
- sorahn 9y agoboth `className` and `htmlFor` are what the actual DOM uses. [1][2] [1]: https://developer.mozilla.org/en-US/docs/Web/API/Element/className https://developer.mozilla.org/en-US/docs/Web/API/Element/cla... [2]: https://developer.mozilla.org/en-US/docs/Web/API/HTMLLabelElement/htmlFor https://developer.mozilla.org/en-US/docs/Web/API/HTMLLabelEl...
- danabramov 9y agoYes, the reason is that you can't write something like const { class } = props Which is very common and deeply confusing. So even though "class" will technically work now, it will still warn, and ask that you use "className". (And officially supporting both would make it confusing for third party components since each would have to also support both.)
- iBelieve 9y agoI think you can (with a warning), but it's still recommended to use the normal React naming conventions according to [0]: > Note: always use the canonical React naming for all supported attributes. Looking through the examples, it looks like non-string class values will be converted to strings, while non-string className values will be ignored (with a warning). [0] https://facebook.github.io/react/blog/2017/09/08/dom-attributes-in-react-16.html https://facebook.github.io/react/blog/2017/09/08/dom-attribu...
- hitekker 9y agoGreat 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.
- jchw 9y agoNo, that's the opposite in my opinion. You should be catching errors. Ideally as early as possible. Most ideally when compiling your app, least ideally on a user's computer. I think a previous article on HN elegantly put it as, "move errors to the left." While this is more of a lateral move, it's an important one. Before, an error during render left your app in an undefined, potentially unstable state. Then, you might find some unrelated junk errors in your Sentry or whatever you use, and on top of that the user is wondering why when they click nothing happens. Now, you can recover from an error completely, even if you don't have control over the code running in other components. That's a big deal when you might want to have third party components or something to that effect.
- raquo 9y agoEveryone 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 9y agoDo you mean wrapping all components with a HOC?
- 3131s 9y agoIf I were to cave in and learn React, can someone recommend an existing project that would serve as good learning material?
- rkuykendall-com 9y agoI always recommend this article to people who want to learn react, as it focuses on the concepts and not the code, which actually differs a lot on if you use a JS compiler: http://jlongster.com/Removing-User-Interface-Complexity,-or-Why-React-is-Awesome http://jlongster.com/Removing-User-Interface-Complexity,-or-... The author creates a library, piece by piece, which introduces the same concepts. Makes it much easier to jump into the 'real' framework.
- truekojo 9y agoThis repo has been quite helpful pour moi... https://github.com/gothinkster/react-redux-realworld-example-app https://github.com/gothinkster/react-redux-realworld-example...
- 3131s 9y agoThanks! In the past I've looked at the docs and got something basic going with create-react-app, but since I've been put off by little things here and there I'd like to see a working example of a larger system to better appreciate what's good about React. This seems like what I was looking for.
- gt2 9y agoLooks good but can any React experts comment as to - whether or not this really uses best practices? - leverages React to the fullest?
- acemarke 9y agoThose 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.
- jimmy2020 9y agoThis release is MIT license release after they start losing in front of more real open source frameworks like vue. Better late than sorry facebook!
- mhd 9y agoSo, 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…
- l1ambda 9y agohttp://jamesknelson.com/learn-raw-react-no-jsx-flux-es6-webpack/ http://jamesknelson.com/learn-raw-react-no-jsx-flux-es6-webp... Looks like Mithril code (https://mithril.js.org/ https://mithril.js.org/) if you alias React.createElement to a short function name. I learned Mithril before React, and kinda think it's a better learning experience to learn the simple way like this first, and then add build tools, Redux, JSX later (if you choose to).
- danabramov 9y agoIt'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 9y agoIn 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>
- deleted 9y ago[deleted]
- amk_ 9y agoWrote about that recently: https://medium.com/@alexkrolick/writing-react-components-for-3rd-party-embedding-50331c18e26 https://medium.com/@alexkrolick/writing-react-components-for... See also: the docs
- _mb 9y agoCongratulations on the release. Well done!
- RichardDudka 9y agoMy shop has seen failure to black screen since migrating. Anyone else?