Tailwind is the second best thing ever happend to frontend, only Vue 3 tops it.<p>Not having to come up with names for CSS classes, no duplicated CSS code, no fighting conflicting classes, everything in one file, being able to visualize a component just by reading the code... it's a godsend. I'll never go back to SCSS unless work obliges me.<p>Vue 3 with <script setup lang="ts">, TailwindCSS and Vite. The way God intended.
As a forceful critic of Tailwind over many years now, I must say all of the announcements under the CSS-first configuration are extremely welcome. This makes it possible to take advantage of all of Tailwind's design tokens, reset, etc.—and even even customize them via real CSS—and then use tokens in honest-to-goodness CSS via native variables. This opens up a new world of "light" usage of Tailwind for its theming and utilities, *without* throwing away all of the awesomeness of modern CSS architecture, the cascade, and even shadow DOM in web components.<p>I'm a huge fan of this major improvement to the framework.
CTRL+u gives a nice example of the syntax.<p>For example to make a box with rounded corners and a top and bottom section, all you need is this intuitive one-liner:<p><div class="mt-5 mb-8 first:mt-0 last:mb-0 relative overflow-hidden rounded-2xl"><div class="pt-2 bg-slate-800 shadow-lg group"><div class="flex text-slate-400 text-xs leading-6"><div class="flex-none text-sky-300 border-t border-b border-t-transparent border-b-sky-300 px-4 py-1 flex items-center">app.css</div><div class="flex-auto flex items-center bg-slate-700/50 border border-slate-500/30 rounded-tl"></div></div><div class="children:my-0 children:!shadow-none children:bg-transparent"><pre class="language-css"><code class="language-css"><span class="token atrule"><span class="token rule">@import</span> <span class="token string">"tailwindcss"</span><span class="token punctuation">;</span></span></code></pre></div></div><div class="pointer-events-none absolute inset-0 rounded-2xl dark:ring-1 dark:ring-white/10 dark:ring-inset" aria-hidden="true"></div></div>
> Standalone CLI — we haven’t worked on a standalone CLI for the new engine yet, but will absolutely have it before the v4.0 release.<p>This part is the most exciting to me. Given the rest of the release announcement, I'm assuming this means that it'll be built in Rust rather than embed Node. While I'm not a Rust zealot of anything, I'm very partial to not embedding Node. Particularly when it depends on using Vercel's now-abandoned pkg[1] tool.<p>[1] <a href="https://github.com/vercel/pkg">https://github.com/vercel/pkg</a>
My friends: do we need tailwind as soon as Safari 17.4 is out?
Chrome has @scope already available and safari soon.
With @scope we don’t need utility frameworks at all and can make use of scoped css with css variables for unification. What do you think?
I am not a front end developer, but I do maintain a few websites and I have used Tailwind for all of them.<p>My general take of the overall quality is that the maintainers of Tailwind have really good intuition in terms of what to prioritize, as well as excellent design taste. Tailwind is one of those tools where it only makes sense once you start to use it, but each version they've announced brings a continuously more polished product.<p>If you don't like Tailwind or you don't understand it or if anything I'm saying makes you mad, try first building something big with it. It's pretty maintainable, easy to read and write, and, most of all, is very portable. (I mean that in the sense that something you write in one place can be copy and pasted somewhere else and it will more than likely work exactly the same.)<p>As far as this version is concerned, it looks like not a whole lot has changed from a compatibility perspective, but I think when version 4 becomes official it might have more breaking changes. In any case, the prospect of a new engine is very cool, as faster builds are always welcome.<p>Congratulations to the team! I may not be a front end engineer, but with Tailwind I don't really have to be to make what I want.
Out of curiosity, does anyone out there use tailwindcss with htmx (or other hateoas approach)? You obviously don’t want to have your hypertext representative of application state to have anything to do with styling, but something like tailwind can be odds with that. Cascading style sheets and hateoas obviously go together perfectly, as it’s markup and styling decoupled as god intended, but with something like tailwindcss, what are people doing?
I use Tailwind at work daily and I still believe it is a crutch for a bad design system. I see pros and cons. If you keep your class count relatively small, you can "see" how the element is going to look if you are good with CSS, and it is incredibly intuitive. On the other hand, when you see blocks with 20+ classes, just like some examples posted here, they are hideous and all the readability goes down the drain, I take this should be made up for with the use of components and limiting copy pasting.
Also I don't think you have to use either Tailwind or more classical approaches, in fact I like mixing both. During a rush a couple of years ago my team had to give a more up to date look to mane features in our app and, provided you have a strong component system, those touch ups were mostly related to positioning and sizing, and that represents 99% of our usage of Tailwind.
Looks like a lot of great improvements, but wanted to put in one vote in favor of keeping the capability of having a JavaScript-forward configuration/usage approach, rather than requiring a CSS-forward approach.<p>For us, one big benefit of using Tailwind has been that we can avoid spending a lot of time thinking about CSS and CSS tooling, and being able to configure everything via JS has helped in that regard.
I wish tailwind would support attributify like <a href="https://github.com/unocss/unocss">https://github.com/unocss/unocss</a>, which is much more readable for complex layouts:<p><pre><code> <a bg="red" text="white" dark="bg:red text:white">link</a></code></pre>
I was excited to use this in my Demo project, but `import from "node:@tailwindcss/postcss@latest"` throws error about the `exports` field in package.json.<p>With that aside, the blog post mentions not having to use `postcss-import` but it seems to include that as dependency. So we're still using `postcss-import`.
If an org can't organise its workflow (name things) and adopt external organisation (magic bullet frameworks), the org will always have poor organisation in the long term.
Switching the theme configuration to CSS variables makes a ton of sense.<p>But what is the point of introducing a directive called "@theme{}" though for configuration?<p>Why not just do ":root{}"?
How does people solve component variants? Say <Button type="success" size="lg"> or <Button type="danger" size="sm"> ?<p>For optimal gzipping (and saner readability) it's recommended to have sorted classes (prettier-plugin-tailwindcss)<p>But if you want to have some overridability (avoid clashing of p-4 and p-8) you need tailwind-merge.<p>These two don't play together well
This is not a complaint. But as someone who uses AI heavily for tailwind, I found that GPT-4 couldn't update the syntax even after the cutoff is updated. Likely it gives equal weightage to documents regardless of the date. And even with 2023 cutoff it just can't work with new syntax of many libraries I tried.<p>I had hopes with google in this as they already likely have things like official docs, updation etc labelled so they can give different weights to every document. But then there is Gemini.
Everything about this sounds like how I expected Tailwind to work the first time I tried it.<p>I wanted to love it, but instead got bogged down in all this PostCSS nonsense and configuration before I could do anything.<p>Happy to see they're moving towards a "it just works out of the box" approach.