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.
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?
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!.
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)
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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:
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.
> 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
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.
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?