So, contrary to what spicyj is saying, to me it seems to create the most confusion in the long run at the expense of addressing some short-term concerns ("people already call it React 14"). I'd much prefer they switched to 1.0.
Don’t forget Facebook has a large React codebase so it cares very much about automating migrations.
If React switched to 1.0, with some breaking changes every three months, it would be 14.0 again in a couple of years. Then googling for tutorials would get confusing. Why not do that now?
I like the upgrade paths but can you really say with a straight face that an API is stable if the code you write could be invalid a few months later? That's a maintenance nightmare!
Are you using React? I’m curious if this is your feedback on the pace of changes, or if this is just a guess.
In reality React API surface area is pretty small so most changes are automated by codemods. Codemods are programs that modify your source code. They work pretty well because Facebook uses them on a large scale.
Not everything is covered by codemods but generally the feeling I get from talking to the community is that React moves at an acceptable rate, and changes take about a day to apply once a three months for most apps. Deprecation warnings also give you several months to fix use cases that will be unsupported in the next version.
In return, this allows React to become a better library and not stagnate. I see your point in theory but please talk to the people using React, and you might find that it is not a problem in practice.
Once every 3 months is too frequent. Imagine curl broke compatibility every 3 months and you had to relearn curl. How terrible! I'm pretty sure you'd use something else after a while.
I'm not saying React should be as stable as curl, but it should be striving to become that. The JavaScript community loves to have these eternally evolving libraries that are never actually stable and that's not good for anyone. You should have a long term plan that says "we still don't know what this library should be, but within 2 years we should have it figured out". In reality it feels like JS libs only become stable after they've been abandoned.
Every three months might be too often for a tool like curl. In case of React, the community seems to be happy with the tradeoff between moving forward and keeping the old code working.
You might want to ask a few people who use React to draw the conclusions. I talk to a lot of people in the React ecosystem, and so far the feedback I heard is that updating React has been the least of their worries, compared to some other libraries in the ecosystem which are far less stable.
Personally, I updated a fairly large (~1000 modules) app from React 0.11, to 0.12, to 0.13. After the ecosystem catches up and libraries release compatible updates (if they need to), it always took less than a day to upgrade. Doesn’t seem like a big price to pay for avoiding stagnation and actually improving the library.
And I wasn’t even using codemods which React team ships (and widely uses internally at Facebook). Codemods just convert your code through most of the API changes automatically.
If React 15 was good enough for you when you started using it, it doesn't necessarily fundamentally stop working when React 16 ships.
No, but your project is seldom 100% finished either. So as you do minor changes to it, and want to use some new lib, you find out that it's not compatible with your old version.
And libraries stop get maintained too -- and when you finally try to make the conversion it will be harder the longer you have waited, because aside from porting your code to all new React stuff, you'll also need to find replacement for all those libs at once (not piecemeal, which would be the case if you kept the project up to date faster).
This could also happen for all kinds of external reasons too -- e.g. you use a third party service and they change their API. Or you update your OS and your old libs suddenly stops working. Or a browser deprecates some feature (like Object.observe that Google warns that it will be removed on March).
Yes.
> Every three months might be too often for a tool like curl.
Why should a tool for creating dynamic HTML be held to a lesser standard? I wouldn't expect the level of stability that curl has yet, but I would expect it to be an eventual goal of the project. The reason why we build abstractions is so we can eventually stop worrying about a problem; that can't happen without stability.
> You might want to ask a few people who use React to draw the conclusions. I talk to a lot of people in the React ecosystem, and so far the feedback I heard is that updating React has been the least of their worries, compared to some other libraries in the ecosystem which are far less stable.
That's because you talk to other enthusiasts who are happy about changes. Try asking people outside of the React Slack channel for a wider perspective.
I've had people complain on my projects about upgrading apps using APIs deprecated 2 or 3 years prior. And I feel genuinely bad about it, because if they are having to justify spending 3 or 4 days refactoring their app (which is hard to do in a lot of companies) because I made an API mistake 3 years ago... I feel bad about it. We should strive for better stability.