Yes, but that's just because I think for simplicity they created one large CSS file that is used for all their components and example pages. That's not very realistic. You're not supposed to do it like this for your own project. Instead if you use Tailwind CSS and PurgeCSS I'm pretty sure you would end up with ~10 or 15 kB of CSS gzipped, maybe less.
Disagree. Dumb is doing the same thing over and over again and creating new tooling to do the same thing over and over but with added dependencies and frameworks. The fundamentals of web development have barely changed but the flavor of the month way of doing the same thing is constant.
HTML and css are way too low level to be productive in, in my opinion. Especially when dealing with wide ranges of screen sizes, browsers, and platforms. The only way I’m interested in touching the stuff is if there are tools to alleviate the pain.
Caveat: not a UI developer, I’ve mostly done backend work And DevOps for quite some time.
I base my comment on the effort required to make a simple web page that a) looks the same across different browsers and devices, b) is responsive, c) supports relatively basic concepts like dropdown menus, columnar layouts, etc...
It’s way too much effort for me to want to mess with, and then you have to repeat the same things for every site you make.
> They come with all sorts of predesigned components like functions and structs that might help you move quickly at first, but cause more pain than they cure when it comes time to make your program stand out with custom behavior.
> Tailwind C is different.
> Instead of opinionated predesigned components, Tailwind provides low-level utility macros that let you build completely custom functionality:
And then every Hacker News discussion of Tailwind C would inevitably include a link to their "Why using Tailwind C is definitely not just as bad as writing inline assembler" documentation page.
Ooh, and then the creator of Tailwind C would start selling the Tailwind C Library, with like an implementation of memcpy that you just cut-and-paste into your program every time you need to copy memory.
It seems to require so much CSS knowledge that you might as well just use regular class names and write the CSS components yourself as it requires you to understand how flexbox etc works anyway to use it's utility classes properly.
You're right. Don't use Tailwind if you don't know CSS well.
The use case is for creating Template Components with something like React, Vue, Hugo, Razor or another component template framework. Tailwind offers a large list of customizable variables to use to help keep your CSS consistent. You're still pretty much writing CSS though, just with shortcuts. I consider it Emmet CSS + Variables. I also highly suggest using a plugin for your editor that offers hinting on all the crazy names no matter what CSS framework you use.
If you want a higher abstraction, Bootstrap or Foundation provide that. There is now also this Tailwind UI that you can purchase that would also provide that to some degree.
I thought the anti-css crowd who use React etc generally preferred some form of Styled Components where the style is written in JS? It's a mixed up world of factions :)
Whether building a regular website or a web-app I generally just use component names (like .card) the same way. I'm more of a fan of defined components with limited variations though than people being able to change anything with a lot of utility classes. Sort of like having a succinct API with a constrained depth. I see css as an api to the original designs and Tailwind introduces too much freedom for my comfort! I will endeavour to give it an honest trial though and maybe I will meet you somewhere in the middle.
This is where I ended up with this framework. It requires so much css knowledge that it is for the advanced but not expert who would be bothered by a number of things.
I've been reading awful takes like this since I started writing software.
"PHP is an awful language, superior developers write in Perl."
"Rails is bloated and slow, making it unfit for any real work."
"True developers don't rely on frameworks, writing all your own code is the only way to be performant."
If you wanna handicap yourself, be my guest.
I've written three or so projects in TailwindCSS, and it lets me create responsive designs quickly. It gives me a very sane set of defaults to build off of. And most importantly, it helps me get a product to production faster than writing raw CSS.
that may be so, but I think it's a valid point to bring up the tradeoffs you're making, including using a non-standard dsl that other designers/developers/hires will likely be unfamiliar with.
personally having written css since I was a teenager, my gut reaction is "eww", but if the team or stakeholders deem it to add value to a project and not affect productivity, sure why not?
I think it’s not for people who know CSS. It’s specifically for SPAs where site-wide changes are related to component changes and so having to change the html is not that different from changing the css.
I can not force myself to use something like this but I’ve been writing CSS for a long time.
I use BEM and predefined sets of colors and space values to ensure consistency and that’s efficient enough for me.
This kind of attitude, while totally relatable IMO as we grow frustrated with massive piles of crapware, is also how we wind up with NIH problems as organizations scale beyond just a few people. There is a very consistent theme by their creators across companies large and small - brilliant, productive, controlling, and eventually fired.
I'm kind of with you on this. We're rebuilding a large internal admin tool with all in house css and components, it's tiny and fast. We didnt want to bring in bootstrap or some other huge framework. Those were fine when I was a jr developer - not anymore
The internet is in a perpetual state of beginner dev tutorials and junior developer tools. I am still waiting for the awesome stuff to come out but it all the same stuff.
> We're rebuilding a large internal admin tool with all in house css and components,
Why would you have shared in-house css and components? Just write vanilla css right?
Tailwind is that shared in-house css and components for people/team that don't have shared in-house css and components. If you can afford to build one, sure use that!
This is made for prototyping too, this is to get to the MVP quicker. Again, if you have a shared in-house css and components library that does the same, sure use that instead, it makes much more sense!
> Those were fine when I was a jr developer - not anymore
That's a scary sentence. Why do you believe it matter whether you are junior or not to use that library? A library is made to avoid doing twice the works. If you already did that work, you don't need that library, that's for sure, but it's totally unrelated to your level as a developer.
I don't think that's it. Open https://tailwindui.com/css/app.css and Control-F for "placeholder-" -- are there really examples and component pages on this website that set the input placeholder text color to every single different color in the color palette, at every responsive breakpoint?
Congratulations on building your time machine. And welcome to 2020. 165kb is nothing these days and only takes a fraction of a second to download and processes even on a slow computer. You're going to find all kinds of other cool cool stuff you didn't have in the 90's. Did you know you can build and deploy an entire application without ever running a compiler or touching a physical machine now? We have REPLs were you can interact with your application live, in real time. It is a really amazing time to be building software now. So, again, welcome.
Congratulations on leaving your bubble. And welcome to the developping world. 165kb is a pain in the ass over 3G, and when people buy loads for them sim card giving them a data amount still measured in megabytes, it matters a lot, even the big ones like facebook had to make lite versions because of it.
You're going to rediscover all kinds of other cool cool stuff you forgot you could do whle wasting resources in the last decades. With everyone going with bloated mess and electron apps, it is a really amazing time to be building snappy softwares now. So, again, welcome.
(the arrogant tone of your message was really misplaced)
"Be kind. Don't be snarky. Comments should get more thoughtful and substantive, not less, as a topic gets more divisive. Have curious conversation; don't cross-examine.
...
Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith."
165KB is still a lot of pretty-making text. Attitudes like that are why "webapps" eat hundreds of megabytes of memory for tasks where low-tens would be more than enough, even allowing for some slopping programming and lots of abstractions. That 165KB hangs around in memory in probably more than one form, and becomes part of future layout decisions on the page, if they come up.
>Did you know you can build and deploy an entire application without ever running a compiler or touching a physical machine now? We have REPLs were you can interact with your application live, in real time.
How do I interact with REPLs in real time without touching a physical machine?
All of these new frameworks look great, but there just isn't a good way to switch from, e.g., Bootstrap to a new one. I've never come across a framework that had any kind of conversion tool or even a guide on how to efficiently switch.
Right now I don't think CSS frameworks are intended to be a drop-in replacement; each one will also introduce a subtle change in style that you have to work with. In theory you can rebuild your application reusing functional components and only replacing visual ones, but it's still going to be a lot of work.
But I think a lot of people wouldn't just replace the CSS framework, they'll rethink the whole UI and everything that goes with it with a big operation like that.
<p class="piew1 piew2 piew3 Lorem ipsum dolor sit amet consectetur adipisicing elit. Nemo expedita voluptas culpa sapiente alias molestiae. Numquam corrupti in laborum sed rerum et corporis. Nemo expedita voluptas culpa sapiente alias molestiae" id="Lorem ipsum dolor sit amet consectetur adipisicing elit. Nemo expedita voluptas culpa sapiente alias molestiae. Numquam corrupti in laborum sed rerum et corporis. Nemo expedita voluptas culpa sapiente alias molestiae">
Do these stylistic simple preview images have a name? I have been searching for these for a long time to use in my application without designing them all by my own. A free-to use pack of these would be really great.
It's really nice, but is there something this pretty for bootstrap?
I literally manage something like 10 different products/websites. And the only way to stay sane and have some pace with features is to use bootstrap for all of them (we currently use bootstrap for maybe 5 of them, and the rest were inherited sites that we're migrating).
I love the look of this but don't have the time or the will to migrate all our sites to learn yet another CSS meta-language with its own sets of concepts and classes.
It's not the same exact look of course, but it has dozens of pages, widgets and components that look clean. It's all well formed code too with ES6 JS, Webpack, etc..
I haven't tried it with a React app but I have used the theme for one of my projects that's using SCSS, Webpack and ES6 JS. The docs are really good and everything is segmented nicely. It shouldn't be bad to get it set up with React.
> Take a look at the extended license, which you'll be needing in many cases. $999 vs $28, for a single site license. No thank you.
I don't think the license is worded very well. If you read it as "end user" being a visitor of your site then pretty much every theme on themeforest would cost $999 but that's not the case.
I think what the license means is if you're bundling the theme in with a product you plan to sell and distribute then you need an extended license, unless it happens to be for freelance work in which case a regular ($28) license is fine (the "note to freelancers" clause handles that). If you have a free or paid SAAS app or something like then you can use a regular license too because you're not distributing the theme as a paid product.
I've talked to the author of the theme directly and mentioned using it for a course platform I'm building (end users of the site would be paying for individual courses). He didn't mention needing an extended license for that. He even went as far as giving me permission to release the course platform as open source with his theme included[0].
[0]: What I wrote isn't official for saying you can do the same. I recommend contacting the author directly if you have intent to do that.
When I first learned about Tailwind I though "wow this is amazing!", but it quickly became obvious I was more or less learning another "language", which I really didn't need when re-entering the crazy world of frontend.
I might reconsider it again once I am more comfortable with what frontend has become, but that is still quite a bit away.
I was experiencing the same thing. I thought it looked really well crafted, but bumped into the same finding as you. Components built on top of it would be great though!
I had a different experience – Tailwind made CSS a lot more approachable for me.
A big part of Tailwind's value is that it provides a curated, well-documented subset of the most important CSS attributes. The utility classes are consistently and concisely named (unlike many native CSS properties, which grew organically).
You're totally right that it is yet another abstraction, and that can be tiring. Personally I found it to be well-designed and transparent enough to make it worthwhile.
Tailwind's draw seems to be in its name -- it helps you work faster. So for people whose bottleneck is writing lots and lots of HTML/CSS, it's probably great.
I'm guessing most of the naysayers here work in the web applications world with component-based architectures, where the HTML/CSS is a small portion of the total time they spend coding, so they can't understand why someone would sacrifice readability, maintainability, and organization for speed on something that isn't a bottleneck for them. The thing is, it absolutely might be a bottleneck for agencies and other companies that need to build lots of custom sites.
We ended up painfully removing it from a large frontend project because the custom classes sprinkled everywhere got out of hand and the design started to look more and more inconsistent in a lot of places. Switched to CSS modules (and React components using them) and never looked back.
This is exactly what I'm concerned about at my current location. In a world where it's tough to get anyone to refactor, what's it going to look like after 6 months of use and nobody is creating abstractions into semantic classes?
It seems like if your project is not suited to a "website bashing" or prototyping approach long term, and you need semantic classes to allow for easy theming type use cases, it could be more trouble than it's worth?
It's just CSS classes. You do style="p-4" to make a horizontal padding. It's the simplest thing to learn -- by a long shot compared to most UI libraries everyone has been cooking up lately.
I know this would be hard to pull off but I kind of wish we could see the small / medium / large views of each component as a preview.
Right now it's not possible to tell what would happen when any of these components were resized since it's just a static image as a preview but responsiveness is one of the most important things to see.
> They've implemented that, and have size sliders for some of the components.
It seems they've only done it for the ones they are ok with making freely available.
But that still leaves a vast majority of the components (almost all of them) as static images at 1 specific screen size.
They should consider adding screenshots of each size, or a few second gif / video showing how it looks at various breakpoints. Otherwise potential buyers (like myself) have no idea what things look like at each size. I don't mind a premium price but I'm not going to blindly buy it without knowing what the components look like beforehand. What it looks like is the most important thing for a CSS theme.
This does look very pretty. I want to use it. But is this just another template? What's to stop any site built on this from looking identical to other sites bootstrap style? What are the customization options on here?
There seem to be relatively few themes out there, but it seems the intent of Tailwind is that you are building a custom design. There is no reason these themes couldn't exist, but you'd also want custom some components to completely break away from the behavior of the ones supplied.
Your question is intriguing to me because I come from web development long before the Bootstrap was available. Teams I worked on would frequently take custom designs and turn them into clickable HTML templates with all UI components before spending a lot of time with the site itself. Bootstrap took this a lot further, but also enables the early parts of design to be skipped. You then have your issue with the site looking like a Bootstrap site.
My personal opinion is that Tailwind along with this new offering enables a better way out of that situation. Bootstrap is still known to more people and has less of a learning curve which are important points for some.
Looks sexy. But can someone ELI5 why I'd use Tailwind over e.g. a Bootstrap theme? Not trying to be snarky - genuinely trying to understand the advantages.
The idea of utility CSS is that you have to set every single style yourself.
So for a button, you might have a class='rounded shadow p-4', which becomes rounded corners, drop shadow and a padding of 1rem.
On the one hand, you have to do a lot more to code. Instead of just adding class .btn in Bootstrap you would need to add all those classes.
On the other hand, the styles are not all the same as everyone eles's, and you can have different styles for one element if needed. You can have a button that only shares some styles, or a theme that has a lot of complimentary styles.
A downside of utility classes, is that you don't have a base to work off, you have to know what classes would go on a button in order to quickly get something nice.
The solution to that is a numerous collection of Tailwind Components. Copy the styles as ou need, and modify as you need.
But now we have an official collection from the framework creators themselves. Use them as a base, but - by changing a class or two, easily modify them for your project.
Of course, in Bootstrap, you could always have written your own classes to overwrite Bootstraps. That can be much more complex, and usually you wind with side effects. In my experience, the more you deviate from the prebuilt styles in semantic libs such as BS, the more hair you lose.
You are clearly not their market, but there is a big market for this. That price is inexpensive when you look at the time and effort involved of building the same components from scratch, even though Tailwind is a pretty productive tool once you know it.
Great job, this looks awesome! I wish something polished like this was around when I started my stuff. I'm not sure how I feel about Tailwind being almost 1mb of CSS :D, but it's probably worth all the time you save, especially for apps the size isn't such a big deal.
This was covered early in the tutorial I followed last summer. As someone who likes good web perf and remembers when sites were much slimmer on the frontend, I was very pleasantly surprised with the results I got.
In practice, Tailwind is used with a build step and one of the steps is to run the final CSS through PurgeCSS to drastically reduce the size. Search in the comments here for PurgeCSS - someone had a similar worry and I think they got it down from 1mb to 3.4k or something.
I am still not convinced to make the switch to Tailwind from MaterialUI. Looking at the source code of the examples, it looks like a huge block of code with a lot of duplicate text/class names.
The HTML-CSS "separation" question will never have a "right" answer...
Judging from all the positive comments in this thread, clearly I must be missing something. This looks horrible to me. Instead of meaningful CSS classes you just get a bunch of small classes that do very small things, which you're supposed to combine until it looks like what you want. How is that better than writing your CSS manually?
(Again, I realise the failure is probably on me. But I don't get it.)
- The classes cover many common use-cases and, in some cases, present a simpler "API" than hand-rolled CSS would
- You can eyeball a HTML fragment and get a good idea of how the pieces fit together, compared to the normal approach of needing to work out what each individual class does, and then how they fit together. It's easy to remember what the Tailwind classes are doing.
- It's dumb, but the ability copy-and-paste entire HTML fragments from one place to another and have the styling "just work" is slightly mind-blowing
- Some CSS attributes work oddly depending on the order in which they are applied, or the order of the composition of classes that both attempt to apply the same attribute, and that problem goes away with Tailwind
There are other advantages, but these were all quite surprising to me, because my expectations of CSS have always been quite low.
Their argument is that the idea of separating content from presentation was always a lie, and that your JS, CSS, and HTML code is always intertwined. I've found this to be partly true for web apps.
Tailwind is essentially unusable without a build step. You can configure it to make composite classes for common styles (button, card, etc.), but if you buy into their philosophy you'll probably want a component-based design (web components, React, Vue, etc).
It's better than working with CSS manually because you work at a slightly higher level. If it was transformed into a css-like language I would prefer that. As a non-UI expert, I also enjoy having an enumerable limited set of sane choices for most properties.
>if you buy into their philosophy you'll probably want a component-based design (web components, React, Vue, etc).
With tailwindcss or tachyons you get some of the benefits of component frameworks without having to use component frameworks, because you can colocate html & "styles" in regular template based systems and scope sections on a page this way. Great DX if you need to render sections conditionally, e.g. for ab testing.
If you think in sections rather than individual components anyway, which tailwind kind of promotes by design, you don't gain that much with a component framework.
The actual CSS functions like an inverted triangle (see ITCSS) the utility classes access from the html, so you won't have any specificity issues because it's already sorted out by having the CSS in a fixed order.
Another advantage is portability of sections between modern frontend JS frameworks and template based systems, you can just copy and paste things around, which is harder if the information about the styles is separated from the html, and without a fixed inverted triangle like CSS structure.
What if you want every link (from the perspective of the user, not based on the tag type) to have the exact same style? How would you do that without some sort of build step with an atomic unit for a link?
You could define the anchor element in the preflight.css file (normlize.css/reset).
Yeah, a section is a component, but in my book it also involves the visible page background where the element is located (you could override the page background with a section color), like a slice of the page.
The core principle is that you wrap up all UI elements into components. Most frontend and backend/template frameworks allow you to do this. You then verbosely apply the Tailwind classnames to perform styling, staying out of custom .css files all together.
In my experience trying to do semantic CSS just adds a lot of extra cognitive overhead and breaks down in the inevitable requirements churn every project goes through.
I was skeptical of Tailwind too until I actually tried it. It’s one of those things like JSX that defies received wisdom but in real use is very nice.
It's easier to parse but what does "hero" actually do? You need to go digging around in all your stylesheets to figure it out and in most cases actually load up the page and inspect it. That overhead is gone in a functional approach.
If you build things as components as you are supposed to (every backend and frontend framework has been geared around since the late 90s) Your CSS styling should correspond directly to your components (whether they are JS or a MVC partial view). So it should be obvious.
> You need to go digging around in all your stylesheets to figure it out and in most cases actually load up the page and inspect it.
When are you changing CSS and not inspecting the page at the same time? You are going to have to check your work. This doesn't happen if you keep things tidy as you go along. Working in a large team and/or scrum is no excuse for checking-in poor code.
You could however the problem is that the comment will invariably will be left after thing have changed and will just cause confusion.
Generally what the code is doing should be fairly obvious and should not need comments. Comments should be reserved where things aren't obvious.
I don't think it is a good idea to create code where it isnt obvious what it does. CSS is relatively simple tbh things really shouldn't be complicated.
It might not work in very large teams without an agreed on working style, but I don't see how it would be a problem in smaller teams or for individuals agreeing on using comments to their advantage.
Sure in a 4 line example it's fine. On a real site with 5 different kinds of hero elements, with some styles in common but a lot of small variations and each with its own responsive behavior it's not so easy anymore. Coming up with good names for things is one of the hardest jobs in programming and this style forces you to name everything.
I've been building sites the way you suggest for 20 years. I also had a negative knee jerk reaction to tailwind. But I had enough of an open mind to try it and now I have no interesting in going back.
> Coming up with good names for things is one of the hardest jobs in programming and this style forces you to name everything.
People say that. If you build stuff in components like you are supposed to you almost always have a server side component or component logic that you will have to name. So you are going to have to start naming things properly somewhere.
You are simply kicking the can down the road.
> I've been building sites the way you suggest for 20 years. I also had a negative knee jerk reaction to tailwind.
It isn't a negative kneejerk reaction. I've worked with sites where they have done similar things to tailwind and it is a nightmare to understand what is going on with the page.
> But I had enough of an open mind to try it and now I have no interesting in going back.
The markup is almost unreadable, it completely defeats the point of what CSS is supposed to do and it creates considerable mental overhead for someone who isn't familiar with it.
But I suppose I shouldn't really expect anything else from other web developers that over the last 20 odd years somehow manage to not understand the tech they are given.
And despite your crude last jibe at web developers attracted to Tailwind's model, most competent web developers will be able to quite easily pickup this very sane CSS utility framework :)
>And despite your crude last jibe at web developers attracted to Tailwind's model,
No my jibe was at web developers in general. CSS and HTML are quite simple really. If you actually keep things semantic and build your document properly with appropriate markup ... lo and behold things just work properly.
I can understand the divistush of the past when CSS 1 and 2 were quite limited. However today there is simply no excuse.
> most competent web developers will be able to quite easily pickup this very sane CSS utility framework :)
Sure I can read it. The problem is with things like this is that you are learning how to work with their model that basically doesn't work like CSS is supposed to work.
So you it essentially nullifies your existing skillset and forces you into using their framework. I bothered to actually learn CSS properly and understand the technology and then I have to work with something which basically throws that all out the window and forces me to work how they want me to build stuff. No thanks.
If you think that is a "sane" way of working, I really don't know what to say.
People say that. If you build stuff in components like you are supposed to you almost always have a server side component or component logic that you will have to name. So you are going to have to start naming things properly somewhere.
Sure, so you can do it once and use functional css to define the styles that go with that component right alongside the markup instead of having to maintain another css class name for that component in a separate file, mostly likely with arbitrary and inconsistent padding and margin and font-size values.
If you actually think ahead i.e. don't just start coding straight away you can avoid that. All you are doing is making excuses for not doing your job properly.
I had that same initial reaction when I first read about Tailwind.
I am now a convert and although it's hard for me to articulate exactly where the magic lies, these are contributing factors:
- You can do the entire thing in HTML quickly, including media queries and pseudo-classes.
- The predefined sizes and other values are granular enough that you can do just about everything with them, but coarse enough that you often get it right in the first shot. In a sense, it's a little like going from drawing a chart on blank paper to grid paper.
- Tailwind intellisense in VSCode shows you the colors you likely need.
Each of these points are tiny and could easily be achieved in another way, but combined they have increased my personal joy in frontend development quite significantly.
I use Tachyons, which is also utility-based (and, afaik, an inspiration to Tailwind). The primary improvement is that the amount of CSS you need to write is reduced by 90 % or more. Okay, but now you have to write and repeat all these CSS class names, so what have you gained? Not having to write CSS is more than enough for me, but another important thing is that you get all the information you need in one place to see how something is rendered. You also get that with inline styles, but they are much more verbose (at least compared to Tachyon's short class names), and there are some things that you cannot do with inline styles, but can do with classes. But you no longer have to go back and forth between the stylesheet and wherever you are performing your DOM-rendering to get an understanding of what's happening.
Tachyons has truly taken a lot of the pain of writing web applications away for me. It looks kind of ugly in the beginning, but I can't imagine going back to writing oodles of CSS again. Haven't used Tailwind though.
I’m using Tachyons over Tailwind because not needing a build step appeals to me. I vastly prefer the smaller footprint of Tachyons, but I do miss Tailwind’s comprehensive color palette sometimes. I could always manually add it in, but for now I’m sticking to Tachyons’s default colors to keep things simple.
Not sure how it'd be on a proper-production level app, but for side projects, being able to just iterate on a single element is pretty neat.
I don't necessarily want to remember 30 different context-specific class names when adding a new link or button on a simple page if I know a bit of syntax I can get exactly what I want, when I want it.
Again, it's very much a project specific choice, but when you're playing and tweaking and having fun with a design (or simply, iterating on one element multiple times), it's a nice library.
That being said, I can imagine a point where once you're happy with a design, there'd be a push to refactor.
If you have a few minutes, check out a screencast or two from their docs [0]. I was very much in agreement that utility-first looked pretty awful until I saw it in practice.
After watching a few of those I started thinking about how much faster it could be to use these utility classes instead of writing it by hand. Everywhere he adds a few quick classes I was thinking "here I'd be going back to the CSS, hunting for that class name, maybe duplicating it to create a unique variation... and it took him 7 seconds with a utility class. Hm."
Haven't gotten to try it on a project yet but it's on my list.
How is that better than writing your CSS manually?
My take is that it's not. It's just a convenient shortcut for those who aren't well versed in CSS.
I see what kind of problem they're trying to solve, but I think it collapses under its own weight the same as complete, closed components do - just later into the project.
I find that the verbosity is annoying at first, but it makes it incredibly easy to come back to some old HTML and work out exactly what it's doing, and why. Even with Bootstrap, you need to maintain a mental model of what the classes are doing and how they compose, and each custom class adds more complexity to that mental model. Yes, Tailwind has lots of classes, but each class does one thing, so reasoning about the final composition is incredibly easy.
This exactly. With more traditional approaches it can be very difficult to find exactly what css rules are affecting what elements. Tailwind is more verbose but also requires a lot less context to understand what’s going on.
It also makes responsive styling a lot easier in my experience.
> Tailwind has lots of classes, but each class does one thing
I think this masks a lot of complexity that you have to manage when taking on this approach. And it's not because the approach is good or bad, more what it is or isn't suited for.
The example on the homepage is very slickly presented, but the end result markup is extremely verbose. If I have a Card component, I would like to update them all at once when needed which is what css classes are generally good for. I find BEM naming conventions much more friendly to come back to than markup full of miniature class names.
My sense is this is for people who do not know css to the level needed to implement BEM. Also, it replaces the cost of knowing css and naming things (class names) with the cost of learning the tailwindcss classes.
I will stick to BEM + colors and sizes maps because this feels almost like using the style tag on each element.
For non-css expert engineers writing spa components, tailwind can be useful.
I can also see that it’s not trivial to mix tailwindcss and scss processors so it’s a no for me.
It has the benefit to limit spacing and color sets to presets but I already do this in my BEM codebase.
The recommended way to handle components is by using template partials or JS to manage your card component rather than CSS classes. [1]
Though, you can still use BEM with TailwindCSS through the @apply directive. Adam calls the directive a kind of "trick" to get more devs on board with utility-first but it does help a lot of you're used to reasoning about CSS with BEM.
It’s common, even expected, to extract that card into a component of some kind (React, web components, mustache template, etc) so you still only have to update the css once.
Isn't that what the container/component split is for? Presentation logic in a container, markup and styling in a component. If you need to reuse the same visual component in logically different contexts you create a new container that mangles the props as appropriate.
Yeah, you can. I've just seen this result in really complicated components. Other styles of CSS naturally separate presentation from html markup generation, so the cost of forking and specialized components is much lower.
Sure, until, you need a variation on that card for some elements, and add some other tailwind classes to the HTML to do it. Everything seems to work fine for a while.
Then you update the styles of the card again but the new styles clash with the ones in those tailwind classes and you end with broken styles in some elements.
Mixing components and utility classes is a recipe for future chaos.
No, you just create a new card component and adjust the tailwind classes on it.
Or, if it is a minor change, then conditionally include / exclude a small subset of tailwind classes.
The point is to not write your own CSS, you only use tailwind classes. In this way you can look at the template for each of your components and reason about / edit their style and layout easily.
I had a similar recoil to this approach and then I tried it, and I think they are actually onto something.
Yes, you may have more than one card in your system, but in all likelihood you aren't repeating the HTML for that card more than once, rather you have it in a template of some kind which is called. So while you may have more than one card on your site, you probably don't have the template for it defined more than once. (at least ideally you don't)
For those cases where you do want to extract that code, Tailwind makes that easy to do.
Tailwind is a weird thing and like I said I really thought it was insane at first. But after rewriting a site in it in a few days I have to say it is better than the standard semantic CSS by a mile.
It's good across projects/teams/job too. You know what everything does.
You don't have to learn every btn--rounded--primary thing for every app you work on.
That's fair. However, it is pretty straightforward to extract these to something reusable using Sass, css-modules, or templating (Handlebars, Nunjucks, React, etc).
So you can move really fast and experiment when you need to, and then extract to something shared when you're ready to DRY it up.
It's as if one person was arguing for hard-line separation of style and content, and another person was arguing that in-line is the way to go, and then Tailwind came along and said, "Why not both?"
So now it's the worst of both worlds: an abstraction layer and dirty code.
It's not necessarily bad. There are pros and cons to all css approaches. Atomic classes definitely have their fans. It's more a question of which pros and cons matter to you.
I think it's a little more subtle than you're saying.
When you use inline styles for everything, you're making the initial development a little faster by making future maintenance and changes a lot harder. (Like, if you decide headings should be italic instead of bold, that's a one-liner fix if you're using CSS properly, but if you're using inline styles you have to individually fix every heading on every page.) So most people have internalized "don't use inline styles for everything" as a general rule.
But if you don't actually care about that sort of future maintenance (or you're charging hourly for it), then using inline styles for everything looks really attractive to you! But you can't literally use inline styles for everything because even non-experts know that using inline styles for everything is bad for future maintenance. So instead you pull in Tailwind so you can say you're using a CSS framework.
And then the components get bloated to handle logic differences between views of the component, so you went from bloated CSS to bloated components and the need for everything to be a component in order to share a single look and feel.
Once the components get too bloated, you start forking them, and you are back to each page looking subtly different.
But can you realistically change the design centrally of something built only with utility css classes? If the class of an element doesn’t specify its semantics you cannot properly target it in a redesign without updating the markup.
I think people that use utility CSS like this will never maintain anything they create. They'll just throw everything away and start over with another framework.
I think that the idea of using well designed CSS rules and classes basically just turned out to not be very useful in the real world (one discussion of the issues: https://speakerdeck.com/vjeux/react-css-in-js)
"[...] you have to individually fix every heading on every page."
You should have utilized a template engine in the first place. So you'd only have to change the layout/partial/component that is responsible for rendering the heading. Moreover, you could also have extracted the component with css by creating a .title class and using @apply.
That assumes you have the means, the knowledge, and the time, to go through a build step.
What you find to be clean code might go the opposite way for someone (i.e. why would I use scss if utils are all I need?).
You might work with large scale apps where BEM may make more sense. You might work on a site builder where utils might be better. You might be creating splash pages for marketing purposes where going for element selectors may be enough.
This feature makes it a very progressive library for various stages of development. Inline earlier, then gradually extracting the style for reuse in later stage. Besides, their documentation is really good for one to learn those newer css concept.
Another reason Bootstrap > Tailwind is consistency & context. Adding the class `alert alert-danger` to a div tells my coworkers that it's an "alert" & it will look like an alert everywhere. If I want to change how alerts look, I change the CSS
With Tailwind you'd have `bg-red-100 border border-red-400 text-red-700 px-4 py-3 rounded relative`. Then I'd have to change my HTML everywhere to update the appearance of alerts & its not always obvious that I'm looking at an alert in code.
Nope. Once you see same (sub)set of classes repeated, you would instead define .alert and .alert-danger using Tailwind's @apply directive, and you now have a single place to change how your `alert alert-danger` looks :)
This looks nice, but one question I have regarding licensing is that for the simpler and more "obvious" components, where's line between learning from their demo (when the code isn't locked behind a paywall) and having to purchase a license? Take "Wide Tables"[1] for example; I have built almost the exact same thing myself with Tailwind by learning from an (IIRC official) example before.
Shouldn't there be a possibility for one class to extend other or to somehow include or merge classes, such that btn = rounded + shadow + p-4? This would allow you to use utility classes as building blocks for semantic ones.
(Disclaimer: I'm a backend dev and I don't know CSS well)
IMO, as soon as you do this, you may as well use some other framework. You can no longer reason atomically about the class names when you are using @apply.
Tailwind UI is not a theme, it's a component library. The target audience is different.
I bought this the moment I got the email about it this morning because this is going to help my productivity in building web applications. When you use Tailwind, you aren't using a pre-made theme as you would with a bootstrap theme you buy, you are designing it from scratch.
With this UI kit you'll get some nice building blocks to become even more productive, but you'll still end up modifying stuff to make it yours.
Compared to what? If you look at any agency license (use on as many sites as you want) for themeforest WordPress themes, they are about the same price, if not higher. I guarantee you, they‘ll make a million bucks on launch day!
I've found some themes pretty difficult to modify, or that it makes working with third-party components harder (say for Bootstrap), but since Tailwind UI is built on Tailwind, it won't be difficult to tweak.
I don't think this is exactly comparable to a theme, but I do agree that it's priced too high.
Not only that, but I think the pricing model is wrong; lifetime access for a one-time fee is a big mistake (and one I previously made with a startup).
As a developer, I understand that you need a predictable, repeatable income stream to keep going - and if I'm going to invest in something like this, I want it to keep going. I'd far prefer to pay something like $49/y instead of a one-time $249 fee.
I don't think it's really in competition for Bootstrap. Bootstrap is a set of common components and a grid system. Tailwind is a set of utility classes to build your own components.
It's great there's yet another UI framework on its way. Choice is awesome.
I'm a frontend guy (among other things) and for past 2 years I've been using Nuxt (app server, node.js) and Vuetify (material UI framework for Vue.js). Given what kind of results that stack can (and does) achieve, I wonder if people in the same boat as me (using the same stack) would even attempt to use Tailwind CSS/UI.
Whatever the case is, I'm glad there's a project that's useful and that helps authors finance their effort. Thumbs up!
Looks sexy but damn that's expensive. $250 for some pre-built styles I probably need to edit a lot anyway.
I rather use a free option like https://semantic-ui.com/ than pay that much. Maybe if you are company but it doesn't really work if you are a solo dev or using it for a side project.
Not sure why you’re getting downvoted. I’m a developer but I don’t do much frontend stuff. I would absolutely look into something like this if I wanted to set up a website quickly and wanted it to look good without spending too much time on it
The problem with this IMO is that some enterprising person will just use regular tailwind (or another utility-css framework like tachyons) and re-implement all of these components and give it out for free, circumventing the license and killing the value of this.
Normally with themes it would be time prohibitive to do so, but the nature of utility-css is that it's relatively straightforward to implement each component, even without looking at the CSS that's obviously easy to inspect.
I think what they should do is build a tool that let's you build your entire site using these components and charge for that. Otherwise, I guarantee within a year of today, 2/26/20 there will be a free version of this on GitHub created by the community.
---
On a side note, if some bored person out there wants to make a huge splash in the CSS community, figuring out a way to target a specific DOM element, create the equivalent of an AST and specify a "dictionary", which would be a utility-css framework (tailwind, tachyons, basecss, etc) and finally reimplement the targeted DOM element in the chosen framework would be amazing.
Assuming you buy into utility-css, that would remove all existing friction in adopting it. Then that would mean you could grab an existing theme [1] and convert it to tailwind components as desired.
It might happen, but I don’t think it would kill the value. There are tons of free and pretty great UI kits, CSS themes, etc already. Adam Wathan has done a really good job building up a community around Tailwind, and that brand and goodwill is part of the value here, I think.
> There are tons of free and pretty great UI kits, CSS themes, etc already.
There are tons that look visually appealing, but very few I've found that take a component-based approach (where they document each component individually - or think about how they interplay with each other). I've found the CSS is usually muddled, they often have legacy build pipelines that has to be rewritten to fit with Webpack, and a distinct lack of flexibility.
If Adam solves that side, Tailwind UI will be worth the money.
If it causes other theme providers to up their game, even better.
> The problem with this IMO is that some enterprising person will just use regular tailwind (or another utility-css framework like tachyons) and re-implement all of these components and give it out for free, circumventing the license and killing the value of this.
No because I believe that for every enterprising person wanting to circumvent paying for software, there are that many people who want to support the entrepreneurial spirit Adam and company show, and pay for good work. That's what capitalism is suppose to be about at least, anyways.
I wouldn’t bet on that. Most people want things for free and would stole digitized assets if they can go away. In a way what you wrote is true, but I’ll reverse it: for anyone willing to pay, there are many...
Common fallacy. Historically there has been a system of morals that has governed capitalism. Capitalism is about making a profit but also increasing the general welfare. The true capitalist dream is to make tons of money and bring forth great societal good. It's only now where the US has becoming increasingly amoral that we see the "late stage" capitalism we see today.
> On a side note, if some bored person out there wants to make a huge splash in the CSS community, figuring out a way to target a specific DOM element, create the equivalent of an AST and specify a "dictionary", which would be a utility-css framework (tailwind, tachyons, basecss, etc) and finally reimplement the targeted DOM element in the chosen framework would be amazing.
This is quite doable for us at Protoship (we've built both a design-to-Tailwind CSS+HTML converter as well as a webpage-to-Sketch Chrome extension). It is a very appealing idea - to be able to recast any webpage into a Utility CSS framework, but I'm curious to hear about situations where it would've been useful in commercial work.
I use Semantic-UI, which had a problem of finding sustainable funding. There is a community fork (Fomantic-UI), which does not align with my (business) needs: stability, bug fixes, long-term sustainability, rather than adding features left and right and becoming Yet Another All-Encompassing JavaScript-heavy Framework.
Tailwind-UI looks very interesting and I would have no problem paying for it, rather than getting a "free" version, if only for the long-term sustainability. Community projects often go through endless rewrites, and suffer from feature creep and lack of direction.
In a business setting (I run a self-funded SaaS business) I am much more interested in a framework that fixes bugs and is stable.
The only thing that worries me is that the pricing is one-time rather than subscription. How can the authors expect long-term sustainability with a one-time payment? Maintaining a CSS library is a continuous effort, not a one-time thing.
Semantic-UI is a perfect example of the atrophy that I fear with combined CSS and JS frameworks. I'm pretty bullish on utility-CSS (I prefer tachyons since it's much simpler than tailwind). I don't think frameworks should necessarily combine the JS and the CSS. Ideally you would have a competitive market of people selling themes, using utility-css components so you're not limited by framework, and then you can just use your own javascript that you're going to have to use anyway (alpine, react, ember, angular, vue, etc)
I think if utility-css frameworks get popular someone will abstract the components from the frameworks and things like tailwind ui will become unnecessary (rather it will just be utility-css-ui and will work with any css-framework that implements the "interface").
Semantic UI is the perfect example of why you shouldn't go with something that's generic. Unfortunately the project just became too bloated for one person to handle. Your concern about sustainability is a good one and that's exactly why many of the frameworks' authors sell themes. However, themes usually require a lot of work and are difficult to implement using the actual css framework. tailwind ui is different because if you had the theme it's really easy to recreate it because it's utility first.
Essentially, utility CSS is a philosophy that promotes having tons of general-purpose classes to apply style rules of extremely limited scope - usually(?) just one rule per class.
There's inherent value in supporting something with money though, it's likely to actually stick around and improve, rather than some hacky OSS project that will die in a few months.
Even if they sell 15,000 licenses in a year, that’s over a million dollars each. Not everything needs to be recurring revenue, they can make a truckload of money In a very short time span.
I would expect their market is the group of professionals for whom doing that is simply not worth the time.
When your job is delivering high quality UX and there are always more apps to build in the pipeline, having someone give you a library of useful components works.
I have licenses for probably 4-5 of these, and they've all saved many hours of time, and resulted in avoiding the cost of a dedicated designer.
For everyone is who skeptical about utility-first "atomic" or "functional" CSS, and don't want to go through the hassle of getting Tailwind with necessary build steps set up, I'd recommend giving a smaller-scoped library such as Basscss a try. It's >3kb, you can include it using a CDN link, and it covers most of what you need to be productive.
Wow, just today I was creating css lib for my project with similar naming and behaviour rules. Thanks for showing it out, I will check (eventually create) sass version of it. In my personal opinion, for simple projects, this is all what developer needs. Intuitive, extensible, low dependency and fast.
Yes, I agree. I use basscss for a ton of small projects, and my personal sites. It's so small, it's trivial to include even when I'm using larger frameworks like Bootstrap.
Recently used Tailwind for a quick and dirty MVP. It came out looking very polished (way more so than the cookie-cutter bootstrap look) and cut down the development time quite a bit allowing more time to focus on the important stuff on the backend. Worth giving it a try on a side project if you haven't.
Like you, I was put off by how crowded the HTML looked but got used to it and found it way quicker to update and kept the css file clean.
366 comments
[ 3.9 ms ] story [ 389 ms ] threadThere are also live demos of the app and marketing pages:
1. https://tailwindui.com/page-examples/landing-page-01
2. https://tailwindui.com/page-examples/detail-view-01#
Plus a screencast on how to use it to build these pages: https://vimeo.com/393580241/82c6d7c5f6
plus javascripts
See how dumb that sounds?
Caveat: not a UI developer, I’ve mostly done backend work And DevOps for quite some time.
It's an interesting concept.
It’s way too much effort for me to want to mess with, and then you have to repeat the same things for every site you make.
Yes, you can check off on your list that you no longer have any .S files. But did you actually gain anything?
> Most C libraries do too much.
> They come with all sorts of predesigned components like functions and structs that might help you move quickly at first, but cause more pain than they cure when it comes time to make your program stand out with custom behavior.
> Tailwind C is different.
> Instead of opinionated predesigned components, Tailwind provides low-level utility macros that let you build completely custom functionality:
And then every Hacker News discussion of Tailwind C would inevitably include a link to their "Why using Tailwind C is definitely not just as bad as writing inline assembler" documentation page.Ooh, and then the creator of Tailwind C would start selling the Tailwind C Library, with like an implementation of memcpy that you just cut-and-paste into your program every time you need to copy memory.
The leap between vanilla css and tailwind is not large at all.
Assembly: raw html and css C: A framework like Tailwind Python: Components, like TaildwindUI or any of the React components I’ve seen
I think that’s not a bad analogy.
CSS frameworks are great because there is a flavor that should fit just about anyone.
The use case is for creating Template Components with something like React, Vue, Hugo, Razor or another component template framework. Tailwind offers a large list of customizable variables to use to help keep your CSS consistent. You're still pretty much writing CSS though, just with shortcuts. I consider it Emmet CSS + Variables. I also highly suggest using a plugin for your editor that offers hinting on all the crazy names no matter what CSS framework you use.
If you want a higher abstraction, Bootstrap or Foundation provide that. There is now also this Tailwind UI that you can purchase that would also provide that to some degree.
Whether building a regular website or a web-app I generally just use component names (like .card) the same way. I'm more of a fan of defined components with limited variations though than people being able to change anything with a lot of utility classes. Sort of like having a succinct API with a constrained depth. I see css as an api to the original designs and Tailwind introduces too much freedom for my comfort! I will endeavour to give it an honest trial though and maybe I will meet you somewhere in the middle.
"PHP is an awful language, superior developers write in Perl."
"Rails is bloated and slow, making it unfit for any real work."
"True developers don't rely on frameworks, writing all your own code is the only way to be performant."
If you wanna handicap yourself, be my guest.
I've written three or so projects in TailwindCSS, and it lets me create responsive designs quickly. It gives me a very sane set of defaults to build off of. And most importantly, it helps me get a product to production faster than writing raw CSS.
personally having written css since I was a teenager, my gut reaction is "eww", but if the team or stakeholders deem it to add value to a project and not affect productivity, sure why not?
I can not force myself to use something like this but I’ve been writing CSS for a long time.
I use BEM and predefined sets of colors and space values to ensure consistency and that’s efficient enough for me.
Why would you have shared in-house css and components? Just write vanilla css right?
Tailwind is that shared in-house css and components for people/team that don't have shared in-house css and components. If you can afford to build one, sure use that!
This is made for prototyping too, this is to get to the MVP quicker. Again, if you have a shared in-house css and components library that does the same, sure use that instead, it makes much more sense!
> Those were fine when I was a jr developer - not anymore
That's a scary sentence. Why do you believe it matter whether you are junior or not to use that library? A library is made to avoid doing twice the works. If you already did that work, you don't need that library, that's for sure, but it's totally unrelated to your level as a developer.
1. https://angry-hypatia-f1529a.netlify.com/
2. https://github.com/philippbosch/tailwind-ui-purge-css-exampl...
If even the creator of Tailwind doesn't use Tailwind properly, does anyone?
I'm not particularly against JavaScript, but I'm not willing to install and use npm and several hundred dependencies.
All documentation for purgecss always includes postcss and a gazillion other packages I have never heard of.
Maybe something in Go, as a single executable?
https://purgecss.com/CLI.html
Good luck being a employable lol
still in js, but very fast, ~10KB (min), 0 dependencies, and does not require npm [1]:
however, it expects properly formed html and css; the parsers are quite unforgiving.
(i'm the author)
[1] https://github.com/leeoniya/dropcss/tree/master/dist
You're going to rediscover all kinds of other cool cool stuff you forgot you could do whle wasting resources in the last decades. With everyone going with bloated mess and electron apps, it is a really amazing time to be building snappy softwares now. So, again, welcome.
(the arrogant tone of your message was really misplaced)
Please don't do that. You are using sarcasm to ridicule the guy you are responding to, and that's an unproductive way to argue.
It is also against HN comment guidelines (https://news.ycombinator.com/newsguidelines.html):
"Be kind. Don't be snarky. Comments should get more thoughtful and substantive, not less, as a topic gets more divisive. Have curious conversation; don't cross-examine.
...
Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith."
165KB is still a lot of pretty-making text. Attitudes like that are why "webapps" eat hundreds of megabytes of memory for tasks where low-tens would be more than enough, even allowing for some slopping programming and lots of abstractions. That 165KB hangs around in memory in probably more than one form, and becomes part of future layout decisions on the page, if they come up.
How do I interact with REPLs in real time without touching a physical machine?
But I think a lot of people wouldn't just replace the CSS framework, they'll rethink the whole UI and everything that goes with it with a big operation like that.
</sarcasm>
I literally manage something like 10 different products/websites. And the only way to stay sane and have some pace with features is to use bootstrap for all of them (we currently use bootstrap for maybe 5 of them, and the rest were inherited sites that we're migrating).
I love the look of this but don't have the time or the will to migrate all our sites to learn yet another CSS meta-language with its own sets of concepts and classes.
I've always liked the Bootstrap 4 CodeBase theme ($28): https://demo.pixelcave.com/codebase/be_pages_dashboard.php
It's not the same exact look of course, but it has dozens of pages, widgets and components that look clean. It's all well formed code too with ES6 JS, Webpack, etc..
I don't think the license is worded very well. If you read it as "end user" being a visitor of your site then pretty much every theme on themeforest would cost $999 but that's not the case.
I think what the license means is if you're bundling the theme in with a product you plan to sell and distribute then you need an extended license, unless it happens to be for freelance work in which case a regular ($28) license is fine (the "note to freelancers" clause handles that). If you have a free or paid SAAS app or something like then you can use a regular license too because you're not distributing the theme as a paid product.
I've talked to the author of the theme directly and mentioned using it for a course platform I'm building (end users of the site would be paying for individual courses). He didn't mention needing an extended license for that. He even went as far as giving me permission to release the course platform as open source with his theme included[0].
[0]: What I wrote isn't official for saying you can do the same. I recommend contacting the author directly if you have intent to do that.
https://github.com/tabler/tabler
abler is free and open-source HTML Dashboard UI Kit built on Bootstrap
[0] https://github.com/tabler/tabler
http://www.urbanui.com/majestic/template/index.html
http://www.templatewatch.com/kapella-free/template/pages/for...
I might reconsider it again once I am more comfortable with what frontend has become, but that is still quite a bit away.
A big part of Tailwind's value is that it provides a curated, well-documented subset of the most important CSS attributes. The utility classes are consistently and concisely named (unlike many native CSS properties, which grew organically).
You're totally right that it is yet another abstraction, and that can be tiring. Personally I found it to be well-designed and transparent enough to make it worthwhile.
I'm guessing most of the naysayers here work in the web applications world with component-based architectures, where the HTML/CSS is a small portion of the total time they spend coding, so they can't understand why someone would sacrifice readability, maintainability, and organization for speed on something that isn't a bottleneck for them. The thing is, it absolutely might be a bottleneck for agencies and other companies that need to build lots of custom sites.
And the argument is that this comes at the expense of maintainability.
It seems like if your project is not suited to a "website bashing" or prototyping approach long term, and you need semantic classes to allow for easy theming type use cases, it could be more trouble than it's worth?
Right now it's not possible to tell what would happen when any of these components were resized since it's just a static image as a preview but responsiveness is one of the most important things to see.
It seems they've only done it for the ones they are ok with making freely available.
But that still leaves a vast majority of the components (almost all of them) as static images at 1 specific screen size.
They should consider adding screenshots of each size, or a few second gif / video showing how it looks at various breakpoints. Otherwise potential buyers (like myself) have no idea what things look like at each size. I don't mind a premium price but I'm not going to blindly buy it without knowing what the components look like beforehand. What it looks like is the most important thing for a CSS theme.
I do think they have a fourteen day free trial, though.
Your question is intriguing to me because I come from web development long before the Bootstrap was available. Teams I worked on would frequently take custom designs and turn them into clickable HTML templates with all UI components before spending a lot of time with the site itself. Bootstrap took this a lot further, but also enables the early parts of design to be skipped. You then have your issue with the site looking like a Bootstrap site.
My personal opinion is that Tailwind along with this new offering enables a better way out of that situation. Bootstrap is still known to more people and has less of a learning curve which are important points for some.
So for a button, you might have a class='rounded shadow p-4', which becomes rounded corners, drop shadow and a padding of 1rem.
On the one hand, you have to do a lot more to code. Instead of just adding class .btn in Bootstrap you would need to add all those classes.
On the other hand, the styles are not all the same as everyone eles's, and you can have different styles for one element if needed. You can have a button that only shares some styles, or a theme that has a lot of complimentary styles.
A downside of utility classes, is that you don't have a base to work off, you have to know what classes would go on a button in order to quickly get something nice.
The solution to that is a numerous collection of Tailwind Components. Copy the styles as ou need, and modify as you need.
Until now, there was no official collection. Some of my favorite collections are at https://tailwindcss.com/components https://www.tailwindtoolbox.com https://tailwindcomponents.com https://www.creative-tim.com/learning-lab/tailwind-starter-k... Forms: https://tailwindcss-custom-forms.netlify.com
But now we have an official collection from the framework creators themselves. Use them as a base, but - by changing a class or two, easily modify them for your project.
Of course, in Bootstrap, you could always have written your own classes to overwrite Bootstraps. That can be much more complex, and usually you wind with side effects. In my experience, the more you deviate from the prebuilt styles in semantic libs such as BS, the more hair you lose.
Utility CSS allows you to change or customize far more flexible in a fast pace environment than Bootstrap.
If you prefer lighter CSS, Tachyons is another option which I found more easier to read even if I have a long classes.
By adding a simple utility, your css gets very short very quickly.
https://tailwindcss.com/course/optimizing-for-production/
The HTML-CSS "separation" question will never have a "right" answer...
(Again, I realise the failure is probably on me. But I don't get it.)
- The classes cover many common use-cases and, in some cases, present a simpler "API" than hand-rolled CSS would
- You can eyeball a HTML fragment and get a good idea of how the pieces fit together, compared to the normal approach of needing to work out what each individual class does, and then how they fit together. It's easy to remember what the Tailwind classes are doing.
- It's dumb, but the ability copy-and-paste entire HTML fragments from one place to another and have the styling "just work" is slightly mind-blowing
- Some CSS attributes work oddly depending on the order in which they are applied, or the order of the composition of classes that both attempt to apply the same attribute, and that problem goes away with Tailwind
There are other advantages, but these were all quite surprising to me, because my expectations of CSS have always been quite low.
Not really. styled-components makes this simple if you're using react.
Tailwind is essentially unusable without a build step. You can configure it to make composite classes for common styles (button, card, etc.), but if you buy into their philosophy you'll probably want a component-based design (web components, React, Vue, etc).
It's better than working with CSS manually because you work at a slightly higher level. If it was transformed into a css-like language I would prefer that. As a non-UI expert, I also enjoy having an enumerable limited set of sane choices for most properties.
With tailwindcss or tachyons you get some of the benefits of component frameworks without having to use component frameworks, because you can colocate html & "styles" in regular template based systems and scope sections on a page this way. Great DX if you need to render sections conditionally, e.g. for ab testing.
If you think in sections rather than individual components anyway, which tailwind kind of promotes by design, you don't gain that much with a component framework.
The actual CSS functions like an inverted triangle (see ITCSS) the utility classes access from the html, so you won't have any specificity issues because it's already sorted out by having the CSS in a fixed order.
Another advantage is portability of sections between modern frontend JS frameworks and template based systems, you can just copy and paste things around, which is harder if the information about the styles is separated from the html, and without a fixed inverted triangle like CSS structure.
Isn't a section just a case of a component?
Yeah, a section is a component, but in my book it also involves the visible page background where the element is located (you could override the page background with a section color), like a slice of the page.
https://tailwindcss.com/docs/utility-first
The core principle is that you wrap up all UI elements into components. Most frontend and backend/template frameworks allow you to do this. You then verbosely apply the Tailwind classnames to perform styling, staying out of custom .css files all together.
I was skeptical of Tailwind too until I actually tried it. It’s one of those things like JSX that defies received wisdom but in real use is very nice.
Do people really struggle with this?
It far more straight forward just to call something what it is and you can actually read the CSS afterwards.> You need to go digging around in all your stylesheets to figure it out and in most cases actually load up the page and inspect it.
When are you changing CSS and not inspecting the page at the same time? You are going to have to check your work. This doesn't happen if you keep things tidy as you go along. Working in a large team and/or scrum is no excuse for checking-in poor code.
Generally what the code is doing should be fairly obvious and should not need comments. Comments should be reserved where things aren't obvious.
I don't think it is a good idea to create code where it isnt obvious what it does. CSS is relatively simple tbh things really shouldn't be complicated.
I've been building sites the way you suggest for 20 years. I also had a negative knee jerk reaction to tailwind. But I had enough of an open mind to try it and now I have no interesting in going back.
People say that. If you build stuff in components like you are supposed to you almost always have a server side component or component logic that you will have to name. So you are going to have to start naming things properly somewhere.
You are simply kicking the can down the road.
> I've been building sites the way you suggest for 20 years. I also had a negative knee jerk reaction to tailwind.
It isn't a negative kneejerk reaction. I've worked with sites where they have done similar things to tailwind and it is a nightmare to understand what is going on with the page.
> But I had enough of an open mind to try it and now I have no interesting in going back.
The markup is almost unreadable, it completely defeats the point of what CSS is supposed to do and it creates considerable mental overhead for someone who isn't familiar with it.
But I suppose I shouldn't really expect anything else from other web developers that over the last 20 odd years somehow manage to not understand the tech they are given.
And despite your crude last jibe at web developers attracted to Tailwind's model, most competent web developers will be able to quite easily pickup this very sane CSS utility framework :)
No my jibe was at web developers in general. CSS and HTML are quite simple really. If you actually keep things semantic and build your document properly with appropriate markup ... lo and behold things just work properly.
I can understand the divistush of the past when CSS 1 and 2 were quite limited. However today there is simply no excuse.
> most competent web developers will be able to quite easily pickup this very sane CSS utility framework :)
Sure I can read it. The problem is with things like this is that you are learning how to work with their model that basically doesn't work like CSS is supposed to work.
So you it essentially nullifies your existing skillset and forces you into using their framework. I bothered to actually learn CSS properly and understand the technology and then I have to work with something which basically throws that all out the window and forces me to work how they want me to build stuff. No thanks.
If you think that is a "sane" way of working, I really don't know what to say.
Sure, so you can do it once and use functional css to define the styles that go with that component right alongside the markup instead of having to maintain another css class name for that component in a separate file, mostly likely with arbitrary and inconsistent padding and margin and font-size values.
I am now a convert and although it's hard for me to articulate exactly where the magic lies, these are contributing factors:
- You can do the entire thing in HTML quickly, including media queries and pseudo-classes.
- The predefined sizes and other values are granular enough that you can do just about everything with them, but coarse enough that you often get it right in the first shot. In a sense, it's a little like going from drawing a chart on blank paper to grid paper.
- Tailwind intellisense in VSCode shows you the colors you likely need.
Each of these points are tiny and could easily be achieved in another way, but combined they have increased my personal joy in frontend development quite significantly.
Tachyons has truly taken a lot of the pain of writing web applications away for me. It looks kind of ugly in the beginning, but I can't imagine going back to writing oodles of CSS again. Haven't used Tailwind though.
I don't necessarily want to remember 30 different context-specific class names when adding a new link or button on a simple page if I know a bit of syntax I can get exactly what I want, when I want it.
Again, it's very much a project specific choice, but when you're playing and tweaking and having fun with a design (or simply, iterating on one element multiple times), it's a nice library.
That being said, I can imagine a point where once you're happy with a design, there'd be a push to refactor.
After watching a few of those I started thinking about how much faster it could be to use these utility classes instead of writing it by hand. Everywhere he adds a few quick classes I was thinking "here I'd be going back to the CSS, hunting for that class name, maybe duplicating it to create a unique variation... and it took him 7 seconds with a utility class. Hm."
Haven't gotten to try it on a project yet but it's on my list.
[0] https://tailwindcss.com/screencasts/
My take is that it's not. It's just a convenient shortcut for those who aren't well versed in CSS.
I see what kind of problem they're trying to solve, but I think it collapses under its own weight the same as complete, closed components do - just later into the project.
<div class="lg:flex lg:items-center lg:justify-between"> <div class="flex-1 min-w-0"> <h2 class="text-2xl font-bold leading-7 text-gray-900 sm:text-3xl sm:leading-9 sm:truncate"> Back End Developer </h2> <div class="mt-1 flex flex-col sm:mt-0 sm:flex-row sm:flex-wrap"> <div class="mt-2 flex items-center text-sm leading-5 text-gray-500 sm:mr-6">
Personally I would prefer Bootstrap over this approach.
It also makes responsive styling a lot easier in my experience.
I think this masks a lot of complexity that you have to manage when taking on this approach. And it's not because the approach is good or bad, more what it is or isn't suited for.
The example on the homepage is very slickly presented, but the end result markup is extremely verbose. If I have a Card component, I would like to update them all at once when needed which is what css classes are generally good for. I find BEM naming conventions much more friendly to come back to than markup full of miniature class names.
I will stick to BEM + colors and sizes maps because this feels almost like using the style tag on each element.
For non-css expert engineers writing spa components, tailwind can be useful.
I can also see that it’s not trivial to mix tailwindcss and scss processors so it’s a no for me.
It has the benefit to limit spacing and color sets to presets but I already do this in my BEM codebase.
Though, you can still use BEM with TailwindCSS through the @apply directive. Adam calls the directive a kind of "trick" to get more devs on board with utility-first but it does help a lot of you're used to reasoning about CSS with BEM.
[1] https://tailwindcss.com/docs/extracting-components
Then you update the styles of the card again but the new styles clash with the ones in those tailwind classes and you end with broken styles in some elements.
Mixing components and utility classes is a recipe for future chaos.
edit: thinking more, you can override classes. So yeah, maybe utility/atomic classes are not as effective here.
Or, if it is a minor change, then conditionally include / exclude a small subset of tailwind classes.
The point is to not write your own CSS, you only use tailwind classes. In this way you can look at the template for each of your components and reason about / edit their style and layout easily.
Yes, you may have more than one card in your system, but in all likelihood you aren't repeating the HTML for that card more than once, rather you have it in a template of some kind which is called. So while you may have more than one card on your site, you probably don't have the template for it defined more than once. (at least ideally you don't)
For those cases where you do want to extract that code, Tailwind makes that easy to do.
Tailwind is a weird thing and like I said I really thought it was insane at first. But after rewriting a site in it in a few days I have to say it is better than the standard semantic CSS by a mile.
So you can move really fast and experiment when you need to, and then extract to something shared when you're ready to DRY it up.
button { @apply border bg-white; // ... }
So now it's the worst of both worlds: an abstraction layer and dirty code.
When you use inline styles for everything, you're making the initial development a little faster by making future maintenance and changes a lot harder. (Like, if you decide headings should be italic instead of bold, that's a one-liner fix if you're using CSS properly, but if you're using inline styles you have to individually fix every heading on every page.) So most people have internalized "don't use inline styles for everything" as a general rule.
But if you don't actually care about that sort of future maintenance (or you're charging hourly for it), then using inline styles for everything looks really attractive to you! But you can't literally use inline styles for everything because even non-experts know that using inline styles for everything is bad for future maintenance. So instead you pull in Tailwind so you can say you're using a CSS framework.
Once the components get too bloated, you start forking them, and you are back to each page looking subtly different.
You should have utilized a template engine in the first place. So you'd only have to change the layout/partial/component that is responsible for rendering the heading. Moreover, you could also have extracted the component with css by creating a .title class and using @apply.
Tailwind recommends PurgeCSS, but i'll plug my own lib here:
https://github.com/leeoniya/dropcss
i have a specific section on how to handle tailwind's unorthodox classnames:
https://github.com/leeoniya/dropcss#special--escaped-sequenc...
<div class="lg:flex lg:items-center lg:justify-between">`
Isn't this why we have CSS preprocessors? So we can do:
<div class="description-of-what-this-is">
.description-of-what-this-is { .lg_flex() .lg_items-center() .lg_justify_between(); }
Assuming there's enough complexity beneath the mixins to justify their use -- some of these might just be CSS properties.
What you find to be clean code might go the opposite way for someone (i.e. why would I use scss if utils are all I need?).
You might work with large scale apps where BEM may make more sense. You might work on a site builder where utils might be better. You might be creating splash pages for marketing purposes where going for element selectors may be enough.
// in JS, then build .btn-blue { @apply bg-blue-500 text-white font-bold py-2 px-4 rounded; }
With Tailwind you'd have `bg-red-100 border border-red-400 text-red-700 px-4 py-3 rounded relative`. Then I'd have to change my HTML everywhere to update the appearance of alerts & its not always obvious that I'm looking at an alert in code.
Nope. Once you see same (sub)set of classes repeated, you would instead define .alert and .alert-danger using Tailwind's @apply directive, and you now have a single place to change how your `alert alert-danger` looks :)
<Alert type="danger"> Are you sure? </Alert>
Of course this solution would work in other templating engines as well.
The alternative would be extracting css components:
.alert { @apply px-4 py-3 ... }
.alert-danger { @apply bg-red-100 .. }
[1] https://tailwindui.com/components/application-ui/tables/wide
(Disclaimer: I'm a backend dev and I don't know CSS well)
https://tailwindui.com/components/application-ui/forms/input...
the currency sign not matching the selected symbol is confusing
For example - http://landrick.react.themesbrand.com/ is 17$.
https://g-axon.com/wieldy-ant-design-react-redux-admin-templ... is 24$ (which uses ant design)
I bought this the moment I got the email about it this morning because this is going to help my productivity in building web applications. When you use Tailwind, you aren't using a pre-made theme as you would with a bootstrap theme you buy, you are designing it from scratch.
With this UI kit you'll get some nice building blocks to become even more productive, but you'll still end up modifying stuff to make it yours.
I honestly think this is priced too high.
Not only that, but I think the pricing model is wrong; lifetime access for a one-time fee is a big mistake (and one I previously made with a startup).
As a developer, I understand that you need a predictable, repeatable income stream to keep going - and if I'm going to invest in something like this, I want it to keep going. I'd far prefer to pay something like $49/y instead of a one-time $249 fee.
Does this mean, Tailwind UI is Tailwinds "answer" to that problem? Like, it's are direct Bootstrap competitor?
I'm a frontend guy (among other things) and for past 2 years I've been using Nuxt (app server, node.js) and Vuetify (material UI framework for Vue.js). Given what kind of results that stack can (and does) achieve, I wonder if people in the same boat as me (using the same stack) would even attempt to use Tailwind CSS/UI.
Whatever the case is, I'm glad there's a project that's useful and that helps authors finance their effort. Thumbs up!
I rather use a free option like https://semantic-ui.com/ than pay that much. Maybe if you are company but it doesn't really work if you are a solo dev or using it for a side project.
Normally with themes it would be time prohibitive to do so, but the nature of utility-css is that it's relatively straightforward to implement each component, even without looking at the CSS that's obviously easy to inspect.
I think what they should do is build a tool that let's you build your entire site using these components and charge for that. Otherwise, I guarantee within a year of today, 2/26/20 there will be a free version of this on GitHub created by the community.
---
On a side note, if some bored person out there wants to make a huge splash in the CSS community, figuring out a way to target a specific DOM element, create the equivalent of an AST and specify a "dictionary", which would be a utility-css framework (tailwind, tachyons, basecss, etc) and finally reimplement the targeted DOM element in the chosen framework would be amazing.
Assuming you buy into utility-css, that would remove all existing friction in adopting it. Then that would mean you could grab an existing theme [1] and convert it to tailwind components as desired.
1 - https://themes.getbootstrap.com/preview/?theme_id=4231
Tachyons is licenced under MIT too.
There are tons that look visually appealing, but very few I've found that take a component-based approach (where they document each component individually - or think about how they interplay with each other). I've found the CSS is usually muddled, they often have legacy build pipelines that has to be rewritten to fit with Webpack, and a distinct lack of flexibility.
If Adam solves that side, Tailwind UI will be worth the money.
If it causes other theme providers to up their game, even better.
No because I believe that for every enterprising person wanting to circumvent paying for software, there are that many people who want to support the entrepreneurial spirit Adam and company show, and pay for good work. That's what capitalism is suppose to be about at least, anyways.
This is quite doable for us at Protoship (we've built both a design-to-Tailwind CSS+HTML converter as well as a webpage-to-Sketch Chrome extension). It is a very appealing idea - to be able to recast any webpage into a Utility CSS framework, but I'm curious to hear about situations where it would've been useful in commercial work.
Tailwind-UI looks very interesting and I would have no problem paying for it, rather than getting a "free" version, if only for the long-term sustainability. Community projects often go through endless rewrites, and suffer from feature creep and lack of direction.
In a business setting (I run a self-funded SaaS business) I am much more interested in a framework that fixes bugs and is stable.
The only thing that worries me is that the pricing is one-time rather than subscription. How can the authors expect long-term sustainability with a one-time payment? Maintaining a CSS library is a continuous effort, not a one-time thing.
I think if utility-css frameworks get popular someone will abstract the components from the frameworks and things like tailwind ui will become unnecessary (rather it will just be utility-css-ui and will work with any css-framework that implements the "interface").
Semantic UI is the perfect example of why you shouldn't go with something that's generic. Unfortunately the project just became too bloated for one person to handle. Your concern about sustainability is a good one and that's exactly why many of the frameworks' authors sell themes. However, themes usually require a lot of work and are difficult to implement using the actual css framework. tailwind ui is different because if you had the theme it's really easy to recreate it because it's utility first.
It is described in the Tailwind docs here - https://tailwindcss.com/docs/utility-first/
a) how hard it is to make a library like this that's any good
b) people will want to support them anyway
$249 (or $599 for a team license) one time is really very little if it does what it promises.
When your job is delivering high quality UX and there are always more apps to build in the pipeline, having someone give you a library of useful components works.
I have licenses for probably 4-5 of these, and they've all saved many hours of time, and resulted in avoiding the cost of a dedicated designer.
https://basscss.com/
Like you, I was put off by how crowded the HTML looked but got used to it and found it way quicker to update and kept the css file clean.