GOPHERSPACE.DE - P H O X Y
gophering on hngopher.com
HN Gopher Feed (2017-09-26) - page 1 of 10
 
___________________________________________________________________
React 16
648 points by markthethomas
https://facebook.github.io/react/blog/2017/09/26/react-v16.0.html
6.0.html
___________________________________________________________________
 
alexquez - 6 hours ago
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 - 2 hours ago
  It is very good, but I wonder what their intentions are. Is it to
  help hire talent?
 
    matmo - 1 hours ago
    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.
 
  [deleted]
 
mmgutz - 5 hours ago
Will existing create-react-app apps automatically get React 16 when
they update it?
 
  acemarke - 5 hours ago
  No, but because React is just another dependency in your
  package.json, you can easily update it via NPM or Yarn.
 
  danesparza - 5 hours ago
  Should be as simple as 'yarn upgrade react'
 
    Bahamut - 4 hours ago
    Well, a little more than that since there's react-dom and
    various other deps :)
 
slaymaker1907 - 5 hours ago
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.
 
hitekker - 2 hours ago
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.
 
  jchw - 2 hours ago
  No, 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.
 
  danabramov - 51 minutes ago
  Can you please file an issue? We can discuss specific pain points
  and concerns there.It's a bit hard to reply to a comment here
  with technical points :-) The valuable discussion will get
  buried.As explained in the blog post about error handling, the
  recommendation is to add error boundaries in "strategic places"
  (e.g. around main UI blocks) so that they fail gracefully. But it
  requires some design input on how it should work. It means error
  states should be part of your app's design, and I understand this
  might seem unusual.Still, let's please continue this in the issue
  tracker.
 
  raquo - 2 hours ago
  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 - 20 minutes ago
    Do you mean wrapping all components with a HOC?
 
jimmy2020 - 1 hours ago
  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!
 
a13n - 6 hours ago
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!
 
foota - 5 hours ago
Amazing work, hats off to y'all.
 
root_axis - 5 hours ago
Thanks for first-class async rendering, been a long while coming.
 
unohoo - 5 hours ago
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
 
debaserab2 - 6 hours ago
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.
 
_mb - 26 minutes ago
Congratulations on the release. Well done!
 
3131s - 2 hours ago
If I were to cave in and learn React, can someone recommend an
existing project that would serve as good learning material?
 
  truekojo - 1 hours ago
  This repo has been quite helpful pour
  moi...https://github.com/gothinkster/react-redux-realworld-
  example...
 
  rkuykendall-com - 2 hours ago
  I 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-...The author creates a library, piece by piece,
  which introduces the same concepts. Makes it much easier to jump
  into the 'real' framework.
 
hazelnut - 4 hours ago
How does it compare to Marko? https://github.com/marko-js/marko
 
iamcwu - 4 hours ago
Just wanted to add I noticed CRA (create-react-app) was just
migrated to MIT license!
 
fairview14 - 4 hours ago
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 - 6 hours ago
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 - 6 hours ago
  Not to mention the decreased size! This is a really really great
  upgrade.
 
  jamier1978 - 6 hours ago
  same here. Really good to see these types of updates going in
  along with the bigger things like fiber
 
