Hacker News new | past | comments | ask | show | jobs | submit login

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




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


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.


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.


I'm not sure ember's HTMLBars (the default, a drop-in replacement for handlebars) is any more stringly-typed than JSX.


Humm no, JSX is just a DSL. I much, much prefer virtual DOM over String templates but I also prefer hyperscript over JSX: h('div')


JSX is a macro (it's expended to plain JS at compile time). Almost every other major framework uses DSLs (strings are evaluated and transformed into code at run time).


Yeah, in the beggining there wasn't autobinding, if you remember well. Then comes autobinding, now there's no autobinding anymore.


Yeah I still use `React.createClass({})` because... autobinding.

Also wish someone would explain the draw of ES6 classes. React is about composition, not inheritance. Have never seen a `React.Component` extended.


Basically nobody does this, as far as I know. I think some of the big component authors like Wijmo do, but not most people, it's way too messy.

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);


React themselves say they never use it [0]

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


We have a fairly large react codebase with some components using inheritance. It's not the solution to every problem certainly, but sometimes an abstract base component can be useful.


See my comment downthread regarding intended use of React.Component: https://news.ycombinator.com/item?id=14065106 .


Thanks. I responded there.


ES6 classes are a complete mess brought by corporate people loving OO, even in a setting that doesn't make sense.

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.


Classes and inheritance are features of type systems, not OOP. Plenty of functional programming JS libraries use classes for testing types (for example, the Either monads' Left and Right).


Classes and class inheritance are features of class-based systems, yes.

Prototypes and prototype inheritance are features of prototype based systems.


I've seen one. It is the horror, the horror.


I still think JSX is a bad joke. Luckily React has nothing to do with it.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: