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?
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
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.
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.
I mean “stable” by “takes 2 hours to update the code once in three months”. Are you building websites or rockets?
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.
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.
And now we're back to the original question, which was "why do you care about an imaginary number?"
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.
With all that said, the responses to my question are very reasonable, such as "people I know and respect have used it and stated sane upgrades historically." In the absence of this piece of tech in my own social circle, SemVer is a convention that Facebook will have to live up to. 6 months to a year after Facebook switches to it, I can research how reasonable they are with introducing breaking changes and supporting old, stable versions. I believe that more people will be vocal about a major breaking change post 1.0 than pre-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).
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.
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.