6 ms·

> Let’s take an example. > This is how you write a card component with Bootstrap: <div class="card"...> <img src="..." class="card-img-top" alt="..."> <

• alex_suzuki 4y ago
  That was my exact same feeling after reading the example…
  • KrugerDunnings 4y ago
    I was sceptical about tailwind for a long time for precisely this reason, it does looks verbose, and that was until I used it. The tagline "design without leaving html" is true and where all the productivity comes from.
    • brianwawok 4y ago
      In Vue SFC, my scoped CSS is a few lines below the HTML. And my HTML doesn’t look terrible like this.
    • alex_suzuki 4y ago
      Fair enough, I never tried it. It’s just for someone who might be inclined to give it try (like myself), the example in TFA makes a really bad case.
    • mikeg8 4y ago
      I just watched a talk On why simplicity matters by Rich Hickey from Rails conf 2012, and I think this discussion is a good example of easy vs simple. Tailwind feels easy because it’s proximate, flexible, quick etc. but it makes the markup disgusting looking and, although I haven’t used it, I feel like it could easily lead to an inconsistent global design as each component can have their own styles that are isolated from the cascading/inheritance effects. It doesn’t feel simple to me… there is just something about all these inline styles (that’s exactly what these utility classes become) that really turns me off.
      • KrugerDunnings 4y ago
        Cool I've watched the same talk, did you use tailwind? No, well you can define your own css classes that combine multiple tailwind classes but using the same postcss syntax. Bootstrap philosophy is, writing css is too hard so we did it for you. With tailwind css is no longer hard and it lets you focus on designing, instead of changing the main color or your bootstrap theme.
      • kaba0 4y ago
        You ain’t writing HTML like “here is a 10000 line file, let’s style it”. You almost always have some repeating components (which is a shame that it wasn’t really a well-defined thing for so long in web circles, this is like the most basic abstraction of frameworks from the 80s), and you make that HTML file from multiple of those. These inline styles are just the implementation of your <Button> — changing that will change every button of yours. Hickey’s talk is a very very great talk, but I fail to see its relevance here. All tailwind does is give names to often used css attributes and allows one to apply them very specifically. It has no strange abstractions going on, it is basically “developer WYSIWYG” for CSS styling
• armatav 4y ago
  Now change the padding on card-body. All of a sudden tailwind makes more sense.
  • ceejayoz 4y ago
    Isn’t that a single SCSS variable in Bootstrap?
    • samtho 4y ago
      SCSS cannot be of use to the 98% of all bootstrap sites that just use the CDN to deliver a compiled stylesheet. The point here is can just change it in the HTML.
      • sussmannbaka 4y ago
        Tailwind cannot be of use to those same sites either, because the compiler needs to process your HTML to cut the generated CSS down to size. You have merely traded one tool for another. If you actually want to change things without preprocessing, your option remains good old HTML and CSS.
        • rendall 4y ago
          Amazing, the lengths that devs go to not to learn CSS fundamentals.
          • kaba0 4y ago
            It’s almost like CSS just fails at its job (though to cut it some slack, it was never designed for “apps”)
  • awb 4y ago
    Now maintain an app with 3 front end devs. With Tailwind there’s no consistency across developers. It’s all highly configurable, but no convention.
• deleted 4y ago
  [deleted]
• KaiserPro 4y ago
  This bit annoyed me greatly. I'm not an expert on CSS and I've not done anything serious for years, but I have used used bootstrap, so I was curious to see why people thought tailwind is better. But the two examples are completely different, and I dont understand why they would do that. Surely the the benefit of an example is to point out how hard it is to do the same thing in the old system compared to the other. not have two wildly different examples and say "look, the other one is shite"
  • RHSeeger 4y ago
    > Surely the the benefit of an example is to point out how hard it is to do the same thing in the old system compared to the other I think the idea here is "how is you accomplish the end goal in each, using their normal way of doing things". For example, if you were going to build a sorter in C vs Smalltalk, you would use procedural code for C and object oriented code for Smalltalk. Both would show how a sorter would be built in the style of the language in question (vs building an object oriented approach in C).
