7 ms·

> Like always, we have a few breaking changes in this release. We know changes can be painful (the Facebook codebase has over 15,000 React components), so we al

by Touche 11y ago

> Like always, we have a few breaking changes in this release. We know changes can be painful (the Facebook codebase has over 15,000 React components), so we always try to make changes gradually in order to minimize the pain. Since React is a semver project, from the website: > How do I know when to release 1.0.0? > If your software is being used in production, it should probably already be 1.0.0. If you have a stable API on which users have come to depend, you should be 1.0.0. If you're worrying a lot about backwards compatibility, you should probably already be 1.0.0.

drinchev 11y ago
Yes. This bugs me out. It's already so popular and a lot of people use this in production and rely on that. I really hope they do what NodeJS/IO did and figure out that it's far away from any "pre-release" state to keep the version number after two 0s.
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).
draw_down 11y ago
Is it a semver project? Doesn't seem like one, the whole idea is to raise major version when you break compatibility.
- robertfw 11y ago
  Only after a 1.0 release. 0.x implies that breaking changes are always possible My experience has been that the React team provides plenty of advance warning with deprecation notices, similar to the experience of others I've never really been caught out by anything The worst case I've dealt with is bringing an app from .12 to .13 after not touching the code for five or six months. It only took me a few hours to bring everything up to date.
  - Touche 11y ago
    > Only after a 1.0 release. 0.x implies that breaking changes are always possible Yes, which is why so many projects never reach 1.0. There are basically 2 types: 1. Those who don't want to have to care about compatibility at all. 2. Those who care about compatibility a little bit but don't want a large version number. React seems to fall into #2 here. They want a small version number and the perception of stability. But in reality there have been 14 breaking changes, this is version 14 software. It's easier to convince someone to upgrade from 0.13 to 0.14 than it is 1.0 to 2.0 even though breaking changes are just as likely in the former. But the latter has a graver perception.
    - danabramov 11y ago
      >2. Those who care about compatibility a little bit but don't want a large version number. >React seems to fall into #2 here. Seriously, a library that goes out of its way to provide useful deprecation warnings and always keeping deprecated behavior for a version, with versions coming out once in three months, and released with codemods automating the transition for you, cares a little about compatibility? React team will eventually jump to bumping major, and it's a good question to ask, but it's a good question to ask the team instead of guessing what and why they do. https://gist.github.com/zpao/6e12ee0f46ce87af2287#versioning https://gist.github.com/zpao/6e12ee0f46ce87af2287#versioning
shabbyrobe 11y ago
I can't help but feel that maybe Semver made a mistake by including 0.x at all. It's rare that you don't see a bit of software churn through a few breaking versions rapidly while in the early stages of development, many of which happen well after attracting significant public interest and dependence. Semver provides for this already with the major version and for pre-releases with the `-alpha`, `-beta`, `-rc` suffixes, so 0.x in this case seems to provide developers with an out-clause to consider major revisions non-major and put off committing to 1.0 for far too long. This also seems to be at least partially fuelled by a historical aversion to hitting double-digit major versions, although we owe Chrome a debt of gratitude for demonstrating to us that there's little to fear by doing so. Hopefully this approach continues to catch on. Would React's users (and the users of many other extremely popular libraries/tools doing the same 0.x dance) have been better served by declaring a 1.0 version much, much earlier in the development process? I think so.

by Touche 11y ago

drinchev 11y ago

Yes. This bugs me out. It's already so popular and a lot of people use this in production and rely on that. I really hope they do what NodeJS/IO did and figure out that it's far away from any "pre-release" state to keep the version number after two 0s.

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

draw_down 11y ago

Is it a semver project? Doesn't seem like one, the whole idea is to raise major version when you break compatibility.

robertfw 11y ago
Only after a 1.0 release. 0.x implies that breaking changes are always possible My experience has been that the React team provides plenty of advance warning with deprecation notices, similar to the experience of others I've never really been caught out by anything The worst case I've dealt with is bringing an app from .12 to .13 after not touching the code for five or six months. It only took me a few hours to bring everything up to date.
- Touche 11y ago
  > Only after a 1.0 release. 0.x implies that breaking changes are always possible Yes, which is why so many projects never reach 1.0. There are basically 2 types: 1. Those who don't want to have to care about compatibility at all. 2. Those who care about compatibility a little bit but don't want a large version number. React seems to fall into #2 here. They want a small version number and the perception of stability. But in reality there have been 14 breaking changes, this is version 14 software. It's easier to convince someone to upgrade from 0.13 to 0.14 than it is 1.0 to 2.0 even though breaking changes are just as likely in the former. But the latter has a graver perception.
  - danabramov 11y ago
    >2. Those who care about compatibility a little bit but don't want a large version number. >React seems to fall into #2 here. Seriously, a library that goes out of its way to provide useful deprecation warnings and always keeping deprecated behavior for a version, with versions coming out once in three months, and released with codemods automating the transition for you, cares a little about compatibility? React team will eventually jump to bumping major, and it's a good question to ask, but it's a good question to ask the team instead of guessing what and why they do. https://gist.github.com/zpao/6e12ee0f46ce87af2287#versioning https://gist.github.com/zpao/6e12ee0f46ce87af2287#versioning

shabbyrobe 11y ago

I can't help but feel that maybe Semver made a mistake by including 0.x at all. It's rare that you don't see a bit of software churn through a few breaking versions rapidly while in the early stages of development, many of which happen well after attracting significant public interest and dependence. Semver provides for this already with the major version and for pre-releases with the `-alpha`, `-beta`, `-rc` suffixes, so 0.x in this case seems to provide developers with an out-clause to consider major revisions non-major and put off committing to 1.0 for far too long. This also seems to be at least partially fuelled by a historical aversion to hitting double-digit major versions, although we owe Chrome a debt of gratitude for demonstrating to us that there's little to fear by doing so. Hopefully this approach continues to catch on. Would React's users (and the users of many other extremely popular libraries/tools doing the same 0.x dance) have been better served by declaring a 1.0 version much, much earlier in the development process? I think so.