Why I Love Tailwind

That example also encapsulates everything that wrong with how CSS is used today.<p>The markup contains no information about <i>what</i> the contents are anymore, so you lose the ability to target anything that is <i>X</i>: for example an email, an avatar within a &#x27;people-card&#x27; etc.<p>HTML&#x2F;CSS was supposed to separate <i>content</i> from <i>looks</i>. Of course that ship has sailed long ago, since modern day development seems to be insistent and mushing HTML, CSS and JS together in the same file. <i>Looks is logic is content is looks is a mess.</i><p>HTML&#x2F;CSS was also supposed to be <i>re-usable</i>. Now instead the re-usability is within react&#x2F;angular&#x2F;etc. components, so you now have to use react and javascript everywhere you want to show similar elements - if you want to have the ability to easily change them later.<p>Of course this isn&#x27;t the point. If you have the ability to work with react components, you probably are knowledgeable enough to use CSS.<p>So the only remaining use-case is &quot;way for non-technical people to write objectively bad HTML and have it look nice&quot;.<p>Which again, is fine. Sometimes bad is good enough when the alternative is nothing at all.<p>I&#x27;m still not a fan.

The discussions of Tailwind are always heated but fundamentally boring because all the threads are started by people making the obvious objections that arise before you use it which were answered by Adam three years ago.[1] Do people who have actually used Tailwind in a real project have anything to add?<p>[1] <a href="https:&#x2F;&#x2F;adamwathan.me&#x2F;css-utility-classes-and-separation-of-concerns&#x2F;" rel="nofollow">https:&#x2F;&#x2F;adamwathan.me&#x2F;css-utility-classes-and-separation-of-...</a><p>For my part, I am seeing slow rendering on some of my sites (page doesn&#x27;t appear on webpagetest.org until 1s after network is done), and I wonder if maybe having atomic CSS is slower to render? Anyone have experience with that?

Wasn&#x27;t the whole point of CSS to separate presentation from data, and move away from &lt;font color=red&gt; and other &lt;table&gt; that made layouts too difficult to change? Consider this:<p>&lt;h2 class=&quot;text-purple-500&quot;&gt;Customer Support&lt;&#x2F;h2&gt;<p>How is this different from &lt;h2&gt;&lt;font color=&quot;purple&quot;&gt;Customer Support&lt;&#x2F;font&gt;&lt;&#x2F;h2&gt;? This is still considered bad practice, right?

Tailwind sounds like a crazy and backwards concept. It looks insane and I used to feel the same way. However, after trying it and it clicked I can&#x27;t imagine myself going back. It&#x27;s one of those things you really need to try before you get it.<p>Now I find all of these arguments against it like someone trying to convince me not to use syntax highlighting (<a href="http:&#x2F;&#x2F;www.linusakesson.net&#x2F;programming&#x2F;syntaxhighlighting&#x2F;" rel="nofollow">http:&#x2F;&#x2F;www.linusakesson.net&#x2F;programming&#x2F;syntaxhighlighting&#x2F;</a>). I understand the reasoning but it&#x27;s not something I would even consider.

This is why I don’t <i>love</i> Tailwind as much as I’d like:<p>&quot;It gives developers without a deep understanding of design the ability to build visually gorgeous, modern user interfaces.&quot;<p>This is flat out a myth i widh people stop regurgitating. Look, unless you do css as your primary skill or really passionate about the more visual side of things (the &quot;front of the frontend&quot;) then you don?t magically have the skills to use all kind of css layout te hniques to do precise and elegant UI, given the sketch &#x2F; figma files. Heck most JS devs I’ve worked with barely understand how flex works. Best scenario they make somthing <i>close</i> to provided design, but not quite ... and crucially the finishing touches , the consistency , understanding of design principles that inform every layout you make is missing, so the end result is never quit3 what the designer provided with all kind of small but noticable imperfections like incorrect font sizes, une en spaces, missing white spaces, inconsistent vertical rhythm, relative sizes between icons and text etc etc.<p>Yes, tailwind is good. As a standard utility framework it?s awesome but please stop prentending it turns JS devs magically into css&#x2F;html experts.

