Very interesting thoughts and very reasonable indeed π I specially like the emotional way you bring it up with ππ
And I can totally relate. I donβt use Vue on day-by-day basis now (unfortunately), mostly occasionally, and mostly for prototypes, pet projects and teaching my son coding. And the reason I like Vue is that itβs very comprehensive and straightforward. Itβs easy to explain web dev and programming with Vue even to a child. But all that is because of the options API. So deprecating it (if itβs on the map) is a really bad idea IMO.
Hi Fyodor thank you for your comment. Glad to see that you liked the article.
I would say that they "soft-deprecating" the Options API. In the docs is mentioned that they don't plan deprecating it but if you read the docs throughout you will see that Options API is discouraged.
π In Vue 2, Options api was fine for full application but now in Vue 3 they say that options api is for low-complexity apps or without using a bundler.
π They also say that for new projects choose Composition api only and using it, it's better performance wise because you "shave-off" some kilobytes.
π Also, Code written in Composition API and script setup is also more efficient and minification-friendly than Options API equivalent.
So how can you win against the arguments to use CompA when you are in a team? You simply can't.
That's why I have switched totally to CompA.
If someone would ask me what is the best way to use Vue 3, I would say that it is Composition API with Typescript because I see that Vue team pushes us towards this way.
Options API is the reason that I choose vue against react. OptionsAPI is pretty intuitive and used in a straight way. Vue should stick to the options API, and provide composition as an option.
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.
Very interesting thoughts and very reasonable indeed π I specially like the emotional way you bring it up with ππ
And I can totally relate. I donβt use Vue on day-by-day basis now (unfortunately), mostly occasionally, and mostly for prototypes, pet projects and teaching my son coding. And the reason I like Vue is that itβs very comprehensive and straightforward. Itβs easy to explain web dev and programming with Vue even to a child. But all that is because of the options API. So deprecating it (if itβs on the map) is a really bad idea IMO.
Hi Fyodor thank you for your comment. Glad to see that you liked the article.
I would say that they "soft-deprecating" the Options API. In the docs is mentioned that they don't plan deprecating it but if you read the docs throughout you will see that Options API is discouraged.
π In Vue 2, Options api was fine for full application but now in Vue 3 they say that options api is for low-complexity apps or without using a bundler.
π They also say that for new projects choose Composition api only and using it, it's better performance wise because you "shave-off" some kilobytes.
π Also, Code written in Composition API and
script setup
is also more efficient and minification-friendly than Options API equivalent.So how can you win against the arguments to use CompA when you are in a team? You simply can't.
That's why I have switched totally to CompA.
If someone would ask me what is the best way to use Vue 3, I would say that it is Composition API with Typescript because I see that Vue team pushes us towards this way.
I feel something is wrong with the vue development team. They should think again why vue is so popular against react.
Options API is the reason that I choose vue against react. OptionsAPI is pretty intuitive and used in a straight way. Vue should stick to the options API, and provide composition as an option.