Androider - 4 hours ago
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 - 2 hours ago
  Can you tell what app is it? I'm looking for an app that can do
  server side chart rendering if necessary.
 
    cies - 1 hours ago
    I'd go with SVG charts (SVG is well supported -
    http://caniuse.com/#feat=svg)http://mediatemple.net/blog/tips
    /svg-charting-libraries
 
  Ralfp - 4 hours ago
  Could 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
  gzipped15kb shaved in production builds. Thats quite nice!
 
    realityking - 1 hours ago
    Unfortunately 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 - 1 hours ago
      They're only required if you target IE10 or lower.
 
        Bahamut - 49 minutes ago
        Some older versions of Safari as well I believe since
        Safari had shipped a broken implementation prior to
        becoming ES2015 compliant.
 
  ellyagg - 4 hours ago
  You have a 200 KLOC React app? That's amazing to me. Just you? Is
  it public facing?
 
    jbreckmckye - 2 hours ago
    If it's a Redux app, there'll be a lot of boilerplate in that.
    Not 200 KLOC's worth, but a fair bit.I recently inherited a
    moderately sized Redux app with over 1300 source files! It's
    not a trivial app but it's not a word processor or videogame,
    either...
 
      acemarke - 2 hours ago
      As a Redux maintainer, I'll toss out my obligatory reminder
      you can use as much or as little abstraction on top of Redux
      as you want. Don't like writing action constants by hand? Use
      `redux-actions` to generate action creators that have an
      overriden `toString()`. Don't like touching multiple files?
      Use the "ducks" pattern. Want something that adds additional
      layers on top so you don't have to write a lot of reducers
      and action creators by hand? Use Kea or redux-tiles or redux-
      scc.I'll also post a link to the slides and livestream video
      for my React Boston talk this last weekend, where I talked
      about the Redux ecosystem and gave an overview of useful
      Redux libs that can help with various use cases:
      http://blog.isquaredsoftware.com/2017/09/presentation-
      might-... .
 
        edoloughlin - 2 hours ago
        It's been 10 months since I last used React and I'm already
        way out of touch. Does anyone else feel exhausted just
        reading that list?
 
          chrshawkes - 2 hours ago
          yes
 
          root_axis - 1 hours ago
          I dislike this attitude. That list is not exhausting,
          it's a list of specific tools that solve specific
          problems, if you don't have the problem don't concern
          yourself with the tool.
 
          lllr_finger - 55 minutes ago
          And this attitude is equally frustrating. Tools and
          libraries exist to save developers time. The cognitive
          overhead of building and maintaining your own framework
          piecemeal can be detrimental to shipping code, especially
          if you don't have pragmatic and decisive leadership on
          your team.
 
          root_axis - 6 minutes ago
          > And this attitude is equally frustratingIt shouldn't
          be. If you don't like a tool, don't use it. Nobody is
          forcing you to use redux, you don't need it, even if
          you're building a complex react app, setState works just
          fine, seriously.> The cognitive overhead of building and
          maintaining your own framework piecemeal can be
          detrimental to shipping codeSo don't do that. Identify
          the problem, then use the tools that solve the problem,
          if you can't figure out which tool is the right one for
          the job that's your problem, not the fault of the tool.
          If I need to drill a hole in my wall I don't complain
          about how many drills are on the market, I just use the
          simplest tool to get the job done or hire someone who
          knows what they're doing> especially if you don't have
          pragmatic and decisive leadership on your team.The tool
          is not responsible for someone failing to use it
          correctly, that's absurd.
 
          strken - 47 minutes ago
          For me, the biggest problem with redux is that- I don't
          already understand how an app using redux works when it
          reaches a decent size; therefore don't know what problems
          it will have and need to learn more- I can't start using
          redux to understand those problems without making
          important architectural choices early on, i.e. between
          sagas/thunks, ducks/not-ducks, or how to remove
          duplication from reducers, because the community has so
          many parallel solutions to any given problem; therefore,
          I need to write a toy app instead of using it on a real
          product- redux on its own seems to need about ten
          packages before you can load information from a json api
          and pass it to react, a task which is the basis for most
          toy apps; therefore, every toy app I write seems bloated
          and heavyweightIt's a hard ecosystem to bootstrap
          yourself into.
 
          acemarke - 29 minutes ago
          What sort of issues are you running into as far as "how
          an app using Redux works"?  For myself, the first thing I
          usually do when looking at an unfamiliar Redux codebase
          is to look at the store creation logic, see what
          middleware packages are being used, and see where the
          root reducer logic is being imported from.  Then, I skim
          through the reducers to get an understanding of what the
          state structure is, what kinds of values are being
          stored, and what some of the reducer operations are.I'm
          not sure why you say that "you need 10 packages to load
          JSON data".  Assuming that you're in a browser that
          supports the Fetch API, you need _no_ additional packages
          at all.  You can make an AJAX call in a connected
          component, and call `this.props.dispatch({type :
          "DATA_LOADED", payload : response.data})` in the success
          handler.Now, we do encourage people to try moving that
          logic out of components to make it more reusable, which
          usually means using thunks.  However, redux-thunk is all
          of 12-ish lines long, and if you'd prefer not to actually
          add it as a separate package, it can easily be pasted
          into your app directly.  But, you genuinely shouldn't
          _need_ more packages than that to be making AJAX calls.
          There's plenty of additional abstractions that are
          available around making network requests and processing
          the results, but those are all purely optional.
 
        vanderZwan - 1 hours ago
        I didn't quite get redux when I first (had to) use it, and
        I still wonder if I'm doing it wrong, because I do 99% of
        my dispatches with one simple action.I ended up making a
        dead-simple merge(oldObj, newObj) function that's halfway
        between Object.assign({}, ..) and lodash.merge() (it
        doesn't merge arrays)[0]. It makes it easy for me to update
        deeply nested state trees, provided the nested data is
        simple enough.As a result, 99% of my dispatches uses one
        action type, PLAIN_MERGE, and a dumb state tree indicating
        what I'm updating, like so:    const handleChange =
        (values) => {       dispatch({         type: PLAIN_MERGE,
        state: {           scatterPlots: {
        plotSettings: {               [selectedPlot]: {
        [axis]:                    clipValues: {
        lowerBound: values[0],                     upperBound:
        values[1],                   },                 },
        },             },           },         },       });     };
        That might be some deep nesting, but it actually reflects
        the structure of the interface too, so it's kinda self-
        documenting.The associated reducer is simply return
        merge(state, action.state). Again, maybe I'm missing
        something but it seems like a pretty simple and effective
        solution to me?[0] https://gist.github.com/JobLeonard/c4292
        594ce4d439ab20ec109f...
 
          acemarke - 1 hours ago
          That's a technically legal use of Redux.  Redux doesn't
          care if you have an action object that only contains a
          type + some values and do all the work on the reducer
          side, or precalculate the new state before dispatching
          the action and have the reducer simply blindly merge in
          whatever was provided.  Redux simply calls the root
          reducer function, and saves the root state value it
          returns.There's actually prior art for what you're doing
          (per the articles at [0] and [1]).  The code will work,
          and the changes should show up in the Redux DevTools.
          Dan even described that as a possibility in some of the
          earlier Redux issues ([2], [3]).Now, having said all
          that: I _personally_ would say that a "single SET_STATE
          action" approach goes against the intended spirit of
          Redux.  One of the core principles behind Redux is that
          it should make it very easy for you to understand when,
          why, and how your state was updated, and what part of the
          application triggered that state update.  If you only
          have a single SET_STATE action type, then reading the
          action history log in the DevTools won't tell you much
          useful.  You can see the action contents and the diffs,
          but the action log itself won't have any semantic
          meaning, and you can't easily trace back to where the
          action was dispatched because the entire codebase is
          dispatching the same action type.Redux also doesn't care
          if you do "setter-style" action naming like SET_USER_NAME
          and SET_USER_ADDRESS, or "event sourcing"-type naming
          like "USER_ATTRIBUTES_UPDATED".  However, either of those
          approaches is going to at least provide _some_ semantic
          meaning, making the action log easier to read and the
          origin of the action easier to trace.I'd encourage you to
          read through the "Structuring Reducers" section in the
          Redux docs [4].  In particular, the "Normalizing State
          Shape" page [5] talks about why we recommend normalizing
          your data into a flatter structure, rather than keeping
          it nested.Finally, you might want to read through my two-
          part blog post "The Tao of Redux" [6], which goes into
          detail on the history and design of Redux, the intent for
          how it _should_ be used, and why common usage patterns
          exist.[0] https://medium.com/@jeswin/implementing-redux-
          is-tedious-but...[1] https://medium.com/@benevolentNinja
          /minimal-redux-setup-e6a1...[2] https://github.com/reactj
          s/redux/issues/155#issuecomment-113...[3] https://github.
          com/reactjs/redux/pull/140#issuecomment-11395...[4] http:
          //redux.js.org/docs/recipes/StructuringReducers.html[5] h
          ttp://redux.js.org/docs/recipes/reducers/NormalizingState
          Sh...[6] http://blog.isquaredsoftware.com/2017/05
          /idiomatic-redux-tao... ,
          http://blog.isquaredsoftware.com/2017/05/idiomatic-redux-
          tao...
 
        jbreckmckye - 1 hours ago
        > As a Redux maintainer, I'll toss out my obligatory
        reminder you can use as much or as little abstraction on
        top of Redux as you want.Tell that to the previous
        developer. To be blunt, if your library isn't very usable
        without helper utils or wrappers, it probably isn't really
        doing its job.This is my first time using Redux, and my
        experience has been quite negative. This project has so
        many reams and reams of code that just doesn't clearly _do_
        anything. Line after line of throat clearing and
        pseduostructure.I accept that this may just be a poorly
        written application. I've looked over the Express code and
        that's not much better, which is remarkable given that all
        it does is proxy API requests. But all these action
        creators and reducers and constants seem to have added a
        lot of indirection to what is still thoughtless and
        illiterate code.We are seriously talking about rewriting
        the whole thing. For a one year old project that's quite
        damning. Can you point me to an open source codebase that
        might convince me Redux-done-right makes for readable code?
 
          acemarke - 52 minutes ago
          I'm sorry to hear that your experience has been negative
          so far.There's a commonly repeated phrase that "Redux is
          a pattern, not a framework".  Redux doesn't have anything
          built in for actually updating the state, or defining an
          application architecture.  Redux primarily provides a
          pattern for separating the write logic from the rest of
          the app conceptually, and adding centralized behavior on
          top of that via middleware and store enhancers.  So, how
          you build and organize your application around that
          pattern is up to you.Similarly, Redux does not _require_
          that you use action creators, action type constants, or
          that you separate everything into multiple files by code
          type.  Those are common _conventions_.  It's absolutely
          legal for a Redux-connected React component to do:
          this.props.dispatch({type : "ADD_TODO", text : "Buy
          milk"})  However, there _are_ reasons why those patterns
          exist in the first place.So, a few thoughts.  First, I'd
          encourage you to take the time to read through my two-
          part blog post "The Tao of Redux" [0], which goes into
          detail on the history and design of Redux, the intent for
          how it _should_ be used, and why common usage patterns
          exist.Second, while I don't have a specific Redux
          codebase to point to as a "shining example of best
          practices" strictly off the top of my head, I do have a
          list of some selected Redux applications that may be
          worth looking at.  Some of them are purpose-built
          examples, and others are "real" apps.  See the list at
          [1] - I know that there's some good codebases in that
          list.  I'll also suggest taking a look at "Project Mini-
          Mek", the sample application for my own blog tutorial
          series [2].My React/Redux links list has a large section
          of articles discussing good Redux architecture and best
          practices [3].  Some of those articles might be
          helpful.Finally, I'd be happy to spend some time
          discussing your current app's codebase, and perhaps offer
          some suggestions on ways you can make it better or easier
          to deal with.  HN isn't a good place for that.  However,
          I spend most evenings hanging out in the Reactiflux chat
          channels on Discord.  Please feel free to ping me there,
          and we can discuss things further.  The invite link for
          Reactiflux is at [4].[0]
          http://blog.isquaredsoftware.com/2017/05/idiomatic-redux-
          tao... , http://blog.isquaredsoftware.com/2017/05
          /idiomatic-redux-tao...[1] https://github.com/markerikson
          /redux-ecosystem-links/blob/ma...[2]
          https://github.com/markerikson/project-minimek[3]
          https://github.com/markerikson/react-redux-
          links/blob/master...[4] https://www.reactiflux.com
 
          jbreckmckye - 26 minutes ago
          Thank you, I will take a look at those resources. I
          cannot promise that I will keep using Redux in future,
          but I will try and give it a fair chance.
 
          acemarke - 11 minutes ago
          Sure.  And please really do feel free to ping me on
          Reactiflux if you have questions or would like to discuss
          things.Redux isn't for everybody or every use case.
          However, I do think it's frequently misunderstood.  If it
          _really_ isn't helping you solve your problems, then you
          should certainly use something that's more appropriate or
          useful.  But, it's also entirely possible that a better
          understanding of how it can be used, or how it can be
          adapted for certain situations, might make it more useful
          and helpful for your use case.  A lot of my time writing
          about Redux has been spent trying to help clear up
          misconceptions, answer questions about real-world usage,
          and help people better understand how it works and can be
          used, so that they can make more informed decisions about
          Redux.
 
lechiffre10 - 3 hours ago
Congrats to the facebook team. Awesome work!
 
mhd - 1 hours ago
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?
 
  l1ambda - 56 minutes ago
  http://jamesknelson.com/learn-raw-react-no-jsx-flux-
  es6-webp...Looks like Mithril code (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 - 54 minutes ago
  It's exactly the same as it always have been. See the
  doc:https://facebook.github.io/react/docs/react-without-
  es6.htmlhttps://facebook.github.io/react/docs/react-without-
  jsx.html
 
    spicyj - 35 minutes ago
    In particular: you just need these script tags:      crossorigin src="https://unpkg.com/react@16/umd/react.developme
    nt.js">       /react-dom@16/umd/react-dom.development.js">
 
  TAForObvReasons - 2 minutes ago
  Vue tutorial is still ES5 non-*: https://vuejs.org/v2/guide/The
  intro fiddle is incredibly short and involves zero build steps or
  foreign techniques:HTML      src="https://unpkg.com/vue">     
  

{{ message }}

     
  JS    new Vue({       el:
  '#app',       data: {         message: 'Hello Vue.js!'       }
  })
 
supernintendo - 6 hours ago
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...
 
  duckfruit - 5 hours ago
  Portals are like one of those ideas (like all great ideas) that
  are incredibly useful but seem obvious in retrospect. Thank you
  facebook and the react team for all your hard work!
 
  yasserkaddour - 5 hours ago
  Yeay! 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-
  specificati...https://news.ycombinator.com/item?id=15340528
 
  qaq - 5 hours ago
  How exactly does it put patent controversy behind us? Before you
  had limited patent grant now you have none
 
    abritinthebay - 3 hours ago
    It doesn't - but it does make lawyers fret less.It's also more
    compatible (which, tbh, is actually more important practically)
    and that was the main problem with the whole Apache thing.
 
    brlewis - 5 hours ago
    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 - 4 hours ago
      Like every other piece of OS software that is known to be
      covered by patents
 
        brlewis - 3 hours ago
        Just because software is not known to be covered by patents
        doesn't mean you don't have to worry about software
        patents.
 
  tootie - 6 hours ago
  I 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 - 5 hours ago
  We are in the same position, except with backbone instead of
  spine. Nice idea for a use case of portals.
 
fortythirteen - 6 hours ago
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 - 6 hours ago
  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 - 4 hours ago
    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...
 
      abiox - 4 hours ago
      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 - 33 minutes ago
        The LICENSE file is a grant that Facebook can't revoke even
        if it wanted to.
 
  qaq - 5 hours ago
  How does it help you?
 
    k__ - 4 hours ago
    Removing FUD to sleep better.
 
  binthere - 6 hours ago
  It took really long and a lot of community effort for this
  change.
 
  [deleted]
 
scottfr - 3 hours ago
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 - 3 hours ago
  I always assumed `class` was a keyword, which is why then went
  with `className` instead.
 
    sorahn - 2 hours ago
    both `className` and `htmlFor` are what the actual DOM uses.
    [1][2][1]: https://developer.mozilla.org/en-
    US/docs/Web/API/Element/cla...[2]:
    https://developer.mozilla.org/en-US/docs/Web/API/HTMLLabelEl...
 
    danabramov - 44 minutes ago
    Yes, 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 - 3 hours ago
  I 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-attribu...
 
skrebbel - 4 hours ago
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 - 32 minutes ago
  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.
 
  crucialfelix - 2 hours ago
  I don't think you would need to polyfill Map:
  http://kangax.github.io/compat-table/es6/#test-Mapor Set:
  http://kangax.github.io/compat-table/es6/#test-SetI 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 - 41 minutes ago
  The 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.
 
petetnt - 3 hours ago
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.
 
MatthewPhillips - 5 hours ago
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.
 
  PKop - 5 hours ago
  This comes later when the mentioned async rendering feature is
  available right?
 
  spicyj - 5 hours ago
  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 - 5 hours ago
    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 - 3 hours ago
      this seems like hasty generalization.
 
_Codemonkeyism - 6 hours ago
Not a flamewar, starting a new project, VUE or React?
 
  bdcravens - 6 hours ago
  Depends on your criteria. At this time I feel like React has a
  larger ecosystem (assuming there isn't a lot of incompatibilities
  with v16), and there's a clear path to mobile if that's a choice.
  Vue seems to be a simpler programming model, and makes it easier
  to iteratively build. Personally I'd say don't make a choice at
  the beginning, but build a simple version of your app in both
  (say login and 2 or 3 pages) and make a decision based on that.
 
  ernsheong - 5 hours ago
  Sincerely, we should be leveraging the browser platform and
  increasingly build our apps on modern platform APIs (e.g. web
  components), instead of on a framework platform that means more
  bytes down the wire to do what the browser platform can already
  natively do.Admittedly there are tooling gaps with projects like
  Polymer, but these are being addressed. YouTube.com is already in
  production built with Polymer.So just leaving this comment here
  to encourage everyone to rethink the framework defaults of
  React/Vue in 2017.
 
    ernsheong - 5 hours ago
    Video here from Polymer Summit on the genesis of web components
    and the problem it was meant to solve (explosion of frameworks
    circa 2010, and slow JS apps):
    https://www.youtube.com/watch?v=y-8Lmg5Gobw
 
  conradfr - 4 hours ago
  Vue is React with some Angular flavoring (html templates) and
  more integrated libraries (state, router, etc).Usually not a
  problem but some issues on Github are in "Chinese" (not sure if
  Mandarin or Cantonese sorry) so not very helpful.If you want more
  choices for those libs (at the cost of potentially more
  dependency update hell) React is great and more popular.
 
    neolefty - 4 hours ago
    (Side note: Mandarin & Cantonese have the same writing.)
 
      conradfr - 1 hours ago
      Oh, I feel stupid then. Thanks for the correction.
 
  _Codemonkeyism - 5 hours ago
  Thanks to all who have replied, you helped a project succeed :-)
  Thanks for the downvotes to keep HN clean.
 
  beckler - 6 hours ago
  They're both pretty similar. I would say try working with both on
  something really small and see which one you like better.
 
    tomelders - 6 hours ago
    Vue.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.
 
      achairapart - 3 hours ago
      They're both opinionated. Actually, every framework out there
      is trying to reinvent the wheel (shame on Web Component slow
      and still ineffective development, what a pity).I guess will
      stand out and prosper the one with the largest adoption (to
      this point, React). All this looks exactly like the old
      jQuery vs Mootools vs Prototype debate 10 years ago.History
      repeats itself.
 
      mediumdeviation - 5 hours ago
      Counterpoint: 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.
 
        root_axis - 5 hours ago
         > it demands immutability, which JS has no native support
        for.You don't need native support, just don't mutate state
        when calling setState, which is a pretty simple rule to
        follow.> it wants you to use FP,This isn't really true.
        React components are often written as ES6 classes and
        stateless functional components are only functional
        insomuch as they are literally just a function. I can't
        think of any advanced FP concepts that are necessary for
        idiomatic React.> JSX is a DSLTechnically true, but in
        practice it is just ES6 and the HTML side of JSX so closely
        resembles actual HTML that the DSL criticism loses most of
        its meaning.> I've seen someone use && as a poor man's if
        statementIt may be a code smell, but it's certainly valid
        JavaScript and not a technique that could be correctly
        described as contributing to the idea that JSX is a "DSL".
        Also, you don't have to do that, just use an if statement
        or a ternary operation to compute your result outside of
        the JSX block and reference the resulting variable in the
        template part of the render function.
 
        tomelders - 3 hours ago
        On JSX... ok, that's not Javascript. Nor is it HTML. But it
        absolutely the right tool for the job, if that job is
        creating component based web applications.JSX is such a
        perfect fit that I take umbrage with people who sneer at
        it. What better way is there to bridge the gap between the
        DOM and Javascript? And JSX isn't exclusive to React
        anymore. That's testament to how useful and practical JSX
        is. I can see JSX becoming bona fide standard like HTML.
 
        mlsarecmg - 3 hours ago
        > 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.Nothing in React forces you in any way to use
        ternaries. You can do all your pre-calculation in the
        render method, and if that's your style you would most
        certainly do that.    const Say = ({ reverse, text }) => {
        if (reverse)             text =
        text.split('').reverse().join('')              return
        
{text}
     }                  />  Btw, Vue isn't any different here, you use ternaries
        there as well, only that it's severely limited as you
        couldn't refer to other components, the template is a dead
        string after all:    template: `                 index) in items">             {{ index > 2 ? item :
        item.split('').reverse().join('') }}         `  > It
        demands immutability, which JS has no native support for.It
        doesn't do that at all. Even redux uses plain shallow
        copies. Vue on the other hand does exactly that, it uses
        observables which aren't supported in most browsers. Reason
        why as of version 3 you will maintain two codebases (one
        for IE11 and prior, one for evergreen) since Proxies aren't
        back-compatible.> it wants you to use FPNot at all. It is
        unopinionated.
 
        shaneos - 4 hours ago
        > React is a library written for a language that is not
        JavaScript (the first prototype was written in OCaml)This
        is incorrect.  React was written first in JavaScript in the
        Facebook Ads org, to be used in the Ads Create Flow
        application.  Jordan's dive into OCaml came later, which is
        why we now have Reason many years later.
 
      wolco - 6 hours ago
      It'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.
 
      kevin_thibedeau - 5 hours ago
      > Vue.js is more of a DSL.You can use Vue as plain JS. You
      don't lose much by abandoning the single file components.>
      React is just Javascript.Except the entire ecosystem is
      designed to steer you toward JSX which is not "just
      Javascript".
 
  jsnanigans - 6 hours ago
  It depends on your project, they are both great frameworks
 
    IgorPartola - 6 hours ago
    This is the most curious answer here. What factors would you
    weigh?
 
      acemarke - 6 hours ago
      It's actually a very legitimate answer.  Vue and React are
      similar tools that solve basically the same use cases, with
      some technical and cultural differences.- React uses JSX and
      JS logic for render methods.  Vue usually uses templates,
      although JSX is also supported.- While React _can_ be used as
      a plain script tag, it's usually compiled as part of a build
      step. Vue can be compiled, but it seems friendlier to the
      "drop-in script tag" approach.- The Vue community values
      official integrated addons for routing and state management.
      The React community prefers a "pick-and-choose your own
      adventure" approach.- Since React has been around longer,
      there's probably more React components and related libraries
      available- A larger percentage of the Vue community is
      located in ChinaThe best comparison of Angular, React, and
      Vue I've seen thus far is at https://medium.com/unicorn-
      supplies/angular-vs-react-vs-vue-... .  It lays out a lot of
      the similarities and differences in a fair way, and gives
      some suggestions for why you might pick one over the others.
 
        IgorPartola - 6 hours ago
        Sure. I am well aware of these differences. They are
        basically two different implementations of the same idea
        with two communities that do things slightly
        differently.What I fail to see is how I would choose one
        over the other for different types of projects. To me, it's
        a choice a person or a team makes for all projects at once.
        Jumping back and forth between stacks here would be a lot
        like jumping back and forth between Django and Ruby on
        Rails. They aim to solve the same thing, and if you can use
        one effectively then why would you reach for the other?
 
          water42 - 5 hours ago
          I think you're overcomplicating how transferrable
          framework knowledge is. An expert React developer could
          switch to Vue no problem if there was demand for it.
          Similarly an expert Vue developer could switch to React
          no problem.
 
          IgorPartola - 4 hours ago
          I am not. The original question was about starting a new
          project and the orinal answer was ?depends on the
          project?. I am asking how it depends ?on the project? and
          not on the person. What properties of the project would
          drive you to choose one over the other?
 
          bpicolo - 3 hours ago
          I think it's more organizational, yeah? The context for
          two different projects can drastically differ.
 
          IgorPartola - 2 hours ago
          Right. So "It depends on your project" should be "it
          depends on your team" or "it depends on your
          organization"?
 
          bpicolo - 2 hours ago
          Probably. Also depends on your mood at the time ;)
 
      jonny_eh - 6 hours ago
      Which appeals to your aesthetic more? If you're looking to
      grow a team, which is more appealing to engineers available?
      Which has a better ecosystem of support libraries?
 
        tomkinson - 5 hours ago
        all good questions also ^
 
      tomkinson - 5 hours ago
      Wire size. Your projects specific needs. Built out time (i.e
      making your own components). DOM requirements. Licensing.
      Community. etc. This is an enormous list of variables to
      determine. If you were not making a complex site or SPA,
      learning and using React could be huge overkill even though
      it could still get the job done. The best way to determine
      what framework or language to use, for me has always been to
      assemble my tree of needs first. That included things like,
      how complex are we talking here. Do we need state management?
      Do we do most of our rendering server side? Do I have to
      learn the framework? Are the docs good? Etc. Build a map of
      our own needs first, then spend a few hrs holding it up to
      the various options.
 
        IgorPartola - 5 hours ago
        Still. It's like saying that you need to own both a DEWALT
        and a Bostitch drill because they are just different enough
        when working on dry wall in colonials vs capes. I mean I am
        sure there is someone out there that uses Vue for odd
        projects and React for even ones (and Angular for every
        13th one that they start on a date that ends in a 5), but
        most developers I know try both, then stick to the one that
        they like best.
 
  overcast - 6 hours ago
  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.
 
    stefantheard - 6 hours ago
    This has been my experience as well. With react if I need
    something I can generally find a component someone else has
    already made that is well supported / decent quality. With Vue
    I will generally have to roll my own.
 
      irrational - 2 hours ago
      I haven't looked at React's components (which component
      library would you recommend?), but so far Vuetify has all the
      components I've needed.
 
        stefantheard - 2 hours ago
        I am referencing "component" as a more general term. I
        think Vue has support for all of the common forms/divs/etc,
        I was more talking about like if you wanted an extensible
        calendar implementation or a scalable data table
        implementation there are probably 10 usable components for
        each of these examples in React but in Vue it would be
        harder to find one.
 
    tomelders - 6 hours ago
    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 - 5 hours ago
      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 - 4 hours ago
        Because the rest of your application is Javascript. Less
        cognitive burden when you switch to working on different
        layers of your application.
 
          overcast - 3 hours ago
          Except JSX isn't JavaScript, and no one uses React
          without it. So it's arguably just as much of a cognitive
          burden.
 
          irrational - 3 hours ago
          Wait, do you really experience cognitive burden when
          switching between html, js, and css? It surprises me if
          you do.
 
          tomelders - 2 hours ago
          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.
 
      Shywim - 5 hours ago
      Depends what you call idiomatic. I dont think JSX is really a
      JavaScript idiom, more like a HTML idiom applied to
      JavaScript which happen to be often used together.*At the end
      of the day, I think that calling something idiomatic is
      subjective and so, varies from people to people.*: to be
      clear, my point is many people use JSX with React because it
      feels idiomatic (I manipulate HTML/DOM, so why not just write
      with HTML-like syntax?) but it is not idiomatic to JavaScript
      and I don't think the other React APIs are that nice to use.
      If I didn't use JSX with React, I'd tend to use other
      framework because, in my opinion, they make more sense.
 
        l1ambda - 5 hours ago
        JSX is optional.
 
          bpicolo - 4 hours ago
          It's optional, and also not optional. Nobody is using
          React without JSX in practice, because it's ugly and
          verbose.
 
          l1ambda - 1 hours ago
          Not true, without JSX, React is basically Mithril, if you
          alias React.createElement to a short function name.
 
          bpicolo - 50 minutes ago
          Yeah, and I'm arguing that it's pretty ugly to write
          nested html that way.Hater-or-lover of JSX, it is
          definitely an intuitive way to think about HTML in the
          context of JS.I prefer the vue model that's a bit closer
          to the metal, though, if only because of quirks like
          className
 
          l1ambda - 37 minutes ago
          Think I see what you are getting at--in practice most
          folks using React are going to use JSX and build tools,
          and if you alias the function it's kind of non-
          standard.Mithril has "class" instead of "className"; that
          irks me too.
 
          oceanswave - 5 hours ago
          And vue optionally supports Jsx, so original comment or
          using it as a reason why ?react sucks? is being super
          pandentic. It?s ok to have multiple frameworks!
 
          Touche - 4 hours ago
          Optional features contribute to a tool's complexity,
          especially when every single example assumes you are
          using said optional feature.
 
      twfarland - 6 hours ago
      Agreed. Pure views are much simpler.
 
        bpicolo - 4 hours ago
        You can write prop-only, pure views in vue. :)
 
      irrational - 3 hours ago
      Different peoples brains work differently. React clicks with
      your brain, but not Vue. I've been doing web development
      since 1996. I read through both the React documentation and
      the Vue documentation. Vue just clicked with my brain. I
      totally groked it from the beginning. React... not so much.
      Vue has been amazing for us so far.
 
    mlsarecmg - 4 hours ago
    Vue is as easy to learn as Angular was. Saying that Vue is less
    complex - this line gets thrown around as if anyone would
    easily agree. It is a traditional templating framework, it
    ships its own javascript emulator and scripting engine, you re-
    learn everything. Composition is not natural to it. Every
    single structure is arbitrary. It has an API documentation that
    spans 70 pages. The cognitive overhead is large.If you know
    plain javascript you know half of what makes react. The API
    surface usually consists of a single function: render. The rest
    are 3-4 class lifecycles, setState, a few jsx semantics and
    that's it. You solve problems in the same way you always solved
    them, there is nothing to re-learn and you don't bend to the
    framework.Go ahead and re-create this in Vue, tell me what
    you're doing is easier:    import timestamp from 'time-stamp'
    const Header = props => 

