Knowing CSS is mastery to front end development | Hacker News Reader

Knowing CSS is mastery to front end development

helloanselm.com

215 pointstipiirai209 comments

I disagree with many of the comments here. CSS is not too complicated. It's a good way to style HTML elements.

There are some popular abstractions to writing CSS such as Tailwind. Although I do see it misguiding a lot of people. When you don't know CSS but want a webpage, use a template instead. If you want deep custom styling you will need to understand CSS. Tailwind is just a collection of predefined utility classes which you then over use, breaking a few clean code principles along the way, but you get a decent looking website without writing all the utility classes yourself, which can be helpful especially in larger team projects.

There are improvements to this problem such as DaisyUI.

But regardless, they do require some understanding of CSS. And if you do understand some CSS, getting to the next level and learning how to write scalable CSS is not much harder. The simple requirement of having global and scoped styling is a given in every modern framework.

This is partly what led me to create a guide on writing modern scalable HTML and CSS: https://webdev.bryanhogan.com/

- Tailwind (wow, the website is laggy): https://tailwindcss.com/

- DaisyUI: https://daisyui.com/

- Some modern framework, e.g. Astro: https://astro.build/

From daisyui.com:

  Tailwind CSS provides low-level utility classes, wich usually inlcude only one CSS rule.
  daisyUI classes are a combination of multiple CSS rule that are named semantically for each part of the UI.

So, to put it simple, Tailwind re-implements css property-value pairs as classnames, whereas daisyui re-implements css classnames.

It seems like the whole dance is to avoid

  class="btn" style="font-color: #3e3"

So what is different from above is that a style override is now possible via class like

  class="btn font-color-3e3"

(or whatever tailwind provides as builtin class). Are these layers of indirection worth it, and still needed with modern css? I remember we came to css frameworks and BEM because it was difficult to scope css.

> and BEM because it was difficult to scope css.

I suspect this reflects the cultural problem that in many organizations no one really wants to create or stick to a systematic design.

Scoping CSS isn't trivial as a site grows large, but it's far from intractable.

Tailwind's orientation on concrete details everywhere is the "just give up" solution -- stop trying to get the organization and culture to do work they don't want to do.

EDIT: I'd also guess there's an element of poor feedback loops for most development tools. When people people talk about things like "I don't want to have to look up what every class means", they're speaking to one reality of code componentization across the multiple dimensions of styling/semantics/markup/logic in development environments that often can't support interactive, legible, and interconnective feedback as development is done. There are probably solutions to this but they're more involved and less well known or fungible than just collapsing styling/semantics/markup into a single dimension around a consistent constrained UI domain language you can add to your resume in a week tops. This is friendlier to the predominant "culture" for building front ends right now.

> Tailwind's orientation on concrete details everywhere is the "just give up" solution

Yes, and that is why I am genuinely curious whether going the nuclear approach is still needed, or that css variables, @scope and what-not of today solves the problems of the past.

Because it seems that Tailwind introduces problems that CSS sought to resolve, and now DaisyUI seeks to resolve the problems of Tailwind.

Are we now at a point that devs do not know enough about the basics and are mentally stuck on tools they do know? Or is it that the old problems still have not been solved?

Yes & yes.

It seems to me really learning CSS has been something most devs who started doing anything else have long wanted to avoid. I suspect it just scratches different itches and feels more like configuration than programming. And of course once an abstraction layer becomes key in established development culture, the opportunities for reward are probably broader with the abstraction than with the layers underneath it. Not sure styling has coalesced around Tailwind or DaisyUI enough to lock that in, though.

