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.
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.
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?
> 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.
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?
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.
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.
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.
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:.
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.
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.
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.
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.
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.
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.
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!
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.
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"
> 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.
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.
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.
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.
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).
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.
> 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?
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.
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.
"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.
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.
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?
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.
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/