5 ms·

I came in here to comment on this. React sounds exciting from what I've read about it, but I didn't realize it was pre-1.0. To teams who are using it in produ

by eric-hu 11y ago

I came in here to comment on this. React sounds exciting from what I've read about it, but I didn't realize it was pre-1.0. To teams who are using it in production, did you talk about this? What are arguments for using it despite it not being 1.0?

epmatsw 11y ago
We're migrating from Backbone to React, and it's been lovely. Our main argument is essentially what the grandparent said: based on the policies React has been following, it basically behaves like a 1.0 release. There's clear deprecation warnings and announcements, and those are caught by our test suite. The only backwards-incompatible changes that have happened since we started using it earlier this year have been mostly painless Ctrl+F fixes, and even the bigger ones (ReactDOM, etc.) have not been too much of a problem. And from a logical perspective, if it's stable enough for Facebook (Alexa #2) to use for production, it's stable enough for a smallish HR software company.
- ry_ry 11y ago
  Tangenital, but I think backbone still has a place post react. React fills the void between web components and app flow, but it's not the whole story - it still confabulates data structure and function - whereas backbone handles views at a more abstract level. An html input that does something cool is basically what web components are intended for. A module composed of several of these micro components is where react is beautifully elegant, whilst something like backbone deals entirely in spreading of concerns presented via object literals with benefits. Backbone may not necessarily be the solution to the problem but it operates in a similar space to flux, such as it is, rather than react.
  - epmatsw 11y ago
    We've had good luck embedding React components inside of Backbone views. The downside is that you can't really go the opposite way (embed a small pre-existing Backbone view inside of a React component), at least without risking some weird behaviors.
drinchev 11y ago
There's something wrong these days with version argumentations and reasoning. TypeScript is version 1.6, which was released when Node was 0.12 and includes React 0.13 support of JSX files. So I'm not sure anyone puts a reason behind version numbers anymore.
williamcotton 11y ago
What's in a name? That which we call a rose by any other name would smell as sweet.
- Silhouette 11y ago
  That which we call a rose by any other name would smell as sweet. Perhaps it would, if that other name had been chosen from the start. However, in this case, many projects will have existing code using the earlier conventions. Moreover, there is a substantial volume of documentation and tutorial blog posts and conference videos and example code repos using those older conventions, all of which has just been invalidated. This isn't just a loss, it is all now actively harmful to new developers adopting React or those trying to update to a newer version, because it's actually misleading. If a library you're thinking of using in production is as willing to break API compatibility as React is, even if the changes are mostly announced a little way in advance, you should think long and hard about the overheads and instability you're going to incur with a dependency on that library before you adopt it. Move fast and break stuff might work if you're Facebook and thus have both final control over the library in question and effectively unlimited resources to maintain your code base, but it doesn't work very well for the 99.999% of web development projects that don't have those resources available. To be fair, the React project itself seems to be quite transparent about its development methods. It's not as if they're advertising the library as stable -- it's still clearly shown as a 0.x version, for example. However, a lot of people are jumping on the bandwagon anyway and just hoping for the best, and that's probably not a good idea. From an API point of view, all of that is what's in a name.
masterj 11y ago
Why do you care about an imaginary number? FB (and many other large companies) heavily use this in production, and have to migrate their own apps. FB even goes farther and uses the master branch (well, synced every week or so). That's a far heavier endorsement than whatever side of a decimal a number falls on.
- Touche 11y ago
  > Why do you care about an imaginary number? It's not imaginary, it represents stability. By not going 1.0 you are saying it is alpha software and should not be used. Not everyone has Facebook's budget or resources to upgrade every 2 months.
  - danabramov 11y ago
    React upgrade path is stabler and smoother than 90% of >1.0 libraries I have seen. Please don't jump to conclusions. ;-)
    - quarterto 11y ago
      It's about the perception that the number provides.
      - danabramov 11y ago
        Fixing this is on the roadmap: https://gist.github.com/zpao/6e12ee0f46ce87af2287#versioning https://gist.github.com/zpao/6e12ee0f46ce87af2287#versioning
      - untog 11y ago
        > It's about the perception that the number provides. And now we're back to the original question, which was "why do you care about an imaginary number?"
  - masterj 11y ago
    > Not everyone has Facebook's budget or resources to upgrade every 2 months. Even if you're FB, dedicating the engineering time to upgrading/testing/deploying 15k+ components by making a breaking change would be madness. Anecdotally, when the React team breaks something (rare) a lot of people internally start yelling, and it never makes it into the releases. FB makes for one-hell of an integration test environment.
danabramov 11y ago
>To teams who are using it in production, did you talk about this? What are arguments for using it despite it not being 1.0? That it's stabler than most 1.0+ libraries is a good argument. Facebook uses React at massive scale, so they're very careful with changes, go out of their way to keep deprecated behavior for at least a version (and a version takes a few months), provide codemods for changes that can be automated, provide useful warnings, run React master in FB production, and catch many issues in internal FB-specific tests before they even reach the React master. This is as stable as you can get without stagnating the platform. The only problem with React being pre-1.0 is the impression that it isn't stable, which couldn't be further from truth. That said they plan to address this perception eventually: https://gist.github.com/zpao/6e12ee0f46ce87af2287#versioning https://gist.github.com/zpao/6e12ee0f46ce87af2287#versioning PS Yeah it's a bit frustrating React doesn't bump majors and bumps 0.x minors instead and yes semver says “production better be 1.x” but realistically I choose real stability over “fully adhering to semver production-is-above-zero doctrine” any day, and stability is what React releases deliver. As long as NPM understands what breaking changes are (and caret gives the intended meaning for 0.x), I don't really care which number as bumped, as long as the migration is relatively painless, and the platform moves into the right direction.
- Touche 11y ago
  > That it's stabler than most 1.0+ libraries is a good argument. What exactly do you mean by stability here? A 1.0 library (according to semver) is not allowed to break compatibility unless they bump to 2.0. Pre 1.0 version 0.14 is equivalent to version 14 if it had been 1.0. That's 14 breaking change in about 2 years. Or 7 a year. That's a lot. That's not stable.
  - spicyj 11y ago
    (To be fair, the initial release was 0.3 and we skipped over 0.6 and 0.7. http://facebook.github.io/react/blog/2013/12/19/react-v0.8.0.html http://facebook.github.io/react/blog/2013/12/19/react-v0.8.0...)
  - Bahamut 11y ago
    I'm guessing here, but I'd fathom that "stabler" means that it has less severe bugs than most libraries, but is true given the number of eyes on it and its popular following.
coldtea 11y ago
>To teams who are using it in production, did you talk about this? What are arguments for using it despite it not being 1.0? The main argument is that "1.0" is an arbitrary number (semvers or not). There are hellish unstable and buggy projects on version 4.x and stable, production-proven projects on 0.x. Not to mention projects that when going from 2.x to 3.x or so, decide to just rewrite everything with new APIs and incompatible changes (of course semver allows this, but as it's also often accompanied by core devs abandoning the 2.x version, you're left with either an EOLed codebase or a breaking-changes rewrite).

by eric-hu 11y ago

epmatsw 11y ago

We're migrating from Backbone to React, and it's been lovely. Our main argument is essentially what the grandparent said: based on the policies React has been following, it basically behaves like a 1.0 release. There's clear deprecation warnings and announcements, and those are caught by our test suite. The only backwards-incompatible changes that have happened since we started using it earlier this year have been mostly painless Ctrl+F fixes, and even the bigger ones (ReactDOM, etc.) have not been too much of a problem. And from a logical perspective, if it's stable enough for Facebook (Alexa #2) to use for production, it's stable enough for a smallish HR software company.

ry_ry 11y ago
Tangenital, but I think backbone still has a place post react. React fills the void between web components and app flow, but it's not the whole story - it still confabulates data structure and function - whereas backbone handles views at a more abstract level. An html input that does something cool is basically what web components are intended for. A module composed of several of these micro components is where react is beautifully elegant, whilst something like backbone deals entirely in spreading of concerns presented via object literals with benefits. Backbone may not necessarily be the solution to the problem but it operates in a similar space to flux, such as it is, rather than react.
- epmatsw 11y ago
  We've had good luck embedding React components inside of Backbone views. The downside is that you can't really go the opposite way (embed a small pre-existing Backbone view inside of a React component), at least without risking some weird behaviors.

drinchev 11y ago

There's something wrong these days with version argumentations and reasoning. TypeScript is version 1.6, which was released when Node was 0.12 and includes React 0.13 support of JSX files. So I'm not sure anyone puts a reason behind version numbers anymore.

williamcotton 11y ago

What's in a name? That which we call a rose by any other name would smell as sweet.

Silhouette 11y ago
That which we call a rose by any other name would smell as sweet. Perhaps it would, if that other name had been chosen from the start. However, in this case, many projects will have existing code using the earlier conventions. Moreover, there is a substantial volume of documentation and tutorial blog posts and conference videos and example code repos using those older conventions, all of which has just been invalidated. This isn't just a loss, it is all now actively harmful to new developers adopting React or those trying to update to a newer version, because it's actually misleading. If a library you're thinking of using in production is as willing to break API compatibility as React is, even if the changes are mostly announced a little way in advance, you should think long and hard about the overheads and instability you're going to incur with a dependency on that library before you adopt it. Move fast and break stuff might work if you're Facebook and thus have both final control over the library in question and effectively unlimited resources to maintain your code base, but it doesn't work very well for the 99.999% of web development projects that don't have those resources available. To be fair, the React project itself seems to be quite transparent about its development methods. It's not as if they're advertising the library as stable -- it's still clearly shown as a 0.x version, for example. However, a lot of people are jumping on the bandwagon anyway and just hoping for the best, and that's probably not a good idea. From an API point of view, all of that is what's in a name.

masterj 11y ago

Why do you care about an imaginary number? FB (and many other large companies) heavily use this in production, and have to migrate their own apps. FB even goes farther and uses the master branch (well, synced every week or so). That's a far heavier endorsement than whatever side of a decimal a number falls on.

Touche 11y ago
> Why do you care about an imaginary number? It's not imaginary, it represents stability. By not going 1.0 you are saying it is alpha software and should not be used. Not everyone has Facebook's budget or resources to upgrade every 2 months.
- danabramov 11y ago
  React upgrade path is stabler and smoother than 90% of >1.0 libraries I have seen. Please don't jump to conclusions. ;-)
  - quarterto 11y ago
    It's about the perception that the number provides.
    - danabramov 11y ago
      Fixing this is on the roadmap: https://gist.github.com/zpao/6e12ee0f46ce87af2287#versioning https://gist.github.com/zpao/6e12ee0f46ce87af2287#versioning
    - untog 11y ago
      > It's about the perception that the number provides. And now we're back to the original question, which was "why do you care about an imaginary number?"
- masterj 11y ago
  > Not everyone has Facebook's budget or resources to upgrade every 2 months. Even if you're FB, dedicating the engineering time to upgrading/testing/deploying 15k+ components by making a breaking change would be madness. Anecdotally, when the React team breaks something (rare) a lot of people internally start yelling, and it never makes it into the releases. FB makes for one-hell of an integration test environment.

danabramov 11y ago

>To teams who are using it in production, did you talk about this? What are arguments for using it despite it not being 1.0? That it's stabler than most 1.0+ libraries is a good argument. Facebook uses React at massive scale, so they're very careful with changes, go out of their way to keep deprecated behavior for at least a version (and a version takes a few months), provide codemods for changes that can be automated, provide useful warnings, run React master in FB production, and catch many issues in internal FB-specific tests before they even reach the React master. This is as stable as you can get without stagnating the platform. The only problem with React being pre-1.0 is the impression that it isn't stable, which couldn't be further from truth. That said they plan to address this perception eventually: https://gist.github.com/zpao/6e12ee0f46ce87af2287#versioning https://gist.github.com/zpao/6e12ee0f46ce87af2287#versioning PS Yeah it's a bit frustrating React doesn't bump majors and bumps 0.x minors instead and yes semver says “production better be 1.x” but realistically I choose real stability over “fully adhering to semver production-is-above-zero doctrine” any day, and stability is what React releases deliver. As long as NPM understands what breaking changes are (and caret gives the intended meaning for 0.x), I don't really care which number as bumped, as long as the migration is relatively painless, and the platform moves into the right direction.

Touche 11y ago
> That it's stabler than most 1.0+ libraries is a good argument. What exactly do you mean by stability here? A 1.0 library (according to semver) is not allowed to break compatibility unless they bump to 2.0. Pre 1.0 version 0.14 is equivalent to version 14 if it had been 1.0. That's 14 breaking change in about 2 years. Or 7 a year. That's a lot. That's not stable.
- spicyj 11y ago
  (To be fair, the initial release was 0.3 and we skipped over 0.6 and 0.7. http://facebook.github.io/react/blog/2013/12/19/react-v0.8.0.html http://facebook.github.io/react/blog/2013/12/19/react-v0.8.0...)
- Bahamut 11y ago
  I'm guessing here, but I'd fathom that "stabler" means that it has less severe bugs than most libraries, but is true given the number of eyes on it and its popular following.

coldtea 11y ago

>To teams who are using it in production, did you talk about this? What are arguments for using it despite it not being 1.0? The main argument is that "1.0" is an arbitrary number (semvers or not). There are hellish unstable and buggy projects on version 4.x and stable, production-proven projects on 0.x. Not to mention projects that when going from 2.x to 3.x or so, decide to just rewrite everything with new APIs and incompatible changes (of course semver allows this, but as it's also often accompanied by core devs abandoning the 2.x version, you're left with either an EOLed codebase or a breaking-changes rewrite).