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.
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.