I can certainly understand why the Vue team is heading in this direction (some of what you propose will make it easier to write less code and have that code be easier to follow), you're substituting one complexity for another. While yes you will be able to group named attributes together so that they flow logically, you're distributing functionality all over a component making THAT part harder to read.
As many others have said, knowing that all my computed properties are in one place (for example) is a good thing. It's easy to read and it's fast to find the computed, watch, etc. components because they are in the same place - grouped by framework functionality. That's one thing that I really enjoy about Vue. Where the break occurs is not so much in that area with respect to collecting things together - its that the data section is declaring one type of functionality (standard vars) and the others are declaring vars that have a behavior. That part in the current syntax is less than elegant and this seems to address it in a way - though have to const everything and return the variable list seems less DRY when in that syntax.
Will the world end if you make this change - no, but it starts to look a whole lot like the frameworks we didn't choose because we liked the simplicity that came from Vue's syntax. Large bodies of React code can be a nightmare to work through because React doesn't require adherence to any spec - and what you're doing here can lead to the same. It will likely end up littered all over the place as it ends up in larger React projects.
Quite frankly if I wanted heavy TypeScript support - I would have just stayed playing with Angular. If I wanted to have React Hooks - I would be using React. Vue will run the risk of losing the thing that makes people like Vue as opposed to the other frameworks, and the benefit is negligible IMO. Don't write it off as people being afraid of change - but moreso people having made an intentional choice in framework for very specific reason.
That said, I would MUCH prefer a @props based approach if you're going to shake up the syntax. Going with classes and annotations is very readable and tends to be organized given the way a traditional developer writes code.
"Quite frankly if I wanted heavy TypeScript support - I would have just stayed playing with Angular. If I wanted to have React Hooks - I would be using React. Vue will run the risk of losing the thing that makes people like Vue as opposed to the other frameworks"
I can certainly understand why the Vue team is heading in this direction (some of what you propose will make it easier to write less code and have that code be easier to follow), you're substituting one complexity for another. While yes you will be able to group named attributes together so that they flow logically, you're distributing functionality all over a component making THAT part harder to read.
As many others have said, knowing that all my computed properties are in one place (for example) is a good thing. It's easy to read and it's fast to find the computed, watch, etc. components because they are in the same place - grouped by framework functionality. That's one thing that I really enjoy about Vue. Where the break occurs is not so much in that area with respect to collecting things together - its that the data section is declaring one type of functionality (standard vars) and the others are declaring vars that have a behavior. That part in the current syntax is less than elegant and this seems to address it in a way - though have to const everything and return the variable list seems less DRY when in that syntax.
Will the world end if you make this change - no, but it starts to look a whole lot like the frameworks we didn't choose because we liked the simplicity that came from Vue's syntax. Large bodies of React code can be a nightmare to work through because React doesn't require adherence to any spec - and what you're doing here can lead to the same. It will likely end up littered all over the place as it ends up in larger React projects.
Quite frankly if I wanted heavy TypeScript support - I would have just stayed playing with Angular. If I wanted to have React Hooks - I would be using React. Vue will run the risk of losing the thing that makes people like Vue as opposed to the other frameworks, and the benefit is negligible IMO. Don't write it off as people being afraid of change - but moreso people having made an intentional choice in framework for very specific reason.
That said, I would MUCH prefer a @props based approach if you're going to shake up the syntax. Going with classes and annotations is very readable and tends to be organized given the way a traditional developer writes code.
Exactly. It seems less DRY and less KISS
You are absolutely correct, you just read my mind.
This new syntax is looking so much like React IMO
"Quite frankly if I wanted heavy TypeScript support - I would have just stayed playing with Angular. If I wanted to have React Hooks - I would be using React. Vue will run the risk of losing the thing that makes people like Vue as opposed to the other frameworks"
Totally agree!
You're right about what I mean "It's easy to read and it's fast to find the computed, watch, etc."