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

Personally I am more concerned about keeping my team building cool features than updating react. This has led to us having two distinctly non-interoperable code bases, one with react 0.12 and one with react 14-15. This makes me worried that now we will have a third with react >15.

I think we can all agree that many of the ideas, while not new, were revolutionary to front-end web developers. And that is what I love about working in this stack. But other than these ideas, the projects themselves are just stumbling along trying to catch up with some perceived "modern" way of coding, and it is the dev teams and projects that suffer.

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.

Messy.

I use coffeescript classes as components without any problem and that inserts an "extends" function into every compiled .js-file that has a class.

I suspect people that need ES5/ES6 compatibility that currently rely on React.createClass as a peer dependency can switch to maintaining their own createClass function local to the project. Suboptimal, but not a lot of code.

For example:

The utility types in https://flow.org/en/docs/types/utilities/ can be used to great effect to express things like "A type of the keys of T, but values passed through this function" or "A type that is the difference of these two maps".

In practice, this helps me write things like React Components that take some of their props from the root store via context, and the rest of their props directly, and for Flow to actually know which is which just by reading the code (no explicit typedefs!), override root store props as needed (so long as I don't change their types), and throw a type error if I miss or misdefine one. Awesome.

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.

Not sure what's wrong with what I said about async? it's a new keyword in ES2017. It's a difficult to use control structure that doesn't do anything you couldn't do with callbacks. What part of "modern programming" do you need Async for?

I don't think I'm brilliant for being able to think through basic functional programming concepts. Actually the opposite... I think you need to be very smart to understand and debug promises, that's why they are bad. I like callbacks because they don't require me to be smart.

Maybe I'm smart for knowing I'm shooting my future self in the foot when I write code that requires smarts, but that's a little convoluted. The reason I care is because the ES6 community sold out beginners by adding all of this syntactic sugar. Javascript used to be a good beginner language.

Maybe you could explain how this is the same thing?

https://babeljs.io/docs/plugins/transform-class-properties/

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

Is better if you care about performance.

The composition is usually in the form of higher order components. It's very simple to wrap a function with another one, with more or different functionality. Classes just make it equally as simple when the wrapped component has its own state to manage.

Point is, nobody really cares whether they're ES6 or createClass, because nobody's actually doing inheritance. It's just that we JS devs like to stay on the bleeding edge, and we like to think that we're converging on standards even if that's a silly dream.

Example: show a spinner for 1 second before displaying.

    const F = (props) => <div>{props.content}</div>;

    class C extends React.Component {
      state = { initial: "state" };
      render = () => <div>{this.state.initial}</div>;
    }

    function delayWithSpinner(WrappedComponent) {
      return class extends React.Component {
        state = { showSpinner: true };
        stop = () {
          this.setState({ showSpinner: false });
        }
        render() {
          return this.state.showSpinner
            ? <Spinner duration={this.props.duration} onCompletion={this.stop}/>
            : <WrappedComponent {...this.props}/>
        }
      }
    }

    // exactly the same composition pattern for
    // both classes and functions.
    const SlowC = delayWithSpinner(C);
    const SlowF = delayWithSpinner(F);

> At Facebook, we use React in thousands of components, and we haven't found any use cases where we would recommend creating component inheritance hierarchies.

[0]: https://facebook.github.io/react/docs/composition-vs-inherit...

You can "autobind" with this notation:

myMethod = () => {

}

but it doesn't look as good as myMethod() {} and you have to remember this EVERY TIME you add a method.

Also, you never need to use the constructor in React. Just do: state = {} in the body of the class. You may need babel presets #918718$$&ééàdi for it to work though.

Think about the reasons jQuery and WordPress were popular, despite performance issues, they JUST WORKED for people. React is the jQuery of vdom projects, don't try to make it the something it is not.

* absolutely no any types or other imprecise types, no files skipped, no lines skipped, etc * every single piece of external data (API requests, reading from localstorage/IndexedDB, etc) is explicitly validated to make sure it exactly conforms to expectations * all dependencies are also typed to the same standard (not just some type definitions slapped on top of an npm module, those could easily be wrong and often are)

Probably some are. But none of mine are, sadly. And I don't think I'm in the minority.

I think the complaints you have are valid but should be solved by js, not react.

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%...

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.

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?

Sure, google.com probably needs to support IE 6. For my own business, I'm not willing to make compromises for browsers below 2%. That currently means Safari 10, Chrome 56, and IE 11. And IE 11 is really stretching it by now–next time it gets in my way, I'll give people a reason to upgrade.

Now I don't have "enterprise" customers, and it's a rather small business. For anything medium-size up, the calculus changes, and probably makes it worthwhile. But at some point, these mystical "enterprises" really have to get their act together and stop dragging technology back to 2006.

But, I'm not arguing that web sites should only serve ES6 to browsers, only that packages should be distributed as ES6 and the app should be responsible for compilation.

IE11, older FF and Chrome, and especially older mobile devices with older Webkit based browser (Android and iOS)

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.

Are you kidding? she/he is talking about IE.

Still though, it's hard to adopt a policy that axes even just 1% of your customer base just for the sake of easier development cycles when alternate options exist.

But how does that apply to Chrome, or React? Is there any indication that Chrome carries more technical debt than, say IE7? Similarly, in what way does Facebook need people to adopt React, and would that matter enough to accept such compromises? Is there any indication that their code quality is inferior to <pick whatever commercial js library you want>?

And if this is the complaint about churn, that, at this time would be older than our js stack if it were true: React came out in 2013, it's four years old. Before that, most people probably used JQuery, which came out in 2006, i. e. 11 years ago. Is learning a new library every five years too much, considering this is one of the most dynamically evolving ecosystems of technology?