I'd guess css vars, @scope, etc do solve some problems. I'd also guess something equivalent to full native mixins would be needed to solve most technical expressive/organizational problems and I'm not sure css vars get there. Plus there's the various factors in org culture that tend to undervalue all kinds of areas of front-end design and engineering (which I'd guess largely boil down to a combination of the incentives towards conversion-oriented tinkering and bikeshedding pride among recognized product stakeholders).

  > I'd also guess something equivalent to full native mixins would be needed to solve most technical expressive/organizational problems and I'm not sure css vars get there

You said native, but could a CSS preprocessor in the meantime fill that gap? If @layer and @scope would fix the problems pre-BEM, I think we are done then.

  > Plus there's the various factors in org culture that tend to undervalue all kinds of areas of front-end design and engineering

Yes, if it is people just don't want to reuse, but want to have a quick hack for something like

  <button class="class_6447823468">

then it is more a tool for an organization/skill problem I guess.

I just don't see how you can reach and enforce a consistent, maintainable styling across a medium to large website with something like Tailwind. Do people trade quality, consistency and freedom for a limited set of design tokens that might be applied inconsistently?

I have to admit I have not done much in css since a long time, and given the enthusiasm for Tailwind I wonder if my understanding is lacking.

In my experience, after now something like 5 years of using Tailwind in projects large and small, it scales reasonably well. You just do what the authors suggest: encapsulate styling in components instead of CSS classes.

Now, that isn't quite the panacea it can sound like. The standard components like buttons and dropdowns are solved quickly and then you have the unusual components that always show up here and there, which are more likely to stand out. But, that was my experience with BEM/Bootstrap/whatever before that as well.

that css preprocessor would be CSS modules and yes it solves the scoping problem today

Preprocessors have solved things fairly well for a while now

https://pdx.su/blog/2023-07-26-tailwind-and-the-death-of-cra...

This article is coming up on two years old, and still holds true. You can just now do a lot of the things that required external tooling in plain css

Just want to say thanks for this -- I hadn't seen it before, and it touches effectively on a number of practical criticisms I have of Tailwind plus some I hadn't articulated yet.

And I'm really glad it brings the context of web craftsmanship into this, I think it's related. As I've argued elsewhere in-discussion, a fair portion of Tailwind's appeal probably comes from the way it fits with the "grain" of business web dev culture, which itself is driven by product management culture oriented around conversion metrics (often wielding iffy A/B testing) and rewards for bikeshedding. The benefits of craftsmanship or systematic design are less legible and so design direction and front-end tasks tend to be one-off screen-by-screen and pretty churn-y. Semantics are an afterthought and invisible to most stakeholders, attempts to systematize are often seen as irrelevant if not obstacles to business goals.

Tailwind just gives up. Give the business and its agents what they want, get through your task list, and find somewhere else to care about the subtleties of quality.

I didn't address it as much in the article as I probably should have, but in the time since I've written it, one of the other things that I've really come to terms with is the fact that a very large number of developers don't view frontend as "real" programming.

These developers come from all sorts, backend, mobile, whatever, but all share a uniform disdain for frontend web. It's something to get done and get out of the way so you can get back to "real" programming.

And so anything that slows down the "getting things done" step is seen as an obtuse undue burden. Learning JS gets a small pass (a lot of criticism too, some justified, some tired, and some unjust) since its at least got the dressings of a "real" programming language, and HTML is simple enough that you can learn most of what you need in an afternoon. But CSS doesn't get that pass. Its not really a programming language, and its not drop dead simple. Its actually rather complex, and used to be even harder.

And so, time and time again, we see these tools that aim to be a panacea for this issue. ExtJS, Bootstrap, BEM, Tailwind, there's a long lineage of these things. And they all try and shield the poor developer from having to actually learn to use the tools at hand.

I'm not going to use the tired analogy of a carpenter not knowing how to use a hammer so he uses a rock instead, because that does some disservice to tools like Tailwind, which are impressive engineering feats in their own right. Rather, its a guy normally used to working with sheet metals being tasked to frame a house. He uses his peen hammer to drive nails, and it works well enough, as long as he's just putting nails into wood. But the moment he needs to remove some sticks to open up a new doorway where there were previously studs, suddenly he finds that he has no claw on the end to pull the nails out, and has to resort to using a screwdriver and a pair of pliers.

Thats what tailwind is. The peen hammer. You can write a frontend just fine with it. But the moment you have to change anything already written down, you run face first into its limitations. So you find yourself working your way through templates or whatever the analog in your project is, pulling out bg-blue-300 and replacing it with bg-purple-300, maybe using some find-and-replace to help with the process, but knowing you cant rely on it entirely because there are some blue-300 things you want to stay blue and others you don't.

> Because it seems that Tailwind introduces problems that CSS sought to resolve

> Are we now at a point that devs do not know enough about the basics and are mentally stuck on tools they do know? Or is it that the old problems still have not been solved?

You should read all of https://tailwindcss.com/docs/styling-with-utility-classes. Experienced developers use Tailwind because it solves real problems with CSS that are hard to understand until you've worked on complex sites, with complex designs, and/or with large teams. People will often tar Tailwind users as people that don't understand CSS well when this isn't the case.

Plain CSS is fine for simple designs and document based sites, but e.g. cascading styles, specificity, and the way styles are spread between files becomes a nightmare to grow and maintain later. CSS wasn't invented with the kinds of complex responsive UIs and designs we need to write now, so it's not a surprise the traditional way doesn't scale well.

Ever worked on Java/OOP code with huge complex fragile inheritance trees spread across files where you can't figure out which piece of code is overriding something, or how to make your change without breaking something else? It's not unlike that, yet people will blindly defend the traditional CSS approach because the flaws aren't widely accepted yet.

I don't dismiss Tailwind, CSS had trouble with scoping styles. From there we got to BEM. Now CSS has grown to tackle that issue.

So the question is whether Tailwind is now becoming an obsolete approach. Especially as DaisyUI tries to put yet another block on the Jenga tower.

> From there we got to BEM

Problems/friction here is still: now I'm forced to give verbose names to all my divs, CSS is verbose, responsive CSS is very verbose, you can't easily compose the styles from different classes (like adding a shadow or text styling from elsewhere, where each was multiple lines of CSS), styling is split between the HTML and CSS files which slows down editing and debugging, it's hard to keep styling/spacing/sizing consistent unless you (verbosely) use variables everywhere.

All of these add up to make writing and maintaining CSS a draining and frustrating experience, especially if you want to quickly iterate on a design where you're not quite sure yet how it should look.

I'm not a user of DaisyUI but Tailwind still has a lot of pros over standard CSS and BEM.

> to put yet another block on the Jenga tower.

In a similar thought, why not write the styles directly on the HTML? Heavily restyling a site always requires modifying the HTML along with the CSS and adding divs that are only there for styling, so let's admit they're not separate and remove a layer of indirection and remove the extra verbosity BEM brings? BEM is mostly admitting that cascading and specificity are CSS features to avoid, so why stop there?

For me, it's always been much less of a technical thing, and much more that the material coming out of the product design part of the business is never actually consistent enough that you can have a single consistent CSS file drive the whole site.

Yeah -- that's a big part of what I mean with "stop trying to get the organization and culture to do work they don't want to do" or "just give up."

I do think there are tooling shortcomings that could change required investments and therefore organizational outlooks, and that the Tailwind approach comes with some technical debts that could an alternative like that worth it. But it'd take a team with a good amount of free time, experience, and unusual levels of insight to produce such a thing. Probably some clout to get it off the ground.

In the meanwhile, Tailwind represents a plausibly acceptable local maxima that coincides with a lot of other things about larger web dev practices and culture.

And to be clear, mine is a descriptive assessment, not a normative one. Tailwind is functionally adaptive to the dysfunctions as well as the functions of the predominate business web dev culture, not an expression of worthy ideals.

It's a bias to think the problem is people not knowing how to architect a good CSS solution. The reality is projects are maintained by multiple people over the course of its life. OOCSS only brings technical debt and constraints, and not to mention bloated CSS files. A good explanation why OCSS is bad https://www.fcss.club/manifesto and why functional CSS or atomic css is better in the short and long-term https://www.fcss.club/why. Tailwind just brings more complexity.

It's not font-color 3e3, it's font-red-300. That's an important distinction, because the second one respects the design system your art team spent a lot of time establishing. By using their language you normalize the set of styles utilized in an application, instead of individually and repeatedly hard coding the hex values.

Second off, tailwinds true power becomes way more obvious if you consider pseudo selectors like lg: and hover:.

I never got the appeal of Tailwind, it's almost a 1-to-1 map from style="" to classname="", they just made the terms slightly easier to remember.

Tailwind is a prime example on how good marketing can help you win a market, even if the alternative is free, even if it's already crowded, even if your product is trash. Marketing wins.

Edit: I have used Tailwind, a lot. Recently, upgrading from v3 to v4 in a Next.JS project, which was supposed to be a no brainer, turned out to be a four hour ordeal. I cannot spend that much time just to make sure that "background-color: red" still works, lmao, it is such a travesty. Because of that, I'm in the process of removing it from my projects now.

For the longest time, I didn't get it either. It took me actually trying it out in a project to like it. It's true, much of it is the same as writing inline-styles, but it's also more powerful than that. Here's a few things that I like about it:

- Ability to use pseudo-selectors, etc. in "inline-styles"

- Limited set of predefined values to use for padding, margin, and such that make it a bit easier to stay consistent

- Some helpful utilities like good looking shadows and animations

Sure, I could achieve all of that in a different way. Nothing about it is ground-breaking or even unique, but it's a nice package that works well for me.

> Limited set of predefined values to us...

With the ability to predefine css constants I guess it's now possible to use the style prop directly and not have to use raw hex colors and pixel values (eg. there are css libraries with these https://open-props.style).

That’s exactly what I thought until I actually tried tailwind. Now I really like it.

It has pros and cons like anything though. Trying to style a fundamental component is pretty painful. Like imagine your company’s main “button” element. It’s got 8 different sizes, optional icons on both sides, animations, styles, each needing to support different color combos. Tailwind is miserable for that. You get giant huge balls of spaghetti classes all over your button, and it’s pretty incomprehensible.

But for “glue” styles, it’s freakin amazing. Putting those components together, giving them spacing, even making simple components that don’t have lots of conditional properties? It’s really nice. You can style stuff quickly and consistently right from the markdown, you don’t have to think of classnames for every teeny little thing, and you can somewhat imagine what stuff looks like just by looking at the jsx.

I remember the crazy hype around it when it got popular, and it really put me off. Didn’t even try it for a long time. Now I’m in a codebase that doesn’t have it, and I miss it! I don’t miss it terribly, but it was a nice little QOL upgrade

> You can style stuff quickly and consistently right from the markdown, you don’t have to think of classnames for every teeny little thing, and you can somewhat imagine what stuff looks like just by looking at the jsx.

I still don’t understand what it brings over putting style= whatever on the element.

> I still don’t understand what it brings over putting style= whatever on the element.

You can't put a style for dark mode and one for light mode. Lifting these properties from styles to classes allows you to combine them with media queries and states.

Sounded to me like parent commenter was not advocating for that sort of thing so much.

They said

> Like imagine your company’s main “button” element. It’s got 8 different sizes, optional icons on both sides, animations, styles, each needing to support different color combos. Tailwind is miserable for that. You get giant huge balls of spaghetti classes all over your button, and it’s pretty incomprehensible.

Which to me sounds like they would not use Tailwind for dark mode / light mode things either. But I might be misunderstanding

It sounds like you're saying we need to consider the flexibility and articulation that classes enable when they reflect considerations beyond concrete presentation.

I just today, I helped to a junior that asked me how he can move a button on a toolbar. He was fighting against some legacy webapp made with JSPs, that have a f** zillon of style="XXX" stuff on nearly everything. And what is worst ... nearly everything using "position: absolute" to layout nearly everything.

Try to maintain that horrent webapp.

PD: That webapp it's what a ex co-worker called "technical bankrupt"

If you got lots of "custom" styling for elements, why can't one write a CSS class just as easily and give the element that class? Why is Tailwind better? Am I not also writing the definitions in Tailwind then and assigning those classes to my element then? I don't get what the benefit is supposed to be.

That’s exactly what I do for elements with lots of custom styling!

I guess I didn’t explain fully, but for things like the button example, I use regular ol css modules. Tailwind is for all the glue. And in my experience, most of the css you write when working on a feature is glue.

.brand-btn {}

.brand-btn--inverted {}

.brand-btn--icon-right {}

.brand-btn--smaln {}

.brand-btn--smaller {}

.brand-btn--big {}

However, very rarely need too many combinations of the same button with a brand logo.

We don't develop without components anymore.

You can have a nice component with all the cases, type-safe, and apply few utility classes to produce more maintainable code.

> Edit: I have used Tailwind, a lot. Recently, upgrading from v3 to v4 in a Next.JS project, which was supposed to be a no brainer, turned out to be a four hour ordeal. I cannot spend that much time just to make sure that "background-color: red" still works, lmao, it is such a travesty. Because of that, I'm in the process of removing it from my projects now.

What does "it" relate to in the last sentence? Tailwind or Next.JS?

Anyway, making sure that background color still works, is that an argument for Tailwind? Wouldn't that be a great argument for simply using standard CSS properly?

>> I never got the appeal of Tailwind

They're not arguing for Tailwind. They have used Tailwind.

Agreed. Tailwind is an abomination.

Its biggest problem is that it's a leaky abstraction. The classes translate _almost_ 1:1 to the equivalent CSS, but not quite and not always. In the best case scenario, you use a utility class and don't think about the CSS. In the worst, you must understand both how to implement the feature in CSS and how Tailwind does the translation. Then you need to think how to make Tailwind do what you want to do in CSS.

All of this adds a considerable amount of mental overhead while developing. And in the best case scenario developers don't even bother learning CSS, which eventually leads to a stagnation of knowledge. It wouldn't surprise me if some junior frontend developers don't even understand CSS, and just call themselves "Tailwind developers".

Yes, all abstractions move the focus to a higher layer up the stack, but the troubling thing with Tailwind is that on one hand it pretends that it's a lightweight abstraction (or not an abstraction at all[1]!), while at the same time causing confusion and degradation of knowledge of what it's supposed to be abstracting.

And then there's the insanity of seeing dozens of utility classes on elements, where if you're not careful, each one could look and behave slightly differently. The number of times I've been tempted to just change the margin value on a single element to fix something is too high. It reminds me of the ` ` and single-pixel GIF spacer hacks we used decades ago. The claimed solution to this are components, which sometimes are not a good fit, or grouping utility classes into a single class, but then why am I using Tailwind at all? There are also libraries like DaisyUI built on top of Tailwind to resolve this problem, but the thought of piling more abstractions on this Jenga tower makes me shudder.

I can understand why developers who are not great designers would find it appealing, and how it could be useful while prototyping, but in both cases using plain CSS (with some pre-processor, if you must) would be more maintainable and beneficial for the developer in the long run, while only slightly more inconvenient in the short-term.

[1]: https://news.ycombinator.com/item?id=33787346

>All of this adds a considerable amount of mental overhead while developing

Not in my experience.

> Recently, upgrading from v3 to v4 in a Next.JS project, which was supposed to be a no brainer, turned out to be a four hour ordeal.

You might think that is too long but that amount of time to migrate IMO is short.

What I am dealing now is a mix of styled components, SCSS and global styles. 4 hours is not even close enough to deal with half of it.

I will take TailwindCSS any day over this mess.

i think theres a divide between people who have worked in good front end repos and ones whove worked in horrible ones. I had to work on an app that was a mix of styled components, scss, inline styling, and globals. It was a wreck and every change took longer because of all the spaghetti styling you had to eat, Id take tailwind in a heartbeat over that.

>Marketing wins

TIL that I have just been manipulated and that my joy of using it is really just ignorance. Good to know.

"CSS is not too complicated. It's a good way to style HTML elements."

Humans think comparatively. So, it might help to tell them what CSS replaces.

HTML has many structures: text, images, links, tables, divisions, etc. We'd have to style them in a procedurally-generated layout. We'd learn a GUI or 2D graphics engine. Maybe several, use a cross-platform with its limits, or write our own. At one point, we needed native extensions like Flash.

Learning all of that would be difficult even for an experienced programmer. Whereas, many casual coders have learned CSS fairly easily. Then, it's usually just a matter of twiddling with it until it works right. Also, browsers make the twiddling cycle fast and easy vs testing homebrew GUI's.

So, it's definitely easier most of the time. It's not always what's best. It's a nice baseline for HTML, though.

My experience was the opposite: I picked up HTML-based web design quite easily, but when CSS came along, it was so finicky that I was never able to make it reliably do what I wanted. Everything seemed to be connected to everything else by invisible springs, so that if you breathed on one thing a little funny, something unwanted would happen somewhere else. I ended up abandoning web design altogether rather than continue fighting with CSS.

With traditional HTML layout, I could just write out a document, and reasonably expect that it would come out looking right: but using CSS was a frustrating, trial-and-error process, where it was often easier to change my design to fit what the CSS was willing to do than to suffer along, wrestling with endless side-effects, trying to make something happen that would have been easy with tables.

"I picked up HTML-based web design quite easily, but when CSS came along, it was so finicky that I was never able to make it reliably do what I wanted. "

That is true. It's easy to learn. It's easy to get to do straight-forward things. It's too unpredictable in many, use cases where an alternative layout might be used. However, those required actual programming on top of executing, third-party code.

They went with usually easy and safe for better or worse.

Something at the level of bootstrap or daisyui makes a lot of sense to me, a developer.

But designers I've worked with -- and I've really got to defer to their expertise here -- often seem to be too constrained by the fixed design structure on what I'll call "signature" sites or pages. For things that aren't that important/visible, sure, these general systems work well enough. But for other things, there's a specific vision they are trying to achieve, and forcing that through something like daisyui and bootstrap is a hell of a lot more work (for me) than building from css directly, or from utility classes like tailwind provides.

I think the reality is, the developer is building *app-level* components from html, css, and js. Naturally, you reach for something to take drudgery out of it, thus you work in terms of a middle-level abstraction. daisyui and tailwind are both such abstractions, so from a high-level there's isn't really much distinction or argument to be had. tailwind is somewhat lower level and more flexible while daisyui does more for you at the cost of reduced flexibility. Obviously, you pick something like daisyui when you're pretty sure you don't want/need the extra flexibility of tailwind, or tailwind when you're in doubt. Since you're going to have an app-level library of components, it's just not a big deal either way, just a matter of how pleasant it will be to develop and maintain those components.

Lately I’ve been using bootstrap grid only and been happy with that.

I think for getting in the 70th percentile of UI design, tailwind + daisyui are fine. If you need to have the absolute best UI, it is necessary to understand CSS from the ground up.

Isnt daisyui exactly what we were doing before the tailwind stuff came about? Are we now full circle again and need an entire plugin to handle this?

Yep, this aligns with what I think. Gonna check out your website about CSS. In my experience when I need to do some CSS, of course I need to look up how to do things, but I get into it and then it is rewarding, making something work nicely with minimal code. I made a personal website that is responsive without media queries at all. Requirements vary, but when you have a good grasp of CSS and don't rely on other stuff doing CSS for you, you can write good modular CSS, that just works.

The tailwind page doesn't manage to have responsive layout that doesn't jump around at arbitrary widths. Instead of floating/moving elements seamlessly when the width is reduced, they suddenly jump around to their next position. This is rather "meh", not great. I guess they go full in with media queries.

I think CSS gets all the flack it gets unfairly because people often run into it as a byproduct of other work they do. Whereas these developers probably aren’t running into windows/macos/ios/android app development.

I’ve ran into almost all of this, and css is still the worst thing in the list. It’s literally the highest wtf/gfy per minute among all. Barely debuggable, inconsistent, comefrom by design, inarticulate crap.

Especially since all the things that one would expect should be easy were just really difficult to do for a long time, things like vertically centering, layouts before grid/flex, changing a style in one place and not accidentally breaking some other part of html. There was a lot of tribal knowledge about browser quirks, how to clear floating divs for example, selector precedence, how margins collapse, etc, it's all just non-essential complexity that bites you in the ass when you have the least time to deal with it.

Exactly. Css is magic, in a sense that you can’t make any sense of it. Just look at this: https://stackoverflow.com/a/19719427 , you can “tune” collapsing margins by adjusting overflow, float or position. Yeah! Imagine adjusting your seat by pressing brakes or turning radio off.

Perhaps the only difference when using hidden is the unintended consequence of hiding content if the parent has a fixed height

This is css community fundamentals. It works “perfectly”, but make sure your height is not specified. Oh, and don’t change the container type. And with time it all depends more and more on other hacks, until your layout turns into a knot of hacks and cross-sectional assumptions smeared all across the “codebase”.

And then you ought to make fully isolated non-leaky components with it. I mean, you can’t, but here’s a hack to make them fit together. I mean, in this particular case, wow thank god the container is already position absolute.

> Just look at this: https://stackoverflow.com/a/19719427 , you can “tune” collapsing margins by adjusting overflow, float or position. Yeah! Imagine adjusting your seat by pressing brakes or turning radio off.

The seeming complexity here is because people refuse to learn the box model, so they learn all sorts of incantations and guess at what they need to do: https://developer.mozilla.org/en-US/docs/Learn_web_developme...

C is magic in that I can’t make any sense of it when I don’t bother to learn it.

Thanks for not posting the link to the “boxing model”. It gets posted every time, as if web/css invented boxing and padding and spacing and borders, and everyone else was a clueless noob. Which clearly shows inability to even comprehend both the problem and how deep css guys are into the bizarre ways of thinking about layouts that css suggests through its paradoxical under- and at the same time over-engineering. Where everything is a combination of crutches that can’t stand straight on their own.

And yes, C is a pile of crap too. I programmed in it for 15 years.

Agreed. No static typing. Everything is global. Super easy to accidentally break a thing on some other page that you aren’t aware of. It’s just a brittle stack. Tailwind is by far my favorite bandaid for dealing with all of that. Perfect? No. But it’s the best thing I’ve used in almost 25 years doing this professionally.

What are you talking about? CSS is statically typed. It has a fairly strict, well defined schema.

Most of CSS is indeed statically typed (property have statically typed valid values). It's not true anymore when you introduce custom properties and IACVT though.

Custom properties can also be typed https://developer.mozilla.org/en-US/docs/Web/CSS/@property

Idk what gp meant, but css lacks what could be called “selector accounting”. You never know which parts affect what and whether they affect anything at all. Because instead of importing/use-ing styles or classes, it imposes styles over some unpredictable set of nodes through a selector. On top of that, every name is global.

This contrasts to every modern language, regardless of declarative or not, where to get the effect you import it explicitly into a chunk/block/component/etc.

If css was C, it could add “unsigned” to every first int variable in a function that goes after a typedef. Which was part of “aspect oriented programming”, which was deemed an absurdly bad practice, to put it simply.

The sad reality is that younger folks are too busy learning JS and backend devs just don't understand it. I've yet to learn new CSS patterns from anyone I've worked with in front end in the last 6 years. On the same note, I've worked on a few teams that have made backwards decisions and have chosen dead tools instead of embracing new CSS patterns. I think I have to take Ana Tudo, Lea Verou and Rachel Andrew for doing enough advocacy to keep my skillset relevant.

Thanks for all this.

> And if you do understand some CSS, getting to the next level and learning how to write scalable CSS is not much harder.

I want to believe.

I know some CSS and can write SCSS. But reaching the next level seems difficult.

I haven't had a chance to read the all the comments so this may have already been mentioned further down the line, but -- IMO mastering CSS (vanilla) is essential to understanding how browsers render content, which itself is vital to understanding how to structure content (and by extension, write browser JavaScript)

Just learn it! It's worth it. It also makes Tailwind and all those abstractions way easier to grasp.

P.S. Sass (SCSS) is incredibly powerful. Learn that too!

> Tailwind is just a collection of predefined utility classes which you then over use, breaking a few clean code principles along the way

I mean, if you're talking Clean Code the book, I think Tailwind does that "break it down too far" part pretty well.

CSS has way more features today than 15 years ago but is easier to master in my opinion.

Back then, CSS implementations had a lot more quirks and you had to keep all of this in your head. Just because one combination of CSS properties in Firefox worked one way did not mean it worked even similarly in Internet Explorer.

Every time that I see someone talking about Tailwind like a panacea, I put weird faces. For looks a weird way to write a style attribute to a HTML tag. Something that MUST be avoided.

CSS is overly complicated for how little it does. You have to learn it. For comparison, when I did Android development, I never had to "learn" how their xml DSL works, it's mostly "just work"tm.

Android has constrain layout, css is now at level 4 and still doesn't have it, it has at least 5 overlapping layout mechanisms. I guess more choices are always fun, if you are a code poet instead of an engineer.

CSS was designed without engineers' consideration, while these days it's mainly the (front-end) engineers that write them. No module system, and integration to the rest of the web stack by APIs that feel accidental, class=? <link>?, var(--?), centering things...

Don't even get me started on css frameworks, why do I have to do so much work to style on the web, while it's barely any cognitive load to style on any other platform?

isnt daisy ui basically just doing what bootstrap did back in the day?

It's astonishing to me how many front end developers refuse to learn how to use vanilla CSS and Javascript, and the lengths they go to avoid touching them. I think of a lot of modern web tooling as a giant mech suit developers climb into to do battle with the underlying technologies of the web. There's so many layers of abstraction between you and the medium you work in, you can go your whole career without learning how to build a website yourself.

The original justification was 'scaling' (a word that stands behind a lot of bad behavior, actually), because you cannot just write bare CSS for a large production website, obviously. But then it creeps down the ladder until pretty soon your hobby website is a 20 megabyte SPA with 500 NPM packages backing it.

I think you miss the point.

Having 25 developers trying to manage a CSS stylesheet together while naming classes does not scale.

Having 25 developers not worry so much about stepping on other people’s toes with Tailwind scales better.

Or in a nutshell: What is one of the hardest problems in CS? Naming things. What is Tailwind’s biggest feature? Build a frontend with minimal need to name things.

CSS modules solved the classname collision problem years prior, though.

When people say "CSS modules", I never know which one they mean. There's a feature on the spec track for CSS "imports". There's also a family of webpack plugins with various behavior. CSS modules, collectively solved it a number of times with various trade-offs. You can even end up with multiple kinds of CSS modules in the same code base.

25 developers working in the same module? Without a common style?

Afaik we came from plain CSS -> BEM, because scoping styles was hard, so people found a discipline in naming things to isolate styling. Scoping did not exist in CSS.

Then we got a movement from BEM -> Tailwind, because doing the scoping by hand was a bit difficult(?)

Then we get Tailwind -> Tailwind + DaisyUI because Tailwind results in messy concretion.

--------

The question I have: are the modularity/scoping primitives in modern css good enough now, rendering Tailwind e.a obsolete?

Are we still using Tailwind because people do not understand the original problem?

Maybe someone can enlighten me.

Going from plain CSS to BEM more or less meant abandoning the "cascade" part of CSS. We've basically spent the last 15 years styling our markup directly, bouncing back and forth between different strategies for doing so in the most capable, and aesthetically palatable way possible.

Why on earth would you ever have 25 front end developers editing the same classes in the same stylesheet?

12 year old project, 2 developers per year, turnover every year. That’s all it takes.

> Having 25 developers trying to manage a CSS stylesheet together

Your comment suggests you mean 25 developers simultaneously

2 developers per year can easily maintain a coherent stylesheet.

> does not scale

CSS already has @layer; and @scope is coming (waiting for firefox).

There are naming conventions like bem. There are also tools to guarantee unique class names (css modules, 'single-file components' in various js frameworks).

There are design systems to standardize and reduce the amount of CSS.

There are web components, with their styles encapsulated in the shadow DOM.

Hard agree, written Tailwind since the very inception. I love it for exactly this, the purging, JIT, arbitrary values, plus you can just write plain CSS any time you want. I have used Tailwind on big FAANG sites and boutique shops. Worked great for both, scales, and is very customizable.

> Having 25 developers trying to manage a CSS stylesheet together

As opposed to 25 developers trying to manage a React component together? I don't think that's feasible either.

Hence why companies adopt UI toolkits, otherwise it gets messy. Without discipline it's hard to develop a set of core components and often times devs will duplicate work and fail to extract common parts due to the nature of working on features across the stack and failing to recognize common patterns.

My point was, you use the language features to separate concerns into manageable pieces (which CSS can do just as well as TypeScript).

Tawilwind was created at a time when we were still feeling the IE days, triton was still a thing and people generally had to look up resets or how to setup tooling to help them with vendor prefixes (that was before Interop was a thing), etc. All this while, designers would ship individual design tokens for implementation (e.g. a button, a combo box). Things like “styled components” would feel like a relief because “oh I can style a button without breaking the entire website”.

Since then, all these points of friction have been improved or removed all together. We wouldn't lose anything if we revisit the platform and see how we can get all the benefits of tailwind without actually adopting it by default.

By the way, the same argument can be made about React and revisiting what one can do with modern DOM features.

I guess something all frameworks born in the past to solve real problems have in common - we tend to forget to deprecate them once the underlying need for them was gone.

It has never been easier to build web applications with a vanilla stack.

In 2010 there existed incredibly solid arguments for abstraction over the DOM. You had browsers with insane quirks and you had no choice but to support them. Over a decade and a half later, I'd argue we are in a completely different world. The only browser that bites my hand these days is Safari, and it's barely a nibble compared to what we used to deal with.

Those who adapt to the new reality will likely outpace those who continue to hobble themselves with rusty old training wheels.

As with any profession, most workers are just proficient in whatever they need to do. The people littering these things with comments about how Tailwind is "enough" are probably telling the truth for their personal experiences. A lot of web developers don't have professional experience working with designers and implementing software to visual specifications.

> and Javascript, and the lengths they go to avoid touching them.

I love CSS. I can make it do a tap dance and enjoy getting into the weeds with it.

JavaScript… is an entirely different ball of wax.

You see, I was there in the beginning, where major breaking changes in JavaScript existed not only between the major browsers, but also between point releases of the same damn browser.

I tried. Really, I tried. But after a few years I realized I had an epic case of PTSD where JavaScript is concerned, and to this day I see it as Lucifer’s own programming language, explicitly designed to drive developers mad.

What compounds this is a total refusal by the developers of JavaScript to do what every single other programming and scripting language out there has done copiously, and even eagerly - to deprecate old and obsolete features, and especially bad design choices. JavaScript does none of this, choosing instead to layer more inadvisable workarounds over already-traumatizing bad decisions.

Which is why I eagerly await the death of JavaScript at the hands of WebAssembly. Good riddance to a pox on the Internet.

I’m forking Shopify’s polaris-react library for my personal use and some of the components are clearly made to people who don’t know how to use CSS.

For example, there’s a component called “InlineStack” which is just a javascript wrapper for a div with flex. This stuff drives me nuts.

The benefit of components like InlineStack is that the components then have names that semantically describe their purpose in the layout.

The fragmentation this creates is not worth it, we're building the tower of Babel of web technologies. If you look at 'modern' web applications every html component is rephrased into something like this 'inlinestack' crap.

The tower of Web Babel was built 5 years ago during peak React. It’s gotten better tbh as more competition has creeped into the web space due to React dropping the ball and resting on their laurels.

While I understand the gut reaction to seeing something like InlineStack, it’s not any different than a utility class except the abstraction has been made on the component level instead of the CSS level within a bunch of different components. The other thing is that these types of components provide a layer for abstraction that extends beyond the web. If I’m writing a app that targets web and native mobile, I can let the compiler decide which version to place in the build to take advantage of native features of the platform.

At a certain scale, programming becomes about maintaining consistency at said scale and less about the craftsmanship of an individual component. As a developer who also enjoys writing CSS and building layouts myself by hand, I understand your frustration but it’s misguided towards a group of developers who are trying to solve different problems.

We don’t need to implement everything that FAANG comes up with in their “innovation labs” and I 100% believe that there is a place for handcrafted code in applications for decades to come. But let’s not lose site of the fact that table saws haven’t replaced hand saws. They serve different purposes for different audiences and that’s okay!

Don’t forget that components also add more runtime complexity.

Not to be pedantic, but I am legitimately confused about how the babel of tower metaphor is being used here. In biblical lore, the flaw of the tower of babel was that it too successful as a unifying project. Is this what you mean in regards to react? It seems that other comment meant the opposite.

I’d personally prefer to write markdown instead of html, especially when writing comments on sites like these.

But I have to know that stars represent html italic tags (and bunches of other stuff).

Thankfully this has been standardised and every markdown parser knows what stars mean. So I only have to learn this once.

Most frameworks haven’t been standardised and that’s where the frustration lies.

Abstraction is good when it becomes a commonality, bad when it remains niche.

Why is InlineStack any more semantic than say FlexDiv?

Semantics is at some point arbitrarily agreed upon and memorized.

It's not, FlexDiv is just another name for Stack, they are describing the same aspect. Eg. you can imagine one CSS library using Flex, one Group and the third one Stack for the same concept, eg. some other UI frameworks use VBox and HBox. But it is still different from TopSectionHeader, SectionHeaderInner, SectionBodyWrapper, or whatever other names you have to come up with to give your component "semantic" meaning according to their content.

> to give your component "semantic" meaning according to their content.

This is one of the biggest pros for Tailwind, is that it leads people away from this misbegotten mindset. The scare quotes around "semantic" are right. It's amazing how many of the same people stress separation of concerns to separate content from presentation, then turn around and name the presentation after the content.

I instead use <div class=“flex”><\div> now.

If the class name is not enough for me to guess, I just hover the class name and the LSP will show me the applied styles.

Another issue is that Shopify changes the name of these components for no reason, for example InlineStack was once called Inline, then HorizontalStack, then InlineStack, while the flex box model hasn’t change since 2012

Naming things is hard but I feel like there is something odd about a class name referencing a single CSS property as it is basically an inline style: <div style=“display: flex”></div>

Not sure why it matters, <b> is the same as <span style="font-weight: bold">... If you want, name it "stack" or "vbox" instead of "flex".

Because flex just references the layout engine, and div intentionally has no semantic meaning. Fwiw I don't think InlineStack is a particularly good name either, but the criticism of this needs more justification than just "it's not how we did things in the past".

Semantics evolve over time. This is true of natural language and coding practice.

It's a bit like the <center> tag. A codebase that's littered with stuff like "InlineStack" is harder to work with and parse because the resulting div soup still requires extra styling, which is now both markup and CSS.

Why is it harder to work with? It makes it immediately obvious what the visual layout is and what the purpose of the component is and a lot of time all you want to do is have a flex on a component and you don't need other CSS to warrant yet another CSS class. It's the same reason why utility CSS was created (eg <div class="flex">). It also saves you from having to come up with a semantic name in your CSS for every wrapper.

Compare the following:

    <Stack gap={2} direction="row">
       <Box>
         <Avatar />
       </Box>
       <Box>
         <Button />
       </Box>
    </Stack>

    -----

    <MyCustomWrapper>
        <InnerChild>
          <Avatar>
        </InnerChild>
        <InnerChild>
           <Button />
        </InnerChild>
     </MyCustomWrapper>

I think this looks way simpler

  <div className=“flex gap-2”>
   <Button/>
   <Avatar/>
  <\div>

Then just apply the box styles using *: selector or directly in the component

Because sometimes you just need a flex wrapper. And it's easier to see InlineStack everywhere in your JSX than deciphering the layout from mixed CSS. Whereas plain CSS separates some concerns away from HTML, it also intermingles different concerns together, like layout, positioning, spacing, look & feel, etc. At least with structural or utility components like Stack, Group, Flex, or whatever it makes it more obvious what the intent is.

Then you are doing something wrong about the layout & components in the page.

I'm in good company with all the modern UI toolkits and css libraries that have utility classes and container components which make the code I write reusable and composable. It's way better than using classes as "hooks" to style the markup and end up with a nesting of selectors to specifically target elements. You could compare it to HTML actually, I use a <stack> the same you would a <table>, and not reinvent with some custom wrapper like <div class="basketball-scores"> just to have a name attached so I can style it.

You're leaving out the most important bit of a component like InlineStack: the props [0]. Yes you can just apply `display: flex` to the div you're working on, but like any proper abstraction these guardrails make using flexbox correctly the easiest path forward (the "pit of a success").

[0]: https://github.com/Shopify/polaris/blob/eb6161f6b4e02679b5e8...

CSS for styling is straight forward (which makes sense since ‘CSS’ is cascading ‘styling’ sheets)

CSS for layout takes sometime getting use too.

For me, the benefit of any css framework is not in prepackaged styles - it’s in simplifying layout for desktop/tablet/phone.

For me TailwindCSS actually was helpful in learning CSS. You still apply the same core CSS fundamentals. If you created a complex layout in Tailwind, you can also do it in normal CSS. I look up the exact rules behind their classes frequently in their docs.

If you just copy classes and don't care to understand them, it's a different story of course.

You don’t apply the same core fundamentals because Tailwind works to specifically remove the core fundamental of CSS: the cascade.

I guess, but that has certainly been a huge relief in my personal experience.

yes, specificity wars make it really hard to reuse components across multiple product domains and teams within a large org.

by css fundamentals, they just mean what the various style properties do.

Also removes the sheet, fwiw

How does tailwind remove cascading? It's just css classes.

The mastery to front end development is understanding the semantics of HTML.

At every single company I worked for, I had to teach people to stop using div tag for everything. You can style things however you want, or even create components that the browser does not allow you to style (as long as you have fallbacks).

Does HTML even have semantics? You practically can use div for everything, and then use CSS to make it act like whatever component you wanted.

You should let the defaults do their job, but they don't do very much. HTML's main semantic is to give things a hierarchical structure. Visually it's a free for all after that

Yes, html has lots of semantic elements.

https://developer.mozilla.org/en-US/docs/Glossary/Semantics#...

> but they don't do very much

no no no, different elements have different behaviours. for example, a button automatically has accessibility features like being able to tab to it and select with Enter key, which is essential for a screenreader. do that with a div and you end up building the functionality from scratch.

if all you care about is the visuals, sure, there's little difference, but once you scratch the surface you will have a poor product by not using the correct elements (where there is a clear "correct" ofc, sometimes it's subjective).