• jmmv 4y ago
  When I saw the Tailwind example, the first thing that came to mind was... "Wasn't CSS supposed to decouple presentation from content"? Because this sure looks like going back to <font> tags and style="" attributes everywhere.
  • samwillis 4y ago
    "Separation of concerns" often results is code rot and harder to main codebases. Placing the styles, js and HTML for a "component" in close proximity helps to reduce this and can in my experience make development significantly quicker. Separate css style sheets make sense for "document" web pages, but for "applications" I have found keeping the style close to, or inline with, the HTML much better. Personally I prefer the concept of the "single file component" popularised by Vue. Having one file that contain the js, HTML and css in close proximity but not on top of each other works really well. A common phrase used to describe this is "locality of behaviour".
    • greenie_beans 4y ago
      yeah i've never been a fan of separating html, css, and javascript. it's a dogma that doesn't work well for frontend development.
  • tlrobinson 4y ago
    That made sense for documents, and maybe even web apps before the rise of component-based web libraries that make it easier to collocate HTML, JS, and styles in reusable components.
    • TeMPOraL 4y ago
      It didn't make sense even for documents. A document usually cannot be cleanly factored into content independent from presentation - the border between the two is fuzzy, and there's always some bleed-through. You could say, perfect is the enemy of good, with almost every document you could easily get 95% there. That's true - but that 5% made the whole idea into a leaky abstraction. The more strict you were about the separation of content and presentation, the harder it got to deal with the 5% that were both - and back then, people were dogmatic about this. Many of us here probably remember the CSS Zen Garden[0] - the site that demonstrated just how far you can go with CSS if you keep the content and styling separate. I used to be in love with this, but now I think the site did incredible damage to web developers of that era: by getting people excited about flexibility of CSS, it made people forget that any particular site they're building is not going to have 20 alternate stylesheets to choose from - rather, it's going to have one, and the content on that site will be created with a specific presentation form in mind. Devs and designers ended up chasing half-formed visions of what could be, without realizing those visions made no sense in practice. (This of course doesn't mean that doing HTML and CSS in JS is a better idea. It's also a bad fad, just for different reasons.) -- [0] - https://en.wikipedia.org/wiki/CSS_Zen_Garden https://en.wikipedia.org/wiki/CSS_Zen_Garden
• hosh 4y ago
  Tailwind looks like it goes back to the days when people use in-line styles. I mean, it would be a lot more useful if people used the Tailwind classes as primitives to compose site-specific components, which can be further changed locally.
  • orwin 4y ago
    That's what people do? Or at least that's what I'm doing in my pet project to learn React and typescript.
  • kaba0 4y ago
    > Tailwind classes Not classes, but components as primitives. You just go to the component’s definition and can see its style at a single place, right next to its structure without which CSS makes no sense.
• zumu 4y ago
  I'm also not a fan, but for bootstrap you have to understand how those semantic class names turn into CSS and presentation, whereas the bottom is directly telling you what it does. It also gives you a lot more flexibility out of the box. Tailwind accepts greatly reduced DRY for straightforwardness. It's kind of like inline styles with training wheels. I'd much rather do this type of thing in the CSS layer, but doing it inline has advantages. Mainly, I think the reason it's caught on is new junior devs get productive in it very quickly.
  • bredren 4y ago
    Bootstrap templates contain examples and simple utility classes though. They prepackage bundled JS for interactivity, skipping over any build process. There are also way more websites running bootstrap that need maintenance or enhancements. These seem like a better fit for junior programmers. I think tailwind has caught jr programmers because course sellers have had an easier time getting market share because there isn’t remotely as much (free) content, examples and docs about tailwind. I think the influence of people with a vested interest in selling courses (like the hosts of Syntax web dev podcast) is what gets people to choose newer frameworks, not practicality or employability.
  • JUNGLEISMASSIVE 4y ago
    [dead]
• tlrobinson 4y ago
  The article did a poor job of explaining this, but I think the assumption with utility-first CSS is you’re using some component framework. So instead of having to separate the HTML and CSS, and invent names for every child element of a component, you just use the utility classes in the component, and reuse the component rather than the (component level, not utility) classes.
  • rendall 4y ago
    > The article did a poor job of explaining this... Yes, I agree, and that was more my point than any dig at Tailwind itself. Just because the article argues badly does not mean the argument itself is bad.
• thraxil 4y ago
  I've been doing web dev since the 90's and my first reaction to Tailwind was the same. Basically, "are we doing <font> tags again? really?" What the article (and many that are trying to introduce Tailwind) doesn't make clear is that Tailwind is purposely lower level than something like Bootstrap and it really exists to let developers make their own higher level framework. In particular, the idea is that you use Tailwind's `@apply` to bundle your own components. So you would do: .card { @apply md:flex bg-slate-100 rounded-xl p-8 md:p-0 dark:bg-slate-800; } .card-img-top { @apply w-24 h-24 md:w-48 md:h-auto md:rounded-none rounded-full mx-auto; } .card-text { @apply pt-6 md:p-8 text-center md:text-left space-y-4; } Then your markup becomes <figure class="card"> <img class="card-img-top" src="..." ...> <div class="card-text"> ... You basically can quickly build up your own replacement for Bootstrap out of components that fit well together, handle a lot of the messy implementation/compatibility details for you, and results in a bespoke framework with only exactly what you need and easy to change when you need to. I think most of the articles and documentation that don't make it clear that Tailwind isn't a direct replacement for Bootstrap, but something that you use to build a better Bootstrap do it a real disservice. Anyway, I think `@apply` should be one of the first things mentioned when introducing Tailwind. That made it click for me. I wish it didn't require building/compiling with JS, but I guess we lost that battle way back with SASS/LESS.
  • batperson 4y ago
    When it comes up '@apply' I don't really it as an improvement even over vanilla CSS. Seems like tt that point you're basically learning an entirely new syntax just to save time on typing a few characters.
  • FireInsight 4y ago
    Just using @apply isn't really the idea with Tailwind, and iirc one of the devs said they regret it. Tailwind exists in a world with component-based frameworks and advanced editor tooling. Some light repetition is thus toleratred, and it is expected that when more abstraction is needed it can be created using components. Thus you can abstract away non-CSS code too.
• JUNGLEISMASSIVE 4y ago
  [dead]