I'm a selftaught (web) developer. On sunny days, you can find me hiking through the Teutoburg Forest, on rainy days coding or with a good fiction novel in hand.
[...] "separating CSS" is relevant [...] - because it keeps your project maintainable by a team of devs, designers and other team members.
[...] why you think the bundle size will be affected negatively - in fact, judging just by size, I don't think it will. But the value of using this style of applying styles, in my eyes, does not outweigh its costs
I get your points. I'm biased on a few as well, so lots of words would probably not convince. Let me try and elaborate with a few:
About bundle size:
Perhaps phrasing on my first point was poor. With additional bundle size, I meant: It's another package I have to take care of during my dev workflow. I understand your point with atomic component design - it's a pattern where utility CSS frameworks such as Tailwind+PurgeCSS really shine. Because when you develop, you must make compromises between technical cost ( and debt ) vs. value added.
In a nutshell: The value I see at first and second glance does not outweigh the cost of using this package. It's just my opinion. It might as well be wrong and I'm sure there are projects where this will save a lot of time. I just cannot envision them clearly.
Separation of concerns is the idea that each module or layer in an application should only be responsible for one thing and should not contain code that deals with other things
As per my understanding:
HTML = structure
CSS = style
JS = interactivity
So if you say
"Styling shouldn't be considered a concern"
I say:
"Then neither should interactivity be"
Let's create a single language that does HTML, CSS + JS at once. Even better: Let's all use .jsp for everything again. That'll be fun.
In all honesty: There's a reason why there are whole CSS design systems, such as BEM or SMACCS around. If properly applied, they empower you to scale your product without compromise. Or shift it over to other teams without a lot of struggle.
Or refactor / rewrite a big chunk of your HTML templates. If you scrap your Tailwind-powered views, all the styling is gone for good. If you use a design system, all CSS classes will persist and you can quickly prototype new pages.
Now you might argue: "But this works with Tailwind too!". Sure it does, but building the templates AND the styles at once from scratch doubles the mental payload you might have to carry. If you already have a guiding star, it'll be much easier.
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.
TL:DR
[...] "separating CSS" is relevant [...] - because it keeps your project maintainable by a team of devs, designers and other team members.
[...] why you think the bundle size will be affected negatively - in fact, judging just by size, I don't think it will. But the value of using this style of applying styles, in my eyes, does not outweigh its costs
I get your points. I'm biased on a few as well, so lots of words would probably not convince. Let me try and elaborate with a few:
About bundle size:
Perhaps phrasing on my first point was poor. With additional bundle size, I meant: It's another package I have to take care of during my dev workflow. I understand your point with atomic component design - it's a pattern where utility CSS frameworks such as Tailwind+PurgeCSS really shine. Because when you develop, you must make compromises between technical cost ( and debt ) vs. value added.
In a nutshell: The value I see at first and second glance does not outweigh the cost of using this package. It's just my opinion. It might as well be wrong and I'm sure there are projects where this will save a lot of time. I just cannot envision them clearly.
About SOC
As per your advice, I did Google "separation of concerns css in js". The first entry that came up led me to the book 'Programming JavaScript Applications by Eric Elliott', where the first sentence reads:
As per my understanding:
So if you say
I say:
Let's create a single language that does HTML, CSS + JS at once. Even better: Let's all use
.jspfor everything again. That'll be fun.In all honesty: There's a reason why there are whole CSS design systems, such as BEM or SMACCS around. If properly applied, they empower you to scale your product without compromise. Or shift it over to other teams without a lot of struggle.
Or refactor / rewrite a big chunk of your HTML templates. If you scrap your Tailwind-powered views, all the styling is gone for good. If you use a design system, all CSS classes will persist and you can quickly prototype new pages.
Now you might argue: "But this works with Tailwind too!". Sure it does, but building the templates AND the styles at once from scratch doubles the mental payload you might have to carry. If you already have a guiding star, it'll be much easier.