Tailwind CSS: From Side-Project Byproduct to Multi-Million Dollar Business

This seems like such a destructive approach to software development, and especially open source. It seems pretty obvious that having additional tooling will only boost the popularity of the original project.

I wrote "ruined my launch day" because I understood him. He (& team) worked on their premium (paid) project at the same time but couldn't release it because they had a lot to do to maintain the main project.

This is a good thing, right? You want to use technology where authors will not sacrifice quality.

It didn't ruin the launch in any other way. My Show HN had ~300 upvotes and #2 Product of the Day on Product Hunt, so pretty good results thanks to the technology & community that Adam created!

You can achieve the convenience of taildwind with plenty of css in js libraries and not make an utterly unreadable un-composable UI component library.

Libraries like this basically exploit the "stick to the platform" mentality in which developers rather accept a poor methodology than a proper one that deviates from the "web platform"

Any chance you can/will integrate the TailwindUI components for those that have purchased them? For me, that would be killer for quick mock-ups and starting points.

BUT! This proves there isn’t a “right” way to do things and developers have differing preferences—enough to make 7 figures of revenue.

This may be the stated point, but it breaks down in many cases. Tailwind, Tachyons, etc. are often a more straightforward, maintainable approach.

You get 1 class apply to many nodes relationship.

You only write the css once more (or never again if you use tailwind or tachyons) and reuse it many times.

More thoughtful reply to similar question from Adam Morse of tachyons: https://github.com/tachyons-css/tachyons/issues/12#issuecomm...

Spacing, button styling, border radius, shadows, font sizing - basically the things its easy to get wrong - are already decided for you so its easy to make something that looks decent pretty instantly.

I have also been using Tailwind Builder[1] which is pretty helpful for learning Tailwind and also generating things like menus and basic page layouts pretty quickly.

[1] https://tailwind.build/

(1) You have to think less. Try "margin-top medium", look at the result, "oh it's too much", try "margin-top small", look at the result, ok fine. No px-fiddling.

(2) It produces more consistent results (i.e.: things tend to look nicer).

What doesn't win me is that, while I see the increase in development speed this brings, I don't see how would you handle maintainability (i.e.: what happens when the design needs to change?). I suspect the trade-off here is that you just renounce to such redesigns and commit to the idea that you'll rebuild the entire thing if/when the time comes (tech advances so quickly in this space that you may want to do it anyway).

Once you get over the small learning curve, it gets to be VERY productive. Think of it as writing CSS at a slightly higher level of abstraction. That abstraction being in not having to edit two separate files or areas of your HTML document (unless you want to abstract further with @apply).

Not having to go through the 'define identifier in element, then define in StyleSheet' workflow. With Tailwind you get the most commonly used style definitions pre-defined. But not so high level that it LOOKS pre-defined. Giving you room to customize greatly. How could it not be faster?

I recently completed a theme in Tailwind, mostly to get the hang of it: https://planflow.dev/free-themes/. And managed to go from idea to finished theme in about 4-5 days. That's the fastest I've ever done it.

But the web environment has changed. React and Vue introduced modularity of style and structure with components. So I can just use a Button component across the website instead of a CSS class. This means CSS is mostly written only for that specific component or file. So tailwind and those other css-in-js have sprung up to bring both into one file.

And I’ve been using tailwind for about a year now and can very quickly throw together most layouts. It feels very smooth to be able to define the div and it’s style on one line at the same time. And short classnames like “m-4” and “w-full” are also more succinct than the raw html style property.

Positioning, sizing and styling is very easy, especially when you can control all those aspects with variables in your view classes.

You have to try it to understand it.

Keeping your CSS and HTML completely separate just doesn't work in practice though e.g. we still need to throw in ad-hoc wrapper `div`s because CSS isn't powerful enough to do what we want, we have to pollute the HTML with class names that have little semantic relevance outside of styling as we're creating the styling, and it's a pipe dream that designers can jump in and help with the styling without help from the programmers.

It's a nice idea but keeping HTML and CSS 100% separate hasn't panned out - people need to accept that and stop promoting the separation of CSS and HTML dogmatically. The reason there's so many CSS frameworks and different ways to do the same thing on the frontend is a strong evidence we're still figuring out the best way to do things. CSS has been out for around 20 years now and it still doesn't do what we need it to.

Also, if you're keeping your data (like blog posts, product information) in a database, your data is already separate from your UI/styling. What are you gaining by splitting up your styling further? Is a similar level of splitting up done in other (non-HTML) UI frameworks?

  <div style="padding: 20px;" />

  <div class="p-2"/>

For a simple website semantic HTML or SMACSS can work, but for any semi-large scale websites with many variations of components it'll quickly descend into specificity hell. Using atomic classes keeps the specificity flat, and it avoids an entire category of errors that haunts many large projects just by making the styles sort of self-contained (you still need the stylesheet).

Of course there are other approaches to this problem such as "namespacing" your CSS using BEM and dynamically generating class names using CSS-in-JS, but using atomic classes is a very maintainable way to style HTML, if a little hard to read.

IMHO it is really quite similar to using HTML attributes for styling or inline styles. Maybe those wheren't actually such terrible ideas. They are the easiest thing for a beginner to understand, so maybe they are actually the easiest way to reason about styles for non-beginngers too.

What makes it different is: - higher level component frameworks: wether you use react, vue, web components or use a templating engine in a component pattern, that is all the abstraction you need. Introducing an additional layer of abstraction/reuse with shared CSS classes is uneccessary overhead. - constraints: the scales for spacing, color, typography and everything else that you configure for tailwind lead to nice, consistent designs without much effort. I think that would be a key problem when just using inline styles.

We keep a few hundred grand in the bank as a payroll cushion but everything else gets pulled out and put in our personal bank accounts. We're both millionaires and financially independent at this point, and are only continuing to do what we do because we really enjoy it. We're building a small team so we have more freedom to pursue other fun R&D-style projects while still delivering on what our customers and community are asking for.

So happy that we just bought a team license for Tailwind UI.

Too many marketplaces exist where there is no value-add instead of sitting in the middle.

One of the reasons I bought Tailwind UI is _because_ Adam & Steve knew what they were doing, had good attention to detail and because I'd already purchased Refactoring UI. I'd worry that with a marketplace the quality would drop, no matter how much guidance you give.

Hoping instead that we can find the right small team size that lets us do more of this in a first-party way, and selectively support the tools we find people ask for the most.

Could definitely see a world where we work with experts in different technologies to port our stuff over and maintain it under some sort of retainer agreement though, just don't see us ever giving up any of the actual UI design or initial implementation work.

As a developer, Tailwind UI is a god send, I've been waiting for years for a great looking CSS framework with pre-made components

(Also, they had a pretty big audience already after selling Refactoring UI which is a really useful book for developers that can't design, like me)