Skip Navigation
Programming @beehaw.org
Paradox @lemdro.id
• 100%

Tailwind CSS, and the death of web craftsmanship

pdx.su Tailwind, and the death of web craftsmanship

There's a worrying trend in modern web development, where developers are throwing away decades of carefully wrought systems for a bit of perceived convenience. Tools such as Tailwind CSS seem to be spreading like wildfire, with very few people ever willing to acknowledge the regression they bring to...

59
59 comments

  • I have to disagree with this paragraph. That Tailwind enforces a design system is its biggest strength. Having a small selection of colors, font sizes, and padding to choose from is what makes a website feel much more cohesive than one where developers pick arbitrary values every time they style an element.

    But you don't need Tailwind for that; design systems are easy to implement these days using CSS custom properties.

    23

  • I've seen people, lead and principal engineers, who refuse to learn modern JS, insisting that since it was bad in 2006 its bad today.

    It's still bad, though. That's not the reason why, but it still is. All the frameworks and things like TypeScript try to work around and hide the uglyness and stupidity of JavaScript, but they neither remove nor fix it. The way HTML was initially designed is the exact opposite of how it is used. It was intended to present data in a standardized way and leave the rendering and styling to the client application. People tried to create pixel-perfect designs with it. The entire resulting technology stack was created by idiots for idiots. And JavaScript is consistent in the misguidedness of the endeavor. All the marketing talk about platform independence is bullshit. It is easier to write platform independent GUI applications in C than in HTML + CSS + JavaScript. All the frameworks and languages transpiling to JavaScript trying to belie that just lead to a breeding ground of incompetent GUI developers doing esotheric coding ("doing it the way it is done" while understanding zilch about the fundament). The resulting developers are useless outside of their steaming pile of web GUI shit. The least worse of them are the ones promoting and perpetuating this failed technology stack by adding further layers of abstraction to try and hide that it is build on and from shit, creating even more esoteric developers in the process - by idiots, for idiots. Web GUI developers are paid less than any other branch of developers and it is completely justified.

    22

    • It is easier to write platform independent GUI applications in C than in HTML + CSS + JavaScript.

      Um, what? There are very few GUI toolkits targeting both desktops and phones, and none of them are reasonably usable from C.

      14

      • You forgot to read the very small fineprint after the rant hyperbole: *) true for desktop applications. You could go with C++ and QT. Though, writing C++ code is never easy/fun (still better than JavaScript, though). Any argument about natively compiled multi platform GUI applications regarding mobile is moot either way for multiple reasons. The angle I'm going to push here is: Everybody and his mother tries to push their custom iOS and Android apps, relegating web sites to the desktop. Any multi platform GUI toolkit with a cross-compilable language will give you twice the functionality in half the development time over HTML+CSS+JavaScript. And don't get me wrong: I'm not really suggesting that websites have no place. And there are good reasons to want websites. I'm trying to paint a picture what a horrible absolute clusterfuck the web GUI technology stack is.

        1

    • Lol so you're one of the devs the author is talking about. Imagine getting this worked up over a topic you clearly don't understand. "Failed technology stack" -- that's right everyone, the most widely used stack on the planet is a failure because this guy doesn't like javascript. Everyone else in the world is obviously a stupid moron for not seeing things his way.

      If you program in anything other than machine code you are an idiot. Remember that next time you use a failed abstraction like C.

      Can't believe this nonsense actually got upvoted. You never even identify any real issues with modern JS or HTML. It's just a bunch of run-on whining. "HTML was meant to provide a standardized way for presenting data" -- lol so literally how it's still used today.

      10

      • At least C has a working equals operator. Go on, tell me about ===, invite the ridicule. I bet I know more about JavaScript than you do. I hate it because I am intimately familiar with it.

        console.log(null==0)
console.log(null>0)
console.log(null>=0)

console.log(0==[])
console.log(0=='0')
console.log('0'==[])

