Comment by ozim
21 hours ago
Yeah there is a lot of idealism in the project - problem is reality doesn’t care about your idea of separation of concerns and most likely your web applications will not benefit from it.
What I mean React and other frameworks went with mixing concerns because of reasons that were practical - for example realization that usually one dev implements HTML and JS code in one task, not like article comes up with designers and devs. In reality lots of designers don’t live in agile sprints and the same repositories as devs there is huge impedance mismatch.
The "separation of concerns" point is very overblown, IMO. It seems to have become a slogan repeated without considering what the goal is, and just completely dismissing components as another valid way of organizing code.
Components have won for a reason - for any given web-based UI component to work it needs to render HTML, to style that HTML, and logic for rendering and behavior. So HTML, CSS, and JS.
It only makes sense to colocate those things so that they're easier to build, understand, distribute, and use as a unit. Often times they're not even separable as the HTML depends on state and logic, etc.
And the weird thing is that any other UI platform has components that combine rendering, styles, and logic together and no-one bats an eye because it would be very odd and cumbersome to do it any other way, but on the web some people think components are bad. And they tend to provide no realistic mechanism for reuse except to use an external system.
Separation of concerns is valid if you look at website as a document.
If you look at website as an application components are valid approach.
I don’t need a framework to make documents - I need framework to make web applications that is why components won so I agree.
I partially agree.
The "separation of concerns" is often misunderstood, and historically people were treating html, css and js like they were completely separate beings, which is of course a recipe for disaster [0].
However, what I'd like to see is separation between logic and presentation. In React world people used to call them dumb and smart components. Then you can use stuff like storybook to gauge your layout before applying "business logic" to the application. On top of that you have an easy way to test your "smart" components.
[0] like that time when I saw an org that decided to be "cloud agnostic" and people started pushing their own databases and http servers to AWS. :)
To add on top.
Usually one does not design a page like website but reusable components that will have its own context and content.
Designer might focus on broad scope how stuff fits in a web app.
That pop-up to edit “task” has to behave the same on 20 different views.
Widget showing task details will probably be integrated also in some far removed place.
That is whole different game that this “standards focused framework” is not addressing and that game was addressed by whole bunch of frameworks that this article nags about.