it's also essential for keyboard navigation. accessibility is not only for people who have some impairment!

Svelte 5 does a great job of raising warnings for this. You try to use an onclick on a div you get warning to make it tab-able and give it an aria role, and a reccomendation that you should probably be using a button.

> I had to teach people to stop using div tag for everything

Can you elaborate a bit on what you mean please?

I've seen juniors style divs as buttons, it's disheartening.

I’ve seen seniors do the same thing.

The root cause always seem to be the same.

Pressure to get things done now. No time in the future to correct things. Possibility of getting fired for falling behind your peers that make the same shortcuts while you attempt to do things better.

It’s always an issue with management that doesn’t care about doing things correct. So the incentive to keep your job is always perverse.

I beat this drum for a while, got ignored, and dropped it.

Then an accessibility lawsuit came in and suddenly people were very interested in the semantic meaning behind each tag

> I had to teach people to stop using div tag for everything.

And the crazy nesting of divs 5, 10, or even 15 layers deep.

Like… _no._ Just hand your senior card back to the issuer, and go back to being a junior. If you cannot create a simple layout with only 2-3 layers of divs _at most,_ there is something seriously wrong with your front-end skill set.

"Knowing" CSS in these days is nearly impossible. There are so many language features. Don't get me wrong: CSS today is cool and nearly anything is possible (can Doom run wirh CSS by the way?), but I work as frontend dev for years and I have not the feeling I really know CSS in depth

