Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Evolution of Scalable CSS

frontendmastery.com

Post reply on HN
Print view View original

31–40 of 59 posts

Re: The Evolution of Scalable CSS

#31

Post by andix »

Tailwind is the solution to most CSS issues. You can also add so many customizations into their config file. There are just a few things that can’t be done with tailwind natively.

With tailwind and react you now only write JSX files. Not separate files/sections for HTML, JavaScript and CSS your mind constantly needs to connect, although they are split up. Huge plus for someone with a goldfish brain like me, that’s getting super confused with more then 5 files open in the editor.

And with tailwind 3.2 they finally allow multiple config files, so you can easily have multiple tailwind instances inside one project. For example one config for the website and another one for the admin-panel.

Re: The Evolution of Scalable CSS

#32

Post by jacobr »

> Tailwind and CSS in JS libraries that pre-compile to Atomic CSS solve the problems of bloated CSS files full of duplicated rules.

> With Atomic CSS, the growth of CSS is tied to the number of unique styles used, not the amount of features developers are shipping.

> For example, it’s common to reuse certain properties like flex everywhere. Rather than have these duplicated in stylesheets under different class names, we only pay that cost once. This is true for each property/value combination.

This is true in theory and when you stick to the very basic stateless utility classes. Check the CSS of any larger site using Tailwind and search for a CSS rule, you will see things like

    .opacity-100 {
        opacity:1
    }
    .hover\:opacity-100:hover {
        opacity:1
    }
    .group\:focus-within .group-focus-within\:opacity-100 {
        opacity:1
    }
and that's not counting media queries, dark mode, etc. In practice, the global CSS file that you load for every single page does grow for every feature you ship, since you use more of Tailwind.

Re: The Evolution of Scalable CSS

#33

Post by jacobr »

dxchester wrote: post #20
azangru wrote: post #2

> The Evolution of Scalable CSS The evolution of practices described in this article is followed up to about ten yeas ago... and then stops, followed by Tailwind. Where is consideration of web components with shadow DOM, which solve the CSS encapsulation problem, the naming problem, and the dead code problem? Where is treatment of CSS variables that pierce the shadow DOM and allow global theming of such components? T…

We wrote about our journey[0] to sanity after Tailwind: The answer is to do it all in strategic moderation: Use a subset of tailwind just for spacing and layout and revel in simple things being simple. Use modular CSS for UI patterns and revel in the readability of your HTML and visual consistency of your UI. And then use custom scoped CSS where required, and revel in interesting things being only as hard as need be,…

Great post. It's similar to CUBE, https://cube.fyi and the creator of CUBE even wrote about using "Tailwind as the U in CUBE"

Re: The Evolution of Scalable CSS

#34

Post by wwweston »

abathur wrote: post #17

> Let’s take a break from all these principles and architectures, and remember that CSS is ultimately about implementing visual designs. I enjoyed the overview (though the web component/shadow Dom bits others noted here would have been nice) but I feel like there's a missing realization lurking at the center of this history: the separation of concerns in the web stack was designed for documents, not layouts or visual…

> I feel like there's a missing realization lurking at the center of this history: the separation of concerns in the web stack was designed for documents, not layouts or visual designs.

I think that realization had solidly set-in throughout the industry by 2010 or so, and why so much effort over the most recent decade went into things that do lend themselves to an app-like focus such as native flexbox & grid capabilities, shadow dom, and even recent things like :has().

But personally... I think that "apps as documents" paradigm has actually worked out pretty brilliantly, even considering how squirrelly CSS can be. The inspectability of the UI layer is one of the reasons why the browser is so much more than the VM that lived, and HTML/CSS has so much flexibility that many native UI toolkits lack. It's not right for every situation, but for the common case I think there are reasons it's often what people reach for first.

Re: The Evolution of Scalable CSS

#35

Post by jacobr »

spankalee wrote: post #10
aphexairlines wrote: post #3

There's still no good way of publishing an npm package with multiple components, stylesheets per component, and transitive consumers using only the stylesheets for the components they reference while rendering fully server side. CSS is still not scalable.

