Earlier quoted context omitted.
“CSS is bad” Why? “Because reasons.” Care to explain? “No need to learn it anymore, my AI can do it for me” Okay, but why is it bad to learn it “Reasons” Uh… what?
[flagged]
Who are you talking to?
Moving away from Tailwind, and learning to structure my CSS
421–430 of 435 posts
Re: Moving away from Tailwind, and learning to structure my CSS
#422Relying on React or Typscript in LLM era seems very stupid, just have the LLM setup whatever dom manipulation you want and have it write decent JS without slop. Far more offline compatible development almost negligible supply chain issues as well. At least ones you can control.
I hope I never have to work with you.
get back to API calling whip noises
Re: Moving away from Tailwind, and learning to structure my CSS
#423Relying on React or Typscript in LLM era seems very stupid, just have the LLM setup whatever dom manipulation you want and have it write decent JS without slop. Far more offline compatible development almost negligible supply chain issues as well. At least ones you can control.
Why write in rust if LLM can write assembler for any architecture?
That's what another HN post a few days away was saying too lol but about Python
Re: Moving away from Tailwind, and learning to structure my CSS
#424Relying on React or Typscript in LLM era seems very stupid, just have the LLM setup whatever dom manipulation you want and have it write decent JS without slop. Far more offline compatible development almost negligible supply chain issues as well. At least ones you can control.
This makes no sense. LLMs and agents benefit from (good) abstraction as much as humans do.
Sure, just doesn't have to be npm or build dependent IMO
Re: Moving away from Tailwind, and learning to structure my CSS
#425Relying on React or Typscript in LLM era seems very stupid, just have the LLM setup whatever dom manipulation you want and have it write decent JS without slop. Far more offline compatible development almost negligible supply chain issues as well. At least ones you can control.
Layout design issues are orthogonal to choice of language and framework. You can apply the article's approach to plain static pages and to SPAs. I tend to work closer to the latter end and find that both React and Typescript are extremely helpful to make my code extensible and maintainable. YMMV.
We strayed away from god after jQuery
Re: Moving away from Tailwind, and learning to structure my CSS
#426Earlier quoted context omitted.
This makes no sense. LLMs and agents benefit from (good) abstraction as much as humans do.
Sure, just doesn't have to be npm or build dependent IMO
LLM agents are also very capable of using npm and build systems, and also get the same benefits from them as humans do. For very very simple things (again, just like for humans), it may be viable. But in anything non-trivial I would be horrified with a codebase that was just LLM-spaghetti-DOM-manipulation.
Re: Moving away from Tailwind, and learning to structure my CSS
#427Earlier quoted context omitted.
To be honest, CSS had the cascade but also had horrible tools for actually managing the cascade for a long time. If CSS had nesting, variables, media queries, the other nice selector queries like :has, and modules out of the gate, we likely would have not needed much of the tooling like tailwind that eventually got built to manage it all with less boilerplate. We built the tools because even when these features rolle…
When you say modules, is that @scope or something else? I can't find any reference to a native thing called modules but this seems to fill the same role.
So I guess modules is not native, but in a fair amount of JSX oriented systems there is a .modules.css file extension that build steps will recognize and automatically namespace with an ID linked to a JSX component.
Re: Moving away from Tailwind, and learning to structure my CSS
#428> I got curious about what writing more semantic HTML would feel like. I've been teaching semantic HTML / accessible markup for a long time, and have worked extensively on sites and apps designed for screen readers. The biggest problem with Tailwind is that it inverts the order that you should be thinking about HTML and CSS. HTML is marking up the meaning of the document. You should start there. Then style with CSS.…
you're unfairly conflating things and putting the blame for a lack of care or understanding on tailwind vs on the dev themselves. nothing about tailwind forces you to build inaccessible or "div soup" apps can tailwind be used poorly? absolutely. but that's true of any tool i've been writing CSS for ~20 years and am quite capable with it, having used CSS, Less, SASS/SCSS, Stylus, PostCSS etc. the reason i have settled…
> “…nothing about tailwind forces you to build inaccessible or "div soup" apps
can tailwind be used poorly? absolutely.
[…]
tailwind is like most tools; it can be used well or poorly depending on who is using it.”
Hmm. Your reply refutes the div-soup accusation, but doesn’t provide any explanation.
Re: Moving away from Tailwind, and learning to structure my CSS
#429Earlier quoted context omitted.
you're unfairly conflating things and putting the blame for a lack of care or understanding on tailwind vs on the dev themselves. nothing about tailwind forces you to build inaccessible or "div soup" apps can tailwind be used poorly? absolutely. but that's true of any tool i've been writing CSS for ~20 years and am quite capable with it, having used CSS, Less, SASS/SCSS, Stylus, PostCSS etc. the reason i have settled…
> tailwind frees you from having to spend excessive time building abstractions of styles/classes that will invariably change. Abstractions like a hero image, a menu, a headline? Sure, it's easy to overthink things but most of the time, it's not that complex. > placing the styles directly into the markup that is affected by it reduces cognitive load, prevents excessively loose selectors In my opinion, it's the opposit…
Tailwind violates DRY but DRY is also not a hard and fast rule. The danger with DRY is that it can force you to build abstraction towers that are difficult to reason about, especially in a static context. And that's where we see the power of Tailwind: I can look at any element and immediately see it's styling. The same is not true with classic CSS, which is additional cognitive load.
Also, DRY can still be somewhat achieved with tailwind by using reusable components, in whatever framework you're using. It could be React, but it could even be blade components in a traditional SSR Laravel app.
Re: Moving away from Tailwind, and learning to structure my CSS
#430Earlier quoted context omitted.
> Sure, it's easy to overthink things but most of the time, it's not that complex. then you sir are the one that have not worked on complex projects. i'm currently the lead on a design system for a fortune 100 company with nearly 100 block level components and many other smaller elements. responsive, multi-theme/site support, animations, accessibility, robust interactivity, etc. not even a button or link is simple wh…
if you're writing class="flex-inline width-30 font-large" it's even worse than inline css because it has an abstraction layer and dependencies. just write css, tailwind has always been total junk.
There are legitimate problems with using CSS, especially in a large team setting. I think we all have experience with append-only stylesheets. That's what tailwind addresses.