I think the doom() function is still getting rolled out across the major browsers. IIRC newer versions of Chrome have a working implementation.

These jokes, as lightheartded as they are, need to stop. Especially true on here.

how many features does CSS - the language - have now in comparison to JavaScript?

How many features do the various APIs altogether have.

How many features do the various object models have, CSSOM, SVG DOM, HTML DOM, Shadow DOM...

What is your knowledge of all these features in comparison to CSS features?

Jumping off of that and go look at any mature language and CS subject, there is probably too much for you "know" completely, but there is of course possibility to "know" a general argument for how to use it properly, once that is known individual things is just looking up syntax.

ok evidently someone thought that all of these things are easier to know than CSS, which is just ludicrous, and gave me a downvote to let me know their disapproval of my opinion.

Very Classy. But not CSS Classy.

I wouldn't get too hung up on downvoting online, ignoring deliberately malicious actors the range of reasons for downvoting can go from "this person posted a hate crime" to "other people already posted something close enough to this" or even "this person gave a perfectly valid answer but it does not feel like it's taking the discussion in the direction I feel it's meant to go"

I know, just every now and then it is particularly weird and I comment. Also it was real quick, like I had said something so offensive it needed to be pounced on. :)

There is knowing and there is knowing.

I don't pretend to know every dark corner of typescript, neither for CSS. But knowing enough detail to be efficient and write maintainable and easily extendable code is important.

