Utility classes aren't the same as inline styles (2021)
frontstuff.io
frontstuff.io
Full disclosure: I am biased toward Django, htmx, and Bootstrap, and avoiding the use of build steps completely. The DX has been amazing.
I'm probably misunderstanding your comment and I think if you elaborate a little it might help.
My understanding is that very few sites (or apps) are NOT a fancy CRUD app.
Also, using libraries like htmx is actually more suitable for the type of work you’re describing than modern SPA frameworks with all the bloat they bring along. Non-SPA libraries play well with other libraries, rather than take over the entire rendering process.
I’m old enough to remember how things were before SPAs; with libraries like jQuery the Web loaded much faster and was actually more interactive than it is with the currently dominant paradigm.
That being said, having done all the job queues, API integrations and so forth you mention countless times, and having done graphics, AI/ML and symbolic stuff like compiler development, I can say confidently that at their best CRUD apps are still comparatively boring to write. I personally think it's a mistake to latch on and get religious with a stack that's going to leave you stranded on the isle of boring code.
With that said, some things that seem boring to you may be interesting to others. And I don’t see how tech stack is relevant; if building CRUD-ish apps, I want the best possible DX. Of course, if/when I venture out of my comfort zone I will need to learn a new stack, but React and Vue become even less relevant for me at that point.
I hear you, but I don't see how immersive games are limited without a CSS build step. Games in particular don't usually have a lot of CSS anyway.
As far as complex webapps go, I'm not thoroughly convinced that the dev team is limited by the lack of a CSS build step. Sure, it makes things slightly more tedious, but not that much more tedious, surely?
Actually, that’s not true anymore. There is the standalone tailwind-cli that can be used without npm.
It's perfectly possible to have a CSS system that is completely maintainable. It takes skill. That skill can be learned, but it cannot be learned if a person is tricked into relying on rapid-application-development tooling like Tailwind and not taking the time to understand the real problems with their CSS (which is very often special cause variation and/or not taking it seriously enough).
Tailwind doesn't solve anything, it just trades one bad thing (poorly written CSS) for another. I won't list the problems with Tailwind as that's been done plenty. I'm just pointing out the fundamental mistake here.
My experience: The first version of our app used React + Tailwind. When we started to ditch React and use server rendered HTML our React components and their embedded Tailwind were useless. When we wanted to share styles with our emails, they were useless. We had to start from scratch. We now have a plain CSS system (well, SASS) that is very well maintained, has only essential variation, and is used across 20+ web apps (that are all served on the same domain -- the user thinks they are one app).
Yeah, and people wrote complex games in assembly. The difference is maintainability and if it can be done by more than one people. CSS doesn’t scale across teams/dependencies in its vanilla form in my experience, not at all. It is “spooky action at a distance” almost by definition, often with no way to even control/revert what some deep dependency does.
In your experience. It was my experience too, until it wasn't. See this: https://news.ycombinator.com/item?id=39501442
> often with no way to even control/revert what some deep dependency does
Without looking at specifics, it is hard to say, but it is very likely that this is a design mistake. It's very likely that the person making these mistakes is also making these mistakes in code and creating tangled messes there.
The state of development is quite poor. "Average" (read: most) developers create tangled messes because it's all they know how to do and they've never taken the time to learn how not to do it. So, when something like Tailwind comes along and says "you can't make a mess with this", then of course they will jump on it. They will not, however, be very interested in recognizing the costs that come along with it. They also will be incapable of seeing that the other path is not only simpler, but it can become easier with practice.
The comment above is definitely a great counter argument to rolling your own CSS from the ground up. I've seen projects with many engineers breaking each other's features because they weren't specific enough with their CSS targeting. The worst part is that sometimes it takes a keen eye to see that something broke in the first place - for example a font is wrong or a div moved etc. It's surprising how many customers don't even raise an issue, they just work around it.
I remember the days when the industry was shifting between Underscore, jQuery, Backbone, Knockout, Ember and React.
React obviously won with its bastardisation of compiled frontends and DOM diffing and Vue recently seems to have caused a stir by giving old paradigms a fresh coat of paint.
After all these years this ecosystem is still in flux...reflux...redux... and no static solution is going to suit every individual or survive indefinitely - the ideal solution seems to be able to adapt to requirements as they come and embrace stack requirements as learning exercises in what does and doesn't work.
> I've seen projects with many engineers breaking each other's features because they weren't specific enough with their CSS targeting.
Agreed, and to add to that -- unless a team is willing to stop the line and understand why and how this happened, it will keep happening. Tailwind eliminates classes of problems without requiring people to collaborate or think. That's its "benefit". As I've said elsewhere, it comes with costs, but many of those are subtle (many devs won't have enough experience to observe them) in their short term effects.
> I'm a fan of understanding the grittier side of the box-model but I've found that I can't outpace a system designed by a team of engineers to solve the problem of quick and easy layouts and components.
> I've seen projects with many engineers breaking each other's features...
I don't usually comment on people using "engineer" to describe software developers, but the irony in these statements is a bit much. What is being described is not engineering, it is hacking. It shouldn't be a surprise that when we hack, we break things.
This is a feature. Utility classes that do more than 1-2 things are hellish to reason about at scale, especially when they start interacting with each other
Yep. The one Tailwind guy on the team will set everything up perfectly, and then no one else will ever have any desire to ever learn Tailwind, and it descends into a complete mess.
You can say "just learn Tailwind!", and see how far that gets you with a group of backend devs who've inherited some UI and just need to add a button.
I have no doubt that people that don't know the fundamentals at play have an easier time with Tailwind. That's how it goes with hacks. They're usually easier to apply than proper design and implementation. We're throwing in the towel with Tailwind, plain and simple.
Agreed, and with Tailwind you never have to leave this fragment of markup you're designing. You don't have to switch files to add CSS and invent meaningful names for styles, then ensure you use the same name in the markup file, nor do you ever have to hunt down and change these names and the markup across multiple files to ensure they are applied consistently down the road of you're using HTML components.
In fact, you rarely have to write CSS at all, you just focus on the markup and sprinkle in the predefined styles that you need. Much simpler.
> We're throwing in the towel with Tailwind, plain and simple.
If by throwing in the towel, you mean we're acknowledging that they took a suboptimal design path, I agree. Transclusion of HTML fragments would have been a much better path to take, and some people were arguing for it even back then (Xanadu folks IIRC). Now we've come full circle, and people are still arguing that decomposition for reuse are not good ways of structuring dynamically changing and evolving content.
I would have never believed me now either, not until I saw it done first hand and learned how to do it. So, call it uncommon knowledge, or a rare skill, or whatever you want, but do know that not only is it possible, but the skills required are the same skills that enable you to build maintainable applications -- not just CSS.
In large part, this is why we failed in the past. We would often treat CSS as a second-class citizen and put our most junior "front end" developers on it. It should have been no surprise that it ended up as a tangled mess.
> You don't have to switch files to add CSS and invent meaningful names for styles, then ensure you use the same name in the markup file, nor do you ever have to hunt down and change these names and the markup across multiple files to ensure they are applied consistently down the road of you're using HTML components.
This isn't a real problem. The only time we've struggled to come up with a name is when CSS forces us to use some mechanical name that includes the word "container" or something like that. Usually, we just name the thing what it is. Usually, very often this is in the domain of the UI (hint, it is likely the same name as your React component, if you are using React and naming things well).
There's another problem here that complicates things. Most people shouldn't be using React for their forms over data applications. It's unnecessarily complex, but people now tend to think that server rendered HTML is yet another lost art. React plays very well with Tailwind in a sense, because you are already forced to make components for your UI, so what's sprinkling a little class soup in that file? What's sprinkling a few type declarations in the same file? What's sprinkling a few hooks in that file? What it all adds up to, once you can see it, is very difficult to read and reason about code all in one place. You can learn to see through the forest, but I personally would rather work on one tree at a time.
By the way, I'm not advocating for writing HTML in multiple places (and therefore re-using the CSS classes), that often should be abstracted in some way. In Rails, we use helpers and view template partials. Every technology has its options. Technically, web components fit this bill as well, but we don't make heavy use of them as I've found them unnecessarily complex.
There's no hunting down random css classes all over the codebase, no dealing with insane cascade issues, no idiotic specificity issues, no unused classes that everyone is afraid to touch because it might break some random div somewhere...
What is it about Tailwind that is unmaintainable, in your view?
To take this article seriously I would need to see a section on the maintenance obligations imposed by utlity classes and inline styles, versus an approach such as semantic CSS. Until then it just looks like "well ackshually they aren't the same". With some strange lofty bits about knowledge.
It does not require any such framework, although those frameworks can use the same approach. PHP and Perl were composing DRY HTML fragments even before JavaScript or CSS were invented. That this is possible and straightforward does not require more than the 30+ years of evidence that already exists.
But if you want more, here's a simple one: CSS promotes DRY of CSS markup at the cost of repeating HTML markup. Do you have more HTML or CSS in any given project?
Classes are used to categorize the markup. It's a document model. Model the document. Then, you apply styles to that. It's about design.
I think this may be the source of many religious wars in frontend land. HTML was originally a document model, but now it does dual duty as a way to block off rectangular sections of application UI.
The purist approach of writing perfectly semantic HTML and placing all presentation in optional, layered style sheets works beautifully - for documents. But I don’t think it works as well when you are designing an interactive UI and you’re really just trying to manipulate pixels on a screen.
Tailwind sure is ugly, but it’s quick to write and a cinch to debug. And in my experience, most UI code is pretty ugly. It seems to come with the territory?
It stands to reason that if it can't be done with HTML, then it can't be done with React, or Swift UI, or anything and we are all doomed. Of course, that's not true.
> Tailwind sure is ugly, but it’s quick to write and a cinch to debug. And in my experience, most UI code is pretty ugly. It seems to come with the territory?
UI code doesn't need to be ugly. It may come with the territory for most teams, but it doesn't need to be that way. We don't need to be working in giant monoliths that take an hour to deploy and run tests either, yet many teams are. We don't need to live in squalor, but when it's all we've known, we become accustomed to it. We give TED talks telling people how great it is to live in squalor and about the "one weird trick" that makes it a little more palatable.
The only "trick" we need is design. I'm not saying it's easy (in that it is readily available and applicable knowledge for the average developer), but it is attainable.
The markup doesn't need meaningful class names because CSS is encapsulated in reusable HTML fragments that have meaningful names. Your approach to structuring markup is simply unnecessarily more repetitive.
Poorly defined "design" principles have a cost, and where they conflict with concrete principles with a proven track record, like "reusable abstractions", then the poorly defined principles are wrong.
They have meaningful names... where? In React (or whatever). They don't in the web inspector (so just use the React dev tools! Yes, more complexity). They don't for testing tools like playwright, cypress, or capybara (so just use data-test-id! Yes, now you have to name something FOR TESTING PURPOSES ONLY, which is a clear sign of failure).
> Poorly defined "design" principles have a cost, and where they conflict with concrete principles with a proven track record, like "reusable abstractions", then the poorly defined principles are wrong.
I'm not sure that attempting to redefine design into something that you can ignore will do you much good, in the long run. If you think that "reusable abstractions" are a problem, then it's highly unlikely that there is a fraction of a square inch of common ground between us and any further conversation will just lead to frustration.
They have meaningful names in the locations where people actually need to care about meaningful names: in the template language or the component model used to generate the final markup. If you're suggesting that class names should be meaningful for people who want to read the generated markup and they can only make sense of it because of class names, you're penalizing all front-end development for an absurdly small niche.
If you need identifiable names for testing purposes, that's what other queryable HTML attributes are for (id and name in particular). In your template language you already have the component name available, so just assign a queryable attribute using that where necessary. Nothing wrong with that.
Tailwind is much more restrained in comparison.
Tailwind's just in time feature does negate this a bit. I'm a huge fan of Tailwind but I've largely avoided JIT for fear of losing the structure finite classes give me.
Edit: the down votes are interesting as this is literally what Tailwind JIT allows. Their post on it even says "We’ll likely add some form of “strict mode” in the future for power-hungry team leads who don’t trust their colleagues to use this feature responsibly."