{props.text}

          const
    Main = () => 
    ReactDom.render(, document.querySelector('#app'))  A
    beginner could blink at this once and start making simple apps
    blindfolded. A Vue beginner would be stuck even trying to
    create components, not to mention compose them, or pass props,
    or access the import. Every single step on top of this has to
    be fished out of the documentation: children, conditions,
    loops, filters, etc.
 
      aboodman - 2 hours ago
      I think the argument could be even more compelling without
      the es6-isms:  function Header(props) {     return
      

{props.text}

;   }    function Main() {     return
      ;   }    ReactDom.render(,
      document.querySelector('#app'))
 
        mlsarecmg - 2 hours ago
        Good call. Although the timestamp would have been
        impossible in Vue since templates don't have scope, they
        couldn't access imports. One would have to jump through
        another hoop and inject/duplicate the function into a
        template method.
 
      mplewis - 3 hours ago
      Vue supports JSX just fine. It also simplifies many things
      when compared to React:? lifecycle method names: mounted vs
      componentDidMount? proptypes: builtin vs `import PropTypes
      from 'prop-types'`? component creation: basic JS object vs
      ES6 class extending `React.component`Please don't spread
      misinformation because you prefer one way of writing frontend
      apps to another. React is better at complex apps, and Vue has
      a simpler API that many find easier to memorize.It's rude to
      insult other commenters by saying "A beginner could blink at
      this once and start making simple apps blindfolded." I think
      you're being hyperbolic, but it comes off as
      condescending.Frontend is hard. No one "blinks at this once"
      and learns how to build component-based layouts with view,
      data, and logic. Please be nice.
 
        mlsarecmg - 2 hours ago
        Why don't you actually recreate the snippet of code up
        there. The same arguments won't win you a price, and i
        don't agree with them for all the reasons i've stated. Show
        me how Vue handles the situation up there in such an easy
        way please, then we would have something to discuss.>
        Frontend is hard. No one "blinks at this once" and learns
        how to build component-based layouts with view, data, and
        logic. Please be nice.You seem to purposely misunderstand
        me. I never said someone could learn react by looking at
        it. I said someone could understand the nature of simple
        composition by looking at it.I learned Vue fully in maybe a
        few weeks. React in an hour here: egghead.io/courses/react-
        fundamentals If you think that studying a 70 page document
        in order to carry out basics like composition is easy then
        so be it. If you'd actually dare to post the example in
        Vue, we'd all see how "easy" the hoops would be you'd have
        to jump through to realize it.
 
      tekkk - 3 hours ago
      Oh please. React itself might not be that difficult but
      thrown in couple overly engineered libraries like react-
      router and immutable.js and that poor beginner will start
      feeling a bulging Javascript fatigue in their foreheads.Once
      you get rolling both of them are good but it's no easy task
      to start-up a React project on your own. You need a lot
      libraries, have to twiddle with immutability which is no
      piece of cake with JS and be constantly aware of small quirks
      like keys when looping jsx-elements, className instead of
      class, how to add css preprocessor, using setState instead of
      directly assigning to it with the constant farce with deeply
      nested Object.assigning oh such fun.React tries to make the
      world a better place with more theoretical approach while Vue
      focuses on tried-and-true methods that work and are straight-
      forward for everyone with a little experience in programming.
      (v-if might not be pretty but it beats JSX conditional)
      Granted modern frontend development has a lot of different
      things to be aware of that make it bit difficult for
      beginners but IMO Vue makes it a lot more simpler and
      productive. Some things I wish might be better like the
      ecosystem but oh well. Overall I'm happier and the only
      problem is having to fight off overly smug React-developers
      who have rubbed their egos so hard that they aren't able to
      even think about better solutions anymore.
 
        mlsarecmg - 2 hours ago
        immutable.js for what? Seems to me you're picking up hear-
        say here and there but why and for what would you want to
        use immutable. Even redux docs speak out against it. It's
        just a random tool like any other, you're assuming it has
        some deeper significance with react, it doesn't.> be
        constantly aware of small quirks like keys when
        loopingThere are no "quirks" in looping anything. It is
        plain javascript. I would call "v-for" a quirk on the other
        hand.    const array = []     for (let item of items)
        array.push(
  • {item.text}
  • )          render (
            
                   {array}         
         )  Recreate the
            snippet above, then let's discuss.
     
              mikewhy - 1 hours ago
              Doesn't that produce the "array items should have key
              prop" message?Also you can use `items.map` in your
              example.
     
              mlsarecmg - 1 hours ago
              I only wanted to show that react doesn't specify a
              programming style. He said javascript maps are "quirky."
              Maps are fine but so are plain loops. Ternaries are fine,
              so are plain if-then-else constructs if someone would
              like it better that way.The example would run without
              keys, it's merely for demonstration. You'd need keys in
              Vue as well.
     
          irrational - 2 hours ago
          "A beginner could blink at this once and start making simple
          apps blindfolded." Um... I've been doing web development for
          decades and I don't have a clue what those lines of code are
          doing.
     
            mlsarecmg - 2 hours ago
            > I've been doing web development for decades and I don't
            have a clue what those lines of code are doing.I don't
            think that's reacts fault?
            http://exploringjs.com/es6/index.html#toc_ch_first-
            stepsOther than the es6 syntax, would you like to specify
            what it is that you don't understand? If you look at it, it
            must occur to you that react components are functions that
            can receive properties and return markup. Now you can
            compose these functions. Just like in Vue or any other
            framework there is a single mounting point. If you
            understand this, you know the largest part of the react
            library.
     
              irrational - 1 hours ago
              I'm not the one who said that a beginner could blink at
              it and understand how to build React apps.
     
              mlsarecmg - 1 hours ago
              I never said you know react by looking at it. But you
              know it good enough to build a simple composition. If i
              asked you to create another component up there that
              contains a span, are you seriously saying you wouldn't be
              able to do it after having looked at it?    const Foo =
              () => hey  or, same thing in es5    function
              Foo() {         return hey     }  ?And if i
              asked you to use this component in another, even if you
              saw how it's done, you would absolutely not be able to
              pull it off again?    function Bar() {         return
                   }  ?To be honest, i thought i didn't like
              react as well when i first encountered it. I didn't
              actually try to understand, the appearance of it seemed
              so radically different that i refused to think of it as
              simple. But i eventually tried and figured that there is
              actually nothing behind this framework. These are plain
              functions, or classes with lifecycles. I was wrong in my
              assumptions.
     
        hesarenu - 5 hours ago
        For a js developer Reactjs is far easier to pick rather then
        learning vue. Reactjs has few life cycle to learn rest is just
        javascript.
     
        ng12 - 5 hours ago
        I think this is a misleading answer. It only appears that way
        because the React ecosystem is much bigger and tailored to more
        complex applications. Comparing the Vue library to the React
        library I find it hard to recommend one over the other -- at
        the end of the day they're pretty similar.
     
    spicyj - 6 hours ago
    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.Happy to answer
    questions if y'all have any. :)
     
      zitterbewegung - 5 hours ago
      Will the new performance improvements also trickle down to react-
      native and or react-vr ?
     
        danabramov - 5 hours ago
        Yes.
     
          aurnik - 3 hours ago
          Do RN projects just need to upgrade React then?
     
            danabramov - 55 minutes ago
            No. We'll update RN with the new reconciler in the next few
            versions.Don't expect it to magically improve performance
            though. But the async stuff mentioned in the post will
            definitely come to RN when it is ready.
     
          k__ - 4 hours ago
          Since RN is using 16 for a while now, they already did, or am
          I wrong?
     
            danabramov - 57 minutes ago
            The "react" package is mostly irrelevant here since it only
            contains a few utilities. The actual reconciler is synced
            separately, and no, it isn't enabled in RN yet (but maybe
            will be in the next stable release).
     
      bcherny - 6 hours ago
      Thanks for the hard work! This release looks really exciting and
      I can't wait to try it out.Out of curiosity, did you switch to
      Rollup for the tree shaking optimizer, or for some other reason?
     
        danabramov - 6 hours ago
        We used it because it produces a single flat bundle without
        extra module boundaries. I think webpack 3 might do the same
        with the experimental concatenation plugin, but we're fairly
        happy with Rollup.
     
          bcherny - 3 hours ago
          I see, and the benefit there is faster startup due to less
          IIFEs?
     
            danabramov - 58 minutes ago
            Yes. It's also nice that we don't expose the internals
            anymore, even when consumed via CommonJS.
     
      dfabulich - 2 hours ago
      Will it ever be possible to slim down React to the size of
      Inferno or Preact? Would it be enough to make the synthetic event
      system optional?
     
        danabramov - 59 minutes ago
        We'll be looking into simplifying the event system in the
        future.
     
      [deleted]
     
      koolba - 5 hours ago
      Kudos on both the release and the licensing changes.Why remove
      the dist folder that was in prior releases?
     
        spicyj - 5 hours ago
        It's been renamed to "umd" for clarity.
     
      [deleted]
     
      codelike - 45 minutes ago
      I've just finished reading
      https://code.facebook.com/posts/1716776591680069/react-16-a-...
      and it provided lots of good insights into how you managed to
      roll out the new release. Thanks for the interesting write-
      up!That blog post mentions your featureFlag approach, the initial
      dogfooding and then the gradual rollout. I'd be very interested
      to hear on top of that:1. How did you approach the rewrite on the
      coding side? What I mean is: Did you just say "Okay, let's start
      from scratch and use the lessons learned from v1?" Or did you use
      a specific approach along along the lines of: "Let's structure
      our code based on these principles and ...?"2. When you started
      the rewrite, how did you know in advance and make sure that the
      rewrite would be faster and have a smaller code-size?3. Was your
      focus during the rewrite on a cleaner code base (and the
      performance improvements followed automatically) or was your
      focus on speed right from the start?4. Any other lessons learned
      during the rewrite? Patterns and approaches that helped/didn't
      help during the coding?
     
      dean - 3 hours ago
      The conventional wisdom in software development is to never
      rewrite your application from scratch. Typically it's much more
      difficult than you thought it would be, and it takes too long.
      Meanwhile, competitors pass you by (remember Netscape?). Just
      wondering how you came to make the decision to do this, and what,
      if any, concerns came up along the way?
     
        dahart - 2 hours ago
        The blog post mentioned getting test coverage before starting: 
        https://code.facebook.com/posts/1716776591680069/react-16-a-...
        I always remember how the SQLite author Richard Hipp talked
        about being able to rewrite major chunks of the SQLite engine
        due to their test coverage. Their testing page currently says
        they have 730x more test code than core library code.
        https://www.sqlite.org/testing.html
     
        brokencode - 2 hours ago
        The conventional wisdom applies to large, complicated software.
        The source for React comes in at around 109kb now. That
        couldn't be more than 10-20 thousand lines of code, which is
        quite small.
     
      sAbakumoff - 5 hours ago
      That's truly hard work to rewrite everything from scratch and
      keep the legacy API untouched! OOC - what was the most difficult
      feature/bug to preserve/fix in this process?
     
      outside1234 - 6 hours ago
      Are there plans to relicense React Native to MIT without a Patent
      timebomb as well?
     
        swah - 5 hours ago
        But now they "have" to relicense React Native, right? Otherwise
        someone will write a React Native clone starting from MIT-
        licensed React, no?
     
        tomkinson - 6 hours ago
        My understanding this was already done last week. I could be
        wrong. GraphQL however, not yet.
     
          vvanders - 6 hours ago
          Not React Native, that still has the patent clause.
     
            yasserkaddour - 5 hours ago
            GraphQL specification has been relicensed minutes ago to
            Open Web Foundation Agreement, graphql-js and relay to
            MIT.https://medium.com/@leeb/relicensing-the-graphql-
            specificati...https://news.ycombinator.com/item?id=15340528
     
              [deleted]
     
          [deleted]
     
        Dolores12 - 6 hours ago
        [edited]
     
          Godel_unicode - 5 hours ago
          Here's the problem with that type of snark; when you're wrong
          it's really bad for you. You are responding to a question
          about react NATIVE, which still has the patent grenade (see
          below).https://github.com/facebook/react-
          native/blob/master/PATENTS
     
            [deleted]
     
          seattle_spring - 6 hours ago
          React !== React Native
     
            jonknee - 5 hours ago
            Well, react-dom !== react-native. Both projects use core
            react.
     
            ofirg - 5 hours ago
            However React == React Native evals as true due to type
            conversion (in ECMAScript projects with or without a patent
            grant are both considered 'truthy'). Really even === is not
            good enough, The only reliably why to test for it right now
            is to put a patent claim against FB inside a try-catch.* I
            am not a lawyer and this should not be taken as legal
            advice.
     
        danabramov - 6 hours ago
        It's possible in the future, but re-licensing React itself was
        already a very large change, and it will take more time to
        review the possibility of this for other projects like RN.
        Thanks for your patience!
     
          moomin - 5 hours ago
          Yeah, pity said large change was implemented before checking
          if it was a good idea.Community: This license is a legal
          nightmare. Something needs doing! Facebook: We have done
          something. Community: Try listening to both sentences next
          time.
     
            rhencke - 5 hours ago
            The MIT license is extremely commonplace in web libraries
            and is well accepted.  (used by jQuery, Preact, Angular,
            etc.)Can you clarify your concerns?
     
              slaymaker1907 - 5 hours ago
              I'm not in anyway connected with FB, but I think the
              reason why React was licensed under MIT more quickly than
              React Native is because of that licensing environment.
              Web frameworks traditionally have very open licenses, but
              native seems more more restricted such as with Qt and the
              C# thing I don't remember the name of.
     
              bernadus_edwin - 4 hours ago
              C# things : xamarin & mono
     
              bennyg - 5 hours ago
              Except the largest 3rd party Objective-C and Java
              (Android) libraries are usually MIT as well. I don't
              really think this has to do with traditions as far as per
              platform licensing goes.
     
        mihular - 5 hours ago
        But does MIT license really solve all patent issues? FB could
        still enforce patents regardless of license if I understood it
        properly.
     
          signal11 - 4 hours ago
          IANAL, but is it fair to say that using React under MIT
          doesn't leave you any worse off than using Angular and Vue?
          (both of which are MIT-licensed)Depending on the patent in
          question, it is possible to be on the hook even if you don't
          use React.
     
            mihular - 3 hours ago
            But do the others have explicit patents?
     
          mlsarecmg - 4 hours ago
          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 - 4 hours ago
            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.
     
              abiox - 3 hours ago
              react isn't covered by fb patent, so using react grants
              nothing in terms of fb patents (implied or otherwise).
     
              mihular - 3 hours ago
              I'd really like to see that written black on
              white,though.
     
    orb_yt - 6 hours ago
    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.
     
      ryanbertrand - 6 hours ago
      We use ad hoc portals for showing modals, flyout panels,
      popovers.
     
        audessuscest - 5 hours ago
        Do you know where to find some usage examples ?
     
          captnasia - 5 hours ago
          If you go to the Portals documentation (
          https://facebook.github.io/react/docs/portals.html ) you can
          find some examples throughout.
     
            teraflop - 5 hours ago
            Both 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 - 4 hours ago
              Sorry, there was so much to do in the release that some
              issues crept into the new docs. We'll fix them soon. :-)
     
              acdlite - 4 hours ago
              Fixed now! Thanks for the bug report!
     
              teraflop - 23 minutes ago
              No problem! And on re-reading my comment, I probably
              shouldn't have used the word "insidiously", it came off a
              lot more negative than I intended. Thanks for the quick
              fix.
     
      AgentME - 4 hours ago
      The portal API sounds great for modals and dropdowns. It looks
      like a good fit for react-float-anchor[0] (used by the more
      interesting to look at react-menu-list[1]). I'm currently abusing
      `componentWillReceiveProps` to get portal-like behavior, but it
      means that test code has to do react-float-anchor -specific
      things in certain situations to see elements rendered in it.[0]
      https://github.com/StreakYC/react-float-anchor [1]
      https://github.com/StreakYC/react-menu-list
     
      maaaats - 5 hours ago
      I've used portals to make modals, as they often have to be close
      to the root. This has had many quirks and bugs from code not
      expecting to be in a portal, hopefully it being a supported
      concept fixes this.
     
      humblebee - 5 hours ago
      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.
     
    zghst - 6 hours ago
    Congrats team!
     
    tootie - 6 hours ago
    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.
     
      benregenspan - 4 hours ago
      Because 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.
     
      andrewingram - 5 hours ago
      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 - 4 hours ago
        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!
     
    wereHamster - 5 hours ago
        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 - 5 hours ago
      Submit a PR :)
     
    sharno - 5 hours ago
    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
     
    Kwastie - 6 hours ago
    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 - 5 hours ago
      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.