Just a hobbyist programmer with an eye on new technologies. Currently helping Quasar and NestJS Frameworks, because....well.....because they're awesome! :-)
You've failed to give us your idea or suggestion as to what the better solution to better code reuse could have been and why it would be better. So, this article ends up just sounding like a rant to me.
You do mention refactoring because, if one needs the composition API, they are more then likely doing something wrong and could just refactor. Really? Are you sure that is true? I don't. My best guess is, you've not understood how the Composition API can help you and thus, haven't embraced the fact it could help you. That's ok. But, you shouldn't write about your lack of understanding like this, as if it's Vue's problem, in a rant. There are many other devs who are embracing it. They can't all be wrong. Right?
You also fail to mention the other main reason for this API direction of Vue - It's for a much better TypeScript support. This is very important for larger developer teams (too) and developer ease of use. (You do understand that I hope). That shouldn't be forgotten or rather should be weighed against the cons of the API, which you also fail to mention in any detail. You never say the new API has inherent problems, except your opinion of it possibly disrupting some delicate balance Vue makes between React and Angular. I disagree wholeheartedly against this perspective. That might have been the case while Vue was growing, now Vue needs to grow in other directions. And, the new Composition API will pull more (smart) React and Angular devs and companies using these technologies to Vue, strengthening its place in the market and allowing that growth.
I will agree that it is very easy to muddle up code reuse concepts with all the new possibilities we are seeing with single file components. In Jake Schatz's presentation you elude to, Jake is trying to give the message of not allowing business "knowledge" to leak into the UI. He is clearly demonstrating we should use abstractions to simplify code and enable better code reuse. He notes two patterns, the "builder" and the "command" design patterns. And, if we are brutally honest, the Composition API is 100% built to support both patterns much better than the current and often loved Options API (I love it too, btw). Imagine a "useCommand" or "useBuilder" and "useDirector" functions (objects).
So, unless you can come up with a better solution, you should stop ranting, because that is all it is. A rant. It has no value other than to get your opinion out in the open. And, you should know, opinion without reasonable and substantiating fact is a lousy opinion. Sorry, but if you want to back up your opinion, come up with what you feel could have been a better direction and why. Then your rant isn't just a rant, but a smart counter argument and I personally would thank you for it.
I am sorry if my personal rant has offended you. You are right that I should have expanded on some points like what a better alternative would look like.
Personally I don't think that Vue.js needed better methods for code reuse because, like I said in my article, if you end up needing composition functions or mixins, your problems could probably be solved by other forms of refactoring – e.g. breaking components down and using vanilla service classes.
Otherwise, if you or the core dev team insist on changing the way Vue works, the now abandoned Class API would have been a much better alternative, and in fact it would have been much more idiomatic OOP Typescript, if you're all about the improved TS support.
If you fail to see the merit of my "balance between Angular and React argument", then you are severely misunderstanding the position Vue occupies in the general JavaScript ecosystem. As a consultant I've helped multiple middle sized to large companies introduce Vue.js to their dev teams, and "better code reuse" or "better typescript support" were literally never mentioned as reasons. The single most often mentioned reason was that Vue.js has a much flatter learning curve and (compared to Angular and React) much less boilerplate, i.e. "the fine balance" I was referring to in my article.
If a team would find themselves in the position of needing much more strictly organized code structure or much better native TypeScript support, they would simply reach for Angular. If on the other hand, they need much better and "pure" functional approach to their code base, they would simply reach for React. My point is, those use cases are already solved better in other frameworks, and Vue should stick to what makes it desirable in the first place. Vue is not a silver bullet that is valid in all the use cases.
Software engineer. Fullstack Node.js. API designer. Play with JavaScript, Python, MongoDB, PostgreSQL, ELK. Available for remote or independent projects.
If you think composition API solves anything for you you probably need to switch to React, Vue philosophy of coding is specifically about options API and proper app architecture. I personally work with Vue since 2015 and never ever had issues with code reusing. Composition API is the worst that happened to Vue and may actually lead to it slow death as there is no more point of using Vue when it's basically the same as React.
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.
You've failed to give us your idea or suggestion as to what the better solution to better code reuse could have been and why it would be better. So, this article ends up just sounding like a rant to me.
You do mention refactoring because, if one needs the composition API, they are more then likely doing something wrong and could just refactor. Really? Are you sure that is true? I don't. My best guess is, you've not understood how the Composition API can help you and thus, haven't embraced the fact it could help you. That's ok. But, you shouldn't write about your lack of understanding like this, as if it's Vue's problem, in a rant. There are many other devs who are embracing it. They can't all be wrong. Right?
You also fail to mention the other main reason for this API direction of Vue - It's for a much better TypeScript support. This is very important for larger developer teams (too) and developer ease of use. (You do understand that I hope). That shouldn't be forgotten or rather should be weighed against the cons of the API, which you also fail to mention in any detail. You never say the new API has inherent problems, except your opinion of it possibly disrupting some delicate balance Vue makes between React and Angular. I disagree wholeheartedly against this perspective. That might have been the case while Vue was growing, now Vue needs to grow in other directions. And, the new Composition API will pull more (smart) React and Angular devs and companies using these technologies to Vue, strengthening its place in the market and allowing that growth.
I will agree that it is very easy to muddle up code reuse concepts with all the new possibilities we are seeing with single file components. In Jake Schatz's presentation you elude to, Jake is trying to give the message of not allowing business "knowledge" to leak into the UI. He is clearly demonstrating we should use abstractions to simplify code and enable better code reuse. He notes two patterns, the "builder" and the "command" design patterns. And, if we are brutally honest, the Composition API is 100% built to support both patterns much better than the current and often loved Options API (I love it too, btw). Imagine a "useCommand" or "useBuilder" and "useDirector" functions (objects).
So, unless you can come up with a better solution, you should stop ranting, because that is all it is. A rant. It has no value other than to get your opinion out in the open. And, you should know, opinion without reasonable and substantiating fact is a lousy opinion. Sorry, but if you want to back up your opinion, come up with what you feel could have been a better direction and why. Then your rant isn't just a rant, but a smart counter argument and I personally would thank you for it.
I am sorry if my personal rant has offended you. You are right that I should have expanded on some points like what a better alternative would look like.
Personally I don't think that Vue.js needed better methods for code reuse because, like I said in my article, if you end up needing composition functions or mixins, your problems could probably be solved by other forms of refactoring – e.g. breaking components down and using vanilla service classes.
Otherwise, if you or the core dev team insist on changing the way Vue works, the now abandoned Class API would have been a much better alternative, and in fact it would have been much more idiomatic OOP Typescript, if you're all about the improved TS support.
If you fail to see the merit of my "balance between Angular and React argument", then you are severely misunderstanding the position Vue occupies in the general JavaScript ecosystem. As a consultant I've helped multiple middle sized to large companies introduce Vue.js to their dev teams, and "better code reuse" or "better typescript support" were literally never mentioned as reasons. The single most often mentioned reason was that Vue.js has a much flatter learning curve and (compared to Angular and React) much less boilerplate, i.e. "the fine balance" I was referring to in my article.
If a team would find themselves in the position of needing much more strictly organized code structure or much better native TypeScript support, they would simply reach for Angular. If on the other hand, they need much better and "pure" functional approach to their code base, they would simply reach for React. My point is, those use cases are already solved better in other frameworks, and Vue should stick to what makes it desirable in the first place. Vue is not a silver bullet that is valid in all the use cases.
I think you summarized very well what i always thought. Thanks.
If you think composition API solves anything for you you probably need to switch to React, Vue philosophy of coding is specifically about options API and proper app architecture. I personally work with Vue since 2015 and never ever had issues with code reusing. Composition API is the worst that happened to Vue and may actually lead to it slow death as there is no more point of using Vue when it's basically the same as React.