There&#x27;s something to be said about being able to build out an entire component with just using your editor&#x27;s css autocomplete. The name &quot;tailwind&quot; is really apt once you get the feel for it.<p>The authors did decide to &#x27;fix&#x27; some css naming, such as Tailwind&#x27;s `hidden` class is `display: none` rather than `visibility: hidden`, which seems wrong at first. But when you see that `visibility: hidden` is `invisible` in Tailwind, it does makes sense. I still can&#x27;t help but think just following the existing naming might have been better, about my only teeny tiny gripe so far.

&gt; This does require some design taste, but most frontend engineers I know have developed that over the years of building user interfaces.<p>Nope. Never really happened for me. Admittedly I don&#x27;t solely work on frontend. But 22 years of making user facing interfaces and I really don&#x27;t feel more confident about it than I did on day one.

I’ve been thinking about an alternative to tailwind but I have no idea how to implement it.<p>I think what would be even more powerful is you configure all the classes with some kind of regexp. They need to be unique. You could provide a function as well that returns the correct css for any given captured units in the class name so eg. &quot;mb-4em&quot; you have template &quot;mb-(\\d+)em&quot; declared. The tool recognizes it and either just puts the number there, uses a mapping (4 becomes 16), or calls a function to return the resulting css properties.<p>What I like about it is you could just as well create more advanced utilities and the parser never generates any classes in advance. It would need some kind of watcher though to detect any new class aded to templates that match the definition file.<p>Then there would be no need to purge anything. Kind of a vague concept I’ll admit, but for me starting with a figma or sketch where designer typically does <i>not</i> folow a consistent guideline, it means I can just start writing templates and keep declaring utilities as I go because in the real world you bet that happens.

Tailwind must have an extremely talented social media guy&#x2F;growth hacker or be a very good product:<p>14 HN front-page hits within just one year.<p><a href="https:&#x2F;&#x2F;hn.algolia.com&#x2F;?dateRange=pastYear&amp;page=0&amp;prefix=false&amp;query=tailwind&amp;sort=byPopularity&amp;type=story" rel="nofollow">https:&#x2F;&#x2F;hn.algolia.com&#x2F;?dateRange=pastYear&amp;page=0&amp;prefix=fal...</a><p>Edit: Got downvotes, guess what haha

Not a fan of it myself. I&#x27;ve never understood this desire to avoid writing CSS wherever possible. It&#x27;s not hard - at least not anymore - but this type of abstraction makes it hard, in my opinion.<p>On top of that, I think it&#x27;s just a bad idea to pepper your html with utility class names.<p>That said, these days pretty much everything I do is React, and styled-components&#x27; ability to interpolate props in styles and attributes is pretty darn nifty.

Oh my god, it just keeps on getting worse!<p>Sure, let&#x27;s take long strings of barely-scrutable utility classes and make them transform into CSS-in-JS statements under the hood via an overcomplicated build pipeline—WTAF.<p>What I find so ironic is pure, native, truly-modern CSS with properties&#x2F;variables, Flexbox, Grid, encapsulation via Shadow DOM if you want it, etc. has gotten <i></i>so-o-o-o<i></i> good, you barely even need a framework anymore. Stuff like Tailwind feels like it&#x27;s solving the problems CSS <i>might</i> have had…er, ten years ago.

Regarding performance, twin.macro seems like a fantastic approach for React users, inlining the styles where needed with Emotion&#x2F;similar.<p>It also answers the &quot;where do custom styles go&quot; question to some extent (answer: the css prop).<p><a href="https:&#x2F;&#x2F;github.com&#x2F;ben-rogerson&#x2F;twin.macro" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;ben-rogerson&#x2F;twin.macro</a><p>Edit: I had stopped reading half way through! This is what the article is about. I&#x27;ll leave my comment up to publicly shame myself.

