When the composition API was announced I was hesitant, my argument was that most of the dev time would go towards the new composition api. It came out and I tried it, and I’d say it was ok. I’ve written large scale applications with Vue 2. Matter of fact I’m currently working on 3 large scale applications in Vue 2 right now at work. So I’m very familiar with the options API in large applications. To me it’s easier. Large Applications are usually more complex to deal with, with the options API I can go to a component and tell you very quickly where things are, and with a little code review we’ve kept components well maintained and clean still.
My point is this - you can write “spaghetti” code on any language, framework, or pattern. In the end it is up to you, the developer, to keep the codebase clean. I’ve already seen, in my honest opinion, not great code with the new composition API, so I don’t think it fixes any problems. It’s up the developers to actually write it that way to fix it. Which in my experience is possible in both ways.
So it’s not that I have an issue with the Composition API, I just don’t think it fixes the problems people say they fix. In the end cleaner code is up to the developer maintaining the project, not the framework or pattern they use, and is still relatively opinionated.
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.
When the composition API was announced I was hesitant, my argument was that most of the dev time would go towards the new composition api. It came out and I tried it, and I’d say it was ok. I’ve written large scale applications with Vue 2. Matter of fact I’m currently working on 3 large scale applications in Vue 2 right now at work. So I’m very familiar with the options API in large applications. To me it’s easier. Large Applications are usually more complex to deal with, with the options API I can go to a component and tell you very quickly where things are, and with a little code review we’ve kept components well maintained and clean still.
My point is this - you can write “spaghetti” code on any language, framework, or pattern. In the end it is up to you, the developer, to keep the codebase clean. I’ve already seen, in my honest opinion, not great code with the new composition API, so I don’t think it fixes any problems. It’s up the developers to actually write it that way to fix it. Which in my experience is possible in both ways.
So it’s not that I have an issue with the Composition API, I just don’t think it fixes the problems people say they fix. In the end cleaner code is up to the developer maintaining the project, not the framework or pattern they use, and is still relatively opinionated.