You don't need to rewrite any code if you don't want to - the new syntax is additive, and the old syntax will remain valid throughout Vue 3.0 and as long as it is still widely used. Even if it eventually gets removed from the Core code, plugins could easily allow the old syntax to be still 100% valid.
I'm traditionally a React developer but have been dabbling more and more with Vue lately and have really liked it. Also I want to emphasize that I am commenting in good faith and am very supportive of the Vue community. I do have a comment about the above point:
When a framework moves towards a new API, you have to also consider the ecosystem around it (stackoverflow q & a, github issues, open source plugins, tutorials, documentation etc..). Saying that people can use the old syntax with plugins does not really make a lot of sense considering this will cause fragmentation. I think what this new API would possibly do is similar to what happened with Angular (I am a former Angular developer who moved to React after 1.5 to 2.0 debacle).
When searching for documentation and information, it will become hard for people to discern between the versions and be especially hurtful for newcomers. For a change like this, would it ever make sense to instead introduce a new framework and continue to support both for the long term? Maybe this new API could continue to evolve into something even more sophisticated if it was branded as a new project and the people who enjoy the existing Vue APIs could also continue using Vue as they have in the past.
The benefits in my mind would be:
The existing API continues to be supported and improved. The projects using it continue to be stable and resources surrounding it continue to be valid.
The new framework / project could be even more innovative & completely breaking changes could be introduced right out of the gate without any negative outcome.
Overall, the new API looks like a net positive and an improvement and the Vue team is doing a great job. This feedback is more centered around how people will find and utilize resources efficiently for the new API.
Either way, I know this is still just an RFC and nothing set in stone, just my 2 cents.
One of the most important beneficiaries of the function API are the library authors. They can take advantage of the new composition pattern in so many ways.
Going with a new framework would force them to write two versions of their libraries - the easier to maintain for new framework and much more tricky for the old one.
With the current approach, they can just use the function API to write their libraries and expose them to users of object, function or class API without any issues.
This is my biggest worry. I'm about to start learning Vue, so I don't really even understand most of what people are posting about, but I do understand that people are saying this is going to make everything we've learned get changed, so now I'm hesitant to even start. 😔
Web Developer currently experienced in JavaScript, React, Node.js but interested to learn multiple technologies and not stick to dead ones.
Specialization- Building high performance SPAs.
All the post ES6 work is being done in their new framework Koa.
Though I think adaption of Koa is still lower than Express because Express just works. Same can happen with Vue.
Just wanted to share my thoughts. There are advantages and disadvantages of all the approaches (even Angular's approach). I trust the Vue team will do their best as long as the community give constructive feedback.
I'm afraid introducing a new framework and supporting both for the long term won't work. Angular has proven that. Now all the dudes who remained in the boat of angularJS have no captain and they will inevitably have to move to Angular or another framework. Soon or later the users of vue2.x will have to face again the same issue. This will just delay it....
Thoughtful post, but please please please no not a new framework! That would really mean fragmentation and the death of Vue, look at what happened with Angular (Angular isn't completely dead but it's being surpassed left and right by React and Vue).
Instead it's fine with me if the 'old' and 'new' syntax coexist for a long time to come, and people gradually adopt the new style how and when they want. This gradual adoption also means that the ecosystem and community can slowly adapt/evolve/migrate and the "old style" knowledge (SO and so on) does't become obsolete overnight (as was the case with Angular 1).
We shouldn't dramatize these changes - compare it to React, obviously the new proposal reminds me a lot of React Hooks. In the React world you see that new styles/APIs are being proposed and adopted without a lot of drama, why couldn't it be the same in the Vue world?
This new proposal does not mandate a "new Vue framework", please let's stay far from that.
I think what this new API would possibly do is similar to what happened with Angular (I am a former Angular developer who moved to React after 1.5 to 2.0 debacle).
This API change is much more like what happened to React when they deprecated React.createClass() or introduced hooks. Why are these changes not called a debacle?
I think Vue has been attracting a lot of people new to front-end/js development, that see Vue as the anti-React. They find react hard, has too much boilerplate, and too much facebook, or some mixture of these. So any movement towards anything react-like is met with loud reverberations in their misinformed echo-chambers.
It's not like Vue 2 is not going to be available as soon as Vue 4 is out.
For a change like this, would it ever make sense to instead introduce a new framework and continue to support both for the long term?
I can already see the toches and pitforks from people coming for us, proclaiming how we completely abandon current Vue in order to write a new hipster framework.
Thanks for your well thought-out comment Nader! Agree that considering the ecosystem is very important, and there are lessons to learn from Angular. The switch from Angular JS to Angular was almost a new framework with the same name - upgrading was a nightmare and typically involved having to rewrite a lot of code, and required you to have to basically learn a new framework. I don't think this proposal is anything like that, given that it doesn't break any existing code and it isn't a proposal for a different framework - just like Vue 2.X you have components that can have props, state, properties computed off that state, watchers and methods and these can be bound to templates. For beginners, designing a Vue component is the same - you need to work out what will be the component's props and data, what needs to be computed off these, and what methods are needed to respond to events. Template bindings will work the same and follow Vue 2.X's syntax. Only difference is a different (and improved) way of writing these options that opens up more possibilities. I think understanding the basic concepts is more important than the syntax, and these don't change.
Agree that there may be some initial pain as the ecosystem switches over, but I don't think it will be too bad. For a time some resources using a setup() function may need to include a disclaimer that this is only valid in Vue 3.X, and some beginners might still come across tutorials that use the object syntax - but it'll still work, and will still teach them the fundamental concepts involved in thinking about and building Vue components, which don't change in the new API.
I think your comments apply equally to React Hooks, but the React team has done a fantastic job explaining the new API, particularly emphasising that like the Vue proposal it is purely additive and does not break anything. At the moment there might be a bit of pain for beginners given that there is a mixture of tutorials and documentation around the internet that use or don't use hooks. But I hope you'd agree that the benefits outweigh this initial pain.
I can see Nader's point. Beginners might find answers to their questions in places like Stack Overflow where older answers use the current API, and newer answers might use the new API.
Even worse, they might get answers to their own questions, asked with e.g. the new syntax, and someone in favor of the current syntax will reply in that style.
Meaning: In order to make full use of the resources available online, Newcomers have to learn both approaches, and learn to differentiate between them.
That could of course be a pain in the ass.
But I also agree that it wouldn't be as painful as AngluarJS -> Angular since most examples would at least be translatable 1:1 from one version to the other, as we still have the same lifecycle methods, computed etc, just written differently, whereas Angular completely replaces the core logic of what a component is and does.
Bumping into answers written in multiple syntax styles is difficult enough as it is without throwing different versions of the API into the mix, but these problems are an unavoidable consequence of growth, and perhaps something StackOverflow should look to mitigate against rather than having it make developers too tentative.
It should be possible for StackOverflow to do API inferences based on the tags, titles, and the code samples — but this is a tangential consideration.
Clearly this person did not write projects using vue-property-decorator, where everything is a class. Those of us that wrote using class based components have now been neglected and left in the dark to fend for ourselves. No longer recommending Vue to anyone if this is how they treat their developers.
LongLiveSvelte
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I'm traditionally a React developer but have been dabbling more and more with Vue lately and have really liked it. Also I want to emphasize that I am commenting in good faith and am very supportive of the Vue community. I do have a comment about the above point:
When a framework moves towards a new API, you have to also consider the ecosystem around it (stackoverflow q & a, github issues, open source plugins, tutorials, documentation etc..). Saying that people can use the old syntax with plugins does not really make a lot of sense considering this will cause fragmentation. I think what this new API would possibly do is similar to what happened with Angular (I am a former Angular developer who moved to React after 1.5 to 2.0 debacle).
When searching for documentation and information, it will become hard for people to discern between the versions and be especially hurtful for newcomers. For a change like this, would it ever make sense to instead introduce a new framework and continue to support both for the long term? Maybe this new API could continue to evolve into something even more sophisticated if it was branded as a new project and the people who enjoy the existing Vue APIs could also continue using Vue as they have in the past.
The benefits in my mind would be:
Overall, the new API looks like a net positive and an improvement and the Vue team is doing a great job. This feedback is more centered around how people will find and utilize resources efficiently for the new API.
Either way, I know this is still just an RFC and nothing set in stone, just my 2 cents.
I even got a name - Nue /njuː/
Thanks for sharing the idea! :)
One of the most important beneficiaries of the function API are the library authors. They can take advantage of the new composition pattern in so many ways.
Going with a new framework would force them to write two versions of their libraries - the easier to maintain for new framework and much more tricky for the old one.
With the current approach, they can just use the function API to write their libraries and expose them to users of object, function or class API without any issues.
This is my biggest worry. I'm about to start learning Vue, so I don't really even understand most of what people are posting about, but I do understand that people are saying this is going to make everything we've learned get changed, so now I'm hesitant to even start. 😔
It's much ado about nothing. Start learning and building now, all things change over time (js, frameworks, life).
This is done by the express framework team.
The express framework API won't change.
All the post ES6 work is being done in their new framework Koa.
Though I think adaption of Koa is still lower than Express because Express just works. Same can happen with Vue.
Just wanted to share my thoughts. There are advantages and disadvantages of all the approaches (even Angular's approach). I trust the Vue team will do their best as long as the community give constructive feedback.
I'm afraid introducing a new framework and supporting both for the long term won't work. Angular has proven that. Now all the dudes who remained in the boat of angularJS have no captain and they will inevitably have to move to Angular or another framework. Soon or later the users of vue2.x will have to face again the same issue. This will just delay it....
Thoughtful post, but please please please no not a new framework! That would really mean fragmentation and the death of Vue, look at what happened with Angular (Angular isn't completely dead but it's being surpassed left and right by React and Vue).
Instead it's fine with me if the 'old' and 'new' syntax coexist for a long time to come, and people gradually adopt the new style how and when they want. This gradual adoption also means that the ecosystem and community can slowly adapt/evolve/migrate and the "old style" knowledge (SO and so on) does't become obsolete overnight (as was the case with Angular 1).
We shouldn't dramatize these changes - compare it to React, obviously the new proposal reminds me a lot of React Hooks. In the React world you see that new styles/APIs are being proposed and adopted without a lot of drama, why couldn't it be the same in the Vue world?
This new proposal does not mandate a "new Vue framework", please let's stay far from that.
This API change is much more like what happened to React when they deprecated React.createClass() or introduced hooks. Why are these changes not called a debacle?
I think Vue has been attracting a lot of people new to front-end/js development, that see Vue as the anti-React. They find react hard, has too much boilerplate, and too much facebook, or some mixture of these. So any movement towards anything react-like is met with loud reverberations in their misinformed echo-chambers.
It's not like Vue 2 is not going to be available as soon as Vue 4 is out.
I can already see the toches and pitforks from people coming for us, proclaiming how we completely abandon current Vue in order to write a new hipster framework.
And I'm only half joking.
Thanks for your well thought-out comment Nader! Agree that considering the ecosystem is very important, and there are lessons to learn from Angular. The switch from Angular JS to Angular was almost a new framework with the same name - upgrading was a nightmare and typically involved having to rewrite a lot of code, and required you to have to basically learn a new framework. I don't think this proposal is anything like that, given that it doesn't break any existing code and it isn't a proposal for a different framework - just like Vue 2.X you have components that can have props, state, properties computed off that state, watchers and methods and these can be bound to templates. For beginners, designing a Vue component is the same - you need to work out what will be the component's props and data, what needs to be computed off these, and what methods are needed to respond to events. Template bindings will work the same and follow Vue 2.X's syntax. Only difference is a different (and improved) way of writing these options that opens up more possibilities. I think understanding the basic concepts is more important than the syntax, and these don't change.
Agree that there may be some initial pain as the ecosystem switches over, but I don't think it will be too bad. For a time some resources using a setup() function may need to include a disclaimer that this is only valid in Vue 3.X, and some beginners might still come across tutorials that use the object syntax - but it'll still work, and will still teach them the fundamental concepts involved in thinking about and building Vue components, which don't change in the new API.
I think your comments apply equally to React Hooks, but the React team has done a fantastic job explaining the new API, particularly emphasising that like the Vue proposal it is purely additive and does not break anything. At the moment there might be a bit of pain for beginners given that there is a mixture of tutorials and documentation around the internet that use or don't use hooks. But I hope you'd agree that the benefits outweigh this initial pain.
I can see Nader's point. Beginners might find answers to their questions in places like Stack Overflow where older answers use the current API, and newer answers might use the new API.
Even worse, they might get answers to their own questions, asked with e.g. the new syntax, and someone in favor of the current syntax will reply in that style.
Meaning: In order to make full use of the resources available online, Newcomers have to learn both approaches, and learn to differentiate between them.
That could of course be a pain in the ass.
But I also agree that it wouldn't be as painful as AngluarJS -> Angular since most examples would at least be translatable 1:1 from one version to the other, as we still have the same lifecycle methods, computed etc, just written differently, whereas Angular completely replaces the core logic of what a component is and does.
Bumping into answers written in multiple syntax styles is difficult enough as it is without throwing different versions of the API into the mix, but these problems are an unavoidable consequence of growth, and perhaps something StackOverflow should look to mitigate against rather than having it make developers too tentative.
It should be possible for StackOverflow to do API inferences based on the tags, titles, and the code samples — but this is a tangential consideration.
Clearly this person did not write projects using vue-property-decorator, where everything is a class. Those of us that wrote using class based components have now been neglected and left in the dark to fend for ourselves. No longer recommending Vue to anyone if this is how they treat their developers.
LongLiveSvelte