I&#x27;m a really big fan of tailwind as someone who doesn&#x27;t like to do frontend. It&#x27;s let me iterate decent-looking proof of concept features and MVPs while focusing mostly on the backend, where previously most of my designs would look like craigslist.

One of the best things about Tailwind (and the component and HTML-first movements in general) is a move towards Locality of Behavior:<p><a href="https:&#x2F;&#x2F;htmx.org&#x2F;essays&#x2F;locality-of-behaviour&#x2F;" rel="nofollow">https:&#x2F;&#x2F;htmx.org&#x2F;essays&#x2F;locality-of-behaviour&#x2F;</a><p>With these approaches, you can achieve a complete understanding of a component in one place, without needing to pick around in a bunch of different places, using id-matching or some other mentally burdensome mechanism to keep everything straight.<p>There are trade-offs (as the essay mentions) but Locality of Behavior obviously has a lot of advantages.

I like tailwind, but I just used it for small side projects so far.<p>Something I don&#x27;t understand yet, is how you would use the &quot;purgecss&quot; feature in a large project or in the context of a company with several teams and a design system.<p>For example, let&#x27;s say we have a shared React components library, which has been built with tailwind. Should this shared library expose an already built and purged css file?<p>Should each of our applications do its own purging? If so, how do I prevent the same m-1 to have two different values, one from the shared component library and another from my own application?<p>If I have to add node_modules&#x2F;my-library to the purge directories... Wouldn&#x27;t that still leave styles for components I might not be importing in my application?<p>Should I have a shared tailwind.config.js?<p>These are the things that worry me about using tailwind in a larger context than a small&#x2F;single project.

Tailwind&#x27;s paradigm (&quot;atomic css&quot;) is great and the future, but there is a much better implementation, the barely maintained Tachyons is way superior and was also the first that made atomic css popular. I wrote following on Reddit which still holds true:<p><i>After 2 days of testing, I chose this stack:</i><p><i>Tachyons as primary CSS-in-JS and media-queries method in my React components; why: it&#x27;s slick, easy and complete and brings you quite far</i><p><i>configuration is super; eg, creating your own color or default font is just putting them in your App.css and they override Tachyons; creating other breakpoints is possible (just change and recompile, this takes 1sec and a tachyons-cli is there, no need to touch webpack or eject CRA)</i><p><i>however, configuring Tachyons is not required at all, I tested it in and out and it&#x27;s all perfect at the moment, it&#x27;s really turn-key and absolutely the right approach to our problem; Tachyons does just one thing and it does is right</i><p><i>I preferred it very much over others like Tailwind because Tailwind has cumbersome and long CSS naming; Tailwind&#x27;s philosophy and strategy is inconsistent; on the one hand, it wants to be atomic CSS, on the other hand, it bloats and pollutes your components almost like real CSS, wth? either I do minimal atomic CSS (it&#x27;s called &#x27;atomic&#x27;!) like Tachyons or I put real CSS in my component; Tailwind doesn&#x27;t know what it wants to be while Tachyons has a clear strategy which is perfectly executed =&gt; an ultra atomic mapping to CSS, Tailwinds bobs up and down with some short names and then some long ones...; also setting Tailwind up or configuring is unnecessary complex and bloated; doc is comprehensive and complete but also because of its own complications and disunity; atomic css doesn&#x27;t need to be science; compared to Tailwind, Tachyons is a dream</i><p><i>I also checked styled-system but found the DX not close to Tachyons and couldn&#x27;t see any benefit over Tachyons; it&#x27;s too cumbersome but in a different way than Tailwind</i><p><i>Tachyons is just 13kb gzipped while fully featured (Tailwind is 36kb)</i><p><i>while small Tachyons has the biggest ecosystem (related libs, cheatsheets, blog posts), at the end of the day, you don&#x27;t need more, again it&#x27;s just a mapper and more advanced stuff should be done with eg Emotion anyway</i>[1]<p>[1] <a href="https:&#x2F;&#x2F;www.reddit.com&#x2F;r&#x2F;reactjs&#x2F;comments&#x2F;a6qhbr&#x2F;checked_21_react_ui_kits_briefly_im_done&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.reddit.com&#x2F;r&#x2F;reactjs&#x2F;comments&#x2F;a6qhbr&#x2F;checked_21_...</a>

