We've gone full circle - CSS components to inline CSS-in-HTML back to CSS components.
But I actually think I will use this. A big problem with CSS is that you end up making overrides no matter how composable you make the classes. And some simple things (e.g. responsiveness) are unintuitive and / or annoying to do in CSS. Hence Tailwind's "CSS-in-HTML" mini classes. But that doesn't fill the core purpose of CSS, bigger general-purpose classes to avoid repetition. Combine the two (general classes + mini classes for slight case-by-case fixes) and you get the best CSS experience I've seen so far (at least I think, I haven't tried it yet).
> A big problem with CSS is that you end up making overrides no matter how composable you make the classes. And some simple things (e.g. responsiveness) are unintuitive and / or annoying to do in CSS.
10000% agree with this. I have found that copy/paste until you need to go back and change the same value a few times is worth its weight in salt with CSS. Never has "a poor abstraction is worse than duplicate code" been truer than in CSS.
What I found in my FE days ways that it wasn't until the project shipped and we were iterating on v2 did the actual reusable classes appear.
Interesting. I write CSS with absolutely no overrides. I compose at the JSX component level, so there's one Button component used everywhere, not a btn class that gets applied to random <button> components. I usually need to reuse more than just a style, so why not encapsulate it at the component level? If I _do_ want to compose individual styles, I use Sass mixins.
And I find that looking at a single media query over semantic classes to be far easier to understand than utility classes scattered over multiple elements. Looking at tailwind responsive classes hurts my brain.
idk, I've been using tailwind for the past 4 months on a large and complex project, and I haven't had to override a single class. There were a few instances in which I needed to write custom css to handle certain scenarios, but that is roughly 100-200 lines of css.
I also never had to do it when I was using Emotion, and I used that for 2 years.
I also haven’t done much CSS since bootstrap 2.x days. I wonder if there is some tooling you would run in your CI to propose CSS changes - not failing like most linters but just nudge the devs a little to improve on low hanging fruits.
Really? You can layer classes or even use IDs for something super specific. The only time I use overrides/in lines are when I’m testing/troubleshooting.
I think the thing with Tailwind that people are missing is the opinion that CSS's bigger general purpose classes to avoid repetition have failed. However, most of us are using some kind of HTML templating system. What matters is that the design work only happens once in the code, repetition in the finished product is just fine. So moving the job of avoiding repetition out of CSS and into your HTML templating system is the right way to go.
HTML templating (specifically FreeMarker macros) is what i’m doing now.
There are still some cases where classes are useful, like JS or when I have very different components with some shared style. But these are mostly edge cases. FreeMarker has some other problems though.
Using a convention for custom classes helps distinguish from tw classes and other libraries, and allows stringent linting of css selectors to make sure the specificity issue is covered (without using !important on all tw and custom utilities which imho is a bad solution).
I’m not saying this is ugly but the visual execution of some of these components is poor. No good usage of padding in some examples, poor ratios between the typography and the containers, inconsistent use of different line widths and border radius, weird and incosistent design choices in spacing and proportions…
I mean. This looks alright and it will certainly make any UI look pretty decent, but the execution is not superb like the actual TailwindUI library which is incredibly well thought from a visual design perspective. Those components are perhaps less shiny than these but they are incredibly functional and way more intentional.
This is a good effort though and I hope to see it improving.
I think it is not a fair comparison with the Tailwind UI where there's probably more than one person doing the work plus the whole expertise of the actual Tailwind authors in the mix.
If you are able to observe what is severely lacking in this implementation, I am pretty sure that the Github author would welcome your suggestions / comments / PRs and any contribution to make this better.
For a start, this is actually good (enough).
In the same vein that TailwindUI is still continuing to evolve as the maintainers are finding optimization to make it better.
Totally agree and I mean it with no animosity. As an adopter of Tailwind, I really want to see more of these components kits and for the exisiting ones to keep improving.
Back when Bootstrap 2 was the most popular UI library one of the biggest problems with it was that the defaults were good enough that no one changed them, and consequently every SaaS startup's product looked the same for about 5 years. Pushing people to tweak things while still giving them a solid foundation is a good thing.
I'm not saying that's necessarily the case here, but there is a strong argument in favor of not making the default theme for a UI library look perfect.
> the defaults were good enough that no one changed them, and consequently every SaaS startup's product looked the same for about 5 years
Sounds like native GUI experience on Mac or Windows for quite some time, then? I'm certainly not offended when all buttons look the same. At least I immediately know that they're buttons.
This sort of stuff was difficult to figure out when I was learning HTML/CSS, do you know of any guides which list similar rules and how to make "proper" use of properties like borders, padding, typography etc?
Refactoring UI [1] is a good place (from the guys behind Tailwind) - admittedly I've drunk the Tailwind koolaid, but there are some useful tips on
there from a designer POV
Unrelated tangent: I'm always frustrated when I see a recommendation for a book only to go and look it up and find that it's actually an "ebook" (in this case PDF).
Not to make a value judgement on ebooks, but I just really like physical books sometimes - if it was on Amazon I likely would have bought it.
Again, not a value judgement on the content - I'm sure it's great (I'm a paid and happy user of TailwindUI)
The Non-Designer's Design Book is the best resource I know of for learning general design guidelines, which apply to what you're asking. I've bought this book for many developers and they've all loved it.
This stuff all falls under the umbrella of “design”. One thing that helped me a ton was the articles at https://learnui.design - especially the 2-part “Rules for Designing Gorgeous UI”. The course itself is also excellent.
You could refine them, group the points and put up a blog post (or a GitHub page) and share that here (as its own submission). If it’s with visual examples, all the more better. I’m sure somebody will find it useful.
I agree that there is room for improvement - though I think it's not a bad V1 at all.
A lot of the products I see turning up on Show HN would look infinitely better if they used this library. (The ones where UI design is clearly not the solo-developer's strength).
Ok, I'll guess I'll be the lone voice of dissent here. I don't like it. I think it goes against the concept of utility classes / functional CSS. As soon as you start making component-level classes, things begin to become opinionated and you lose the universality.
My understanding of the functional CSS approach was that you'd make a button component, and use the variety of "atomic" classes to style it. If you're using a "btn" class etc, it muddles the distinction of where the semantics live, and things get harder to reason about / debug.
Can't you just use @apply to make a single uniform style that utilizes all those classes?
That's my understanding at least, like if you want to make a button, instead of have the same 10+ classes posted everywhere you make a new class with @apply and keep the styles uniform.
Then in the future if you need to change one of the core utilities it's also easily updated to all you the @apply classes you make.
Am I misunderstanding the purpose? I've only used tailwind twice.
yes you can use @apply. DaisyUI also supports @apply directives as well both for their own and tailwind clases.
However you have to use them yourself. With vanilla Tailwind there is no out of the box @apply directives already set you can use. Think of DaisyUI as basically a whole set of @applies someone already made for you.
For users new to frameworks with utility focus it can be less steep learning curve to experiment and all the out of the box abstractions can reduce the need for having your own.
Tailwind is supposed to be used with components. Often it's React/Vue/Web components, but CSS components with @apply, like you're doing, also work perfectly fine.
You're right, it isn't really utility/functional CSS - it's more akin to BEM [1] at this point. But having used both...I think it's pretty much six-of-one, half-dozen of another; you can write good or poor CSS both ways! :D
Well, this is true, but to me this provides a set of good defaults instead of starting from scratch. I see this very useful for example for side projects, where I don't want to start from scratch on every experiment I do.
For a work project, I'd use just tailwind for the reasons you mention.
Very welcome. Sometimes the amount of classes needed in Tailwind is enormous.
I paid for the TailwindUI pack too. But as nice as Tailwind is, the guys who built TailwindUI don't really get or understand a lot of real-world design patterns.
A lot of stuff in there is needlessly complicated. Our team end up trimming down things to 50% of the markup that they use, while retaining full responsiveness.
Overuse of flex for simple paradigms is a constant complaint of mine.
Hope DaisyUI improves Tailwind in some way.
Anyway... sorry to get sidetracked on a sidebar.. lol.
Exactly. I paid for TailwindUI too but have been disappointed by the execution in code. I love the visual design, but give me some abstractions and not 20 classes per element.
> the guys who built TailwindUI don't really get or understand a lot of real-world design patterns
It's all relative. It's clear they understand more than I do, and I'm not a terrible UI designer, so paying for TailwindUI has been a no-brainer in terms of the value delivered to my projects so far.
I would suggest the use of convention like SuitCss for your custom component classes so you can lint them thoroughly to ensure low specificity.
I would recommend to use a prefix on your custom classes, to "namespace" them. "btn" is far too generic. This can even be linted by eg. postcss-bem-linter.
Cool to see this out, but there is something about Tailwind I've never really got. And this is not from abstraction, but in production use on a number of pretty large sites.
Each Tailwind class corresponds to a CSS property, with a few exceptions where you have utility classes for degrees of that property (for example, padding, margin). Then along come these CSS component libraries, which substitute a thicket of these utility classes for a single class. Including Tailwind UI itself.
Given that the relationship of class to property is one to one, why not cut out the middle person and just use CSS directly? There seems no real advantage. You've basically indepedently re-invented CSS, while adding a strange layer of additional abstraction on top. It is nice and fast to write it in the HTML I'll grant, but, the speed advantage is not so great that it is worth it compared to the mental overhead of other aspects of working with Tailwind (e.g. having to trim all the classes with automated scripts and so on).
For each project, there's a unique balance between HTML, CSS, and the greater organization.
Consider a site that mostly renders Markdown or XML documents. Tailwind is probably the wrong choice. You have less control of the HTML content in this case, because it's generated. If you want to use Tailwind here, you'd need to make liberal use of Tailwind's @apply directive for basic declarations, which IMO is not the best expression of Tailwind usage. On the other hand, you have a lot of control over the CSS. It makes more sense to write the CSS directly.
Now consider an organization with many separate web properties, which all require consistent branding. The organization has a UI guy who creates universal stylesheets and components for use across sites. Here you have less control over the CSS, and more over the HTML. Tailwind makes more sense. You can add all the utility classes to HTML that you want, with few overrides or other enterprise pull-ups.
This latter scenario also highlights one of Tailwind's strengths. Tailwind limits your options. If you need to keep a brand consistent across a large number of properties, Tailwind keeps you in the guardrails of the style guide. I can't be the only one who's worked at an organization where there's supposed to be only one shade of blue to represent the brand, but you wind up finding 160 different shades of blue throughout the CSS.
Anyway, Tailwind has its time and place. I love it when it fits.
This is a very nice step in making Tailwind more Bootstrap like (read beginner friendly). One common complaint about Tailwind is that it makes the HTML look very full (full of classes).
If it's just one class per property, you could just type out the CSS. Using emmet in IDE is probably faster than finding the tailwind classes with autocomplete.
>If it's just one class per property, you could just type out the CSS.
You can, but then it rarely happens that you want the CSS to be fixed in that way for all time: the brilliance of tailwind is that you get resposniveness just by adding a few more classes. You cannot do that with inline CSS.
This is the one pro-tailwind argument I can agree with. Sometimes I’ll use their shorthand md: & sm: in @apply in place of media queries. The advantage is that they remain local to their relevant selectors.
Makes me think- all I would really want is to be able to have multiple values in css. Maybe something like .
With Tailwind, if you write out something like that more than once or twice, you're really supposed to bundle it together. Either as a plain CSS class, or a component in your framework of choice.
I suppose a library of common elements is a good thing to have, but the reason I like Tailwind is that I can use the utilities at first and then easily gather them together as plain CSS classes as and when that makes sense to me.
1) A set of a classes with consistent names for scales, colours, etc. You're not working with hex codes or pixel values. It's a more writable and much more readable syntax than inline styles.
2) It has variants for hover, etc (e.g.: class="bg-black hover:bg-white"). AFAIK you can't do that with inline styles.
3) I find it plays nicely with a workflow where I start out not knowing exactly what I'm doing, which is almost all of the time. I can smash ahead and do things in the class="" of each tag, then as I notice that I'm repeating myself, I grab small chunks of the class list and put them in '@apply's in a CSS file. Bottom-up, liek.
The class lists are just a lot more manageable than inline styles. They're copy-pastable and really easy to read when you get used to it, as long as the lists aren't too long.
Whenever I read a comment like this I feel like talking to someone who’s never used Tailwind nor written inline CSS. How do you write inline CSS for pseudo-classes like :hover, :focus, :disabled? Media queries for breakpoints and dark mode? Not to mention more advanced features like divide-, space-, group-hover:, etc.
Well for one you cannot use all CSS features inline, some of them are pretty important. Then there are also bad performance implications of using pure inline styles.
But in terms of structuring your code, there are related concepts in other areas of programming:
The most general concept applied here is stratification or layering. You want to decompose your code into more general pieces so you can use those pieces to compose the actual solutions.
Example: Say you wanted to write a compiler. It typically much easier to simplify, AKA decompose the compiler into a scanner, parser, analyzer, optimizer, emitter etc. The users of your compiler probably don't care that you decomposed and layered your code. But you do care, since you can reason about your code in terms of small/local problems. Maybe you don't stop there. Your scanner can be stratified further, so you can easily build evolve and reason about it.
This is the primary thing these types of libraries do. They give you generalized building blocks that have compositional semantics that make sense. You can use their sane defaults or generate them from scratch using a design system.
Secondly the atoms are discretely defined. You're not dealing with all possible values for each property but with sets that you can join/compose. The generated classes have this little mini-syntax that you first need to get used to a bit, but after a while you'll easily remember the prefix schema of your classes (Tailwind's documentation site is also very well made). Tailwind cross joins the atoms for you, but then also deletes all the classes you didn't use in your project.
a very underrated feature of Tailwind is it's excellent documentation with immediate search. Want italic text? In straight CSS, how long will it take to look up is it font-style: italic; or text-style: italic or text-italic: true ? Tailwind's docs make it virtually instant. Even more impressive with flex and grid layouts (is it justify-items or align-items, etc). I find that Tailwind reduces the time from "idea in brain" to "implemented on page" by about 90%, now multiply that by dozens or hundreds of individual page elements. (to be fair, I don't do a ton of front end so I forget the CSS syntax quite often)
What's the point in spending 20 hours learning some custom interface that's only used in like 5% of projects and will probably be gone in 5 years, when you could spend 30 hours learning the standard that's been around for decades and understand every library for years to come?
I never sat down for hours to learn it. I just started using it. Most of the classes were very intuitive with a working knowledge of the box model. For anything else I just searched the docs or even better, got the VSCode plugin to suggest the correct one
It's not a custom interface. It's just classes. It's got a type of syntax, sure, especially for media queries but it's not much different than "learning" the classes from bootstrap
It's literally just CSS but abstracted as convenient classes as the name "utility classes" implies already. I don't understand why people keep telling others to learn CSS instead. I also hate dealing and writing CSS cause it's cumbersome and unwieldy and this is a much better way of styling my HTML and getting immediate feedback
As others commented, inline CSS has downsides. But there are libraries out there that allow you to write a block of CSS alongside your component that are neatly packaged into a CSS file, like Styled Components (https://styled-components.com/).
Because you don't have to use it in a component system.
It's not a case of hiding it away, it just has a system for building your own css library kind of thing if you want to
Yes, the way I use it is with Svelte. I've created a list of components in Svelte (buttons, links, dropdowns, tables, etc.) I think with how tailwind makes you html look (very full of classes), it is perfectly matched with a component based framework.
That way you get the full tailwind experience without the tedious rewriting of components.
I agree with the positive sentiment, but a cynical take might be that we've basically found our way back, traveling in a circular pattern.
It looks like Tailwind and Tachyons are useful tools but they do have a sweet spot, and I've run into the annoyance of 20+ classes in my tiny projects as well. Descriptive
Real changes to the landscape have been made along the way:
- Flexbox and to a lesser extent grid are grokked by many
- People are much more willing and able to use CSS variables
- Shadow DOM encapsulation and other methods of isolating styles from one component to another are well explored
- there's some stuff on the horizon where people are JITing here and there and writing custom compositors ("Houdini" and related tech)
But I'm not sure there have been any large paradigm shifts in CSS over the last 10 years, and Tailwind no matter how successful it's been commercially and in the headspace of developers seems to have been largely a very useful somewhat passing obsession.
I see this not as a replacement, but as a novice choice. As noted in the documentation, you can use tailwind classes to customize existing components but if you do not want to you can use it like bootstrap. Even for building a quick prototype which can be made to look good in future is a use case for this.
I want to note that I was talking about tailwind vs bootstrap and others in the abstract, less so about DaisyUI specifically.
What lead me to make the comment was the discussion point that "btn btn-primary" was so much more useful than 20+ tailwind classes. I agreed (it's something I have come across as well), but
It's clear that Daisy UI will get you up and running quickly and there are lots of similar projects out there that do things like this, but the meta discussion around whether we're going in circles or if we've actually moved forward and found a nice mix between what was the bootstrap style (1-2 classes that do all the work) and tailwind/tachyons (5-10+ classes that do the work).
To make the discussion less meta -- is the future things like DaisyUI? Bootstrap like classes but with the outlet for overriding not being manual CSS but actually being tailwind-style classes? In the past it was Bootstrap + your special large class/baked in styles, but in the future maybe it's "btn btn-primary box-shadow" or whatever, clearly a middle point of sorts
I'm not a frontend developer so I've been watching this from the outside over the years of reading HN.
The impression I got is that Tailwind is essentially CSS 2.0 with warts ironed out (sorry for the unpleasant mixed metaphor):
A) CSS / Tailwind: lots of little 'atomic' classes describing individual visual properties. Easy to understand, easy to customize, but slow to read, slow to get started, with plenty of stuff to learn
B) CSS frameworks / Tailwind components: fewer classes declaratively describing the component's role (eg 'btn-primary'). Quick to get started, elegant to read, but prone to abstraction leakage and trickier to bend to your own exact specifications
There's always been a need for both kind of tools for different projects, in the same way that e.g. network programming may involve anything from bit-banging commands to high-level protocols.
Over the years CSS frameworks kept improving, but CSS was much slower to do so - although it acquired flexbox, grid, etc., the language limitations stayed, and they were bad enough to spawn SASS/LESS out of a genuine need.
Tailwind saw a ton of hype and adoption because all the developers who had always wanted to go the (A) road now had a well-designed set of simple classes they could use with a lot fewer footguns, plus a bunch of developers who had adopted (B) because it was the road that had all the momentum suddenly realized that they probably wanted to use (A) once it was made less painful.
DaisyUI and similar projects don't do anything that Bootstrap didn't do for CSS, but by building on top of Tailwind it means that, when your project or resources grow and you want to move from (B) to fully customizing your style in (A), you will be able to write your individual little graphic touches in Tailwind instead of plain CSS.
I tend to use it with some sort of component system - vue/react/svelte - so writing the classes out once doesn't bother me.
I actually like it, as looking at the code I can see exactly what it does. 'btn-primary' doesn't convey anything to me. 'rounded text-sm font-bold py-2 px-3 bg-indigo-300' I know exactly what that is going to look like.
I also appreciate the removal of classes not needed if using a build step - much nicer to have a small css file that has exactly what you use, rather than a bootstrap style kitchen sink
so why not just use bootstrap? I'm new to web development, but I thought the whole point of TailwindCSS is that it is more customisable than Bootstrap.
What if you as a beginner can start using Tailwind immediately with this library and can learn tailwind's utility classes at your own pace when you need to customize anything?
I'm not sure about this path, but it might be good for a beginner.
Why? A “create” button that takes you to a creation page is still a link to that page and should be a link. It looking like a button indicates an action that the user understands. It is accessible, semantically correct, and follows accepted design conventions. What is the problem?
Because there's an expected built-in behaviour to these elements.
> It is accessible, semantically correct, and follows accepted design conventions.
There's nothing accepted about disguising a link as a button. Especially when it literally does no action except, you know, linking to a different page.
Though, of course, there are ambiguous situations, especially in the context of PWAs. But code examples are not an ambiguous situation.
I think that ship has sailed, I really don't think that average users expect a button to 'do something' (in the sense it submits a form or something).
Going to a different page /is/ 'doing something' as far as users are concerned. Certainly not the internet of old where a form was a form, and a link was a link.
An average user has no idea what's going on in modern software anymore, to be honest. Nothing is what it seems and is redesigned every couple of months
There is a substantial difference between these two links. One takes you to a location, the other one starts a process which ends with an action.
As a user you are not going to be clicking the “New” button everyday. Maybe once a month, maybe once a year. So you are likely not going to remember where it is from the last time you clicked it. If you don’t find it when you need it, you will get frustrated. It needs a lot of visual weight relative to the other links in this nav section. Giving the same weight as a button is a reasonable decision.
Eh, unless an app is a SPA (where you attach event handlers to buttons to run client side validation or something like that) it’s way simpler to have a form route to another resource via a link. But users think of them more as actions than links, so its perfectly reasonable to disguise a link as a button.
edit: I said “form”, but I meant page. Forms actually use buttons!
Looks good. I’d really like to use this. Mainly I like that the author used same approach as I do whereby with careful use of low specificity, a custom "btn" class can be further customized just by adding TW classes (ie. not css specificity issues).
My only gripe with this is that you should then use a clearly defined and separate naming convention for custom classes, for example SuitCSS is good:
Not
btn btn-large rounded-full
But
du-Btn du-Btn—-primary rounded-full
ie.
PascalCase component names,
optional prefix (eg. du for daisy ui, because other apps also have their prefix see eg. Twitch and Algolia css)
Bem conventions like double dash for modifier as opposed to a descendant
So yeah I would like to be able at a glance to know where a class is from. "btn" is not from tailwind, but where is it from? What if my app uses multiple components, from third party etc? It’s not clear.
Other than that This is better than Bootstrap approach even with custom classes, because you take care of css specificity problem (assuming you can add a tw class anywhere and override the builtin custom classes)...
this is the middle way that nobody uses for whatever reason, the one that makes sense, but requires a good basic understanding of css specificity as well as setup stringent css linter
Also using a convention would let you use a good linter on the custom selectors
I've never used Tailwind, but am familiar with Bootstrap. When looking at the examples, the ones on the right looked pretty much exactly like Bootstrap and I didn't understand what was interesting or novel about it.
Is the code on the left (with lots of classes) actually what tailwind is like to use in practice?
> Is the code on the left (with lots of classes) actually what tailwind is like to use in practice?
As a fan of tailwind, I can say that I initially thought this was dumb and it would be hard to read through a huge number of classes applied to each HTML element. Later, I found that for many of my reusable components, I could combine classes into a single class. As an example, my stylesheet may look like this:
After working with Tailwind for a period of time I came to the exact same conclusion. You can achieve all of this in a better way using CSS variables. You can transform this:
Adjust variable names to taste. No build step, no extra tooling, just as readable in my opinion. On top of that, using CSS variables means that those values can be changed at runtime. You basically get user-driven theming for free.
I'm building an app like this right now and it's been lovely.
I'm on mobile so forgive me for not giving more extensive code examples. In my case, I'm building my app with React, TypeScript, and react-jss. I've got an enum which stores my common media queries and I just use it in the style declaration.
button: {
[MediaQueries.Medium]: ...
}
I can't use CSS variables for that but I personally don't think it's useful to let the user redefine those queries anyway
It's a straitjacket to reduce inconsistency across different sections of a large app/family of apps - and which help a bit with finding common styles for refactoring.
It's not so much about what you do as a single designer on the initial design, more about what a team of designers do when adding new apos/modules to an existing product.
In theory you could use bootstrap and a theme - but your fellow team members will get lost, re-invent some styles etc.
I'm inclined to solve this problem with discipline and corporal punishment - but I'm afraid the tailwind-people are on to something.
Basically the cascading part of css does not work well for applications / a suite of applications - it works better for actual hypertext documents (like sgml might) - where you can make a layout that works, while the browser handles the user experience (UX). When layout/design becomes "just" part of how an app looks, but the important is how it beheaves (including things like hover, expanding menus etc) - bare CSS doesn't work as well. Not technically, but from a perspective of an evolving code base.
I am so glad that I took the time to get fast with CSS. I can build unique UIs in real time, and with Svelte Components, everything is automatically scoped to the component. I would waste so much time and gave a lot of analysis paralysis if I had to choose from all these cool looking libraries and frameworks, learn their api’s, and then learn how to override them more and more over time.
That page is extremely slow without hardware acceleration.
It (hw-accel) was off for me because I updated some things without restarting Chromium, but I dunno. It doesn't "spark joy" with me.
I am seeing that also. Continuously used ~50% of my 2015 Macbook Pro's discrete GPU and caused the system fans to kick off, just looking at the components on the landing page.
My goodness Bootstrap, how far ahead of your time you were. To this day we copy you, god bless you m’lord.
Nope, I reject this. We should be so much farther ahead than this. It’s the garbage fullstack developers that need this crap to make a good ui. They don’t belong on the frontend, and I’m pretty tired of it.
Our UI/UX will get shittier and shittier if we coddle this group.
DaisyUI is a great starting point but it is missing a lot to make it functional and then you end up recreating the wheel.
I agree with some comments that it is lacking that wow factor that TailwindUI has.
I'm working on https://versoly.com/ which is a Tailwind Website builder and have ran into a bunch of issues with Tailwind when it comes to building static sites.
I love that Bootstrap offer "btn btn-primary" and it makes it very easy to keep a consistent site.
For Tailwind to take off it needs
- A list of components (maybe 20 ish, buttons, tabs, navbars being the main ones)
- JS for components
- Container system (I have built one that works similar to Bootstrap and makes it much easier to create responsive layouts quickly)
Once those core parts have been built I believe developers will create more advanced libraries such as lightboxes etc which will save even more time.
But I talk with a lot of full stack and backend developers who still use Bootstrap. They even own TailwindUI and other templates but stick to Bootstrap.
That to me means there is a big issue with Tailwind and the developer experience.
Once solved Tailwind will grow even faster and help more developers/companies.
I believe in semantic class-names, I know one can transform tailwind into cleaner markup but it seems to introduce more work than just building from scratch
That page broke tabbing through interactive elements by using nested focussable elements like this:
<div tabindex="0"><input ...></div>
Because of that, it is sometimes necessary to tab twice to focus the next element. Not sure whether that is a problem of DaisyUI in general or just their website. But it is definitely annoying.
Great! Over the past 6 months or so I've noticed a trend which I like: people are less obsessed with all the modern react-angular-vue-js-everything-html-css-bad notion and a lot of people are starting to admit that this whole sack of gibberish is unmanagable and unmaintainable(the web got it's own version of segfaults where something crashes and no one has even the slightest idea why) and we are coming full circle back to the late 2000's internet. Which to my mind was the golden age of the internet: you could slap a vga cable onto a potato and it had the computational power to display any page, whereas in recent years a single page eating up 200+ mb of your memory and increasing the cpu usage by 15-20% was a completely normal phenomenon. Oh and let's not forget "ew jquery, that's 200kb, that's horrible" all while bundle.min.js is a 15mb freak. Good job, personally I had completely lost hope, now I am starting to have some.
I am not sure this is production-ready. I had a look over some components and the UI/UX is poor in general (bad alignment, padding, bad accessibility, no proper focus traps, no keyboard support, etc.). Maybe some of those are lacking because it is a CSS-only implementation? But you still can't use them as it is without proper accessibility support.
I am more impressed by the landing page than the actual components. Is anyone aware of a good component library for landing/marketing pages for Tailwind?
There are toolkits like https://frontendor.com but they all follow the 5-10 year old "theme" of insanely packed content you had seen on SaaS pages some years ago. Together with many photographs or flat humans... I can't find anything with "new" approach which uses more padding, much more detail to typography, bigger fonts etc. shown very good on the https://tailwindcss.com landing page. Or any hint where all the new startups get their designers for these new fresh layouts?
I must be getting old because I literally don't get front end devs these days...
The landing page is like a few divs with some position centres. What would you even use a "component library" for in this case? The only thing on the entire page with any complexity whatsoever are the component demos (which are obviously part of this DaisyUI thing itself) and the code blocks/syntax highlighting, which I'm sure there's a billion libraries for already.
I'm really struggling to come up with any sort of other dependency that would help me build that page any faster than just opening the text editor and shitting out some HTML and CSS.
Do people just spend so much time working with Bootstrap and whatever other cruft that they just never bother to learn the basics?
At this level of simplicity and for churning out marketing pages where you don't care about maintainability, you're probably better off looking for a WYSIWYG editor rather than a library.
Interesting side effects of css utility frameworks: I was trying to scrape a website that uses tailwind this week and it’s really difficult, as nothing had a unique class name.
It is also an effect of various css-in-js shit, you can't know what the element does if it doesn't have a tooltip. Because now the class name is gibberish.
That's not very nice, maintainability suffers in the same way. You can obfuscate your classes later on.
But alas, the battle for semantic css has already been lost and the community keep going in the opposite way (first bootstrap, which was halfway through, now tailwind which is basically inline styles with variables).
I tried using Tailwind, but I just couldn’t get into it. It’s like having to learn CSS all over again because the classnames do not map 1-1 with their respective properties, and autocomplete is lacking.
Conversely, Chakra UI Box, which does more or less the same thing is super easy to get into.
This looks nice, but I kind of feel like we’ve come full circle two full times to get to this point.
Using DaisyUI for three projects currently and LOVE the hell out of it. Don't get me wrong I love some TailwindUI as well, but the simplicity of Daisy is fantastic. Winning combination for us: DaisyUI + TWCSS + AlpineJS + Go Fiber server & templates.
DaisyUI is beautifully written. This can be the kit with a boatload of work done for you. Think like Bootstrap but better with Tailwind. You can use this to teach how to write well thought-out CSS codes, separation, and extensibility.
TailwindUI is more like Bourbon[1] (was my go-to Sass tool) but on the structural interfaces done for you. I'm standardizing out Web, WebApps, and marketing materials to start with TailwindUI. Someone with good chop of CSS/Tailwind won't likely need to use TailwinUI but it can be a fast tool for teams. It is highly extensible but also has the double-edge sword criteria that a rookie can just keep copy-pasting, repeating codes and still work (not a good thing).
Will we use DaisyUI for the team? Unlikely!
Will I use it for some quick but still larger project, marketing page? I might very likely.
Real nice, pity the "see component" popup that appears when clicking on anyhomepage component prevents from checking it out and there is no way to hide said popup
Real nice, looks professional and casual - well done!
Oh I pray that I remember this website next time I'm looking for an HTML/css template. Great job, this UI looks so polished and is as modern as it gets.
Recently bought Tailwind UI. Haven't really used it much except for a concept UI, and didn't work completely out of the box (you kind of have to know something about Tailwind the open source project first).
Aside from that, it looks like a really convenient way to put together a web UI when you don't really want to focus on the UI part of your app too much.
Not too expensive either, I think it was $175 or so.
So much love for tailwind, I love it. Honestly though I haven't use any other component than Material-UI for the past couple of years. I was thinking to convince my previous company to buy tailwind-ui just for the sake of curiosity :p but then I know I won't use it much. So not sure..
In the end the point of all of us using tailwind is because its not "opinionated" like bootstrap right?
(NOTE: I did not WickedBlocks/WickedTemplates -- it's the awesome work of the folks over at WickedTemplates https://wickedtemplates.com, which they shared on HN I believe a while back)
I'm actually working on a little side project right now where I turn wickedblocks into a set of usable native web components (as in drop an <import> tag and the component on your page and you're off to the races), because I think that's a much more composable way to use these snippets copy & pasting HTML, looks like Daisy needs to be next.
[EDIT] A bit annoying to others probably to drop a lede and I have no idea when I'll get done and publish it with the blog post so if someone just wants to see the code:
If anyone wants to contribute a snazzy icon I'd love to take it! There's no landing page to showcase it yet but there's files like lg-left-header/index.html[0] which showcase usage and the intended simplicity.
Obviously if you're trying to get started, use the blocks as they're presented and the awesome work done by WickedTemplates (they've also got some ready-to-go straight out of the box templates and other stuff for you to use on their main site!), but if you're interested in lit[1]-powered drop-in components, follow that space.
[EDIT2] - For those taking a look at the code, note that there are like... 4 variants of the left-header component. Half of the time spent getting this out (it's all simple in theory -- just copy + paste and swap out static text for variables) was figuring out which parts to unify and which parts to keep separate for easy drop-in use. There's not much there yet, but it's more a matter of me finding time to sit down and make these decisions for every kind of component on the wickedblocks page.
There are some concerns like i18n that I've punted on by just making sure that all static text were component inputs, but ideally integration with browser-supported i18n[2] is the proper way to do things in a minimal but standards compliant way.
[EDIT3] - Added note to make it clear I didn't create WickedBlocks/WickedTemplates
You could say it's a component library like Bootstrap but it's customizable in core because it's based on Tailwind CSS. For example if you want to customize a Bootstrap button, you need to write additional CSS files. With daisyUI you can simply add a class name.
For those wishing to learn the intricacies and beauty of Tailwind, this is a good source. Well written code but might lack the finesse of design. Then use TailwindUI[1] as a kit for your design/frontend team.
This library highlights the biggest issue of tailwind for me.
> Clean HTML
The rest of your code will still use bunch of shitty tailwind shortcuts that are really chaotic the moment you build something more than a simplest component.
I mentioned it in another comment, but I felt the same way until I figured out there is a solution. Here is an example of a simple CSS file with a reusable button class:
I can now just give all of my reusable buttons the ".button" class instead of the giant string above. I can even add more styles or overwrite existing styles to give it a different look such as:
So I don't understand. People are complaining about bootstrap for defaults. Then daisyui has great defaults, and the same class names. I see no reason to customize daisy.
I wish the author would also put up a purchase page on https://themeforest.net/ . I dont mind optionally paying for it - especially a nicely packaged starter for nextjs, etc
But I actually think I will use this. A big problem with CSS is that you end up making overrides no matter how composable you make the classes. And some simple things (e.g. responsiveness) are unintuitive and / or annoying to do in CSS. Hence Tailwind's "CSS-in-HTML" mini classes. But that doesn't fill the core purpose of CSS, bigger general-purpose classes to avoid repetition. Combine the two (general classes + mini classes for slight case-by-case fixes) and you get the best CSS experience I've seen so far (at least I think, I haven't tried it yet).