
React v15.5.0 - shahzeb
https://facebook.github.io/react/blog/2017/04/07/react-v15.5.0.html
======
acemarke
For those who are interested in some of the details of the work that's going
on, Lin Clark's recent talk on "A Cartoon Intro to Fiber" at ReactConf 2017 is
excellent [0]. There's a number of other existing writeups and resources on
how Fiber works [1] as well. The roadmap for 15.5 and 16.0 migration is at
[2], and the follow-up issue discussing the plan for the "addons" packages is
at [3].

I'll also toss out my usual reminder that I keep a big list of links to high-
quality tutorials and articles on React, Redux, and related topics, at
[https://github.com/markerikson/react-redux-
links](https://github.com/markerikson/react-redux-links) . Specifically
intended to be a great starting point for anyone trying to learn the
ecosystem, as well as a solid source of good info on more advanced topics.
Finally, the Reactiflux chat channels on Discord are a great place to hang
out, ask questions, and learn. The invite link is at
[https://www.reactiflux.com](https://www.reactiflux.com) .

[0]
[https://www.youtube.com/watch?v=ZCuYPiUIONs](https://www.youtube.com/watch?v=ZCuYPiUIONs)

[1] [https://github.com/markerikson/react-redux-
links/blob/master...](https://github.com/markerikson/react-redux-
links/blob/master/react-implementation.md#react-fiber)

[2]
[https://github.com/facebook/react/issues/8854](https://github.com/facebook/react/issues/8854)

[3]
[https://github.com/facebook/react/issues/9207](https://github.com/facebook/react/issues/9207)

~~~
STRML
I was in awe the entire time Lin was speaking. Not a single "um" or other
verbal tic; she's an incredible speaker and was admirably lucid throughout
that entire talk. That's so difficult to do. And style aside, she made
understanding Fiber incredibly simple.

Just wanted to express my admiration for her work and gratitude for making
this information public, available, and free.

~~~
tekacs
As someone who talks quite (very?) fast and has to carefully slow down for
public speaking...

... I found Lin's style of speaking very difficult to listen to. I appreciate
the professionalism of the approach (if that's what it is), but if only by a
small margin (perhaps 10-20%), I found her speaking too slow to the point that
I wanted to skip forward constantly and would have found it difficult to pay
attention to in person. :/

Perhaps this might be about the structuring of information as well (I'm
familiar with much of what's being talked about). That said however, I've
historically found that when listening to really good speakers, I find it easy
to sit and have explained to me things that I already know well - so I'm not
sure what's happening here.

~~~
jozan
Youtube player has a setting for playback speed. I almost always watch YT
videos in 2x speed or more.

~~~
Lorin
There is also a minimal Chrome extension called 'Video Speed Controller' that
brings this functionality to all HTML5 videos with a bit more granularity.
It's invaluable.

------
TheAceOfHearts
React team is doing an amazing job. I remember when it was first announced, I
thought Facebook was crazy. "JSX? That sounds like a bad joke!" I don't think
I've ever been so wrong. After hearing so much about React, I eventually tried
it out and I realized that JSX wasn't a big deal at all, and in fact it was
actually pretty awesome.

Their migration strategy is great for larger actively developed applications.
Since Facebook is actually using React, they must have a migration strategy in
place for breaking changes. Since breaking anything has such a big impact on
the parent company, it makes me feel like I can trust em.

Heck, most of the items in this list of changes won't surprise anyone that's
been following the project. Now there's less magic (e.g. React.createClass
with its autobinding and mixins), and less React-specific code in your app
(e.g. react-addons-update has no reason to live as a React addon when it can
clearly live as a small standalone lib).

~~~
ng12
Agreed 100% about JSX. Especially since the only alternative anyone uses is
opaque stringly-typed template nonsense (Angular, Vue, Ember, etc).

~~~
enraged_camel
I use single-page components in Vue and write templates like this:

    
    
      <template>
          <div>
              <h2>{{ title }}</2>
          </div>
      <template>
    
      <script>
        export default {
            data() {
                return {
                    title: "Hello world"
                }
            }
        }
      </script>
    

Works well in my opinion. Separates the template into its own section but
keeps it inside the same file.

~~~
ng12
In my mind this is strictly inferior to JSX, which would be:

    
    
       export default ({title}) => (
          <div>
             <h2>{title}</h2>
          </div>
       )
    

The only benefit to the template is if you use fancy features (#each, binding,
etc) which is worse because now you have two places where the logic happens.

------
STRML
This is a big deal to deprecate `createClass` and `propTypes`.

PropTypes' deprecation is not difficult to handle, but the removal of
createClass means one of two things for library maintainers:

(1). They'll depend on the `create-class` shim package, or,

(2). They must now depend on an entire babel toolchain to ensure that their
classes can run in ES5 environments, which is the de-facto environment that
npm modules export for.

I'm concerned about (2). While we are probably due for another major shift in
what npm modules export and what our new minimum browser compatibility is, the
simple truth is that most authors expect to be able to skip babel
transcompilation on their node_modules. So either all React component authors
get on the Babel train, or they start shipping ES6 `main` entries. Either way
is a little bit painful.

It's progress, no doubt, but there will be some stumbles along the way.

~~~
spankalee
It's really time to start distributing ES6 via npm. All current browsers
support ES6. It's now generally faster than equivalent ES5, it minifies
better, tooling is better, etc.

It's the app that should compile all the code to run in the target environment
if needed. This is what we've done in the new Polymer CLI / polymer-build: we
compile all dependencies but only if necessary.

~~~
Silhouette
_All current browsers support ES6._

That's debatable, particularly when you factor in bugs. However, even if they
did, it seems unwise to assume that all relevant users for all or even most
projects will be on the latest evergreen browsers. Several large groups,
including business users on IE and mobile users on slightly older devices,
probably won't be.

I know there's a certain type of web developer who would love for everyone to
have updated their browser within the last five minutes so all the new toys
are available universally, but that has never been the nature of web
development. Deliberately breaking major infrastructure is just going to make
JS development even more screwed up than it already is.

~~~
debaserab2
This is a common theme I'm noticing a lot lately. Meanwhile, I check my
product's browser breakdown and IE9/10 is still too significant to ignore.
There's just no way our customers would be okay with this. Many are still
locked on older IE versions due to (bad) corporate policies. I can't strongarm
them into upgrading.

Which leads me to wonder: are developers that are so willing to advocate
breaking compatibility with older browsers actually deploying real sites that
have normal representative user audiences? Or is this an insular group of
developers mostly making things for each other?

~~~
Silhouette
I'm afraid this culture is now endemic in web development. Everyone expects
everything to be free, so the people building most of the tools, from the
libraries to the browsers themselves, are mostly either doing it for fun as an
amateur or doing it professionally in order to support something that does
bring in revenues. Neither of these necessarily implies writing or maintaining
ideal tools to support web development more widely; any wider benefit is
largely coincidental. Unfortunately, because so much of the influence is now
concentrated with so few organisations or even individual people, and most of
them are aligned on this, it's going to be difficult to return to a more
widely supportive ecosystem now.

~~~
matt4077
Let's dispense with the "amateurs" first: the complete stack is build almost
exclusively by people employed by Google, Facebook, Apple, Mozilla, and a
handful of smaller, but at least as professional, companies.

Then, I don't understand the rest of the argument. Open Source software has
simply won in the marketplace, mostly because of it's openness, rarely because
of it's price.

Example: Operating Systems, which is the rare beast where an actual closed-
source competitor still exists. Yet the Windows marketshare on the server is
around 10%, and I doubt that it's the price that encourages all those Unicorns
to chose Linux. Databases are a similar story.

> Neither of these necessarily implies writing or maintaining ideal tools to
> support web development more widely

It doesn't necessarily do that, but in the case of Google specifically, it
does: they need the open web as a platform to compete against the "walled
gardens" of Apple and Facebook. Their interests happen to be aligned with
those of web developers, which is why Chrome has revitalised browser
competition, easily beating the laser-focused team at Mozilla.

> Unfortunately, because so much of the influence is now concentrated with so
> few organisations or even individual people

The influence is spread out far wider today than it was at the time where
Microsoft and Flash were able write APIs without asking anybody.

But, more importantly, I'm unsure what you want? A version of React that
supports IE 6 and lynx? They have that, it's called XHTML 1.0 Transitional.

~~~
Silhouette
_Let 's dispense with the "amateurs" first: the complete stack is build almost
exclusively by people employed by Google, Facebook, Apple, Mozilla, and a
handful of smaller, but at least as professional, companies._

You might like to take a look at the history of Babel (formerly 6to5) as one
prominent counter-example. For several years, much of the web development
community has been relying on a great tool that was originally written by one
talented young amateur.

 _Open Source software has simply won in the marketplace, mostly because of it
's openness, rarely because of it's price._

Chrome being prominently advertised every time anyone visited a Google site
using another browser probably didn't hurt. Being installed by default on the
most popular mobile OS also didn't hurt. If openness were all it took, Firefox
would surely still be a more prominent player.

 _It doesn 't necessarily do that, but in the case of Google specifically, it
does: they need the open web as a platform to compete against the "walled
gardens" of Apple and Facebook._

Google wants people to use the Web because it makes its money primarily from
advertising on web sites. It is in Google's direct financial interest to
support the part of the Web ecosystem that in turn supports advertising. That
typically doesn't include, for example, corporate intranets, or embedded UIs
in network-connected devices, or academic sites, which are three big areas
where web technologies are widely used but stability and long-lasting content
are more highly valued.

 _Their interests happen to be aligned with those of web developers, which is
why Chrome has revitalised browser competition_

Writing as a professional web developer who often works in those other areas I
mentioned, Chrome hasn't revitalised browser competition. On the contrary,
it's become the new IE from the old browser wars. A lot of the new
functionality only works properly in Chrome, and often it's not reliable even
there because of the frequent updates that change behaviour and/or introduce
regressions. There's no real concern about proper standardisation or
compatibility or longevity any more.

 _But, more importantly, I 'm unsure what you want?_

I want the fundamental tools on which much of the ecosystem now relies not to
break everything that predates a standard that is less than two years old and
still not fully supported across many active browsers. In this case, that
means being able to install packages from NPM with a reasonable expectation
that they will not require a substantial extra build process to be used.

Obviously no-one contributing NPM packages has any _obligation_ to respect
that. It's not as if we're all paying for their openly licensed work. I just
think the community as a whole will otherwise suffer yet more overheads
getting infrastructure set up instead of actually getting useful work done.

------
ggregoire
For those still using propTypes, I'd recommend to take a look at Flow as
replacement.

[https://flow.org/en/docs/frameworks/react](https://flow.org/en/docs/frameworks/react)

~~~
lfischer
Flow’s interesting, unfortunately it requires more invasive changes to your
code than just prop types. For example, if I remember correctly, you need a
declaration for a class component’s state.

~~~
adrice727
We decided to use Flow in a rewrite of an existing React project at work. I
found all of the type _boilerplate_ around React/Redux to be somewhat
cumbersome at first, but after a few days I didn't even think about it
anymore. It feels a little strange writing React code without it at this
point.

~~~
derekdahmer
Same, we're using Flow in for our React Native app but not yet in our older
webapp.

I've found more bugs that way that more than offset the extra time spent
writing types and being a little bit more verbose to keep flow happy.

The minor annoyances are around the edge cases. Like eslint/flow throws
propType errors when using props that were dereferenced from
`this.props.someObject`. But you can just write the longer version
`this.props.someObject.whatever` and everything's fine.

------
amk_
The breakup of the React package into a bunch of smaller modules really puts
packages that treat React as a peer dependency in a pickle. I have a component
module using createClass that works fine and exports a transpiled bundle in
package.json. I guess now we'll have to switch to create-react-class, or
maintain some kind of "backports" release series for people that are still
using older React versions but want bugfixes.

Anyone have experience with this sort of thing?

~~~
danabramov
Switching to create-react-class sounds reasonable, that's what we intended. It
will work in older versions too.

~~~
amk_
If we switch to it as a hard dependency, library consumers on React <16 will
have an extra package in the bundle. If we make it an optional peer
dependency, package.json becomes less reliable because we would need to check
where createClass is implemented at runtime.

Is create-react-class smart enough to determine whether the version of React
it is augmenting already implements createClass to prevent bundle size bloat?

------
nodesocket
Big news seems to be removal of `React.createClass()` in favor of:

    
    
       class HelloWorld extends React.Component {
    
       }

~~~
thatswrong0
Mild rant:

I'm not convinced ES6 classes are better than components created the old way.

First, the lack of autobinding callback functions for child props is not
ideal. I don't even have to think about it with createClass, and it requires
at least one extra step with ES6. It's less convenient.

Second, I don't think HOCs are necessarily easier to reason about than mixins
in many situations. React is already quite deficient in its own testing
utilities (esp. when it comes to functional stateless components and HOCs such
that I'd recommend everyone use enzyme), and testing a multi-wrapped HOC can
be a PITA whereas whereas a component with multiple mixins is simpler to
reason about in comparison. What I care about is testing the output of a
component; I don't want to have to understand the internal structure of a
component in order to test it in a shallow manner.

Id love to see an argument as to why they are better, but I haven't seen
anything convincing. Plus our app uses a ton of non-invasive mixins and the
upgrade away from them would complicate the app and make testing way more
complicated.

~~~
tlrobinson
If you don't want to think about binding, just use the arrow function syntax:

    
    
        class Foo extends Component {
          bar = () => {
            // ...
          }
        }

~~~
TheSisb2
This compiles poorly and has a performance cost, it turns out. Doing:

constructor(props) { super(props); this.func = this.func.bind(this); }

Is better if you care about performance.

~~~
ConAntonakos
Just curious: are there tests proving this?

------
hueller
This is a good move. Modernization with sensible deprecation and scope re-
evaluation with downsizing when more powerful alternatives exist. Too often
codebases get bigger when they should really get smaller.

------
smdz
I absolutely love how React+TypeScript setup handles PropTypes elegantly. And
then you get the amazing intellisense automatically.

```

interface State {}

interface ISomeComponentProps {

    
    
      title: string;
    
      tooltip?: string
    
      ....
    

}

@ReduxConnected

export class SomeComponent extends React.Component<ISomeComponentProps, State>
{

....

```

------
uranian
What is this problem in the Javascript landscape to keep forcing developers to
do things differently, with the penalty of your app not working anymore if you
don't comply?

I mean, creating a new type of brush for painters is ok, but I don't see the
need for forcing them to redo their old paintings with the new type of brush
in order to keep them visible..

IMHO Coffeescript and some other to Javascript transpilers are still a much
better language than the entire Babel ES5/ES6/ES7 thing. But for some reason
my free choice here is in jeopardy. The community apparently has chosen for
Babel and are now happily nihilating things that are not compatible with that.

In my opinion this is not only irresponsible, but very arrogant as well.

Although I do understand and can write higher order components, I still write
and use small mixins in projects because it works for me. I also use
createClass because I enjoy the autobinding and don't like the possibility to
forget calling super.

Now I need to explain my superiors why this warning is shown in the console,
making me look stupid using deprecated stuff. And I need to convince them why
I need to spend weeks rewriting large parts of the codebase because the
community thinks the way I write is stupid. Or I can of course stick to the
current React version and wait until one of the dependencies breaks.

It would be really great if library upgrades very, very rarely break things.
Imagine if all the authors of the 60+ npm libs I use in my apps are starting
to break things this way, for me there is no intellectual excuse to justify
that.

~~~
Rygu
Although I don't agree with the overall sentiment of your message, I do
understand your situation as a professional. In fact I believe by far the
largest (less vocal) group of React users only use it at work, and never
wilfully agreed to spend their spare time on GitHub because of FOMO, or fear
of dependency upgrades (FODU).

And I believe there should be a better way to prepare your users for a major
version upgrade (React 15 -> 16) than to update the current branch with all
kinds of deprecation warnings. Even if a library - as popular as React -
doesn't plan to provide lifetime support for any major because they like to to
move fast, I understand that, it's simply not okay to ruin older branches this
way, madly assuming everyone is surely going to upgrade to React 16 in the
immediate future.

Ideally, I'd imagine there could be a separate optional package that adds
these warnings dynamically. If that's not possible technically, then an
optional build flag would be nice. Or two separate releases: react-15.5.0 and
react-15.5.0-upgrade-support. Even better: go back to semver, and treat major
upgrades as optional for the first 6 months. This allows other libraries like
routers and style libs to catch up, so app devs can upgrade even more
smoothly.

Maybe after all, DX is about when to provide helpful errors and warnings. And
when not to?

~~~
danabramov
Yea, this is a good idea and something we are considering for the future!

------
PudgePacket
Why do React and other js libraries emit warnings as console.error when
browsers support console.warn?

~~~
tlrobinson
console.warn in most (all?) browsers' dev tools didn't/doesn't provide the
full stack trace.

I think that changed recently in Chrome, at least.

------
sergiotapia
Awesome changelog with great migration instructions. Bravo to the React team!

Going to set aside some hours on Saturday to upgrade our React version.

I recently started to go in with functional components where I don't need
life-cycle events such as componentDidMount. Does anyone know if React is
planning to make optimizations for code structured in this way?

~~~
acemarke
Eventually, yes. The original release notes announcing functional components
mentioned that they would "eventually" add some optimizations, but many people
assumed that meant they already _are_ optimized. Right now, there aren't any
special optimizations for functional components.

------
Rapzid
Fiber is what I'm really waiting for. Not much official chatter about it, but
looks like a 16 release?

They just removed some addons in master that many third party packages rely
on, including material-ui. Hopefully these other popular packages can be ready
to go with the changes when the fiber release hits.

~~~
YCode
When I saw this post I immediately hit
[http://isfiberreadyyet.com/](http://isfiberreadyyet.com/) and was sad it went
back down to 92% :|

~~~
spicyj
We added some more tests for server rendering (which Fiber doesn't yet
support). Working on it though.

~~~
YCode
I appreciate all the hard work you guys are doing; I understand it takes time
and I think most people are willing to wait.

------
whitefish
I'd like to see React support shadow-dom and web components. Not holding my
breath however, since Facebook considers web components to be a "competing
technology".

Unlike real web components, React components are brittle since React does not
have the equivalent of Shadow DOM.

~~~
danabramov
You can use web components in React just fine if that's your cup of tea.

[https://facebook.github.io/react/docs/web-
components.html](https://facebook.github.io/react/docs/web-components.html)

There's also more opinionated integrations like
[https://www.npmjs.com/package/skatejs-react-
integration](https://www.npmjs.com/package/skatejs-react-integration).

And of course you can do it the other way around too.

~~~
petilon
The problem when you use Web Components in JSX is that there is no way to wire
up any custom events fired by the Web Component. JSX will only wire up "known
events".

~~~
spankalee
That's just when you use custom elements in _React_.

I've definitely wired up JSX createElement implementations that handle
attributes and events properly. My preference is for Polymer-style naming:
`on-*` for event handlers, `$` suffix for attributes and everything else is a
property. Others who've done this use special `attributes` and `events`
properties.

------
baron816
I hate that the React team prefers ES6 classes. This is what I do:

function App(params) { const component = new React.Component(params);

    
    
      component.lifeCycleMethod = function() {...};
    
      component.render = function() {...};
    
      function privateMethod() {...}
    
      return component;
    }

~~~
swalsh
Care to add more to this? I've been doing javascript in some form or another
for 10 years. We've always been able to do something "class like", but having
actual real classes in ES6 is great. What is there not to like?

~~~
jschrf
I think this is just a trope that JS devs and newbies have launched on to, and
that it's without merit.

Classes are good. Classes express concrete taxonomies of concrete things in
ways that most developers can understand.

I think we should be happy that JS is flexible enough that adding "class" to
the language is almost purely syntactical: it clarifies and makes semantic a
bunch of otherwise boilerplate "Foo.prototype.blah" code that you see in so
many non-trivial JS apps.

Classes simplify things IMO.

~~~
baron816
There's nothing wrong with classes, they're just not right for JavaScript. I'm
not going to claim that I'm a JS expert or anything, this is just something
I've learned from pretty well established JS experts like Kyle Simpson and
Douglas Crockford.

The reasons they give are that 1) you should favor composition and delegation
over classical inheritance 2) classes keep you from using and understanding
closure and other functional patterns and 3) you just get a lot of really
weird behavior when trying to use classes in JS which results in a lot of
confusion and wasted time, especially for those who don't have 10 years of
experience under their belt.

Edit: Here's Simpson's take: [https://github.com/getify/You-Dont-Know-
JS/blob/master/this%...](https://github.com/getify/You-Dont-Know-
JS/blob/master/this%20%26%20object%20prototypes/apA.md)

~~~
acemarke
It's worth noting that the React team promotes composition over inheritance,
and discourages any levels of inheritance past `class MyComponent extends
React.Component`.

Long term, the React team plans to investigate concepts like "stateful
functional components", but until then, classes are the most straightforward
way of having lifecycles. The existence of ES6 classes is based on the wide
range of third-party "class" implementations across the JS ecosystem, so
clearly there was a desire to have them available. Since they're available,
React is using them.

~~~
linkmotif
> but until then, classes are the most straightforward way of having
> lifecycles.

Huh? Why? React.createClass({}) is/was pretty straightforward. What is more
straightforward about classes? All I see is more code.

~~~
acemarke
I was responding to a comment saying "classes are a bad idea in JS in
general". `React.createClass` is a homegrown implementation of classes,
React.Component builds on ES6 classes, both would be disliked by Kyle Simpson
or Douglas Crockford.

There are three major differences between `createClass` and React.Component:

\- Autobinding

\- Mixins

\- Custom class system vs one that's built into the language

Autobinding is the most useful aspect, but there's a variety of ways to deal
with it: use the Class Properties syntax and write methods as arrow functions,
use one of the many autobind utilities in a constructor, write your own base
class that extends React.Component and do autobinding in its constructor, etc.

Mixins are now a discouraged approach for writing React code. If you still
want to use mixins in React components, there's some "compat component"
classes on NPM, or you could use a non-React-specific method of applying
mixins.

And finally, deprecating a custom class implementation means that it's one
less thing the React team has to maintain, and the lib size is that much
smaller.

------
xamuel
Happy to see propTypes getting shelved. Too many people stubbornly use
propTypes even in Typescript projects. Hopefully this change will usher in the
final stamping out of that.

~~~
YCode
What's wrong with propTypes?

~~~
xamuel
In a non-Typescript project, they're a shoddy half-baked type system duct-
taped together. In a Typescript project, they're almost completely redundant,
they add a huge maintenance burden for basically no gain.

------
bsimpson
Of course, you'd need to use super appropriately, but I wonder if anyone's
taken a stab at porting React mixins to ES2105 mixins:

[http://justinfagnani.com/2015/12/21/real-mixins-with-
javascr...](http://justinfagnani.com/2015/12/21/real-mixins-with-javascript-
classes/)

------
Drdrdrq
Just curious: did Facebook change the license? AFAIK they can revoke
permission to use from 3rd parties. Am I mistaken? If not, isn't this a huge
risk for startups?

~~~
bpicolo
[https://code.facebook.com/pages/850928938376556](https://code.facebook.com/pages/850928938376556)

It's purely defensive, they'll only revoke your license if you sue them for
patent infringement. And they only revoke the patent-grant of React as far as
I can tell, not your license to use it (and there aren't any patents related
to React as far as the internet claims).

~~~
DenisM
Which in turn means they can infringe on any of your patents with no
consequences. If they do, your only choice is to rewrite your entire
application in a hurry, and only _then_ you can sue them.

~~~
tracker1
Of course if you use a similar competing technology and choose to sue them
over patents, they could still find you infringing and sue you anyway.

------
ksherlock
So... create-react-class is an unrelated node module. react-create-class (the
correct one, I guess) is completely empty, other than the package.json.

~~~
acemarke
They haven't actually moved the deprecated code out into separate packages yet
- this is the warning they're about to do so.

The 15.5 announcement does thank several people for "transferring ownership of
package names", so I'm guessing that may be one of them.

------
iLemming
I wonder how these changes would affect Clojurescript libs built on top of
React, e.g.: Om.Next and Reagent

------
aswanson
I cannot keep up. I just started learning react/apollo/graphql and I'm already
out of date.

~~~
danabramov
You're not out of date. :-)

Two APIs moved from one package to another. That's all. I understand it can be
frustrating but there is no big change to learn here.

Your code will still work in 15, and we print warnings telling exactly what to
do to prepare for 16. And we provide tools to automate this change for your
existing code.

------
revelation
I still remember the times when warning were actual likely mistakes in your
code, not "we're adding some more churn, update your stuff until we churn
more".

If you want people to always ignore warnings, this is how you go about it.

~~~
acemarke
Baloney. This is proper release management planning. People keep complaining
that React is too big and needs to shrink down. They're planning to help
address those complaints by removing pieces they no longer intend to maintain,
or are not the primary usage going forward. So, they're putting out a minor
release that will warn people these pieces are being removed, and then they'll
be removed in the upcoming major release. Seems like the right approach to me.

~~~
mtrpcic
Yeah, these are basically Deprecation Warnings, which have been a standard
part of good release management for a long time, across many projects in many
industries.

------
lngnmn
Why people are always end up with J2EE-like bloatware? There must be some
pattern, something social. It, perhaps, has something to do with the elitism
of a being a framework ninja, a local guru who have memorized all the
meaningless nuances and could recite the mantras, so one could call oneself an
expert.

The next step would be certification, of course. Certified expert in this
particular mess of hundred of dependencies and half-a-dozen tools like Babel.

Let's say that there is a law that any over-hyped project eventually would end
up somewhere in the middle between OO-PHP and J2EE. Otherwise how to be an
expert front-end developer?

Google's responsive design looks like the last tiny island of sanity.

~~~
danabramov
React removed extra dependencies that some people don't use, not added. Not
sure what this has to do with PHP, J2EE, or Babel. Your comment sounds a bit
like misdirected rant but if you have specific concerns about React we are
happy to discuss! Cheers.

