I haven't done front end work for about one year. Looks like I'll be re-learning everything at some point, because this looks like a fairly major change. I'd strongly prefer backwards compatibility over a breaking change.
This change is large enough that’ll be looking at the alternatives after more than two years of defaulting to vue, I mean I may still pick vue but I’ll be looking now where before I wouldn’t have.
Change isn’t a bad thing but nor is change for changes sake.
> Change isn’t a bad thing but nor is change for changes sake.
I can understand that the changes here might not be worth it to some, but to call them "for change's sake" is disingenuous and unfair to the Vue team, I think. The linked page clearly motivates the changes. Whether those motivations weigh strong enough for you is a different matter.
I feel like I'm shilling a bit for React over here, but they are nearing two years without major breaking changes, and has been the de facto framework to go to for quite a while now.
The internal politics at Facebook seem really smart here - the React team have said they’re responsible for keeping all the React code there working and updated when things change with the library. So it’s basically infeasible to make breaking changes that can’t be fixed automatically.
It seems inevitable that hooks will be the only API 3 years from now though, and its already the case that all the new literature and examples are only going to teach hooks. Vue might maintain compatibility just as long but they've totally hosed their messaging on this judging from all the comments in this thread.
Well, I mean, sure; if you're using something now, keep using that. I was mostly responding to the use case of coming to front-end after a year of not doing that. If you're going to "relearn everything", consider React; then that'll hopefully be the last time in the foreseeable future that you'll have to do that.