// no equality comparison, but that shit is funny
console.log("2"+"2"-"2")

        Any proper programming language wouldn't even compile any of that nonsense.

        And something being widespread doesn't mean it's either right or good - look at religions.

        3

  • Permanently Deleted

    17

    • That being said, CSS frameworks are still wonderful, used right they can save a lot of time during early development by outsourcing the majority of design to the framework devs.

      That's actually my intent with using a CSS framework. A personal project of mine reached minimum viable product statud status (phones...) recently, I included bulma, and used some of its components for stuff like menus and modals. It was definitely faster than writing everything by hand early on. But I also ended up writing my own CSS anyway, especially with the grid, which is the foundation on which my app works on (it's a grid-based colour mixing app).

      I agree, I think CSS frameworks have a place for prototyping and we shouldn't rely on them as a project moves towards a proper release 🤔

      Then again, some people might think the obfuscation in 20+ classes is somehow a good thing...frankly, I think it's worse than inline styles. It's basically obfuscated inline styles!

      9

      • Then again, some people might think the obfuscation in 20+ classes is somehow a good thing…

        I'd argue that CSS is itself an obfuscation (read: abstraction), and isn't even implemented consistently across browsers. If the abstraction results in less duplication, more consistency across the website, and higher productivity, then I don't think that's a bad thing. (Of course, the flip side is that if using the abstraction results in the same learning curve with less transparency, then the benefits might not outweigh the cost.)

        Having never used tailwind, I can't give a personal opinion on that, but I find it hard to work on any decently sized project without SCSS. Sure I can write pure CSS, but SCSS provides so many QoL features over raw CSS that it's hard to pass it up, and it's easy enough to get setup.

        4

  • Tailwind is just shorthand inline CSS.

    17

  • Very good article imo. I didn’t disagree with anything. I especially agree with the ugliness of the many class names in my html.

    My problem I guess is reconciling how much of a pleasure it's been to use. Perhaps I, a primarily backend developer historically, embody the death of web craftsmanship, but I don’t really want to learn modern CSS if I don’t have to 😅

    The easier I can get something styled and back to doing actual business logic rather than making things pretty the happier I am. I highly respect frontend styling gurus but I'm not that interested in spending time mastering true web craftsmanship, I care more about delivering the product as fast and as beautifully to the user as possible.

    12

  • I think the article fails to mention that one of the reasons tools like Tailwind (and methodologies like BEM, etc.) exist in the first place is to facilitate bigger organisation sites.

    In my personal experience "plain old CSS" isn't feasible as the number of mainterners on a site goes up. Once there is multiple teams (possibly even across multiple departments) contributing to a site, the cascading part of CSS means that it is more or less unavoidable that some change from one team unintentionally breaks something for another team - and this being visual things means that it is very hard to catch with automated tests.

    After having working in a big organisation for a while, most developers will eventually start wishing for something that would make sure that their CSS only applies to their own components. div tags with inline style attributes suddenly starts to look very attractive - which is what eventually led to something like Tailwind.

    11

  • I mean, for me, the greatest pro I've heard for the usage of Tailwind is that it makes collaboration much easier. For example, a PR to add styling to a component is easy to read - you just see the new classes added. Not only that but you know that it only affects that element and that no CSS is still being kept in your CSS files that is no longer being used.

    The cascade is seen by some as one of the most annoying parts of CSS at times because it can make debugging harder - and many will simply abuse !important as a result.

    9

    • I'd argue that styled components, like Vue SFCs or Surface-ui, are even better in this regard. You can see the whole component there, and all the classes along for the ride. And they're usually written in something fairly close to "real" CSS

      2

  • i think about this article a lot whenever i hear about tailwind.

    https://thoughtbot.com/blog/tailwind-and-the-femininity-of-css

    9

    • Interesting perspective. I've added it to the appendix at the bottom of the article

      4

    • ... I'm very much not sure how I feel about that article. And I don't mean that in a negative way, it's just very... huh.

      4

    • But why is CSS so undervalued when it’s a necessary component of most websites and applications? Heydon Pickering writes that it’s partially due to the femininity of CSS: In my experience, men especially earn kudos for their knowledge of JavaScript or Python, but little from CSS skills. CSS, which makes things look ‘pretty’, is considered feminine (don’t tell that to a peacock).

      Uh, what? I've never seen or heard that kind of perspective. And I don't agree with it.

      Technical teams certainly often focus on the more technical aspects. With requirements and [time] pressure, technical teams often remain within that view scope.

      But as soon as you get other people on board technicality loses its importance. What you see is what you discuss and present and has impact.

      I would have never thought of putting a gender on one or the other, or on a language.

      CSS being a feminine language isn’t a bad thing. Quite the contrary, I’d argue that all programming is feminine as it was pioneered by women (who were then pushed out by men).

      This argumentation seems pretty pointlessly far off of the topic at hand. Why do you feel the need to categorize programming - and even all of programming - into a gender? That's completely misguided.

      1

  • Tailwind only really makes sense in a precise use case that absolutely does not cover everything web based and I wish the makers where clearer about it.

    First off, the abstraction problem: since you give up on defining custom classes at length, elements will often receive more than a dozen utility classes. This is fine IF you use a component based framework like Vue and you break down your app into components with a small granularity.

    Second, the stylesheet problem: even minified and compressed, a stylesheet containing all of Tailwind's utility classes is multiple Megabytes. The issue will not come from where you'd expect; downloading may take a while on the first page load, but all page loads will suffer from taking into account such a massive set of rules. Tree shaking makes this fine IF your content is already known at the moment of building the app.

    In the end I feel that Tailwind implements ideas on top of tech it is incompatible with and the abstractions it create are seriously leaking.

    7

  • So glad people are catching on to this. Until like a month ago if you said anything bad about Tailwind you would literally get shadowbanned on HN.

    6

  • I am not sure how other people do it but we use tailwind in SASS using the apply directive, inside a BEM-first structure. I feel like this is the best of what everything can offer.

    4

    • You might consider dropping tailwind entirely then, and using something like open-props, which gives you basically all the features of apply, but in a native CSS package

      5

  • Websites that use reasonable or good HTML markup with structure, the correct HTML tags, useful ids and classes are great to work with. But regularly you see websites with generated HTML without any useful identifiers or structure. A generated garbled mess of anonymous, generic components and styling CSS classes.

    I've worked on content extraction for OpenTermsArchive and write my own injected CSS hacks and browser extensions. Working with good website sources is great. Working with garbled messes is awful.

    HTML losing its markup aspect - that you can traverse and select - makes websites inaccessible.

    /edit - adding:

    The CSS tailwind generates might not be bloated, but repeating the gigantic strings of classes all over your codebase certainly adds to the size of the final HTML output.

    The HTML is not just bigger, but bloated and inaccessible. HTML markup with identifiers and classes is readable and understandable. It has structure and labeling. Inlining styling rules bloats it to the point of unreadability. And losing identifiers and classes is a loss of labeling and selectors.

    3 
  • .btn {
  @apply m-2 p-2 bg-blue text-white
}

    lol, they're basically writing a CSS class with CSS rules

    Why bother to even use @apply? Just write the damn CSS.

    I agree.

    2

  • While I understand the idea behind using CSS "correctly", I have, in my 15 years of professional experience, never ever seen even one project where the hypothetical promises of CSS were actually realized. It ALWAYS ends up with a fuckton of importants, or hunting for ages for the one class fifteen levels of abstraction up that changes your one element, coming up with more and more absurd class names, until they are literally no different from just some random name. Tailwind might seem horrible in a theoretical sense, but in an actually using it sense it's a heaven sent. I want to change the padding on THIS ONE SINGLE ELEMENT, I change it EXACTLY RIGHT THERE where the element is defined, and i can be absolutely sure that I haven't accidentally cascaded someone else's work to death.

    #CSS, in practice, is the insane idea of every single element on your website sharing global, mutable state, and thinking that's in anyway smart.

    2

  • Calling this “the death of we craftsmanship” is hyperbolic nonsense. The author is rage baiting or doesn’t appreciate design systems.

    I use Tailwind as part of a design system’s component library, but I’ve done the same with many other tools before. As with all libs in a UI stack, there is hype, then there is fit with you and your project. I think we could do with less hype & gripe, and more well considered neutral discussion of ergonomics and technical pros & cons.

    1
You've viewed 59 comments.