Don't let perfect be the enemy of good.

After reading mixu/cssbook I felt I knew and understood CSS quite well. But it was 10 years ago! Every new feature brings new edge cases that combine with all existing edge cases. Add some features like WebComponents and you have far too much undefined behaviour.

What undefined behavior have you encountered with CSS?

Tables and Web Components combined with grid or flex is where magic happens.

I think knowing what to ask and where to look represents mastery of CSS.

Understanding the approximate power of things like flexbox and having some aesthetic taste is much of the battle. You have to be willing to get your hands dirty. CSS is almost entirely about art. Figure out which paint brushes and techniques work best for you. There are a lot of viable paths.

That was then, now it is a 3d engine.

No, it has a 3d engine, one that you can happily ignore 99.9999% of the time. CSS has a few gotcha, a few things to got to understand about it (selectors, selector priority and the way content flow depending on absolute / relative positionning), but it is not an impossible language to pick up, far from it.

As the grandparent comment said, don't let the perfect be the enemy of the good.

My problem is that having it makes me want to use it.

It just sounds like you need to spend more time solving problems with CSS. "Knowing" CSS means being able to style most things without needing to check any resources or otherwise look for help.

Occasionally there might be a particular issue that requires contemplation or reading the manual, but that is true of any sufficiently complex design system, especially a living specification such as CSS.

