It is used because UI component frameworks make vanilla CSS an awkward an unnecessary tool (the Cascading part). CSS makes sense as designed for styling a document, but not so much for styling atomic components. If we were designing the web and CSS from scratch around the React model, CSS would not be made to cascade, because that is totally unnecessary and usually leads to more issues than it solves. Apart from theme variables, in a component system there's no reason to have global CSS anywhere; you'd just style each component in isolation. So when in the React model you typically want no cascades at all, the library that is made for that gets popular.
CSS modules are also a solution to the above, but, once you get rid of cascading, and you have one stylesheet per component, it is again unnecessary to have the one stylesheet in a different file from the one component. There's no benefit to splitting a component and its styles into two files; it just makes it more annoying to edit. So we move the styles essentially inline, with either Tailwind or CSS-in-JS.
Thanks for this great explanation of your viewpoint. As an occasional frontend dev who really got into Tailwind, it was always hard for me to explain why I'm so much more productive in Tailwind than in writing CSS. This makes a lot of sense.
It found its place because working on CSS on any non-trivial scale with multiple engineers is painful. The best way to deal with CSS at scale is not to write CSS. And this comes from me who really likes CSS.
CSS is one of my favourite things to do and still is. However, most engineers don't really understand it because most engineers don't really bother learning anything, and as a result you typically end up with a mess.
If someone knows what they are doing and is allowed to make a decent UI library, you can have very clean, efficient styling without libs.
Because what makes it useful , like media queries, can't be put in style attributes. Frankly this whole discussion is just as silly as claiming flex has nothing over table layout.
Then again one should aim to not even need media queries and make things responsive intrinsically, breakpoint-free, continuously. A design where things jump at hard coded viewport widths is not actually a great design.
>inb4 my 1:1 naive mapping of DB to screen works for me
>inb4 the web should be reserved for text documents and hyperlinks and user styles rule and running anything close to applications on the web was a mistake
People like to feel superior to others, so dunking on people using a popular technology tickles some pleasure centers. Considering another viewpoint gets in the way of that, so other viewpoints are ignored.
It's inline CSS, but with all the limitations of inline styles removed. There is a lot of stuff that can't be done with inline styles, like media queries.
Fairphone as a whole feels like a company that prioritises the mission, but only this mission of ethical and reusable hardware. The user experience for power users who are most likely to recommend their devices feels like a let-down.
That's the catch-22 problem. The underlying logic and software rarely care about the platform. They are usually just built Windows because that is the default OS on anything that is not a Mac.
The biggest issue is the lack of tooling and the inability to manage a shared state. We actually ended up creating new libraries like Stencil & Lit.
Custom Elements missed the mark with the problem frameworks solve. We don't necessarily need custom HTML, we needed easy way to build and manage the whole data and visual flow locally while treating the backend response as a datasource.
Nowadays, I use web components for one-off, isolated components as a replacement for iframes, but rarely for anything complex.
This so much, automatic "data struture state -> visual state" without manual synchronization code to update the visual state is the main reason why frameworks are useful, not for components.
BUT, these frameworks are most useful for actual "applications". So much of web development is "merely" focused on making beautiful "pages", and a framework can very well be overkill in those scenarios.
People "going back to basics" really need to learn to evaluate when what you are doing (or how much) falls into each camp.
I have heaps of experience with Stencil and it works great until a certain size indeed. It is a great way to ship web components quickly.
Coding agents will allow us to write plain JS way more quickly but it still takes a bit more time by humans to read compared to reading something that was written with in a framework.
Until the day that I don't have to do reviews of my AI generated code, or some sort of pseudocode abstraction layer becomes available, I think there is still a place for frameworks and libraries to create web components like Stencil.
