[HN Gopher] Tailwindo: Convert Your Bootstrap CSS to Tailwind CSS
___________________________________________________________________
Tailwindo: Convert Your Bootstrap CSS to Tailwind CSS
Author : wilsonfiifi
Score : 66 points
Date : 2021-06-15 14:20 UTC (8 hours ago)
(HTM) web link (awssat.com)
(TXT) w3m dump (awssat.com)
| psadri wrote:
| I'm a fan of tailwind.
|
| 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?
| imilk wrote:
| You can group Tailwind classes into parent classes using @apply
| and everything works as you'd expect
| nickUCB wrote:
| 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.
| ehutch79 wrote:
| 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
| city41 wrote:
| 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.
| yurishimo wrote:
| 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...
| neovive wrote:
| 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.
| aidos wrote:
| 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.
| iamgopal wrote:
| Is tailwind the new de-facto standard what bootstrap was three or
| four years ago ?
| ipaddr wrote:
| 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.
| deergomoo wrote:
| 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.
| ipaddr wrote:
| 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.
| mgkimsal wrote:
| Does it go 'far beyond' what you get with something like
| Vuetify or BootstrapVue? (I've seen they offer react/vue
| binding/components now).
| deergomoo wrote:
| 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
| sumnole wrote:
| No, but it offers the most flexibility of any css framework
| I've seen.
| postalrat wrote:
| If you are after flexibility I'd suggest no css framework.
| Maximum flexibility.
| duxup wrote:
| 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.
| nexuist wrote:
| 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/
| austingulati wrote:
| 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.
| adflux wrote:
| Same here. Worth it.
| ehnto wrote:
| 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.
| pcr910303 wrote:
| > 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)
| ivrrimum wrote:
| I am just finding out about TailWind. Other than dark mode,
| bootstrap has all of those things and some.
| cjlm wrote:
| Might as well migrate to universal.css[0] while you're at it
|
| [0] https://github.com/marmelab/universal.css
| Tade0 wrote:
| Anytime I see Tailwind mentioned I can't help but think about
| this:
|
| https://mobile.twitter.com/samthor/status/140282566806113075...
| rcurry wrote:
| 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.
| dgb23 wrote:
| 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.
| wwweston wrote:
| 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.
| aidos wrote:
| 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.
| Tade0 wrote:
| I've tried it and the amount of visual clutter it introduces
| is matched only by inline CSS.
| zffr wrote:
| 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.
| aaronbrethorst wrote:
| 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
| e12e wrote:
| 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?
___________________________________________________________________
(page generated 2021-06-15 23:02 UTC)