I recommend familiarizing yourself with new features as they are adopted. For example, front end devs are going to need to learn Houdini.

I spent some honest time solving the problems in css. You know what was the industry/search approved solution 90% of the times? Some greasy hack that assumes sizes and doesn’t translate elsewhere or generalize into experience. You just start to know how to make a single x of X, but X is still as big.

Css is a pile of low-effort crap targeted specifically at ad-hoc problems web designers had. It can make front pages, and sucks at everything else.

That was way back, things are a lot better now than they were 15 years ago. Anyway, I got by quite far never assuming sizes with hacks like `height: 0; padding: 100%;` etc. But that kind of stuff is almost never needed today to get good results.

> It can make front pages, and sucks at everything else

I've made some very slick apps and widgets over the years using CSS. CSS isn't the problem, a lack of imagination is. CSS actually covers quite a lot of cases today, and with Houdini etc being exposed, the sky will soon be the limit.

This overcoming is pretty much the spirit of css, while in other gui frameworks you just do things. They don’t require imagination, just straightforward geometry. Presenting it as something cool is idk, don’t have a constructive word for that.

Again, modern CSS is much different from where things were 15 years ago.

I see that you’re confident in css. Maybe you can help me with a simple task that I struggled with recently. (There’s a mountain of these but this one is fresh.)

