I'm a selftaught (web) developer. On sunny days, you can find me hiking through the Teutoburg Forest, on rainy days coding or with a good fiction novel in hand.
What you say is somewhat true. Then again, you can keep writing Vue as before. There'll just be another way of doing it.
I only really grasped the usability of Vue's composition API after starting to learn React Hooks (took me a while, as I highly prefer Vue). If you find the composition fucntions to be a soup - they are, but so is a huge component that uses the options API. Imagine a single file that at some point was meant to do a single thing grow to around 600 lines of code, you might consider moving some code out of it. double that amount and you end up with an unmaintainble mess.
Also, consider state. Composition API permits you to relatively simply create a data provider without using third party packages. Especially (async) actions are candidates to be reused in several components.
Wrapping up, for small projects, you're probably well set to develop Vue apps like before. Frankly speaking, I highly prefer the 'common' way, but would not want to close my eyes in front of new innovations, even if they look alien at first.
Another way of doing it means a total mess in documentation and third party code.
Vue 3 already created a havoc in Vue packages, things are just not compatible. Still even now I start all new projects on Vue 2 and Nuxt 2, cause Nuxt 3 is not production ready. Nuxt 3 had 100 times less downloads, means everyone just sticks to Nuxt 2.
If you find a component with 600 lines of code it just means that it has to be split into smaller components, I had quite large projects and never had to write any large component, everything can be split to smaller components and this makes more sense.
To each their own, I mean it's opinions. I've written a few serious apps with React and some quite complex with vue2, I would use vue2 anytime. If you never had "complex" behaviour become a mess of useEffects, contextProviders and friends, that's ok. I use functional languages for everything else, and to be honest, describing UI's in the browser - given the html/dom model and the existing browser apis - is probably one of the few things I think an object oriented wrapper has benefits. I want hooks for the lifecycle, I want to specify reactive data, methods and data that is reactive but also reacts to any of its automatically tracked dependencies (computed properties). For me that organisation makes sense, the same way single file components make sense even if you extract things out of them to "clean up", but that's just my point of view.
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.
What you say is somewhat true. Then again, you can keep writing Vue as before. There'll just be another way of doing it.
I only really grasped the usability of Vue's composition API after starting to learn React Hooks (took me a while, as I highly prefer Vue). If you find the composition fucntions to be a soup - they are, but so is a huge component that uses the options API. Imagine a single file that at some point was meant to do a single thing grow to around 600 lines of code, you might consider moving some code out of it. double that amount and you end up with an unmaintainble mess.
Also, consider state. Composition API permits you to relatively simply create a data provider without using third party packages. Especially (async) actions are candidates to be reused in several components.
Wrapping up, for small projects, you're probably well set to develop Vue apps like before. Frankly speaking, I highly prefer the 'common' way, but would not want to close my eyes in front of new innovations, even if they look alien at first.
Another way of doing it means a total mess in documentation and third party code.
Vue 3 already created a havoc in Vue packages, things are just not compatible. Still even now I start all new projects on Vue 2 and Nuxt 2, cause Nuxt 3 is not production ready. Nuxt 3 had 100 times less downloads, means everyone just sticks to Nuxt 2.
If you find a component with 600 lines of code it just means that it has to be split into smaller components, I had quite large projects and never had to write any large component, everything can be split to smaller components and this makes more sense.
To each their own, I mean it's opinions. I've written a few serious apps with React and some quite complex with vue2, I would use vue2 anytime. If you never had "complex" behaviour become a mess of
useEffects,contextProvidersand friends, that's ok. I use functional languages for everything else, and to be honest, describing UI's in the browser - given the html/dom model and the existing browser apis - is probably one of the few things I think an object oriented wrapper has benefits. I want hooks for the lifecycle, I want to specify reactive data, methods and data that is reactive but also reacts to any of its automatically tracked dependencies (computed properties). For me that organisation makes sense, the same way single file components make sense even if you extract things out of them to "clean up", but that's just my point of view.