I wanted to try tailwind on a new CRA app but they’re using a version of postcss that just came out and has a bunch of compatibility problems.<p>&gt; As of v2.0, Tailwind CSS depends on PostCSS 8. Because PostCSS 8 is only a few months old, many other tools in the ecosystem haven&#x27;t updated yet<p>There’s a workaround but it seemed like something I’d have to workaround more than it was worth.<p><a href="https:&#x2F;&#x2F;tailwindcss.com&#x2F;docs&#x2F;installation#post-css-7-compatibility-build" rel="nofollow">https:&#x2F;&#x2F;tailwindcss.com&#x2F;docs&#x2F;installation#post-css-7-compati...</a><p><a href="https:&#x2F;&#x2F;tailwindcss.com&#x2F;docs&#x2F;guides&#x2F;create-react-app" rel="nofollow">https:&#x2F;&#x2F;tailwindcss.com&#x2F;docs&#x2F;guides&#x2F;create-react-app</a>

Tailwind is not for me, simply because I don&#x27;t want to have to learn yet another DSL that may or may not be abandoned in the future. I understand this is a personal decision though, but I&#x27;ve been burned too many times by fads.<p>My ideal CSS solution which doesn&#x27;t seem to exist yet:<p>- Be able to write plain old CSS in JS&#x2F;TS directly within a React component&#x27;s tags, with a JS object literal<p>- Automatically generate atomic classes for each CSS rule (or block of rules) and have the system reuse those rules when the same styles are used elsewhere (no rule duplication means smaller bundle sizes for SSR, plus you get the semantic clarity of using plain CSS rules)<p>- Compiled, with zero or near-zero runtime overhead and critical path extraction, all cacheable by the browser. I don&#x27;t want a huge runtime just so that I can dynamically apply a background colour.<p>The thing that comes closest to this is probably something like Linaria [1], but it relies on tagged template literals instead of object literals which means I can&#x27;t use autocompletion. Their API for dynamic styling also relies on HTML data attributes, which is a little clunky.<p>Stiches [2] is another interesting project, however adoption doesn&#x27;t seem very high and it seems to create superfluous wrapper nodes which can cause performance degradation in large VDOM trees. There&#x27;s also no mechanism to colocate styles within a component&#x27;s tags.<p>CSS Blocks [3] looks very promising also, but it doesn&#x27;t allow co-location of styles with React components (you need to make a separate CSS file for each component).<p>[1] <a href="https:&#x2F;&#x2F;github.com&#x2F;callstack&#x2F;linaria" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;callstack&#x2F;linaria</a><p>[2] <a href="https:&#x2F;&#x2F;github.com&#x2F;modulz&#x2F;stitches" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;modulz&#x2F;stitches</a><p>[3] <a href="https:&#x2F;&#x2F;github.com&#x2F;linkedin&#x2F;css-blocks" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;linkedin&#x2F;css-blocks</a>

