Ah, the optimism of youth. Frameworks don't rust if you don't mind sticking with the security bugs of 10-year-old kernels. If you need to upgrade your OS, you need to upgrade your programming languages, which means you need to upgrade your frameworks.
Everything rusts pretty quickly. Maybe you don't need the new features, but you definitely need the new bugfixes.
But to the point you were making - it's not impossible that browsers could evolve to the point where our current version of React is unusable and it's been long relegated to the buzzword graveyard. Of course in that situation we'd have to maintain our own React branch or rewrite in whatever was a popular front-end framework at the time.
My point is that getting stressed out about the front-end JS framework churn isn't helpful to anyone. Pick a stack and stick with it, and only move when it's simply not productive to stay.
What form would the transaction take?
I am low-key building a marketplace for this, because this really should exist. The problem, as a marketplace, is identifying projects both important enough that people will pay for it and aren't* already functionally owned by a company that has a vested interest in their own project management.
(Are you a maintainer who's interested in something like this? Are there projects you would pay for this for? I want to hear from you. com dot edropple at ed)
You always allow people to move forward their subscriptions, but never backwards. You provide migration paths for each supported release.
People will pay for it.
It's a little much to ask from an unpaid open source maintainer, and if you really want it that bad you should be willing to pay for it. Companies like Red Hat have made a living off of people willing to make that tradeoff.
I mean, you could have separate bugfix and feature releases for a relatively low cost, but that would only alleviate the problem for the duration of a release cycle.
In the JS world, there's no mastery. People just keep jumping to newest versions and spend all of their time fighting the new problems. Just. Stop.
The company I work for almost standardized on react/redux. We're not done getting rid of our old stack that people are already looking at Relay Modern, Apollo, MobX, etc. If it wasn't for our investment in a massive home grown React component library, there would probably be VueJS all over the place.
So we lose the ability to help each other. Every team is different, dealing with different problems. We can't build libraries since we don't have a platform to target. That to me makes us much weaker.
So I welcome boring. I welcome the day when people are no longer interested in it so they stop spamming npm to check if a new version of their favorite library is out to upgrade to it when the existing one is working fine.
The frontend framework we use has had six major releases in a year and a half. And I am talking, rip the guts out and change how it works major releases (How semantic versioning is supposed to work).
Like I appreciate that they are doing active development and making it better (because it is getting better, to be honest), but I still feel like you could fix bugs in some minor versions and do like cut major releases to like every six months at least.
I think the irony is that all the freedom I used to see frontend people using is coming back to bite them and their mindset is slowly moving towards what backend people have been doing for a long time.
Right now, if you're in a tech hub and you tell FE people "Sorry, we're standardizing on <thing from last year> and we're gonna hold off on major release upgrades without a good reason", you're gonna lose some people and have trouble hiring or deal with constant internal complains. Why? Because their buddies in <other company across the street> aren't dealing with that restriction.
You need some serious charisma to tell people you're sticking with last year's tech and get away with it. If you're in an environment where you can do that AND still hire fast enough to grow, consider yourself lucky and hope your boss never quits :)
You aren't proving you are resilient to changes by using one of the most current buzz-word filled frameworks out there for two years. The real test happens when your framework of choice truly becomes obsolete, like with what happened to Angular 1.
Perhaps frameworks don't rust in the sense that they deteriorate in terms of capabilities over time. But that doesn't mean that they don't become obsolete. Especially when you're building a product and trying to stay competitive, all the while all the the innovation surrounding a framework has packed up and left for a nicer camp.
The two-way binding/digest nature has really become our enemy. Everything we write has to account for digests and we've wound up with some terribly ugly code to account for digest problems.
Angular 1 is great for hobbyists and it makes implementing simple forms easy but when you use it for an enterprise app, it hurts.
Our app is still vastly better than decade-old 1.0 we've replaced, but we sure hate the digest now.
Good god. You chose Angular 1 two years ago? As in 2015? When its horrific shortcomings were already known and the Angular devs were working on Angular 2.x?
But I agree, I do not think everyone is jumping ship to Vue (or whatever) over the license.
The problem is the marketplace and the companies that will demand the skills when one is job searching.
When we evaluated what tech to migrate to from Angular 1.4, we looked at React and Angular 2. We were also hiring, and the overwhelming majority of devs we spoke to had experience or wanted to work with React.
The marketplace is directed by both buyers and sellers.
We still had to maintain them though as the clients had no money to what would effectively revamp the entire stack to something a lot more maintainable.
Working with a (relatively) unpopular & outdated framework seriously took its toll on both the quality and the developer passion. We had a few really talented people leave simply to avoid working on these projects.
Edit: To echo sixsence's sentiment: Our React & Redux projects have proven themselves to be very resilient over the past few years.
(I personally don't mind working with less popular tech part of time as long as I also work with something that sounds good in CV.)
To be fair, I would put react in the same generation of frameworks as Angular 2 and Vue. It just got to the same basic virtual dom + modular components design earlier than the rest. Vue and Angular 2 don't really offer much besides marginal performance boosts (react fiber, preact etc erase this) and a more familiar way of programming for programmers in the last generation of frameworks angular 1/ember.
At my company we picked a stack and stuck with it. That happened to be React and Redux. I hear Angular 2 and Vue are really great frameworks but I feel under no pressure to really investigate them because we're doing fine as it is.
Two years later and we've barely changed aside from some package versions. We've got a very stable front-end with high code quality and component reuse.
You don't have to listen to the hive-mind. Frameworks don't rust.