The difference is you type that lingo inline into the HTML instead of in separate files and you don't have to come up with any class names.

Sounds a bit like a glorified

    <el style="display:flex;justify-content: start;">...

?

The differences are:

* media queries

* @apply

* low specificity (tailwind doesn't do !important)

EDIT: It "does" important, but only when instructed so, in 1.x it was a global switch, apparently since 2.x its available as a per-class modifier. Thanks dcre

* the theming abstraction

* brevity

Tailwind does have important, it was added with JIT.

https://tailwindcss.com/docs/just-in-time-mode#built-in-impo...

Oh, nice, I think that’s a new 3.0 thing, not a JIT thing.

Looks like TW 2.2 from June. It wasn't in the initial JIT release in 2.1.

https://github.com/tailwindlabs/tailwindcss/releases/tag/v2....

I’m…not sure how I missed that, because I did look for it. Thanks for the heads up!

In this scenario, "@apply" is just "a css class", so i don't think it's appropriate to list that as a benefit tailwind has over inline styles. In both cases you'd be defining the styles somewhere else.

Media queries are a good call out, they're definitely a benefit tailwind's approach has to the built-in browser support for inline styles. Another benefit is hover and focus states, which are very difficult to apply with inline styles.

Yes, or now with Tailwind v3.0 you can write that as

    <el class="[display: flex] [justify-content: start]">...

I wish I were being hyperbolic, but alas, no: https://tailwindcss.com/blog/tailwindcss-v3#arbitrary-proper...

To be fair, one of the big perks of Tailwind (IMO) is not having to have a big ol' folder of CSS that you have to figure out what applies where in HTML, but rather just having all your styling inline (while still staying consistent, which is the usual downside of inlining styles manually). Having to have a tailwind-addons.css when you needed random bits of CSS they didn't have classes for kind of sucked; this looks like a nice QOL that would get me back to the original goal of uniting structure-and-style into singular files.

FWIW, I also hated using header files in C++ and also wrote a Ruby library for inlining all my tests immediately following the functions they test. I like having more context when looking at code without having to flip around from file to file to piece a bigger picture together.

The same reason Vue introduced single-file components!

If you haven't tried Vue yet, I strongly recommend it based on what you said.

Thanks for the recommendation! I've mostly been thrust into React, which works for what I need but I definitely don't enjoy it. I'll give Vue a shot!

Svelte also has single file components.

It seems the biggest advantage most people find in tailwind is working around a react limitation.

This seems silly, but even this has benefits over online styles: it generates a scoped classname that wouldn't interfere with others, and you can use this syntax with JS conditionals to dynamically apply CSS with values interpolated if you need.

Not much different than injecting an object in a `style` attribute in practice, but there's a lot of creative firepower in the arbitrary styles API.

Too late to edit, but not "online" styles—but "inline" xD

Excuse my dad joke "There is a lot of wind at the end of that tail"!

Essentially.

https://mobile.twitter.com/samthor/status/140282566806113075...

Absolutely. But that's not a downside, that's exactly what I want.

Then why not just type that, instead of having to learn a completely separate set of concepts to map to the underlying CSS properties & values? I program with inline CSS styles all the time when I'm prototyping something or building a page quickly.

Because inline styles aren’t flexible enough to be used for everything, so you need to go out to external css eventually.

With tailwind you can do “block md:flex hover:font-bold” and you’ve covered pseudo class cases and media queries very succinctly.

It's much more concise than inline styles, variants and configuration give you a lot more power, and it's not a separate set of concepts. It's a subset of the same set of concepts.

See https://news.ycombinator.com/item?id=29502652

It's like radio presets instead of the full dial. Dial is still available, but a great majority of the time you use the presets.

Coming up with variable/class names is one of the most annoying aspects of programming, so any way we can eliminate that task I think is always going to be a productivity boom

So strange. Using good variable names is even better than docs in my experience. And having HTML where every div is named helps a ton. It blows my mind how different people's preferences can be on these things.

Memorizing and looking up names has significant impact on my productivity, especially on codebases that I do not touch frequently. I often losing my train of thought or momentum because of too much abstraction

Most people suck at naming things. Also, most companies don’t have a strong culture for choosing names carefully.

Honestly, I agree with you on the good variable names, but in average team setting I prefer no names than bad ones.

Yes, communicating intent to other programmers and our future selves is hard, so let's not do it.

well, sometimes. yes.

the semantics of most html elements is useless to know for more devs (and classes don't help users)

in fact a class like .red conveys more useful information to a developer than .standout-link because when we go to change the colour of the button it's the colour we care about, not the "purpose" of the button

that gets long - especially if they are rendered inline, hard to scan through.

I'm often in a cycle where I am tweaking a complex class with 10-20 properties including flex, transforms, animations, etc. - and having them each be on their own line (and the class being in a separate file along with its parents, siblings and children, frankly) is key for readability to me.

I guess in the end I have come to have enormous respect for CSS as a powerful, mature language and I'm not looking to be buffered from it.

I don't think of it as an alternative to CSS. I think of it as a way of writing CSS.

It can get long. I certainly have parts of my app where I break out into plain CSS because it's easier to understand.

I put most of my Tailwind utilities on their own line in my HTML, and for elements that need more than 3 or 5, I do the same but in classes or styled components where I'm listing them off instead.

Keeps everything clean and readable!

For toying / prototyping it's way nicer than I'd ever expect. Seriously fun. I now inject tailwing anywhere possible.

Those files (and components) still need sensible names (that would make very nice class names).

This, I've used it only for about a week, there's no way I could go back now.

You’re not wrong. Once it’s in there, it’s not easy to remove/replace again.

The beauty of it comes when you're working in a team of say 5 other front end devs of varying skill levels. There tends to be a large amount of duplication & overlap, people have different ways of doing things and achieving certain looks. If everyone agrees to use tailwind, you stop people from writing custom code which is ultimately a good thing because custom code requires custom comments and custom documentation etc which let's face it - nobody does or wants to do and even if they do, it's not maintained to the sort of standard tailwind docs are.

Not to mention, if your css isn’t scoped (and let’s face it, this is one thing traditional css sucks at) you just never quite know what rule some developer has put in somewhere at what else it effects.

> the major stumbling block has been how tailwind is mostly just css translated into its own hard-to-memorize lingo.

This is the only problem of tailwind, it relies on its own lingo, as all the OOCSS/BEM projects. When you involve semantics, you will always bring these kind of problems.

I covered this problem and I solved it with this approach http://minid.net/2019/04/07/the-css-utilitarian-methodology/

Consider using this handy Tailwind cheat sheet: https://nerdcave.com/tailwind-cheat-sheet

I have it open in a browser tab almost constantly.

This is wonderful, thanks for sharing!

Spot on. Whenever you add a DSL like this, you need to carefully weigh costs and benefits. A hidden downside is that every new person who views your code base (And you in the future!) has to become proficient with the DSL. The base tech it wraps (HTML + CSS) is more fundamental; less overhead.

Another way of saying this, is that Tailwind adds cognitive overhead.

the classes you define become the new dsl though. so you keep the overhead of learning + the effort of writing and maintaing your own dsl

In my experience it's because any web app with complicated styling rules tends towards this anyways, except all the CSS names are custom, undocumented, and duplicated. The main tradeoff is that the CSS names are not domain specific, but honestly that's worked fine for me.

I hear you. I don't understand the reasoning behind frameworks propensity to abbreviate things, especially at "atomic"/utility levels. I think it partially stems from wanting to prevent ignorant knee-jerk reactions like "hurr durr why not just write inline styles".

I wish framework devs would just hyphenate (or even colon-ize) the CSS property names fully like "display-flex justify-content-start". I think Bootstrap does their own pattern like "d-flex", but all that does is require one to visit the docs to view some less common properties. Autocompletion pretty much makes typing these a breeze, and having less opinionated patterns for property names will make it less painful transitioning between frameworks.

I think that’s a little uncharitable.

One thing to consider is that being a bit more terse in tailwind is good because you effectively end up with media queries, dark mode, hover states etc all placed together.

> the major stumbling block has been how tailwind is mostly just css translated into its own hard-to-memorize lingo.

Autocompletion in your IDE makes this easy (the class names are similar to the CSS attributes, even in your examples, so you can usually guess them) and you use the same classes over and over again so you learn them quick. I barely spent 10 minutes in the Tailwind documentation the first few days because of the VSCode extension.

ah yes - that would be a big help. alas I am not a vscode user. I use webstorm and haven't been able to figure out how to get tailwind autocomplete to work with it.

There's a plugin that you have to install to get it going https://www.jetbrains.com/help/webstorm/tailwind-css.html

oh I forgot to mention. ember. it's an ember project. something about handlebars not being supported yet.

Other than autocomplete, I would also suggest using this cheat sheet to help you: https://nerdcave.com/tailwind-cheat-sheet

Try using an IDE extension for autocompleting Tailwind's utilities based on your tailwind.config.js.

Twin Macro is a great wrapper library for Tailwind-in-JS with strong IDE support and it autocompletes all my utilities. I barely have to type anything to style everything in my project.

I can even hover over utilities to peek at its raw CSS.

https://marketplace.visualstudio.com/items?itemName=lightyen...

I don't do frontend except when I have to and "flex justify-start" is way easier for me to learn and explore with than "display:flex; justify-content: start"

And the keywords all seem to make sense to me? It's "n-dimensional properties" but the dimensions are pretty consistent...

You have to learn the more verbose CSS properties in the first place, and the vast majority of tailwind's class names include the unique keywords of those anyway.

Yeah that's my issue as well and so much divitis and unnecessary nesting...

Can you explain what you mean by this? You’re still applying css to html elements, it’s nothing different, right?