Genuine question, I&#x27;m a dev, but primarily backend and all my frontends are internal&#x2F;chunky&#x2F;it doesn&#x27;t matter<p>I usually do 2 things when styling my crummy internal sites: a) manually write semantically-named classes for things that need it (&quot;help-text&quot;, &quot;external-link&quot;) and b) just in-line styles for everything else (esp. when a style really only applies to one element, or is intimately related to important layout considerations).<p>It seems to me that css classes which contain styling info in their name (h-32, font-semibold, text-cyan-600) aren&#x27;t really any better than just in-line styles, and in fact maybe worse because they [seem to me] to just be an alias [which I have to learn, and will forget later] for a css style. Wouldn&#x27;t it be simpler to just inline the style?<p>So my question is: what&#x27;s the real benefit of this kind of css framework? What are the scenarios where it really helps to do styling this way? Is it just a performance thing? Is it about streamlining a dev workflow in some way that I don&#x27;t get?

&gt; The key to Tailwind&#x27;s popularity is the painstakingly constructed system of design tokens at the core of the framework. The system&#x27;s carefully selected constraints give developers just the right guardrails. They make it obvious whether a choice is good or bad by offering only discrete steps.<p>Can anyone comment more on this? As far as I see, there&#x27;s still a big enough range of font sizes, padding&#x2F;margin sizes, colours etc. that you still have to have an eye for design for the result to look pleasing. I&#x27;ve seen multiple landing pages made in Tailwind for example that don&#x27;t look good.<p>Bootstrap in comparison will have a really uniform look if you use the built-in components, but you won&#x27;t be able to build something that looks as good as Tailwind.

Semantic-UI [0] is also a well established framework for building up design using css classes and html only.<p>It&#x27;s been more or less abandoned when the main developer got tired of it though, I really hope the same doesn&#x27;t happen here.<p>[0] <a href="https:&#x2F;&#x2F;semantic-ui.com" rel="nofollow">https:&#x2F;&#x2F;semantic-ui.com</a> [1] <a href="https:&#x2F;&#x2F;fomantic-ui.com" rel="nofollow">https:&#x2F;&#x2F;fomantic-ui.com</a> (Community fork)

Mhh... I don&#x27;t know how to feel about this.<p>Over the last year, I&#x27;ve shipped a bunch of (p)react components [1, 2, 3] and what is cool about them is indeed that you can now encapsulate a UI function and make it re-usable within your project or even across projects.<p>In theory, this should finally give front end devs the same super powers as backend devs: high reusability.<p>However, a problem that I wasn&#x27;t able to distinctly address is CSS. Currently, there&#x27;s simply too many variants of encapsulating CSS into a &quot;react module&quot;. You can opt to use:<p>- css modules<p>- styled components and derivatives<p>- CSS in JS or classes in JS, etc.<p>But ultimately, if you build your UI as a patchwork of many integrated UI elements (which IMO <i>should</i> be something legit in frontend development), you&#x27;ll end up having to include 5 different CSS-in-bla libraries either in your build pipeline or (worse) in your bundle code that you ship to production (bloats the size and hence your app&#x27;s performance).<p>Long story short: Combining styled components with twin macro and tailwind doesn&#x27;t make my life easier currently. And the benefits to my users will not be apparent directly either.<p>Not to say that all the CSS-to-XY movement isn&#x27;t cool. Still, I think the best solution to this problem has yet to be discovered.<p>1: <a href="https:&#x2F;&#x2F;github.com&#x2F;TimDaub&#x2F;preact-touchable-dock" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;TimDaub&#x2F;preact-touchable-dock</a><p>2: <a href="https:&#x2F;&#x2F;github.com&#x2F;TimDaub&#x2F;react-envelope-graph" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;TimDaub&#x2F;react-envelope-graph</a><p>3: <a href="https:&#x2F;&#x2F;github.com&#x2F;TimDaub&#x2F;react-simple-knob" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;TimDaub&#x2F;react-simple-knob</a>