There’s a flex-row-wrap root with grow-1 containers. Each container is a grid with two columns: fit label, auto control. Visually it’s row of forms of auto-size. Sometimes I want to put a long text into the control column, e.g. as a description of a preceding input. But it participates in size request and makes its grid expand and take all space in a flex row, or more. I want it to request zero space instead, as if it wasn’t there, but take whatever other “controls” received.

In a proper boxing model of a non-web library 15 years ago I’d set the text’s “size request” width to a small value and put all control-column elements into a size group. So they all request the same (max among) width. The predictability of the size request-allocate loop makes it trivial to figure out.

I expect some sort of ad-hoc restriction on either a grid, controls, flex root, whatever. It’s a good chance to disprove me and explode my imagination.

I knew css at a time, then it ran away from me and mocked me from afar.

In this age of LLMs and AI, the incentive to master CSS is even lower.

Frankly, I feel like it goes even further than CSS. People don't really talk about HTML that much, probably just because it doesn't change as much as JS frameworks, etc. But that doesn't mean you should ignore it completely and just use a bunch of divs!

When you start digging into all the different HTML elements and aria guidelines (for example, the differences between `<nav />` and `<menu role="menubar" />`), I think development starts to be a bit more clear, because you start to see how your tools are intended to be used. I think it also makes decisions around CSS styling more clear. And as a bonus, your code just starts becoming more accessible, which is nice.

https://developer.mozilla.org/en-US/docs/Web/Accessibility/A...

This is why I fully moved to flutter. Everything, including styling, is just a widget. It’s surprisingly liberating to write boring C# looking code that accurately describes a UI component without inheritance, overrides, style compiling, etc

Hi. C# dev here. Would you please elaborate a bit how do you use flutter and C#?

I think he means Dart code resembles C# pretty closely.

Same, as C# dev I love Flutter. However I just know in my bones that Google will ditch it some day. It's been too many years without significant adoption and it will stop making sense in the corporate spreadsheet one day.

At least according to this post which was on HN recently, Flutter lacking significant adoption is a myth: https://shorebird.dev/blog/dart-macros/#:~:text=Flutter%20ha...

Basically why Flash ruled back in the day.

It also throws away HTML and throws everything on a canvas instead, which means three things:

1. Accessibility is now an afterthought

2. Giant runtime you have to download for every website

3. Bewildering non-native behaviour on mobile

Agree with you on the runtime. Things are better with wasm and wasmgc, but still you can’t use flutter for any website that cares about SEO.

However for the “app” part (after sign in) it’s a one-time download, cached by service worker, only takes a split second.

It would be really nice if flutter could produce a AOT compilation of the “semantic” HTML for the initial page and then hydrate it. Then it’d be pretty similar to waiting for JS bundles for interactivity.

