> 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.
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.
>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.
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.
> 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.
>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?
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.
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.
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.
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.
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.
> 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.
I care because it's a convention. Without knowing too much about Angular 2, I know that it's got major breaking changes compared to Angular 1. Likewise, I know that a 1.15.2 should upgrade from a 1.15.1 fairly trivially, whereas a 1.16.0 might take a little more consideration.
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.
>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).
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.
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.
> 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.
>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.
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?
Yes, any library that breaks code written according to documented good practices less than six months earlier only cares a little about compatibility. Everything else you mentioned may be true, but it's also mostly irrelevant.
This isn't necessarily a criticism of the React team. As I mentioned in another post, it's not as if they're advertising more compatibility than this and then not living up to what they claimed. The problem is some people having unrealistic expectations and reading more into the high profile of React than they should.
But mere months between fundamental breaking changes in published interfaces isn't a good level of stability and longevity for most production projects, and for any of those projects that don't have realistic plans and resources available for maintaining the integration regularly, React isn't ready yet.
Most breaking changes are including warnings 2 versions ahead of time... In TFA they outlined, iirc, 2 changes that would have less time than this. This isn't a magical, final interface we're dealing with... it's iterative changes over time.
TBH, I don't like getting stuck at one point.. in practice those using React have been embracing the one-way flow that flux-like frameworks bring... This has been distilled down to Redux (imo, the best workflow option for React), which has signalled some distillation in terms of the interfaces React exposes. This is combined with different rendering paths coming to light, and I think it's pretty great.
I'm currently working in an environment that is transitioning from the old-way, to a more current way of doing things. I've been working with node since pretty early on (0.4) and was following it before that. The more I've embraced this continuously updating workflow, the less friction I've experienced as a whole. That doesn't mean no pain, just less of it overall.
The React/Facebook guys have been very good members in this larger community, and I applaud them for their efforts... Dropping their own render in favor of Babel, and reducing some of their mutation enablers only show them to be working with feedback from the community. It may be at a pace that's harder to keep up with, but that doesn't mean that they shouldn't be doing it.
I think you're misunderstanding React's API surface.
It's about 20 core methods, not a giant lib like jQuery.
From my experience, a medium sized project is adjusted to the changes in about two hours. Once every three months.
It is a big deal any time someone's code works, and then they update a dependency, and then their code doesn't work any more.
Even if the actual code changes required to update the integration are minimal, someone still needs to divert to make those changes and then test everything, which is disruptive at best. Before they can do that, they need to identify what changes are required and perhaps learn how to use any automated updating tools that are available, both of which also take time. If one person on the team wants to upgrade to access some new feature or just get a bug fix, everyone else on the team has to come along, so for example they might start seeing warnings that they'll need to investigate. As I mentioned in another post, there is a nasty hidden cost to breaking the interface of fast-moving but lightly documented libraries, because it will tend to invalidate all the tutorials and example repos and demo videos and so on offered by other contributors or, worse, those resources may become actively misleading.
This is a lesson the web development community will learn in time. Unfortunately today it is a very young part of the industry, obsessed with the appearance of making progress, even though actually web development is almost comically inefficient. The lack of respect for issues like standardisation, compatibility and portability is a major contributing factor in that inefficiency, as is the willingness to build on fragile dependencies in the first place.
Yes, they care. But they care more about their ability to make breaking changes without the stench of a major version bump.
You have to ask, why is it currently not 1.0? The roadmap you linked doesn't mention it. There's a reason. So what is it?
By the way, I know you're a huge React cheerleader and that's fine, and you think I'm being critical of React here and you need to defend this. But I'm not, this is a problem throughout the JavaScript community and really the fault lies there, not with any one particular project which is doing something a lot of others are also doing.
> Only after a 1.0 release. 0.x implies that breaking changes are always possible
Oh, I didn't know that, it's unfortunate. IMO, just bump major version every time compat breaks. Otherwise projects end up mincing around forever trying to decide when the shiny 1.0 ribbon can be affixed.
> IMO, just bump major version every time compat breaks.
Some projects do this but most do not. The reason is that if you're using a project that's on version 3 and 6 months from now it's on version 12 that's going to make you think twice about using it. No one wants to go through upgrade pains constantly.
The "hack" is to never go 1.0 to hide how often you are really breaking APIs.
In reality breaking APIs should be a big freaking deal. You shouldn't do it often. You shouldn't do it just because you realized some other API might be slightly nicer. Once the shine wears off people want stability.
I think pre 1.0 should represent that breaking changes are happening more often.. a 3-month release cycle with breaking changes in pretty much every stable release doesn't bode well in that regard. However, they have been very responsive to the larger community and these additions and changes are really a good thing. Mostly they break out rendering pipelines to support multiple renderers, and they reduce opportunities for mutations, which fly in the face of a flux-like workflow.
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.