Tailwindo: Convert Your Bootstrap CSS to Tailwind CSS(awssat.com)
awssat.com
Tailwindo: Convert Your Bootstrap CSS to Tailwind CSS
https://awssat.com/opensource/tailwindo/1_introduction.html
40 comments
Memory impact, no. Atomic stylesheets are generally fractions of the size of a traditional monolithic CSS file. I've loaded up a 6MB CSS file for development locally and it's instant.
Performance is more complicated, but generally it's never an issue. We've had huge webpages forever, often with many different CSS files and HTML included from all across an application and organization. When the browser has all of the CSS files finally loaded into memory, it's FAST.
Here's an old article[0] that looked into some performance metrics. 7000 DOM nodes per page, with crazy nested selectors. The delta between the different tests was around 10% (10-100ms depending on the browser) from the simplest to most complicated, but the absolute rendering time has was still under 200ms for all browsers. Important to note that this test was also conducted when IE9 was still relevant. Computers, and even low end devices, are much faster than what was available in that era.
I reran the tests from the article in Chrome just now, and the insanity selector test ran consistently in under 100ms on a 2020 quad core MacBook Pro. Chrome's performance benchmarking tools confirmed that number as well as the simple benchmark included in the test source.
We also have to take into account that the types of classes included with atomic CSS frameworks are extremely simple for browsers to parse and apply. Because they aren't deeply nested spaghetti, the browser can more quickly index them for use later in the rendering lifecycle.
I would be interested to see what the effects are of atomic CSS on performance using our modern browser environments, but I would guess it's negligible and not relevant compared to any other part of the page rendering and refresh lifecycle.
0: https://benfrain.com/css-performance-revisited-selectors-blo...
Performance is more complicated, but generally it's never an issue. We've had huge webpages forever, often with many different CSS files and HTML included from all across an application and organization. When the browser has all of the CSS files finally loaded into memory, it's FAST.
Here's an old article[0] that looked into some performance metrics. 7000 DOM nodes per page, with crazy nested selectors. The delta between the different tests was around 10% (10-100ms depending on the browser) from the simplest to most complicated, but the absolute rendering time has was still under 200ms for all browsers. Important to note that this test was also conducted when IE9 was still relevant. Computers, and even low end devices, are much faster than what was available in that era.
I reran the tests from the article in Chrome just now, and the insanity selector test ran consistently in under 100ms on a 2020 quad core MacBook Pro. Chrome's performance benchmarking tools confirmed that number as well as the simple benchmark included in the test source.
We also have to take into account that the types of classes included with atomic CSS frameworks are extremely simple for browsers to parse and apply. Because they aren't deeply nested spaghetti, the browser can more quickly index them for use later in the rendering lifecycle.
I would be interested to see what the effects are of atomic CSS on performance using our modern browser environments, but I would guess it's negligible and not relevant compared to any other part of the page rendering and refresh lifecycle.
0: https://benfrain.com/css-performance-revisited-selectors-blo...
I've been using Tailwind for the past year and enjoy the workflow when used with front-end component frameworks (e.g. React, Vue, Alpine) and back-end template engine using partials or components. Using components keeps most of your Tailwind classes centralized and easy to update -- it's great to be able to just open a component and tweak some classes to change the UI. Use props to conditionally change the Tailwind classes in your components. Previously, searching through CSS/SCSS took a bit more reasoning and I found myself creating redundant classes over time to handle edge cases.
You can group Tailwind classes into parent classes using @apply and everything works as you'd expect
Sure you can do tricks like this, but at a certain point it just wraps back around and suddenly you find yourself just doing regular CSS anyways.
Not really, because I only really use @apply for conditional classes and Tailwinds still provides you with a standardization for your CSS code that you don't have otherwise.
Adam Wathan even says this is a code smell, and is just for the myriad of corner cases.
If all your classes are in an apply, why not just use the CSS? most of the utility classes are one line classes
If all your classes are in an apply, why not just use the CSS? most of the utility classes are one line classes
I feel like one of the best benefits of Tailwind is often overlooked. It's essentially a design system in a box. A simple and general one (which makes sense), but a system none the less. All of the classes being related to each other, ie in `p-1` and `m-1`, the 1 means the same value (0.25 rem). But also the fact that the sizing system exists and is pragmatic is very useful. Tailwind sites often feel more consistent and they just "feel" better because Adam and his team took the time to design a well considered sizing system. The same holds true of colors, shadows, font size, etc.
And even better, if you work at a place where a custom design system is needed, Tailwind has pretty much everything you need to customize your own but still give the same Tailwind productivity to developers.
And even better, if you work at a place where a custom design system is needed, Tailwind has pretty much everything you need to customize your own but still give the same Tailwind productivity to developers.
Yes. I use tailwind because it's the easiest way to get something responsive working very quickly. I'm not a designer but stuff made with tailwind always looks presentable and clean. With vanilla CSS I'm constantly forgetting media queries and fail to have consistent margins and padding. Tailwind is great!
This is the same as most CSS-in-JS solutions though isn't it?You have a theme.js (that comes with a default) that confirms to the theme UI standard that is pretty much what your tailwind.config.js is. Then you can save variants (similar to @apply in Tailwind).
I've only used styled-components to any extent for css-in-js, I don't remember it having anything to do with a design system? Can you name some examples, you got me curious.
Do these theme.js files have full sizings, spacings, etc defined?
Do these theme.js files have full sizings, spacings, etc defined?
Because the code can get hard to parse, especially if you are using conditional classes based on state or other values.
I’ve wondered the same but haven’t done any digging into it yet. We’re in the middle on migrating a lot of code over and I plan to test the impact.
It’s all going to depend on what sort of optimisations are done by the browser. They could very well cache style rules by class combination hashes. (They probably don’t, but it’s possible).
Whatever happens, in my case it’s going to be better than the laggy material ui and css-in-is tooling we were using before.
It’s all going to depend on what sort of optimisations are done by the browser. They could very well cache style rules by class combination hashes. (They probably don’t, but it’s possible).
Whatever happens, in my case it’s going to be better than the laggy material ui and css-in-is tooling we were using before.
Might as well migrate to universal.css[0] while you're at it
[0] https://github.com/marmelab/universal.css
[0] https://github.com/marmelab/universal.css
This is a joke.
Is tailwind the new de-facto standard what bootstrap was three or four years ago ?
I've learned that Tailwind is not really a framework so much as it is a philosophy. Most Tailwind classes are just single property wrappers. For example, "flex" is just "display: flex", "bg-dark-400" is just "background: $bg-dark-400", "text-white" is just "color: white"...that sort of thing. It is more of a rebuke of the CSS concept as a whole, as CSS is geared towards large but few classes, and Tailwind is smaller but many classes.
You can use Tailwind to build Bootstrap, like the OP link shows, but you can't do the opposite. I was surprised when browsing the Tailwind docs that they didn't have prebuilt navbar, form, or input classes, but now I realize that's actually the point. You have to build all of those yourself to fit the needs of your project. That's not to say that prebuilt components don't exist at all, just that they're not part of the Tailwind framework project - they exist under Tailwind UI, the commercial offshoot of Tailwind. It's pretty expensive as an indie developer, but I don't mind having to build my own components so it still works out for me.
[1] https://tailwindui.com/
You can use Tailwind to build Bootstrap, like the OP link shows, but you can't do the opposite. I was surprised when browsing the Tailwind docs that they didn't have prebuilt navbar, form, or input classes, but now I realize that's actually the point. You have to build all of those yourself to fit the needs of your project. That's not to say that prebuilt components don't exist at all, just that they're not part of the Tailwind framework project - they exist under Tailwind UI, the commercial offshoot of Tailwind. It's pretty expensive as an indie developer, but I don't mind having to build my own components so it still works out for me.
[1] https://tailwindui.com/
If we're being a little reductive, it's an optimized way to do inline styles for component based architectures, because it turns out inline-styles are actually a pretty good way to style re-usable components. I think that's the major practical difference that might prompt such a philosophy change.
In the more traditional method, you would style a <button> element in a CSS file and never think about it again, while it inevitably becomes part of the CSS nest. If you wanted to use tailwind for a normal non-component based site you'd have to individually style every single button again and again, as there's no cascading and no globally applied styles. I wouldn't use tailwind in that cirucmstance.
But because it's more likely you're using vue/react and your buttons are actually defined as a <Button> component that you re-use, you can write the styles directly on the component where it's used, co-locating the code and making maintenance a bit easier in the process.
In the more traditional method, you would style a <button> element in a CSS file and never think about it again, while it inevitably becomes part of the CSS nest. If you wanted to use tailwind for a normal non-component based site you'd have to individually style every single button again and again, as there's no cascading and no globally applied styles. I wouldn't use tailwind in that cirucmstance.
But because it's more likely you're using vue/react and your buttons are actually defined as a <Button> component that you re-use, you can write the styles directly on the component where it's used, co-locating the code and making maintenance a bit easier in the process.
> it's an optimized way to do inline styles for component based architectures, because it turns out inline-styles are actually a pretty good way to style re-usable components
Yeah, I also understand Tailwind as inline-styles without it's problems:
* it provides less choices (instead of 256*3 colors you have limited choices)
* classes are (a lot) faster than inline styles in most browsers
* has access to features that inline styles can't (e.g. media queries)
Yeah, I also understand Tailwind as inline-styles without it's problems:
* it provides less choices (instead of 256*3 colors you have limited choices)
* classes are (a lot) faster than inline styles in most browsers
* has access to features that inline styles can't (e.g. media queries)
I bought Tailwind UI has a mostly backend developer and I couldn't be more happier with it so far. It really saved a lot of my time in building my MVP, well worth the cost.
Although, I guess I don't know for sure until I start to test the product. But the development at least has been a blast.
Although, I guess I don't know for sure until I start to test the product. But the development at least has been a blast.
I'd be willing to pay, but it's not clear what is included. For an initial look before paying, I downloaded a pirated copy. It only contains the components' html (and alpine, react, vue) snippets, with no extra documentation. If I were to pay for a license, would I get access to log into an account that has a full component browser with examples and extended documentation? If so, can all of that be downloaded as an offline copy, so that it will still be available to me if/when the Tailwind UI product/site is discontinued? Losing access to that important piece of the product would be unacceptable; I suppose I could curl a mirror of the authenticated portal if necessary.
The "simplest" button apparently contains the following ridiculous number of css classes, which is not the kind of css composition I'm a fan of. It may be the most flexible in terms of customization, but it's a nightmare to mentally parse and maintain. I would not want to manage a code base where nearly every html tag looks like this. :/
<button type="button" class="inline-flex items-center px-2.5 py-1.5 border border-transparent text-xs font-medium rounded shadow-sm text-white bg-indigo-600 hover:bg-indigo-700 focus:outline-none focus:ring-2 focus:ring-offset-2 focus:ring-indigo-500"> Button text </button>
The "simplest" button apparently contains the following ridiculous number of css classes, which is not the kind of css composition I'm a fan of. It may be the most flexible in terms of customization, but it's a nightmare to mentally parse and maintain. I would not want to manage a code base where nearly every html tag looks like this. :/
<button type="button" class="inline-flex items-center px-2.5 py-1.5 border border-transparent text-xs font-medium rounded shadow-sm text-white bg-indigo-600 hover:bg-indigo-700 focus:outline-none focus:ring-2 focus:ring-offset-2 focus:ring-indigo-500"> Button text </button>
Same here. Worth it.
No, bootstrap, material, bulma are more popular and would be considered more standard.
I don't think a css framework that charges 200, 400 or 800 (team pricing) for the standard ui components will ever reach that status.
I don't think a css framework that charges 200, 400 or 800 (team pricing) for the standard ui components will ever reach that status.
Tailwind UI is a separate thing, and goes far beyond what you’d get with Bootstrap or Bulma.
Tailwind by itself is intended for people who don’t want the pre-made components you get with Bootstrap etc.
Tailwind by itself is intended for people who don’t want the pre-made components you get with Bootstrap etc.
Opening sourcing tailwinds framework is great. But without the ui components it reduces the appeal to people who can and want to manually build components and needs a guardrail.
Does it go 'far beyond' what you get with something like Vuetify or BootstrapVue? (I've seen they offer react/vue binding/components now).
Personally I think so yes. The available components [0] feel much more designed, like more thought has been put into them, though obviously that's a subjective factor.
[0] https://tailwindui.com/#components
[0] https://tailwindui.com/#components
Not that I've seen.
It's the 'hot topic that gets eyeballs and talk' but that doesn't reflect the same level of general usage.
A little like Vue got all the articles for a while, and don't get me wrong it's very nice, but adoption generally isn't as high as you might think based on discussion and blogs and etc.
It's the 'hot topic that gets eyeballs and talk' but that doesn't reflect the same level of general usage.
A little like Vue got all the articles for a while, and don't get me wrong it's very nice, but adoption generally isn't as high as you might think based on discussion and blogs and etc.
I was a Tailwind skeptic too, but pairing it with a tool for building 'componentized' user interfaces (like GitHub's ViewComponent gem for Ruby web apps[1]) makes it incredibly easy to build attractive, consistent, easy-to-change UIs.
[1] https://github.com/github/view_component/ and https://viewcomponent.org
[1] https://github.com/github/view_component/ and https://viewcomponent.org
Anytime I see Tailwind mentioned I can't help but think about this:
https://mobile.twitter.com/samthor/status/140282566806113075...
https://mobile.twitter.com/samthor/status/140282566806113075...
If we’re trying to be serious: this is a bit like comparing strings to enums/sum types or sets.
The point of atomic/utility CSS is to have a well defined and composable subset of rules. I suggest you seriously try it. I was surprised after a short while. It’s a very productive approach.
The point of atomic/utility CSS is to have a well defined and composable subset of rules. I suggest you seriously try it. I was surprised after a short while. It’s a very productive approach.
I can see this potentially working out well if the "atoms" are roughly at the level of design system elements (for example, maybe something like Tachyons).
At the level of class-per-CSS-property it just makes no sense to me. CSS properties are a well-defined and composable set of rules too.
At the level of class-per-CSS-property it just makes no sense to me. CSS properties are a well-defined and composable set of rules too.
It’s actually more fine grained than that, which is what makes it work. You can add responsive variations and hover styles all in the same place. It’s effectively inline styles on steroids.
And actually, today for the first time in ages and ended up having to add “real css” to style an input[range] and it was so weird and disjointed to me to not define it right where I needed it.
And actually, today for the first time in ages and ended up having to add “real css” to style an input[range] and it was so weird and disjointed to me to not define it right where I needed it.
I've tried it and the amount of visual clutter it introduces is matched only by inline CSS.
Using Tailwind doesn't mean you need to individually list each class every time.
You can use PostCSS to define class that compose multiple tailwind classes together (See how @apply is used here: https://tailwindcss.com/docs/using-with-preprocessors).
My flow is usually to iterate by adding individual classes directly to HTML elements, and when I see a pattern emerge I'll sometimes make a new class with that inherits from multiple tailwind classes.
You can use PostCSS to define class that compose multiple tailwind classes together (See how @apply is used here: https://tailwindcss.com/docs/using-with-preprocessors).
My flow is usually to iterate by adding individual classes directly to HTML elements, and when I see a pattern emerge I'll sometimes make a new class with that inherits from multiple tailwind classes.
Ah, it's just one of those things like Vi or Emacs. You can argue for or against it until you turn blue in the face, but the fact is some people love it, other people hate it, and everyone gets their work done just the same. I don't know if I'm really more productive using Tailwind, but it sure feels like it... and I'm okay with that.
This sounds like a terrible idea. I like it.
Any more examples of what the transform(s) look like? Ie. Given some input, this is the output?
Any more examples of what the transform(s) look like? Ie. Given some input, this is the output?
But I do wonder if inlining classes into each and every element is as efficient as CSS rules that apply to those same elements.
Imagine you have a table with a few hundred cells. You can have something like:
.my_table .cell { ... }
Or repeat those classes in each cell. Is there a performance, memory etc impact?