My main gripe is that the DOM backend never took off. The WASM <-> DOM interop is cheaper than ever, especially if you bundle operations so that you don’t need to cross it as often. Still, they decided to implement everything from scratch :-(

> Everything, including styling, is just a widget.

And that's the downside. What would be just two or three nested <div>s in HTML+CSS turns into several screens of widgets, making navigation and debugging much harder. I once had an issue with extra margin in one of Flutter's built-in widgets and spent hours trying to figure out why - without success.

Between Tailwind and LLM generation I doubt I'll ever write more than a handful of CSS lines by hand in any future project I work on. CSS has, for me, become like the ASM output of the compilers I use. The result is good enough 99.999% of the time for me and I want to work at a higher level of abstraction.

The downvoted comment is correct. The only CSS I've used in the last couple years has been to debug issues Claude couldn't resolve - and to delete excess styling that wasn't being applied anywhere.

It has given me the flexibility, accuracy, scalability, and proved the test of time (going strong on 3 years)

Interesting, I can type CSS much much quicker than describing to an LLM what kind of layout I want and with what look

I find LLMs are best for creating the template, or filling in gaps of my knowledge. Examples:

1. Using a prompt like "Using Tailwind, create a three column layout with main content in the center column and smaller side columns for ancillary information" will generate HTML + CSS faster than I can type.

2. I use the LLM to generate some CSS styling for setting a background blur, which was something I hadn't done before using Tailwind. It created code faster than I could find things in the documentation, though I had to go and patch it up later. In essence it pointed me in the right direction.

If I'm looking at a preview and want to change the styling of a particular element it is usually faster to directly edit it myself than get an LLM to do that. Tailwind makes this faster as the CSS is right there on HTML; I don't have to switch between stylesheet and HTML.

1. I’ve mostly gone to the grid section of the docs of whatever framework I’m using (bulma these days) and copy paste the example, then copy paste my own code when I have enough pages done.

> Tailwind makes this faster as the CSS is right there on HTML; I don't have to switch between stylesheet and HTML.

I mostly use the web inspector for live edits to get a feel then I copy over the final result to the sheet. For more complex components, I use Codepen.

Wow, so much hate against CSS here. I like CSS. I first learnt CSS in 1999 or something. Granted, it has grown much more complex (and powerful) since then, it has a lot of quirks, but it's not that bad.

Lately, I've built simple websites and small web apps in vanilla Javascript and CSS, without using any framework, and it's much more enjoyable than years ago.

> Lately, I've built simple websites and small web apps in vanilla Javascript and CSS

Any public links?

See this for instance: https://atlas.internationalbrainlab.org/

All vanilla JS, HTML, CSS, SVG, except for the 3D widget which is based on Unity.

I agree wholeheartedly. And IMO, CSS isn’t even difficult, it just requires you to properly and effectively visualize the cascade to handle downstream effects.

My problem is when people start using cognitive crutches such as LESS and SASS, which bloat the CSS immensely with insanely redundant styling. I once took a generated CSS file from a “professional” and cut it down from over 500kb to less than 180Kb with zero loss of functionality or presentation. One HTML widget had separate - and absolutely identical - CSS for each and every single one of the 25+ pages it was present on. That was 250+ lines of CSS, instantly evaporated by consolidating down to one common class and two special cases that had extra stuff. Which is insane.

At this point, if you know how the box model works and the difference between margin and padding, you're ahead of 50% of "frontend developers".

I agree. But I feel like nowadays knowing CSS is not necessary to land a job in FED - while knowing frameworks as React/Next/Vue/whatever is.

The idea is that by knowing HTML and CSS you know how to use any framework. Since they are the base technologies that every front-end developer should know, a frameworks should build upon the principles of these.

This doesn't hold true for React, since they just decided to do their own thing, but for frameworks such as Svelte this is a core principle they try to stick to.

Svelte is the only framework I have come across that is actually tackling the problem of front end bloat and I love it

HTML/CSS was on most job descriptions I saw. Entry level wanted those and Javascript at a minimum. Your odds are better if you know all three.

> HTML/CSS was on most job descriptions I saw.

Those are going to be on nearly every FE job description you see. I think OP's point is that they are not necessary to land a job despite their automatic inclusion in the job description.

(Speaking anecdotally, the companies I have worked for either don't have any CSS masters to sufficiently test for mastery or don't include those experts in the interviewing process. Or, more commonly, we are so desperate for framework devs that any amount of CSS knowledge is considered good enough.)

When I am hiring, I will always prioritise devs who have a strong knowledge of HTML/CSS/JS over any frameworks.

If you know the language you can use any framework in that language with minimal effort, and the bonuses of being able to troubleshoot underlying issues is invaluable.

The comments here remind of the "Git isn't hard to understand" humblebrags that we hear again and again on this forum, surrounded by a sea of honest and justified criticism.

If lots of people complain about understanding your product - intelligent people - then your product is hard to understand. Why is the important question.

Usability is a thing and can be improved in some things, but sometimes it’s people that don’t want to read the manual and instead spend their day chasing after abstractions. Which they will abandon at the first edge case they cannot solve because of the lack of foundational understanding.

It doesn't mean that the product is broken. Sometimes intelligence is the worst enemy of self, as you think you can easily understand something or not even have to learn it correctly, as it looks very trivial. This is the case with most software developers that trying to fit mental models from other languages to CSS and then expecting it to behave in the same way. Mismatch of mental models are not uncommon, especially in "intelligent people" as they don't always assume that their understanding may be wrong.

For me, biggest issue with CSS is how it's taught, how it's learned and mental models around the concepts. Most people have a different mental model of how the underlying system works, and this mismatch results in developer trying hard to bend CSS to his will.

CSS may be good or bad, there can be a better alternative... but are there any practical change that may happen soon enough that we stop learning and understanding how CSS works? Even we have a new language, people will try to use it as they used CSS before, so those intelligent people may do the same mistakes again.

We are stuck with CSS, whether we like it or not. I've been writing CSS since 2001 and it progressed immensely, still there are many things that's not possible to do easily with only CSS. But still it's the only thing we have for now and to make it better or to make a better alternative we have to understand how it works before just saying "i need a new tool", as the new tool may have the same issues as well.

CSS is not the performance bottleneck.

CSS is also not difficult. Tailwind is absolute nonsense imo.

Either write some good simple plain css, use a framework with scoped css which already completely eliminates the need for tailwind, or use JavaScript css properties (with a slight performance penalty).

The performance issues are because of use of heavy frameworks, unoptimised images and 1000 ads and trackers which nobody asked for (except management of course).

Css is a garbage api. Styling things should not be this hard. We are stuck with it because of tech debt. That’s most of web technology today.

> To me, the main reason is different: You won’t be a master at frontend development if you don’t understand underlying mechanisms of a language.

True for any paradigm, not just frontend.

Of course but that’s a too general statement. What developers IMO fail to get is that CSS is so different because it’s a language to express design and they don’t understand the basics of design. Almost all programming languages are about logic and taught at all CS / programming schools. But design mostly isn’t and is much more complex than people think first (check for example grid theory).

That is a great observation around logic vs design. Any resources you recommend for more design theory?

Definitely this one https://www.amazon.com/Grid-systems-graphic-design-communica... but also any other great book about design and architecture.

Design have two aspects, the doing (drawing, documenting, adjusting) and the thinking (what’s the actual problem and the concept to solve it, which will give me a frame of choices). There is a lot of content on solving the right problem - check the resources from IDEO, or for a broader view Don Norman for example https://www.amazon.com/Design-Everyday-Things-Revised-Expand...

Also don’t forget typography basics since most websites, apps and documents are mostly only text, there are lots of tutorials out there.

And geometry, which is high school level for the most part IMO but combined with cascading in the third (z) dimension. Introduce 'relative' with its own coordinate system and then do transforms in it (to be fair, its only complex in some cases like where the transformed parent is different from the relative parent). And then get into the time domain for transitions. Its math after all, but not the same that most programming courses teach.

> You won’t be a master if you don’t understand underlying mechanisms.

Think I got that in a fortune cookie once.

> Custom icons for an input field? Welp, it’s not that easy for privacy reasons to add a pseudo-class here in certain cases.

What exactly are those privacy reasons? And by custom icon for input field is meant replacing the cursor with e.g. an svg?

The only thing I can imagine is if they are third-party icons? I don't understand it either.

The issue is that css doesnt allow adding pseudo elements (:before/after) to input fields, making adding icons to an input a little trickier than with other elements.

For better or worse, I’ve been using Tailwind since it was released. I’m not even sure I remember intermediate to complex CSS. Better places to spend time. I’m really grateful for what that team has done.

CSS is one of those things you can become very effective with, without knowing it all. I really don’t think you need to know it all.

I also think it has a lot of tools you don’t always need. Don’t go crazy with selectors!

Why CSS Modules are so unpopular?

It's not standard yet. Behavior is implementation-defined and under-specified. A lot of people have used a thing like this[1], but this[2] is on a standards track. In the documentation for the first one, it describes a default "file scope", but really no definition of what a file is. It seems to be referring to a source file pre-build/bundle, but it really just doesn't say. That would belong in the documentation for some framework, not web platform stuff anyway.

The idea of locally scoped styles is reasonably popular. Like vue single-file-components, and n+1 different implementations of "CSS modules". What it really needs though, is standardization. Things like [2] and the upcoming @scope will provide this.

[1]: https://github.com/css-modules/css-modules/blob/master/docs/...

[2]: https://github.com/WICG/webcomponents/blob/gh-pages/proposal...

> In the documentation for the first one, it describes a default "file scope", but really no definition of what a file is.

Probably because if you don't know what a file is, you have a lot more you need to learn first. It's a bare basic fundamental that goes way beyond CSS.

But scope is true - CSS Modules like to pretend the CSS is specific to where it's used, and gloss over that some css attributes cascade to all children. @scope, and specifically the lower bound part of @scope, would fix this.

You missed my point about the files. Browsers generally don't see files in the way they're talking about. It's not a web standard. It's something for a particular bundle or build tool.

CSS is still a masochistic mess that should be replaced

If we were to replace it, what improvements would the replacement have?

htmx

CSS: The AI's Achilles Heel

On the contrary, I have found reasoning models (DS R1 mostly) to be very good at complex positioning and transition problems. They can't "visualize" anything, so can't design well unless you explain them well (which is the problem in design, most people have vague ideas but can't explain it well in CSS terms).

if you can explain it wel in css you might as well write it yourself :)

If only the web took xhtml path.

If only XHTML changed anything besides adding pointless backslashes to <img>...

what would it change?

Infrastructure as well.

I don't think anyone sane would let "prompt engineers" anywhere near their Terraform/OpenTofu/Pulumi/$OTHER code.

Giving write access to people who depend on LLMs (as in "can do almost nothing without it") is a recipe for disaster. Even giving write access to a junior is less scary than that, in comparison.

> people who depend on LLMs (as in "can do almost nothing without it")

This is what makes me afraid for the future of software development. Even in this thread you see people saying they "don't write css and just let the ai do it." I don't think I could work for a company where the devs don't understand the language and just have chatgpt poop out blocks of code until it works, but we're starting to see exactly that now. And worse: they're proud of it. It's terrifying.

Ironically I feel like these are exactly the programmers that are actually at risk of LLM agents replacing their jobs in the near/medium term.

I don't blame developers treating CSS like a target language for AI to generate.

Most sites are just CRUD. Unless they are working on a site that requires creative styling, people just want to get it over with and work on the "real" problems.

AI has maketh CSS obsolote

How so? That doesn't seem true to me at all.

I’m just being hyperbolic as a joke.

Master Css then get the AI to do it.

Reply on news.ycombinator.com