I'd say that personally, I'm not as much after the separation of concerns itself, rather than just making my code cleaner and more maintainable. Separation of concerns is just one of many ways to achieve that.
It's interesting that you've brought up Vue 3, as it recently became my go-to UI framework. I love it but not because of the separation of concerns and SFCs, but actually the complete opposite!
I came to love the setup() method and the Composition API. To me, they're like React Hooks, which I really like, but better. The reactivity model and one-time setup() execution seem much more pleasant to work with for me. On top of that, better JSX and TypeScript support led me to not that good of separation of concerns, but much better development experience and efficiency, combined with clean and maintainable code.
If you're interested in this topic, I wrote more about it here:
Thank you for your reply, I will also read your Vue post. Seriously, I've also consider of the custom hooks idea for the main points of this post.
My situation here is that most projects use React, and I am also a loyal React user. Vue3 is very good now, but JSX/TSX support is not as rich as react ecosystem. For example, there is no stable CSS-in-JS solution(e.g. styled-components、Emotion) for Vue3.
The React SFC inspiration is actually to solve my pain points in the development, I haven't promoted it yet and I'm not sure how many people will agree with it. Separation of concerns is really just a way, but it is very successful in Vue. In the React environment I want to combine the separation of concerns with the existing TSX/eslint/CSS-in-JS ecosystem in a new cohesive way, and no string template is required.
If you take a closer look, you will find that I am not completely imitating Vue's SFC. Of course, different people have different needs, so their understanding will be different, it's perfectly normal.
I did take a look at your library. The API seems interesting, though I can imagine your potential users would really have to know what they're after in terms of structuring their code.
As for Vue 3 - you're right that the ecosystem is lacking. I get around that in my projects as I recently stopped using CSS-in-JS in favor of Tailwind. And although there are a few pain-points, it's a fairly good solution. But I acknowledge that React ecosystem has better tooling available even for Tailwind, which you can in this blog post (another plug 😅):
I'd say that personally, I'm not as much after the separation of concerns itself, rather than just making my code cleaner and more maintainable. Separation of concerns is just one of many ways to achieve that.
It's interesting that you've brought up Vue 3, as it recently became my go-to UI framework. I love it but not because of the separation of concerns and SFCs, but actually the complete opposite!
I came to love the
setup()method and the Composition API. To me, they're like React Hooks, which I really like, but better. The reactivity model and one-timesetup()execution seem much more pleasant to work with for me. On top of that, better JSX and TypeScript support led me to not that good of separation of concerns, but much better development experience and efficiency, combined with clean and maintainable code.If you're interested in this topic, I wrote more about it here:
Vue with TSX - the perfect duo!?
Arek Nawo ・ Mar 2 ・ 8 min read
Thank you for your reply, I will also read your Vue post. Seriously, I've also consider of the custom hooks idea for the main points of this post.
My situation here is that most projects use React, and I am also a loyal React user. Vue3 is very good now, but JSX/TSX support is not as rich as react ecosystem. For example, there is no stable CSS-in-JS solution(e.g. styled-components、Emotion) for Vue3.
The React SFC inspiration is actually to solve my pain points in the development, I haven't promoted it yet and I'm not sure how many people will agree with it. Separation of concerns is really just a way, but it is very successful in Vue. In the React environment I want to combine the separation of concerns with the existing TSX/eslint/CSS-in-JS ecosystem in a new cohesive way, and no string template is required.
If you take a closer look, you will find that I am not completely imitating Vue's SFC. Of course, different people have different needs, so their understanding will be different, it's perfectly normal.
I did take a look at your library. The API seems interesting, though I can imagine your potential users would really have to know what they're after in terms of structuring their code.
As for Vue 3 - you're right that the ecosystem is lacking. I get around that in my projects as I recently stopped using CSS-in-JS in favor of Tailwind. And although there are a few pain-points, it's a fairly good solution. But I acknowledge that React ecosystem has better tooling available even for Tailwind, which you can in this blog post (another plug 😅):
Tailwind JSX and class composition
Arek Nawo ・ Mar 3 ・ 8 min read