They deserved it, and I'm pleased with their results.
When I started my paid online editor for Tailwind CSS ( https://tailwind.build ) in November 2019, and someone posted a link to my Show HN on Discord, Adam replied:
"bums me out when other people get stuff released using my tools before me because i have to invest so much time into building the actual OSS its all built on :/"
And this ruined my happy launch day :)
When I read that they make much more money, I am again in an emotionally neutral state ;)
I think you draw too many negative conclusions from this one comment :)
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!
Yeah, that really feels like the exact wrong attitude to have. If you don't want people to build money-making products on top of your OSS, either license it that way or make it closed source. Period. I don't see any reasonable grounds for complaint here.
This isn’t really what I was saying when I made that comment (in a personal conversation among a small group of friends).
I love that other people are building things on top of Tailwind and I think it’s great. I was only describing my own emotional state and how much pressure it makes me personally feel to finish our commercial projects, and how stressful it is to feel like there’s not enough time because my time has to be split instead of being able to just focus on the commercial tools.
Purely just me commenting on my own stress and being vulnerable among friends, not any sort of commentary on the ethics of other people building things on my OSS.
> "bums me out when other people get stuff released using my tools before me because i have to invest so much time into building the actual OSS its all built on :/"
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.
FWIW, I don’t think it is destructive, in fact, it is a reformative approach i.e., after all we are human beings, not sages and saints, and the real value lies in being able to do it despite knowing your flaws as a human being, and the “congratulations” from OP is an evidence that they realise it is a part and parcel of life. It takes time to digest the fact that someone has progressed far ahead of you using your tool and when your mind is clouded, you don’t immediately think about how that is a net good.
Speaking without thinking is something I can understand, but it's not an excuse. Nobody is an island, we're all standing on the shoulders of giants, and disparaging another's work when they're arguably helping improve your own project is an attitude I wouldn't expect in an OSS project. As someone else said, if this is the way the author felt about Tailwind, they could have chosen a proprietary license, or just left it without a license to fall back on regular copyright.
What happens a lot of the time is that authors choose open source licenses because they know that's how their project will attract attention. I'm not saying that's necessarily what happened in this case, but it's not uncommon to see authors of some OSS projects seemingly being surprised about how OSS works or what the mentality is expected to be in the project.
All true! But to invoke a common ground here, most people put up a lenient license in the beginning thinking I will attract some attention and if things pick up I will create a product(or some serious library) out of it, make money, while leaving the core as is. But when it surprises them they are not ready for it(which is pretty much all of us). In fact, if I were to guess the OP would have just dropped the original project if it were not for the pacing provided by the Tailwind CSS team. The thing is for most of us personal projects are a way to express our autonomy where you do what you like and want instead of being constrained by some guy telling what you can do, which tools you can use, what features should go in etc, which is the case with most jobs; this autonomy allows you to walk away from your project any time and when that autonomy is played with by anyone who you did not originally see as an ally it can be upsetting. Tbh, it would be naive to think that OSS is still an altruistic movement, maybe some still go by that, but the commoditisation with GitHub becoming your Resume has only made it a more selfish endeavour.
Actually I agree with you and it doesn’t make sense to rant and pity oneself on the Internet, but I think this is a natural consequence of what is being made of OSS in general.
Im pretty sure this won't last long. If tailwind doesn't involve a made up dsl geared toward saving keystrokes but a low-maintenance syntax that is either proper css/sass or css programatic api, then I would give it some benefit of doubt.
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"
I'm a recent convert to Tailwind, like your builder a lot.
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.
I don't understand tailwind. The entire point of CSS is to separate style from structure. How does applying composable utility classes to all of your HTML elements differ from the old days of using HTML attributes for styling?
Edit: So after looking into it a bit more, and specifically the section in the documentation about extracting components, I understand where they're coming from a bit better. Extracting repeated compositions of utility classes into reusable components or named classes is exactly how I use other CSS frameworks such as bootstrap or foundation. I'm seeing the major difference between tailwind and other CSS frameworks as being the lack of pre-defined UI components. The minimalism is obviously a big advantage for performance, but otherwise I still see little difference between Tailwind and other CSS frameworks.
It really is one of those "you gotta try it" things.
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.
FYI, URL routing is broken on that site: if you navigate to /free-themes directly (such as following a link), you end up at /, and can only access the right page by clicking the link in the navigation in a JS-enabled browser.
The problem is that devs stopped doing semantic elements. Its now a div and span fest. The layout however has become more simple due to mobile/smartphones. But the front end complexity has become exponentially more complex. You save one day of work by using a bunch of frameworks, then you have to pay every time a user visits - with less conversions due to a slow site. And then you have to pay every time you make an update - due to the extra complexity. Then you regularly have to pay over and over again to keep the frameworks up to date.
> The entire point of CSS is to separate style from structure.
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?
Your last point is a new argument for me and is really understated. The HTML/CSS fragmentation appears to be a historical artifact more than an architectural ideal
I'm not sold on the idea, but there is one major difference: you constraint yourself to a set of values. This attains two goals:
(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).
In practice with a similar approach, we have seen when design changes, you end up having bits of your site looking old indefinitely. You can tell the “era” a page was built based its design choices. Not good.
- Once you are in the "margin-top: xxx" part, nothing prevents you from saying "just this time" and writing some px (or whatever) value, either because you don't remember the options at your disposal, because none of them feel exactly right or whatever. Using tailwind you would have to create an entirely new size definition, which is a big hassle. That is, using scss does not actively push you to this particular "pit of success" whereas using tailwind does.
- Responsive handling is much more verbose in scss. Consider "sm:mt-2" versus "@include responsive(sm) { margin-top: margins(2) }"
One of the best things about Tailwind in my opinion, is that it makes a load of decisions for you.
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.
Well the point of CSS separating style from structure is to be modular and useable across different websites/pages. So define a button class name I can use anyway in my HTML.
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.
> React and Vue introduced modularity of style and structure with components.
It also works perfectly fine with server-rendered pages in my experience. Any templating engine worth its salt will allow you to extract fragments or partials.
> Start putting css in the style attribute while you’re at it.
I think everybody reacts like this at first (including me) :) If you put styles directly in the attribute, nothing is preventing your from using a color that's not part of your palette, nor using sizes that do not respect your UI "flow". Tailwind comes with a (customizable at build time) well-defined sets of colors and sizes.
The basic tension here is designers are often not really designing a "style sheet" (even if they think they are). So a lot of elements end up being similar, but not the same. And all responsive states are often 'you figure it out'. Plus marketing involves one-off pages where nobody is thinking about reusability. I haven't used tailwind yet, but the utility-first idea has been around for a long while.
They provide a balance of governance and flexibility that allows team members to work independently to create new designs, but not have CSS specificity get out of hand.
One main benefit is to constrain the actual power of CSS specificity.
The other main benefit is that these micro-styles map closely to design semantics, not functional semantics. This is covered in the OP. At a certain scale, the number of distinct functional semantics grows huge, but the design semantics remain bounded.
I personally don't think extracting component classes is a useful tailwind feature.
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.
Another point that hasn’t been mentioned yet is Tailwind also minimizes regressions. With the blanket CSS way, changing a style has too many side effects and can mess up other styling that you didn’t intend on.
One benefit that isn't often mentioned is better developer ergonomics. Styling with utility classes saves you from having to open a CSS and html document side by side (e.g. if you do layouts where it's helpful to see the html structure while writing css), which can make a huge difference if you also need a browser window for visual feedback.
I think the most satisfying part for is the elimination of the constant context switch between my jsx/html and css file.
We use CSS modules and it drives me crazy to keep switching back and forth to add styles.
Plus is think <div className="mx-12 lg:mx-24 md:mx-12 bg:white dark-mode-bg:black />
looks just outright readable and tells me everything i need to know about that div in one glance.
I for one absolutely love it, but have team members little on the backfoot. Preferences i guess
bg:white is exactly the problem. What if I want to change all my white backgrounds to #FCFCFC? I've got the option of going through and updating all my components individually or updating bg:white to be a non-white value.
Everything is generated through a config file which you can completely customise. So you could literally change the colour of bg-white if you wanted to.
It's part of the selling point, that config file becomes your design system. They provide a decent one but you are free to overhaul it as you see fit. It works really well.
If you were building a themeable website, then you'd not be using bg:white; instead you'd use something like bg:main or something similar with a semantic meaning. This kind of customization is one of Tailwind's core workflow.
it's like variables for styling. Instead of throwing some random numbers developers can bump the numbers up p-3, p-4 or text-red-200, text-red-300. It helps to keep things consistent.
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.
It’s a pity that literally every HN thread about Tailwind has someone that wishes to complain and moan about it. We get it, you prefer old school CSS spread across multiple files that you need open all at once.
I understand a lot of people still remain skeptical of utility-first approaches. And answering the same questions repeatedly gets frustrating.
However, please avoid the snark. It diminishes the discussion. It took me a long time to come around to the idea, and the snark of (some of) its supporters was precisely part of the reason for that.
I wonder what they'll do with their money and success.
I'm reminded of LogoJoy - a single founder company that started sucking in huge amounts of cash revenue, which the owner spent on employing people and offices and growing a company and getting investors who recommended they rebrand, destroying much of the value and revenue of LogoJoy. I bet that founder is wishing he stayed a single person company and just banked all that cash. https://betakit.com/looka-lays-off-80-percent-of-staff-as-fa...
So I wonder which way these guys will go. Will they bank the cash and buy houses and have a quiet and happy life, or will they spend it on employing people and growing a business and getting investors to try to make more money?
No plans to go the VC route. We've hired three people now — two developers focused almost entirely on open-source, and another who splits his time between our commercial projects and contributing in our OSS community by answering questions, writing documentation and guides, etc.
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.
Big fan of tailwindcss and paying customer of tailwindui also. The decision to purchase was at least in part based on your active engagement with users on the discord channel.
Adam, Steve, have you considered building a marketplace for Tailwind UI, and focus more on guidance and quality control on the design side instead of building out all the components yourself?
It could help with the creation of interactive components for all ecosystems, like those that are tightly coupled to a specific ecosystem considering that it's not only frontend frameworks, but also backend frameworks that have their own LiveView version or way to do components now (e.g. Elixir Phoenix has Surface which is like writing backend React components, Rails has view components).
Supporting all those combination yourself seems daunting, and it would suck to see components for React or LiveWire/Alpine, but not other ecosystems that aren't covered by the skillset of your team.
We've tossed it around, but ultimately we believe that our customers buy Tailwind UI because Steve and I designed/built it, and we've built a lot of trust in our community over the last 4-5 years. I wouldn't want to be a full-time QA person either.
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.
I bought into it because as a designer I got interested in SaaS, and my impression was/is that you have a perspective on design edgecases that most traditional or semantic html devs lack because they're more focused on content sites and blogs.
Keep up the work, but don't forget smaller frameworks. Your last suggestion with the retainer agreement sounds good!
>instead of building out all the components yourself
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.
They could curate the submissions. But most of the stuff wouldn't be about visual design and the style of the components, but template and component level frontend stuff that's handled differently by each framework.
Sure, but imagine you've paid for it and they come out with more interactive components, but your language ecosystem then isn't part of that because they don't have the capacity to cover every environment. A curated marketplace would be a smart choice imo.
Personally I prefer this approach. It's like with the Streamline icon set. I know I'm going to get icons with high quality and a consistent visual language throughout. That's what you're really paying for.
Wow 2 million dollars with Tailwind UI, I would never have imagined that would be possible when it was first pre-released with only a few templates five months ago. Congrats!
Everybody talks productivity. I completely agree. I was so much quicker with Tailwind CSS than any other approach I was familiar with. But let's talk about maintenance. I had to go back to a project I completed 6 months ago to change a few things and boy do these classes look like a mess!
Played around tailwind css this weekend, pretty good and enjoyable. There's some quirks that make it slightly annoying to use with a static site generator that takes in markdown files and converts them to html. In this case it becomes annoying to style these files via something like tailwind.
For simpler projects there's tachyons as well, which shares a similar philosophy and is a bit simpler in scope.
Yes that's the only way to do it, but then you kinda cirumvent the whole tailwind philosophy. The tailwind typography package is an attempt to fix this, but right now it's annoying to use.
Really happy for them. Tailwind is so good that it’s actually made my website designs 5x better. I’m able to translate my thoughts into pixels so much faster and more accurately with Tailwind than with any other CSS system/framework.
If you haven’t tried it, you should. It definitely looks really silly (inline styles?!?) but it’s so powerful.
TLDR: I've written a moderately complex app using Tailwind and only had to write 33 lines of CSS.
I've been using Tailwind to build a moderately complex app, and for me the killer feature of Tailwind is that _most of the time I don't have to think in CSS_.
It's not that I can't think in CSS - I've written lots of CSS over the years. However, as someone putting together a UI, I want to think in terms of slightly higher-level constructs. With Tailwind I almost never need to think about specific pixels values, weird browser quirks, or how breakpoints are handled. Instead, I can think almost entirely about how to achieve the correct behaviour.
I work with ClojureScript so I have hot reloading and fast feedback, and I can build a moderately complex UI component in a few hours. Not having to context-switch into CSS really helps me to stay in "flow". If there's some very specific design feature that I need, then I can still write some custom CSS, but this is sufficiently rare that in a 10k SLOC project there are 33 lines of hand-written CSS.
I sincerely hope the creators avoid falling into the VC honey pot. At their current scale they're on pace to build a sustainable business around the core open source library. Growing beyond their UI component library toward an open marketplace (a la Noun Project) should be easily doable in the low 7-figure revenue range.
We still find Bootstrap unmatched for training content creators and developers, while making completely custom templates. The utility classes in Bootstrap get us far enough that most CSS specificity is flat.
I'm very impressed that they sold $2m so quickly. Especially given that these are lifetime packages, not SaaS, it's really impressive. It means ~8000 people became their customer in just a few months! That really blows me away, and I'd love to understand more about how they pulled that off.
I bought the $150 package. It’s easily saved me $150 in hours I haven’t spent tinkering with design. It’s a great value proposition. I don’t use tailwind CSS; just the designs.
As the maintainer of several very popular open source projects in the infra-structure space, I was initially impressed by hearing the team had gotten 2M USD in revenue over three months, but then read they'd already brought in 2M USD in the previous two years, totalling 4M USD over ~2.5 years.
If I could figure out a value-stream like these two gents, then my OSS work would be on another level. This isn't your classic "Indie Hackers SaaS" or viral eBook stuff.
Hats off to you. I'll be the first to buy your eBook :-)
I think the key leap they took to generate revenue was to build out a fully-baked, batteries-included product based on their open source library. Sure you could build out the components in Tailwind UI yourself, but a lot of people will pay the $250 to have a solution that "just works".
Its pretty easy. You sell something to your users. And it doesn't even have to be relevant to your product. The hardest part in selling is to acquire users. But as you already have users you can now upsell and cross-sell.
This way your html has semantic classes but the definition of the classes uses something like tailwind instead of raw CSS. One level of abstraction. Seems the best of both worlds?
Wow, a huge success from Tailwind UI project. I would never imagine that Tailwind UI could bring in so much revenue. I think Tailwind CSS is a niche CSS framework that's why I am working on project similar to Tailwind UI. More competition is good for customers. Still invite only tho.
> "In classic developer fashion though, I spent the entire week making decisions about the tech stack, and had maybe one full day at the end to actually hack on the real functionality.
> One of those decisions was what to do about the CSS."
Thank you, Adam, for developing Tailwind CSS. I've been using it exclusively for my side projects since the start of the year. The thought of going back to a less utility-based CSS system (and/or SASS/LESS) leaves me cold.
I'm a customer of Tailwind UI and I have to say I'm very inspired by this post. Great product, solves a real problem. It's bound to reach this point. Great work!
You really are an inspiration to us that made us create the idea of https://Frontendor.com HTML Library and keep going to the end and not giving up about our dream.
The bundle is $249. If you don't think 8k people would pay that to have lifetime access to components that look great and allow you to build a great looking website in hours, you don't really understand the dev market.
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)
Congratulations! I would highly recommend removing that extremely annoying, disruptive and useless "Get Early Access" banner at the bottom of every page on your website (including documentation). GitLab used to have a very similar banner (don't remember exactly what it said). I wrote to them and eventually they have gotten rid of it (I like to think that it was, at least, in part, due to my criticism :-).
When I started my paid online editor for Tailwind CSS ( https://tailwind.build ) in November 2019, and someone posted a link to my Show HN on Discord, Adam replied:
"bums me out when other people get stuff released using my tools before me because i have to invest so much time into building the actual OSS its all built on :/"
And this ruined my happy launch day :)
When I read that they make much more money, I am again in an emotionally neutral state ;)
Congratulations!