Tailwind is such a terrible option to teach newcomers. It’s basically a vast CSS dialect, at this point it would be much more valuable to learn CSS itself.
I'm a hardliner against CSS frameworks. Any time you learn a CSS framework, you're picking up a tool that is going to break or be made obsolete in a couple years. Just learn CSS right the first time and you're good forever.
The problem with that is it takes a long time to learn CSS well enough to make something that doesn't suck.
That's why CSS frameworks are so popular. I can install bootstrap and make something not terrible pretty quickly. As someone new to programming to do the same in raw HTML and CSS is much much harder.
I understand how that was the case back in the 2k's before we had flexbox and CSS grid. It got better. Raw CSS is better, more logical, and easier than it's ever been. And raw HTML, of course, is a fundamental skill.
Yes, CSS layouting no longer sucks. But there are still endless foot guns which will cause a completely independent page of yours to change unexpectedly/fail to render correctly, and you won’t catch that for a long time.
CSS is like global mutable state — it is too flexible to properly work when multiple people work together on it. Sure, I’m never against learning something from fundamentals, but I am on the opinion that it is increasingly the wrong default.
Tailwind is less dialect, more subset. If someone has zero pre-existing knowledge of HTML/CSS then something like Tailwind is, in my opinion, a much better introduction to styling web pages because it focuses on one dimension: determining which rules you'd like to apply to which elements.
With Tailwind, you're not caught up in understanding the relationship between CSS and HTML which includes challenges like inheritance. Another benefit of Tailwind for new learners is the exhaustive documentation which captures all of the rules and their relationship in one place: it's hard to overstate the value of being able to look at a single page to fully understand how you can pad an element.
Certainly, there's limits to what you can achieve with Tailwind, but given it does expose a learner to the key principles of styling, it can then lead into an expanded learning of CSS if a user is interested in learning more -- you don't have to unlearn anything from Tailwind.
I can absolutely understand why someone would dislike Tailwind, especially those with pre-existing knowledge of CSS for whom this is a totally different way of styling, but to describe it as problematic for newcomers seems ignorant of where the real challenges of learning CSS are.
I was trying Tailwind out a few weeks ago for a very simple static web page. I'm close to beginner with slight knowledge of CSS and HTML. It was surprising to me that all the styling disappeared from <a> tags, and it took some Googling just to see how to work around that. I wound up just going with Spectre to get an acceptable solution. The Tailwind docs seem more for its target audience and not pure beginners. Is there some resource to learn Tailwind in the manner you are suggesting?
I'm unsure what you mean by "...all the styling disappeared from <a> tags..." so I can't confidently provide insight. My first thought was perhaps you're referring to the special `visited` state of an `a` element. However, a `visited` link should not lose styling that it is applied to the element explicitly, so it's unlikely to be that -- part of the value of Tailwind is that it prevents this class of issue.
Can you provide more insight into the specifics of the issue? I am happy to try and diagnose the issue -- even if you've moved on from Tailwind, you might get value out of understanding the issue! A GitHub repository link would be ideal, or some code in a Gist :)
My gut feeling is that the issue you're describing has nothing to do with Tailwind. One of the challenges of learning any library or technology: you can experience an issue outside of the bounds of your understanding and misattribute the issue to the tool in question, even after decade(s) of experience, this'll still happen!
> With Tailwind, you're not caught up in understanding the relationship between CSS and HTML which includes challenges like inheritance.
I’m sorry but to really learn CSS, you need to get this. The fact the TW abstracts this away may be easier to learn, but it does the learner a huge disservice if the don’t get what’s going on. Learning from first principles is always the best approach, even if the learning curve is slightly steeper, because it reduces a lot of mystery down the line when something isn’t behaving as expected.
First principles is far from the best approach to learning. Learning is a means to an end: we learn to use tools so that we can use them. If a tool is built in such a way that I don’t need to understand the underlying technology then that’s a good thing, because it means I can gain value from the tool faster.
I, personally, started writing HTML and CSS long before any of the tools we are discussing existed, CSS Zen Garden was state of the art back when I was learning… and nowadays I am very thankful that I don’t need to keep all of the esoteric aspects of CSS in my head when styling my HTML.
The most effective method for learning is the method that keeps the learner interested, and for most people, that’s the method that gets them to results the quickest. If you want to start learning how to make webpages by doing a deep dive on the DOM and WebKit, great, but that’s not the path for most people.
> This is same as saying teach everyone how to code in C first. Why stop there? Just teach assembly. See my point? -- lvl102 reply to ricardobeat*
I would argue there's something to that.
Maybe hello world level Basic or Pascal or beginner Python first, but then assembly before C or Rust or even JavaScript. Something's been lost for the set of devs who don't know what higher languages are doing for them under the hood.
I'd similarly agree with ricardobeat that CSS frameworks should come after CSS, and JS frameworks after JS. Rapidly ascending abstractions is great, if you take long enough to understand what they're built with, and some things will always be solved more simply by dropping back down a layer or three.
Just to add to your point, I would like to say that I was, in fact, taught C and assembly and I wouldn't have had it any other way
People that never go low level usually don't feel it in their guts how computers work. Which is OK most of the time, but it bites you back often enough that it's annoying having to explain the actual fundamentals when your colleagues haven't had that experience
C programmers usually don’t feel it in their guts either how computers work. The amount of code transformations modern compilers do to make C performant is really mind-boggling.
Though to add a more relevant point, I read a great saying on HN that a good developer knows their stack. A great one knows a layer beneath as well. (I usually butcher up quotes, sorry. It may have been more layers actually)
Comparing Bootstrap to Tailwind is comparing apples to oranges. They are both css "frameworks", but bootstrap is also a completely pre-made optioned design system. You don't really get that with Tailwind.
The point of bootstrap is to get something that's 90% of what you want FAST. And it can easily be customised to build a design system for yourself. With tailwind you have more foundational design work to do up front.
Personally I like the direction Bootstrap going, introducing utility classes, however there is more to do. My main wish is that they embrace web components for the JS side so that they are js framework agnostic.
As with all these tools you should evaluate what's best for you and your team.
Personally I like the model and style of Tailwind UI better, and I am more productive than I was with Daisy UI. I also am much better at identifying sites made with Daisy UI than I am sites made with Tailwind UI, though there's probably other factors. (however, the button animations are usually a dead giveaway)
Yes it is, but in a comparison of Bootstrap and Tailwind it's important not to conflate Tailwind and Tailwind UI, it confuses new users into thinking that can achieve the same as quickly with "pure" Tailwind.
This is exactly why I use bootstrap for all of my projects (none of which are commercial). I don't really care what it looks like in the sense of layouts and color schemes, just that its consistent and easy to use. I've found that its also fairly easy to make small customizations when I need to.
I worked with a front end developer who used and liked tailwind. I always thought that Bootstrap was for people like me, it lets me get set up quickly, then I never think about the CSS on my sites again.
Bootstrap is for everyone from people who want something quick and easy and don't want to think about design, all the way to people implementing a highly customised design system.
I think due to how prevalent vanilla Bootstrap sites are there is the impression that they all look the same. But it's actually a really good starting point for completely bespoke design systems too.
Professionally, I do backend these days but for my personal sites, I like bootstrap. I haven't tried tailwind but I've checked it out a few times, it doesn't seem to catch my interest. It's also hocked like a new religion, similar to how JetBrains hocks their products which also discourages me from wanting to consider it.
Jetbrains? If anything, their userbase is just that fond of the products. I really to remember any case where they would have marketed themselves that way.
For what its worth, their communication style is often regarded as pretty great compared to other companies, they don’t fck around with things like “pricing change”, they plain out say they had to increase their pricing.
Tailwind is far from being the go-to framework in templating/themes and general CMS. It is for sure the go-to choice for teams and startups that can afford developers who specialize in app deployment, but other than that - Bootstrap is just fine and way more popular than Tailwind will ever be.
I really dislike posts that attempt to present their opinion as a new sort of dogma. I argue that this is one of those because his intro specifically mentions teaching junior developers as a senior developer and code smells. Bootstrap and Tailwind have completely different strengths. I don't really see them as in competition with each other.
His most valid point is how hard is to customize bootstrap theming options. The rest of his points are just a matter of taste.
Luckily, if you google for "free bootstrap theme builder", there are several free sites that let you point and click your way to whatever fonts, colors, etc. you want in bootstrap then download a bootstrap.css file that is a drop-in replacement for the one that ships out of the box.
I don't even find it that hard to customize. I'm a backend dev at heart, but I develop my own niche side projects.
I would use something like Symfony's Webpack Encore (but if I had to start over, I might use something lightweight like Parcel.js, I might migrate
though), then let a "yarn watch" run in the background and it would re-compile in 2-3 seconds.
While I'm building my product and doing marketing and making sure it is performant and up all the time, I don't have too much time to adjust the details of the menu dropdown in mobile view (or even figure out how to do it).
Bootstrap also has utilities now (e.g. "py-md-3" for a large padding in the y axis - top and bottom - in larger screens) and that's good enough for me as a solo-dev for my own side project. Adjusting the border radius and the shadow in the "btn" class in the Sass already gives it a different feel.
"senior vs junior engineer" content always feels really cringeworthy. Particularly because self-proclaimed senior engineers tend to insist theirs is the One True Way.
It's even worse when it devolves into "X framework/library sucks" linkbait. Guess what, the only guaranteed worse library is the one you wasted time ripping out perfectly good code to rewrite
I appreciate that Tailwind is a force multiplier for certain teams, but let's not get carried away. There hasn't been a "fall" of Bootstrap. It's still very popular, widespread, and well understood. It's still being chosen for new projects. It depends on the team's needs. The article wavers between acknowledging that and only focusing on apps with dedicated designers:
> Most of the time, you can tell easily if a website is running with Bootstrap or not, even if you’re not a seasoned developer. From my perspective, it doesn’t always sound like good news! Because when using it, websites tend to look the same.
Which is often fine for internal or B2B. For B2C, a unique look may be more important. Many apps are LOB, internal dashboards, B2B SaaS. Often customizing the brand colors is enough.
> With Tailwind, however, you can add your custom styles to almost anything. Why is that so important, you ask? First, because it allows you to design the website how you want it, this is great, especially for designers!
I'd say it's mainly great for designers, although there'll be overlap with developers for certain use cases. With the kinds of projects I work on, I don't generally find myself needing that. When I do, editing the CSS is easier than bringing in Tailwind.
> Look at easy it is! I don’t need to write custom CSS or Sass code. I just need to call the right classes to be able to use it. It’s really, really simple and yet powerful!
This is a bit handwavy. It isn't easier to use Tailwind vs. custom CSS per se. Do away with custom CSS and you're now just writing custom Tailwind. That could be good or bad depending on your team and tooling.
I recently started using Tailwind and really enjoy how fast it makes building new UIs. However, I wonder how we'll view this in the future, when people have to actually go back into older projects using Tailwind and look at the jungle of classnames.
At some point there can be so many classnames on different elements that you basically arrive back at the original problem of complex stylesheets where you don't know what is affecting what.
Combine that with the fact that you need to have good knowledge to which CSS styles each classname refers, and I can see a lot of headaches down the line when someone has to fix the styles on a complex component.
I’ve never used Bootstrap (which seems amazing since I’ve been a professional web developer for more than 22 years), but from what I know of it, I don’t think it is the same kind of thing as Tailwind. Is it?
Bootstrap is a more complete "framework" that has style classes for preconfigured components, with some limited utility classes. Tailwind is all utility classes, with a well-designed system of ratios for things like padding.
> On the contrary, React documentation isn’t great. They didn’t explain how to write efficient tests for a long time. Even with Hooks, I don’t think they give enough information. Most of the time, when I speak to developers about React Hooks, they don’t understand how they work.
I'm not a huge React fan, but I cannot agree with this criticism. Its documentation is thorough and complete. It also introduced the frontend community to the idea of Functional Reactive Programming.
"Introduced" is the key word there. React with Redux was a gateway to FRP ideas for me, personally. Not mutating data, event streams, and pure functions in particular.
That for example has to be the most complicated way I've ever seen to change the font on a bootstrap website. All you need to do is include the bootstrap library and then include your custom css file after. In your custom css file you override the font. No need to change it via sass. I don't think this developer understands basic css overrides. As a side note I use bootstrap and have never messed with the sass section.
I chose bootstrap over tailwind for my personal projects purely because tailwind looks terrible to read. For example the card example they chose. Div class"card" vs figure class"puke lots of classes I will easily forget" .
I think these two frameworks are aimed at entirely different types of people with entirely different goals.
There's a disconnect between the title and the article.
The article ends with this conclusion: "My impression is that Bootstrap is declining." The article is the author's work with both, which is fine, but the title implies an industry trend, which isn't really supported by the article.
The article could have done this by pointing to statistical trends. However, I don't think the conclusion would then be supported. Just looking at NPM, they both are at their high points, suggesting it's not even a matter of competing. (I think Bootstrap has a larger amount of non-npm downloads, so that's not a perfect metric admittedly)
I started a new project a few days ago and, while initially wondering if I should pick up Tailwind, quickly decided to stick with Bootstrap. I'm not a designer, I hate writing front-end, I use Bootstrap for every project I create, so I see no reason to change.
I was going to say this. Tailwind always appeared to be as an alternate way of writing inline styles. I focus mostly on the back end and CSS is always a source of frustration when dabbling in front end, so perhaps I am not the right target anyway.
Tailwind always reminds me that there’s this weird respect pitfall where people treat CSS as too hard / primitive to learn and then spend considerably more time trying to avoid writing it than it would have taken to learn the tools of their chosen trade.
Especially in the modern era, it’s not that hard – what takes time is building a custom design, and that’s a key point he’s missing in this article. If you want to look different than other Bootstrap sites, you can do the same customization work as in his Tailwind example. It’s also likely the case that thinking about how to name things is going to be better than just spraying utility classes long-term since that gets you to think about where things are and are not the same.
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.
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.
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.
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
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.
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.
Dev 1 might make a card component with grey text as #999 and Dev 2 might make a footer component with grey text as #888.
Components are locally consistent but not globally consistent.
Or, let’s say you want to change all your grey text to #777, then you have to go back through all your individual components and hope you didn’t miss anything.
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"
> 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).
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.
"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".
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.
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.)
But CSS has almost never been decoupled from content. Yeah, there is zen-garden, but no real world CSS would be applicable to a different website just as is. They depend on the exact html structure, what is inside what, etc.
If you add this to the fact that you would actually write a <Component> and only specifically style that “inline” once, then you are actually better off with tailwind.
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.
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.
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.
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.
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.
> 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.
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:
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.
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.
My own personal opinion is that Tailwind just looks better. Bootstrap is great for developers who want something instantly nicer than unstyled HTML, but Tailwind is more production-worthy.
Bootstrap and tailwind aren't really trying to do the same thing.
e.g.,...
One client wanted a dashboard for certain data... we chose a bootstrap template they liked and... we were done with many aspects of the visual design. The template looked good, was appropriate for the purpose, the client was happy, and development proceeded to the parts of the site they really needed to control.
Another client wanted a custom design for an outward facing site. Designers and the customer worked together, iterated a bunch, and came up with a design they all loved... I implemented it with tailwind... straightforward for me and the client and designers loved it because it looked just like the design they worked so hard on.
It would have been possible to use tailwind on the first site, but it would have taken longer, for no benefit to the client or project.
It would have been possible to use bootstrap on the second site, but it would have taken longer (to customize) and/or would look more like bootstrap and less like the custom design in places where it just wasn't worth the effort to customize it.
Tailwind and “utility first” CSS is nice, but IMHO using magic string class names isn’t as nice as typesafe ways of styling like styled-components, Styled System, and Shopify’s Restyle.
Full stack type safety, including styling, is where it’s at IMHO.
Maybe there’s other ways of making CSS typesafe and supporting editor autocomplete, but why bother using CSS if you’re not even really using the cascade or non-trivial selectors?
107 comments
[ 2.6 ms ] story [ 173 ms ] threadI'm a hardliner against CSS frameworks. Any time you learn a CSS framework, you're picking up a tool that is going to break or be made obsolete in a couple years. Just learn CSS right the first time and you're good forever.
That's why CSS frameworks are so popular. I can install bootstrap and make something not terrible pretty quickly. As someone new to programming to do the same in raw HTML and CSS is much much harder.
CSS is like global mutable state — it is too flexible to properly work when multiple people work together on it. Sure, I’m never against learning something from fundamentals, but I am on the opinion that it is increasingly the wrong default.
With Tailwind, you're not caught up in understanding the relationship between CSS and HTML which includes challenges like inheritance. Another benefit of Tailwind for new learners is the exhaustive documentation which captures all of the rules and their relationship in one place: it's hard to overstate the value of being able to look at a single page to fully understand how you can pad an element.
Certainly, there's limits to what you can achieve with Tailwind, but given it does expose a learner to the key principles of styling, it can then lead into an expanded learning of CSS if a user is interested in learning more -- you don't have to unlearn anything from Tailwind.
I can absolutely understand why someone would dislike Tailwind, especially those with pre-existing knowledge of CSS for whom this is a totally different way of styling, but to describe it as problematic for newcomers seems ignorant of where the real challenges of learning CSS are.
Can you provide more insight into the specifics of the issue? I am happy to try and diagnose the issue -- even if you've moved on from Tailwind, you might get value out of understanding the issue! A GitHub repository link would be ideal, or some code in a Gist :)
My gut feeling is that the issue you're describing has nothing to do with Tailwind. One of the challenges of learning any library or technology: you can experience an issue outside of the bounds of your understanding and misattribute the issue to the tool in question, even after decade(s) of experience, this'll still happen!
I’m sorry but to really learn CSS, you need to get this. The fact the TW abstracts this away may be easier to learn, but it does the learner a huge disservice if the don’t get what’s going on. Learning from first principles is always the best approach, even if the learning curve is slightly steeper, because it reduces a lot of mystery down the line when something isn’t behaving as expected.
I, personally, started writing HTML and CSS long before any of the tools we are discussing existed, CSS Zen Garden was state of the art back when I was learning… and nowadays I am very thankful that I don’t need to keep all of the esoteric aspects of CSS in my head when styling my HTML.
The most effective method for learning is the method that keeps the learner interested, and for most people, that’s the method that gets them to results the quickest. If you want to start learning how to make webpages by doing a deep dive on the DOM and WebKit, great, but that’s not the path for most people.
I would argue there's something to that.
Maybe hello world level Basic or Pascal or beginner Python first, but then assembly before C or Rust or even JavaScript. Something's been lost for the set of devs who don't know what higher languages are doing for them under the hood.
I'd similarly agree with ricardobeat that CSS frameworks should come after CSS, and JS frameworks after JS. Rapidly ascending abstractions is great, if you take long enough to understand what they're built with, and some things will always be solved more simply by dropping back down a layer or three.
* lvl102's comment was deleted: https://news.ycombinator.com/item?id=34764573
People that never go low level usually don't feel it in their guts how computers work. Which is OK most of the time, but it bites you back often enough that it's annoying having to explain the actual fundamentals when your colleagues haven't had that experience
Though to add a more relevant point, I read a great saying on HN that a good developer knows their stack. A great one knows a layer beneath as well. (I usually butcher up quotes, sorry. It may have been more layers actually)
The point of bootstrap is to get something that's 90% of what you want FAST. And it can easily be customised to build a design system for yourself. With tailwind you have more foundational design work to do up front.
Personally I like the direction Bootstrap going, introducing utility classes, however there is more to do. My main wish is that they embrace web components for the JS side so that they are js framework agnostic.
As with all these tools you should evaluate what's best for you and your team.
I worked with a front end developer who used and liked tailwind. I always thought that Bootstrap was for people like me, it lets me get set up quickly, then I never think about the CSS on my sites again.
I think due to how prevalent vanilla Bootstrap sites are there is the impression that they all look the same. But it's actually a really good starting point for completely bespoke design systems too.
For what its worth, their communication style is often regarded as pretty great compared to other companies, they don’t fck around with things like “pricing change”, they plain out say they had to increase their pricing.
His most valid point is how hard is to customize bootstrap theming options. The rest of his points are just a matter of taste.
Luckily, if you google for "free bootstrap theme builder", there are several free sites that let you point and click your way to whatever fonts, colors, etc. you want in bootstrap then download a bootstrap.css file that is a drop-in replacement for the one that ships out of the box.
I would use something like Symfony's Webpack Encore (but if I had to start over, I might use something lightweight like Parcel.js, I might migrate though), then let a "yarn watch" run in the background and it would re-compile in 2-3 seconds.
While I'm building my product and doing marketing and making sure it is performant and up all the time, I don't have too much time to adjust the details of the menu dropdown in mobile view (or even figure out how to do it).
Bootstrap also has utilities now (e.g. "py-md-3" for a large padding in the y axis - top and bottom - in larger screens) and that's good enough for me as a solo-dev for my own side project. Adjusting the border radius and the shadow in the "btn" class in the Sass already gives it a different feel.
It's even worse when it devolves into "X framework/library sucks" linkbait. Guess what, the only guaranteed worse library is the one you wasted time ripping out perfectly good code to rewrite
I use it because:
1. It looks nice and users are familiar with it / it is a mature / proven system.
2. It’s fast. Drop in the CSS and I’m done fussing with CSS for +90% of situations. On with building the app.
> Most of the time, you can tell easily if a website is running with Bootstrap or not, even if you’re not a seasoned developer. From my perspective, it doesn’t always sound like good news! Because when using it, websites tend to look the same.
Which is often fine for internal or B2B. For B2C, a unique look may be more important. Many apps are LOB, internal dashboards, B2B SaaS. Often customizing the brand colors is enough.
> With Tailwind, however, you can add your custom styles to almost anything. Why is that so important, you ask? First, because it allows you to design the website how you want it, this is great, especially for designers!
I'd say it's mainly great for designers, although there'll be overlap with developers for certain use cases. With the kinds of projects I work on, I don't generally find myself needing that. When I do, editing the CSS is easier than bringing in Tailwind.
> Look at easy it is! I don’t need to write custom CSS or Sass code. I just need to call the right classes to be able to use it. It’s really, really simple and yet powerful!
This is a bit handwavy. It isn't easier to use Tailwind vs. custom CSS per se. Do away with custom CSS and you're now just writing custom Tailwind. That could be good or bad depending on your team and tooling.
At some point there can be so many classnames on different elements that you basically arrive back at the original problem of complex stylesheets where you don't know what is affecting what.
Combine that with the fact that you need to have good knowledge to which CSS styles each classname refers, and I can see a lot of headaches down the line when someone has to fix the styles on a complex component.
I'm not a huge React fan, but I cannot agree with this criticism. Its documentation is thorough and complete. It also introduced the frontend community to the idea of Functional Reactive Programming.
Bootstrap requires learning a new set of class names.
Tailwind is like in-line styles with fewer characters.
With both you can create an exponential number of similar looking, yet unique styles. It makes editing easy, but there’s no consistency constraints.
I think the holy grail will be something that enforces consistency without memorizing a new, unique styling dialect.
I chose bootstrap over tailwind for my personal projects purely because tailwind looks terrible to read. For example the card example they chose. Div class"card" vs figure class"puke lots of classes I will easily forget" .
I think these two frameworks are aimed at entirely different types of people with entirely different goals.
The article ends with this conclusion: "My impression is that Bootstrap is declining." The article is the author's work with both, which is fine, but the title implies an industry trend, which isn't really supported by the article.
The article could have done this by pointing to statistical trends. However, I don't think the conclusion would then be supported. Just looking at NPM, they both are at their high points, suggesting it's not even a matter of competing. (I think Bootstrap has a larger amount of non-npm downloads, so that's not a perfect metric admittedly)
https://npmtrends.com/bootstrap-vs-tailwindcss
might as well just use styles directly?
Especially in the modern era, it’s not that hard – what takes time is building a custom design, and that’s a key point he’s missing in this article. If you want to look different than other Bootstrap sites, you can do the same customization work as in his Tailwind example. It’s also likely the case that thinking about how to name things is going to be better than just spraying utility classes long-term since that gets you to think about where things are and are not the same.
> This is how you write a card component with Bootstrap:
> This is how you write a card component with Tailwind: Let's be honest. All other considerations aside this does not make the case for TailwindIt 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.
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
All of a sudden tailwind makes more sense.
With Tailwind there’s no consistency across developers. It’s all highly configurable, but no convention.
Components are locally consistent but not globally consistent.
Or, let’s say you want to change all your grey text to #777, then you have to go back through all your individual components and hope you didn’t miss anything.
So are your own custom defined colors like text-armatav-500.
Use the thing before you dismiss it.
You should have a design with a catalogue of components to build off of so you don’t have 30 card components.
It’s a your-team issue, not a Tailwind issue.
If you want an unsemantic one-off, you can do it just like Tailwind by setting a utility class like “p2”.
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"
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).
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".
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
Every generation repeats the mistakes of the past, and every time "this time it's different". This time it's different because components.
I'm still well-disposed towards Tailwind and it provides ways to handle this. I was just amused that the example was so bad.
If you add this to the fact that you would actually write a <Component> and only specifically style that “inline” once, then you are actually better off with tailwind.
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.
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.
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.
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.
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.
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:
Then your markup becomes 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.
Seems like tt that point you're basically learning an entirely new syntax just to save time on typing a few characters.
https://chrome.google.com/webstore/detail/gimli-tailwind/foj...
Bootstrap and tailwind aren't really trying to do the same thing.
e.g.,...
One client wanted a dashboard for certain data... we chose a bootstrap template they liked and... we were done with many aspects of the visual design. The template looked good, was appropriate for the purpose, the client was happy, and development proceeded to the parts of the site they really needed to control.
Another client wanted a custom design for an outward facing site. Designers and the customer worked together, iterated a bunch, and came up with a design they all loved... I implemented it with tailwind... straightforward for me and the client and designers loved it because it looked just like the design they worked so hard on.
It would have been possible to use tailwind on the first site, but it would have taken longer, for no benefit to the client or project.
It would have been possible to use bootstrap on the second site, but it would have taken longer (to customize) and/or would look more like bootstrap and less like the custom design in places where it just wasn't worth the effort to customize it.
Full stack type safety, including styling, is where it’s at IMHO.
Maybe there’s other ways of making CSS typesafe and supporting editor autocomplete, but why bother using CSS if you’re not even really using the cascade or non-trivial selectors?