Show HN: Flowbite – Tailwind CSS Components Library | Hacker News Reader

Show HN: Flowbite – Tailwind CSS Components Library

flowbite.com

From a design perspective this looks really good, I like the components, the typography, the generated pages from Figma etc. Also the documentation seems to be clean and user-friendly. It's way better than most of the docs.

From the development perspective and from other comments that are here, and also from many articles like: https://dev.to/jaredcwhite/why-tailwind-isn-t-for-me-5c90 or https://dev.to/neophen/tailwind-is-bad-because-i-don-t-like-... or https://betterprogramming.pub/tailwind-css-is-probably-overh... you can see that there are still a lot of people who hate the way Tailwind work with classes. But in the same time you can see that they have a steady grow month over month since April 2019: https://www.similarweb.com/website/tailwindcss.com/ that means some people love the way Tailwind is working with utility classes.

So I think this is a really good extension that can speed up the development process of people who like Tailwind. For those who don't like Tailwind, there are many other alternatives. There is no such thing that can fit for everybody.

Some questions 1. What did you use to create the docs? 2. What are your next steps with this project?

Thanks for the feedback!

1. We used HUGO as a static site generator and Webpack to put things together using markdown files. (it's open-source: https://github.com/themesberg/flowbite including the HUGO source files)

2. We're now working on the application UI code (pro version) but we will also add new components and external styled plugins (datepicker, charts) to the open-source library.

We have a roadmap on the landing page: https://flowbite.com/#roadmap

Are the blue bullet points and the balck ones TODOs?

Yes, you are correct.

TailwindCSS is the biggest jump in productivity for me in years.

I think where it shine most is when you are making your own UI and need to deploy different components/customizations, ie: If you are doing a single page site is not that obvious "why is like this?", but generating UIs on the fly for a admin backend and suddenly THIS IS THE WAY!.

TailwindCSS is like static types for UI. Note:

    <button class="button"> == fn sum(a,b)

    <button class="font-bold block px-4 py-2 m-1 rounded shadow outline-none text-center bg-primary-700 text-white"> == fn sum(a:U16,b:i32):Result<i64, Error>

The "verbosed" nature of both cause some hate, but you will appreciate it the more big/complex the project is.

What you get with tailwind is exact understand of each component and how it will look based on their "types"/classes.

What you get with others like bootstrap is too abstract/implicit looks that you can't figure at a glance. So, tailwinCSS like static typed programming is optimized for "a glance"/local understanding.

What is also very counterintuitive is that my tailwind pages are LESS heavy than boostrap! (true for html and CSS)

I'm excited to see Tailwind and the "Atomic CSS" style gaining popularity. It's one of those things that looks repulsive and backwards at first, but works so well in real-world projects.

I got interested in atomic CSS a few years ago and used it on numerous projects for over a year. In the end I actually found the real world application of it a step backwards. What you gain in getting up and running quickly you loose in maintainability in my experience.

We keep all of our components in template files so it's quite easy to maintain for us. If we need to change all of the buttons across the app, we just update the Button component.

I also was using component tempalte files although the issue was apparent when returning to any component with any degree of complexity. Regular CSS class names tend to give you a bit of an insight into the role of each div whereas atomic css requires you to parse each line to understand it's role which gets a bit tiring after a while. I tried extracting the strings of atomic class names to variables as a sort of hybrid approach but in the end it felt more or less like emulating 'normal' CSS. I'm sure different projects would fair better though with an atomic approach though.

IMO you can and should still add useful class/id names to explain what your elements are doing. Those just won't have any styling associated with them.

What stops me from switching to Tailwind away from Vuetify is the lack of a well rounded library of components. TailwindUI and now Flowbite get us part way there, but it’s still jarringly sparse compared to dropping in a very customizable v-btn or v-alert, not to mention the crazy robust v-data-table.

When I use stuff like Bulma or Bootstrap instead of Vuetify I feel like I’m doing 10x the amount of work for 0x more customization or optimization.

Is there a case to be made for a Tailwind component library for my use-case?

I hope this comment comes across as constructive and not an attempt to argue about licensing, but I find it really confusing to understand what on this website is under what license/what I can do with it.

Under components are some great looking components with copy-pasteable code. Can I just copy-paste that into a website? If I do then do I need to copy in an MIT license attribution too into that source code where I use it? If I can copy-paste from there without issue then what would I be paying for if I purchased "Tailwind CSS code"? Is it like Tailwind UI where these components are available for free but paying unlocks loads more?

The components are open source and you can use them any way you see fit under the MIT license terms.

The pro version includes fully coded pages and layouts (ie. dashboard layout, landing pages, e-commerce pages) that can accelerate your development even more. We also work based on a Figma file that is based exclusively on the default Tailwind utility classes and you can get that too in the pro version (although there is also a free one posted on the Figma community with the base components).

I think we should create a page comparing licenses and making it clearer.

Do the pro version allow re-use in templates?

Please read the full licensing terms for the pro version here: https://flowbite.com/license.

It was a very simple question, should I ask a lawyer too?

Update: I read it and it's unclear, so that's a no then.

You pretty much copy pasted the Tailwind UI license word for word and replaced a few Tailwind UI-specific words with yours.

Components => download files

Tailwind UI components => FlowBite elements

Tailwind Labs Inc. => Crafty Dwarf LLC

Tailwind UI License: https://tailwindui.com/license

Flowbite License: https://flowbite.com/license/

Awesome, thanks for clarifying that!

At a glance, this looks somewhat better, especially with customization/tokenization, than Tailwind's own TailwindUI.

For those worried about the classes upon classes in the HTML, I find it OK. OK, for hacking up marketing, landing, and websites. There are two ways of using a utility framework such as TailwindCSS.

1. Every module is HTML-designed and is seen from a designer's eye; know what they should look like. We see this in TailwindUI and here too with Flowbite.

2. Use Tailwind as a utility class and create CSS classes looking at the overall design and standardizing components.

Point No. 1 is more straightforward than 2 in the short term, but Point No. 2 would be the ideal approach and more easily maintainable.

Here are few examples from our website that uses Tailwind. Please be lenient; it is not a public consumable template/markup.

The general UI is driven by design token at the Tailwind configuration level -- https://github.com/valinorearth/valinor.earth/blob/master/ta...

Color Scheme follow a similar pattern https://github.com/valinorearth/valinor.earth/blob/master/ta...

Then, we write CSS but using Tailwind as a utility - https://github.com/valinorearth/valinor.earth/tree/master/sr...

For instance, for a button, instead of apply everything in each and every `<button>`, we create a `.button` class and create the button component of our choice https://github.com/valinorearth/valinor.earth/blob/master/sr...

I hope this is useful to few who wants to use Tailwind in either of the two ways.

Question: are there any mature CSS component frameworks out there aside from Bootstrap and Bulma? And why aren't there more?

Not sure how mature, but here it is: https://niui.dev

There are lots, it's just that many mostly advertise themselves as component libraries for particular frameworks. Oftentimes you'll find that the common core is just plain ol' CSS with a little bit of JS in the background.

It would be great if some front-end developer can chime in to tell us which frameworks are worth trying besides Bootstrap (Tailwind?), or it is all yak shaving. Currently I only reach to another framework if:

- I want something lightweight and not bother to deal with compiling/preprocessing (like Milligram).

- I want a MVP without classes (like Picnic.css)

Otherwise I pay a premium theme or create one myself.

Not sure if it matches your criteria of a mature component framework, but there's Foundation and UIkit. I've used both but all of my new projects use Tailwind. It matches my needs better because I use minimal JavaScript. It also doesn't get in my way and the documentation is refreshingly clear.

https://get.foundation/

https://getuikit.com/

> And why aren't there more?

It seems to me these tightly coupled CSS + JS component frameworks are in an awkward position these days. React/Vue allows you more flexibility. If a project is really simple you can use vanilla JavaScript or something like Alpine.js.

Perhaps the demand isn't there anymore.

There's Microsoft's Fluent UI: https://github.com/microsoft/fluentui

Not a framework, but a web component library I maintain: https://shoelace.style

Looks great. One comment re. the docs, as a paid user of Tailwind UI, I really like the way they lay out their components on their docs site. The markup is hidden by default, with buttons to click to grab the source code.

And this makes sense because I'm not browsing the docs looking for markup that I like. I'm looking for a suitable UI component and only once I've picked something am I interested in the specific markup for that one chosen component.

Your docs at the moment have the effect of emphasising the markup more than anything else on the page (due to the dark-themed code snippets, which normally I like!) and when I'm in UI design mode, I'm thinking very visually and really only want to see a clean page listing the various components available.

Other than that, the docs are great so this is only a possible optimisation rather than a major big deal!

I might be naïve and new in UI side of things. What is the big difference between bootstrap, foundation and tailwind? Also, what I saw people end up customizing the components anyways, at what point do you use a UI Component library and what situations you do not.

On bootstrap, Foundation, semantic UI you have all of the CSS code included, on tailwind and windicss you only include what's actually on the page by compiling it.

Not an expert here, but cannot you tree shake Bootstrap too?

https://medium.com/@jacobp100/tree-shaking-bootstrap-95d6301...

To a certain degree and also on semantic, but it always have a core CSS which is largish, windi and tailwind is on a granular/utility basis. So it's often something like 8kb for a page with tailwind/windi but +100kb for semantic.

Guys, do you realize there are 12 classes to define 1 frickin default button? When all you need is btn btn-primary this tailwind CSS thing seems like a bunch of nonsense to me. Sure it's great to see a lot of ready made html components and it's tempting to just grab one and get a head start - and it might just work well for a landing page (I've used tailwind exactly for this) but for full blown applications? Using these components is just madness.

You actually spent $3,500 to buy this domain name? Business must be good.

I've been using DaisyUI which seems similar to this.

I'd love to hear people's thoughts on Flowbite vs DaisyUI. Is it worth the switch?

First of all Flowbite is based on and also includes a Figma design file and it is also different in terms of styling.

We chose a cleaner and more enterprise design to target high-end developers and companies.

I suppose that the differences and whether one or the other is better depends on your project and what you want.

Got it.

So DaisyUI is more for weekend projects where devs themselves own the design.

Whereas Flowbite is meant more for working with a real designer and easily translate the professional design into tailwind-based code.

Cool. Thanks!

I see you have a paid version? I'm curious if you're making any revenue with this already?

Yes, we're making enough to that we can continue developing the project.

> Get started with an open-source set of UI components and elements built with Tailwind CSS

Doesn't it kind of defeat the purpose of Tailwind?

I don't think so. I mean, this is not hiding tailwind behind custom classes or React components or anything, these are literally examples of tailwind usage using tailwind features. So, less of a component library and more of a nice collection of tailwind examples. I think it's a nice way of build the basic structure of your site and then you can change whatever you need.

Tailwind is just a method in which to style components on a page. Replace "Tailwind CSS" with "StyledComponents" or "SASS" or "BEM".

Last thing I would do is to put Tailwind next to BEM. They're not equivalent in any capacity.

Actually Tailwind is the antithesis to BEM, so it's funny how you wouldn't compare them.

The BEM philosophy is to capture individual pieces of your UI as unique CSS classes (.Button, .Button-icon, Button-text). The "utility first" approach removes that abstraction entirely.

I didn't say I wouldn't compare them - I said I would put one next to the other, by which I meant Tailwind that is generally a bad idea.

Interesting, I'd ask you why.

Anecdotally I've built hundreds of websites, and worked on many product teams building web applications all with varying team/product sizes and in my experience BEM scales very poorly. I have never worked on a BEM codebase without a shocking level amount of tech debt. Adding new UI requires creating new CSS files, refactoring existing UI requires also refactoring the separate CSS files, removing UI is the same thing. Due to this disconnect, old code tends to stick around.

One of my product teams moved from BEM to Tailwind and productivity/maintainability improved tremendously.

Adding new UI requires creating new CSS files, refactoring existing UI requires also refactoring the separate CSS files, removing UI is the same thing. Due to this disconnect, old code tends to stick around.

To me this says more about the development practices of that team than about BEM. Chiefly you should be able to automatically determine if a given block, element or modifier is still used/needed. How did they wind up in such a situation?

Meanwhile Tailwind is functionally equivalent to this:

https://twitter.com/samthor/status/1402825668061130755

I would say that this is nice for prototypes, but given how it disincentivises reuse, refactors take an amount of time proportional to the number of instances - that's really bad.

Also since there's no composition, just by looking at the codebase it's not clear if a change is something that should propagate to other, similar instances or land only there.

I'm not sure what gives you the impression that there is "no composition". It's been common practice on many large scale Tailwind builds that I've been a part of to use the @apply directive[0] to create reusable components when appropriate.

[0] https://tailwindcss.com/docs/functions-and-directives#apply

> To me this says more about the development practices of that team than about BEM

Well you could say that BEM requires strict development practices to work well. This is could be a downside for many teams, seeing as this comes at a cost which grows as your team/product do. Organizational overhead is a significant factor when considering a technical solution.

> Meanwhile Tailwind is functionally equivalent to this:

It's a funny platitude, similar to the argument that "Tailwind is just like inlining CSS" but it's of course overly simplified. Variable support, hover/active/other states, and of course breakpoint-specific variants for all of the classes making responsive styles possible.

> Also since there's no composition, just by looking at the codebase it's not clear if a change is something that should propagate to other, similar instances or land only there.

Even with BEM, you usually store components in partials/templates to keep everything contained and to reduce duplication. So in this regard the composition is the same. You import a button in your code, you aren't writing out this every time:

The composition happens within the templates themselves.

EDIT: I'll follow up and say that the "composition" for Tailwind components works very similar to CSS Modules (CSS is scoped to a component, and delivered with the component itself), or StyledComponents (similar to CSS Modules, but built into the React component itself). But with a few more benefits:

  1. Does not rely on a build system to bundle/deliver styles
  2. Less abstraction; no need to create scoped classes even (in the case of CSS Modules)
  3. Works outside of the JS/React ecosystem

Anyone who is still comparing Tailwind to inline styles in 2021 is probably not as experienced as they think they are.

Tailwind is written in SASS and is not like SASS. I would equate Tailwind to an earlier utility framework like Bourbone[1].

Tailwind can be used to build/write "StyledComponents". And one can write in the style/methodology/philosophy of BEM.

All the the above terms are all of different categories.

1. https://www.bourbon.io

The bottom line is Tailwind is not a component library so this doesn't defeat the purpose of Tailwind any more than it would defeat the purpose of StyledComponents.

Tailwind is not, in fact, written in SASS (also, for what it's worth it's Sass - not SASS) - it's a PostCSS plugin. Additionally, the primary use case of Bourbon was to create composable mixins - not to expose utility classes. It would only be comparable to Tailwind if you were using Tailwind's @apply rules and not composing with the utility classes directly in the DOM.

Not really, in my opinion. I was happily surprised to see that this "component library" doesn't actually offer anything to download; it's not a library you can `npm i` to your website. It is basically a set of examples for how to recreate different design elements using Tailwind. It leaves it to you to decide what parts to use and what part to change or remove. Pretty neat.

https://pbs.twimg.com/media/EjE1-LFXcAA-PPp?format=jpg&name=...

Doesn't look all that different from your own site: https://i.ibb.co/VWxZdhr/rado-bg.png

Actually, this here is semantic HTML. The previous example is not.

In which contexts would it matter whether one used article instead of div?

If you're on a screen, it makes no difference.

If you use a screen reader/braille display, you will only be informed about a small subset of "semantic" html elements, such as headings, lists, links, and tables.

If you think it matters for "XML" reasons, well, it's not 2006 anymore.

This looks like to be generated mostly by a CRM. This makes lot of sense.

The former isn't from a CMS.

Reply on news.ycombinator.com