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.
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