Can anyone recommend any text-heavy tailwind themes? Or - are themes even viable with Tailwind?<p>I&#x27;m a backend Dev who plans to buy Tailwind Build (or w&#x2F;e it&#x27;s called). I enjoy the idea of not having to worry <i>(as much)</i> about design, and instead just focus on content layout, etc. Tailwind is neat that way.<p>With that said though i&#x27;m not a fan of the .. &quot;modern&quot; design. I&#x27;ll use it, i guess, but on text heavy pages ala Wikipedia or HackerNews, Tailwind looks like it would waste a lot of space. Though maybe i&#x27;m off base.<p>The point of this is to ask if theming has gotchas. Eg maybe themes work, but they&#x27;re rarely ever supported well enough, leaving you with little gaps in design that cause problems. Thoughts?

I&#x27;m personally a big fan of Tailwind + either HTMX or Alpine.js, as it lets me easily generate modular UI components in the back-end using the &#x27;dominate&#x27; Python library, without having to fuss around too much. (Other frameworks such as React should work as well, I just haven&#x27;t experimented with them very much so far).<p>Munging these tools together has let me create my own &#x27;distributed back end framework&#x27;, so I can define back-end logic and front-end logic in the same place, but have the back-end logic run on whichever machine I choose, so e.g. an edge device can send a fragment of UI to a monitoring dashboard.<p>It&#x27;s all rather nice and I&#x27;m very pleased with myself. :-)

Was always curious, why it was Tailwind that won &#x27;utility-first css&#x27; and not <a href="https:&#x2F;&#x2F;tachyons.io" rel="nofollow">https:&#x2F;&#x2F;tachyons.io</a> which did this approach first.

<p><pre><code> Atomic CSS is not ideal for performance. No tooling can extract the per-page critical CSS, so you end up shipping more CSS to the browser than necessary. The bigger and more dynamic the app, the more unnecessary code you will ship. </code></pre> Isn’t this solved by using PurgeCSS? During your build phase it removes any unused classes from the final build. You end up with a single CSS file, which is usually quite small, that your browser only downloads once and then caches it.<p>Do people actually generate a CSS file for every page?

I think the original concept of using inline styles in your React components was truly a leap forward in terms of styling DX. It seems like most of the developments since (CSS in JS, Tailwind) have just been more inefficient ways of implementing that core inline styles concept. Ok, these new solutions give you pseudo classes, but those can easily be replicated in JS. Beyond that, I don&#x27;t see the upside of the additional complexity these solutions bring vs plain inline styles.

not related to the article at all, but figure I&#x27;d share this thing that was recently released (no affiliation, just a fan of marcel&#x27;s work) : <a href="https:&#x2F;&#x2F;usewindy.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;usewindy.com&#x2F;</a>

Any alternative to Tailwind UI? I can&#x27;t justify that price for hobby projects. I&#x27;m also not interested in material-ui which is becoming open-core.

I really like Tailwind but has anyone figured out how to get it to run quickly in development with Webpack?<p>For example Tailwind 2.0 out of the box produces around 3.5mb of CSS and Webpack 5+ on an SSD takes 5+ seconds to start things up. This is a problem with Docker because if your main app container needs to be restart it involves stopping Docker Compose and then upping things. This means your app is delayed 5+ seconds from starting. In production it&#x27;s no problem with purge CSS and your build step producing the final assets out of band, but I think having a top notch dev experience is really important.<p>You can do some hacks around how Tailwind imports its fils to make CSS updates happen nearly instantly but the initial Webpack start up time still suffers.<p>Currently I get around this by enabling Webpack&#x27;s filesystem cache but this seems like a band-aid solution.<p>Any suggestions?<p>On a non-SSD machine I noticed the start up time being 28 seconds btw. It&#x27;s a non-issue for me but if you want to make open source projects that others use, a ~30 second start up penalty in development is a killer for a pretty large chunk of people.