This is what native CSS module scripts solve. You can import CSS directly into JavaScript modules: import styles from './styles.css' assert {type: 'css'}; https://web.dev/css-module-scripts/ Live example: https://lit.dev/playground/#gist=f0bdd3b5db5e4a404297e695305...

SSR was mentioned though.

Re: The Evolution of Scalable CSS

#36

Post by TimTheTinker »

abathur wrote: post #17

> Let’s take a break from all these principles and architectures, and remember that CSS is ultimately about implementing visual designs. I enjoyed the overview (though the web component/shadow Dom bits others noted here would have been nice) but I feel like there's a missing realization lurking at the center of this history: the separation of concerns in the web stack was designed for documents, not layouts or visual…

Jesse James Garrett (the early web luminary who coined the term "ajax") was already talking about the dual purposes of the web in the year 2000. He called them "Web as software interface" and "Web as hypertext system".

In The Elements of User Experience (2000) he writes: "The Web was originally conceived as a hypertextual information space; but the development of increasingly sophisticated front- and back-end technologies has fostered its use as a remote software interface." [0]

[0] http://www.jjg.net/elements/pdf/elements.pdf

Re: The Evolution of Scalable CSS

#38

Post by jaredcwhite »

Reading an article about the evolution of CSS and ending up at…Tailwind…really feels like a bait and switch. I don't consider Tailwind at all a "solution" for writing scaleable CSS. It's a non-standard DSL for providing styling commands to a build tool, and the HTML/CSS output overloads class attributes everywhere in an absurd way. The "just use @apply" retort is also a non-starter if you want to write stylesheets that aren't vendor-locked to Tailwind's build tooling.

I'm actually working on a large design system that's in the process of stripping Tailwind _out_, because it's in fact not scaleable if you want to provide vanilla component styling APIs via custom properties. And as some others here have mentioned, we're not even talking yet about web components, shadow DOM, shadow parts, etc.

Scaleable CSS should adhere to the actual spec of CSS and how its evolving in browsers. Tailwind is a massive, non-standard deviation from the development of CSS.

Re: The Evolution of Scalable CSS

#39

Post by abathur »

wwweston wrote: post #34
abathur wrote: post #17

> Let’s take a break from all these principles and architectures, and remember that CSS is ultimately about implementing visual designs. I enjoyed the overview (though the web component/shadow Dom bits others noted here would have been nice) but I feel like there's a missing realization lurking at the center of this history: the separation of concerns in the web stack was designed for documents, not layouts or visual…

> I feel like there's a missing realization lurking at the center of this history: the separation of concerns in the web stack was designed for documents, not layouts or visual designs. I think that realization had solidly set-in throughout the industry by 2010 or so, and why so much effort over the most recent decade went into things that do lend themselves to an app-like focus such as native flexbox & grid capabili…

It's an incredibly flexible toolkit. Not calling it bad!

It just isn't cut along the seams we'd cut it along if we were building it fresh.

There's tons of evidence in the record-of-innovation that people are iterating around these problems--so I suspect there are plenty of people who have indeed internalized this to some degree. But I also see a lot of continual coverage that indicates this realization hasn't diffused.

(I don't want to pretend to have invented the wheel, but for example I see the fights around semantic VS functional tailwind-style css as hinging on this. Functional css makes sense for layouts as it collapses pointless separation; semantic classes make sense for documents which are more likely to evolve or get restyled without new markup.)

Re: The Evolution of Scalable CSS

#40

Post by jaredcwhite »

Eduard wrote: post #23

I never understood this with BEM: .nav { &__link { } } Why not this?: .nav { a { } }

Exactly. I've never written strict BEM, mainly just take a few cues from it now and then. When writing components and especially now that we have awesome low-specificity selectors like :where or cascade layers (and soon :has !!), it's really better to just target the DOM structure with semantic/custom element names, parent-child relationships, states like aria, etc. and not saddle every single element with some kind of naming convention. (I honestly don't use `class` much at all anymore.)
Post reply on HN