The one criticism it&#x27;s valid to level at Tailwind is it doesn&#x27;t play nicely with the CSS cascade.<p>Take their plugin, <a href="https:&#x2F;&#x2F;tailwindcss.com&#x2F;docs&#x2F;typography-plugin" rel="nofollow">https:&#x2F;&#x2F;tailwindcss.com&#x2F;docs&#x2F;typography-plugin</a>. It lets you define text styles for regions (handy when you render Markdown into a div, for example).<p>Imagine that you have HTML inside that div, with TailwindCSS classes applied. The specificity of the text styles for the region override the classes, which isn&#x27;t what any end-user wants.<p>The guys behind Tailwind acknowledge this, but there isn&#x27;t a good solution for it. It&#x27;s not a TailwindCSS-only problem; I&#x27;ve written plenty of CSS by hand which has this issue.<p>But when choosing a framework based around element-level classes, this is a limitation which is important to keep in mind.

In <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=25305467" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=25305467</a> there was talk about the PETAL stack of which Tailwind is a part. It consists of Phoenix, Elixir, Tailwind, Alpine.js, and LiveView.

It is entirely possible to have a &quot;semantic web&quot; and tailwind at the same time.<p>IMHO the perfect combination is BEM naming <i>that is purely semantic</i> combined with tailwind cruft that is purely visual.<p>So you can end up with:<p><pre><code> &lt;div class=&quot;profile_card a-bunch of-tailwinds classes&quot;&gt; &lt;div class=&quot;profile_card__heading more-tailwinds-classes&quot;&gt; &lt;h3 class=&quot;even-more-tailwinds-classes&gt;Hello World&lt;&#x2F;h3&gt; &lt;&#x2F;div&gt; &lt;&#x2F;div&gt; </code></pre> I say this as someone who was revolted by the idea of tailwinds that has then seen the productivity of the team at work absolutely skyrocket after using it.

I also love tailwind! To me it feels like the defaults are sane enough + an amazing documentation which summarizes all the CSS I use.<p>Most of the time I think:<p>&quot;I need a small margin on the right and a big one at the bottom, and let&#x27;s see a black background&quot; which is super cheap to mentally translate to &quot;mr-1 mb-10 bg-black&quot; while staying in the HTML. If I&#x27;m repeating too much I can either move that to a custom tailwind CSS component or a react component. It just feels easy working with, and it&#x27;s super flexible.

I still think that this kind of approach it&#x27;s only a &quot;problem moved&quot; from CSS to inline HTML, which makes me mad because i still need to jump from HTML to CSS all the time, plus custom modifications can be painful with tons of overrides and &quot;!important&quot;s. Exactly like bootstrap.<p>BEM (with none-to-few utility classes) was a game changer to me (even if far from perfect) and its most natural conseguence are web components.<p>I&#x27;m loving the Bulma approach BTW.

Tachyons needs this for a button:<p><pre><code> &lt;a class=&quot;f6 link dim ph3 pv2 mb2 dib white bg-black&quot; &#x2F;&gt; </code></pre> Anyone so quick to show the same in Tailwind to have a comparison?<p>You can see the button rendered here (the first at the top): <a href="https:&#x2F;&#x2F;tachyons.io&#x2F;components&#x2F;buttons&#x2F;basic&#x2F;index.html#0" rel="nofollow">https:&#x2F;&#x2F;tachyons.io&#x2F;components&#x2F;buttons&#x2F;basic&#x2F;index.html#0</a>

I&#x27;ve not yet tried Tailwind, but I&#x27;ve found the utility classes in Bootstrap to be really useful. Over the years I&#x27;ve encountered a good number of instances on larger sites using traditional&#x2F;global CSS where a change to a particular style ends up unintentionally affecting random stuff elsewhere. It&#x27;s really irritating.

A design question if I may. Site states &quot;gives developers without a deep understanding of design the ability to build visually gorgeous, modern user interfaces&quot;.<p>I really don&#x27;t understand this statement. If you are bad&#x2F;good at design, how does Tailwind change anything? Can anyone please describe what it is&#x2F;feels like in comparison?

My opinion moved from liking tailwind to loving it when tailwindplay got realsed (play.tailwind.com). It&#x27;s so cool, and faster than any hot-reload ever will be. It&#x27;s in my opinion is the smoothest way to create UI components on the fly with ease that of drag and drop tools, but with much more extended functionality.

I&#x27;ve &quot;learned&quot; CSS through Tailwind, was using it for a couple of years and I&#x27;m now able to build my own design systems in CSS. The reason I moved on is that I wanted a slightly more opinionated system and a different naming scheme, especially for colors.

The only good use case to use something like Tailwind CSS is that your CSS does not grow exponentially and using twin.macro you lost that.

Love it! I&#x27;ve meshed so completely with tailwind on Rails that it put me off learning React. Guess there&#x27;s no excuse now

I don&#x27;t understand why people treat it like a new bootstrap

What do you think of Tailwind vs Tachyons ?

What is Tailwind&#x27;s performance like? It seems like a ginormous CSS (and JS?) blob for a rather simple visual design.

The text flows outside of the box in the very first example of why Tailwind is great. Viewed on mobile. Not convinced.

I spot many comments either stating that &quot;Tailwind doesn&#x27;t respect the whole point of CSS: separation of data and presentation&quot; or &quot;CSS falls completely short.&quot;<p>I think the truth is to be found somewhere in between.<p>This debate is really about what people want and how they envision the Web. Either as hypertext documents that link information; or as a platform for &quot;rich web applications.&quot;<p>While people argue over the problems JavaScript pose when building applications. The same type of arguments also pop up when it comes to CSS. How the focus on semantics hampers building rich applications with a dynamic DOM structure.<p>I posted a comment a few days ago that goes into detail about this. I hope you will forgive me for repeating it here. I feel it&#x27;s relevant to this discussion as well.<p>What changed over the past 30 years is how the Web evolved from a small group of academics and engineers 30 years ago into the billions that it connects today. It&#x27;s not just hypertext. It&#x27;s hypertext and every other conceivable business case which is being shoehorned into the browser.<p>The Web originally wasn&#x27;t conceived to provide affordances that allow for &quot;rich media experiences&quot;. Foundational technologies - HTTP, HTML, CSS, JS,... - weren&#x27;t originally designed to build complex user interfaces and applications. Yet, as more and more and more people got connected: that&#x27;s exactly what they wanted.<p>Remember Flash? Or Java applets? Or Silverlight? Those were hailed as additional technologies that would merge complex user interfaces into the Web. Macromedia coined the term &quot;Rich Web Applications&quot; back in 2002. All of them failed for various reasons.<p>Ever since the Web Standards moving of the mid-00&#x27;s, communities of designers have taken CSS and HTML and tried to bend and use them in any way possible to bring visually stunning experiences on the Web. This is where you will find the direct roots of many ideas and dynamics that are currently in vogue. It&#x27;s their influence, as well as other dynamics - e.g. the introduction of the smartphone, the rise of big tech - that has defined how browser technology has evolved.<p>Over the past decade, browser vendors have tacked on additional browser API&#x27;s on top of the original, decade old foundations, while communities of frontend developers have spawned ever intricate constellations of interlocking JavaScript libraries and frameworks that specifically try to break out of how the Web originally was intended to work.<p>Some things have become easier as specifications evolved a bit (e.g. CSS3). But at the end of the day, your browser still needs to download HTML, JS and CSS, parse all of that, execute and render it onto a canvas.<p>Tailwind solves a particular issue: it tries to do away with the semantics of CSS and abstracts how presentation relates to the DOM structure in order to allow developers to focus on what they should be building: rich, highly interactive applications.<p>Tailwind, however, isn&#x27;t the right tool if you want to focus on building classic hypertext documents &#x2F; websites. It&#x27;s still totally valid to build things using the original web standards principles.<p>It&#x27;s not a tale of one or the other. It&#x27;s a tale of both are valid business cases. I think that should be the core take away here.

Met too

I like Tailwind because it’s the best solution of the bunch at the moment. But I much rather work on iOS over HTML. Now why is that?