10 ms·

Tailwind CSS v4.0 Beta 1

168 points by creativedg 2y ago

seanwilson 2y ago
Tailwind threads usually include comments and questions that are answered in the documentation, so here's some useful links for people that haven't used Tailwind before. A core part of Tailwind is that you reuse styles by using a templating system vs using custom CSS classes e.g. you have a button.html file that contains the styling for your buttons for reuse, so you don't have to keep repeating the same utility classes everywhere. https://v2.tailwindcss.com/docs/extracting-components#extracting-template-components https://v2.tailwindcss.com/docs/extracting-components#extrac... > It’s very rare that all of the information needed to define a UI component can live entirely in CSS — there’s almost always some important corresponding HTML structure you need to use as well. > For this reason, it’s often better to extract reusable pieces of your UI into template partials or JavaScript components instead of writing custom CSS classes. @apply (e.g. .btn { @apply py-2 px-4 bg-indigo-500 text-white }) is only meant for reusing styles for simple things like a single tag and is generally recommended against because you should use templates instead: https://v2.tailwindcss.com/docs/extracting-components#extracting-component-classes-with-apply https://v2.tailwindcss.com/docs/extracting-components#extrac... > For small components like buttons and form elements, creating a template partial or JavaScript component can often feel too heavy compared to a simple CSS class. > In these situations, you can use Tailwind’s @apply directive to easily extract common utility patterns to CSS component classes. Inline styles can't be responsive and can't target hover/focus states e.g. there's no inline way to write "text-black hover:text-blue py-2 md:py-4 lg:py-5 lg:flex lg:items-center" and the CSS equivalent is very verbose. https://v2.tailwindcss.com/docs/utility-first#why-not-just-use-inline-styles https://v2.tailwindcss.com/docs/utility-first#why-not-just-u... > But using utility classes has a few important advantages over inline styles: > Designing with constraints. Using inline styles, every value is a magic number. With utilities, you’re choosing styles from a predefined design system, which makes it much easier to build visually consistent UIs. > Responsive design. You can’t use media queries in inline styles, but you can use Tailwind’s responsive utilities to build fully responsive interfaces easily. > Hover, focus, and other states. Inline styles can’t target states like hover or focus, but Tailwind’s state variants make it easy to style those states with utility classes. Opinion: As utility classes are quick to type and change, and it's easy to find where you need to edit to change the styles of a component, it's an order of magnitude quicker to iterate on designs compared to CSS that's scattered across files and shared between pages in hard to track ways. CSS specificity and cascading aren't often used, and mostly just cause complexity and headaches so are best avoided. Tailwind-style vs classic CSS is similar to composition vs inheritance in OOP with similar pros/cons, where complex inheritance is generally discouraged now in OOP languages. Yes, the Tailwind approach is going against the standard CSS approach, but CSS wasn't initially designed for highly custom responsive designs so it's not surprising if its "best practices" don't fit everywhere. Also, Tailwind is really for custom responsive UI and website designs. If your site is mostly Markdown documents and you don't need a custom design or complex mobile/desktop styling, the above isn't going to make any sense and plain CSS or something like Bootstrap is likely a better choice.
- teaearlgraycold 2y ago
  I see tailwind as a new form of CSS built for the component age. It’s not a framework or design system.
  - sodapopcan 2y ago
    Yes! This sums it up perfectly. To the latter point, it's more so a tool for building design systems that comes with a [very large and thorough] default implementation.
  - conradludgate 2y ago
    I prefer scoped css, eg svelte or react with CSS modules. This allows one to closely pair the styles with the component, but still separate out the styling from the html (I cannot stand tailwind/inline syles)
    - foretop_yardarm 2y ago
      My favourite way too and fwiw not mutually exclusive with Tailwind (in case anyone was wondering).
      - teaearlgraycold 2y ago
        Sometimes it’s necessary when using tailwind (I often use traditional CSS for animations). What’s the hip way to have CSS specific to a component? I remember StyledComponents from years ago. I wasn’t as much into front end then.
  - tuzemec 2y ago
    I see it as a way of granular styling, because there's no cascading. And IMO works great if you style each element (or component) individually. But the moment you need to style real html and not some kind of component structure - you have to look for something else. If I switch to "old man yelling at the sky" mode I would say that's an example of a nice concept (utility classes) taken way too far.
that_guy_iain 2y ago
I'm really curious as to why they felt the need to work on improving performance.[1] Were people complaining it was too slow? Were the performance improvements just the benefit of refactoring they did for other reasons? Considering the build happens once during your build phase, taking under half a second doesn't seem like something I would even bother looking at. So it just jumps out to me, so I'm just curious. [1] https://tailwindcss.com/docs/v4-beta#new-high-performance-engine https://tailwindcss.com/docs/v4-beta#new-high-performance-en...
- sodapopcan 2y ago
  No idea if anyone was complaining, but if building in CI it shaves off some pennies (or more?) no?
  - teaearlgraycold 2y ago
    Given its popularity this can actually get into measurable carbon emission savings. Not world changing. But maybe a few international flights over the lifespan.
    - Sesse__ 2y ago
      The carbon cost of a bloated CSS framework isn't the build time, it's the billions of times the resulting CSS has to be parsed and applied on the web pages where it's used.
      - yurishimo 2y ago
        Have you examined the build artifacts of a site using tailwind? The size of the CSS is often smaller than the same styling in "normal" hand written CSS. There are a dozen blog posts from large engineering orgs that have confirmed that switching to Tailwind slimmed their builds down. Shopify has been a big proponent of Tailwind and they are absolutely obsessed with shipping as little code as possible because of the scale they operate at. Also, browsers are insanely good at parsing and applying CSS. You need hundreds of thousands of unique selectors before the browser takes more than fraction of a second to parse and render an entire CSS file. https://www.trysmudford.com/blog/i-spent-a-day-making-the-website-go-2ms-faster/ https://www.trysmudford.com/blog/i-spent-a-day-making-the-we...
atsjie 2y ago
They are switching from sRGB to OKLCH. First time I heard of OKLCH tbh. Anyone know if that is part of a wider adoption trend or is Tailwind pioneering here? Looking at the examples it does seem to offer some advantages; but was primarily surprised that they now use it as a default.
- block_dagger 2y ago
  According to this article [1] OKLCH accounts for biases in human perception of color brightness. Seems useful, but I don't know the answer to your question. [1] https://evilmartians.com/chronicles/oklch-in-css-why-quit-rgb-hsl https://evilmartians.com/chronicles/oklch-in-css-why-quit-rg...
- kevinsync 2y ago
  OKLCH is a curve that makes everything look nicer lol https://abhisaha.com/blog/interactive-post-oklch-color-space/ https://abhisaha.com/blog/interactive-post-oklch-color-space...
- CharlesW 2y ago
  > Anyone know if that is part of a wider adoption trend or is Tailwind pioneering here? It's part of a wider adoption trend. https://bottosson.github.io/posts/oklab/#oklab-implementations https://bottosson.github.io/posts/oklab/#oklab-implementatio...
- bryanrasmussen 2y ago
  OKLCH has the main advantage of LCH, which is that the numbers make sense, meaning that if you have two colors that are the same lightness they will look like they are the same lightness, because the numbers make sense you can now do programmatic color manipulation - increase lightness by 5 etc. that in the past would have been too difficult to really do (so people would instead just have variables giving the different rgb values and switch them in) OKLCH just basically exists because there is a hue change from blue to purple in LCH when the lightness goes less which does not match how humans think of these colors (supposedly, don't know if there is any cultural difference) So in OKLCH the lighter blue does not look purple like it does in LCH, it looks like lighter blue.
notRobot 2y ago
I've never had as much fun doing front-end web stuff as I've had since I've picked up tailwind.
- yieldcrv 2y ago
  this is the honeymoon phase, wait until your package manager and transpiler is out of date, and your progressive web app framework is out of date, and your typescript version isnt compatible with the upgrade yet, and tailwinds isnt either or it is but none of the documentation is yet, but you have to upgrade because your CI/CD cant run your version of node anymore and now you have 100 flags across 5 configuration files and dont know which one to change to make everything work, but changing it might break the ability for a random dependency to compile, and even if you get that to work it turns out your project doesnt render anymore
  - quantadev 2y ago
    Good rant! That's kind of what web-development seems like sometimes. Almost every part of the technology stack is there to fix some other part of the stack that never was ideal to begin with. TypeScript being the best example. It only exists because JavaScript sucks, and JavaScript only ever existed because in 1994ish some guy failed to get Java to run in the browser, and the only reason we're building apps in what was originally a "Document Rendering" system (HTML) was also not by design either but just an accident of history. One train wreck after another.
    - deleted 2y ago
      [deleted]
    - agos 2y ago
      no, it's not a good rant. this is the billionth "web dev is too complicated!" rant that is present under every. single. thread. about any technology vaguely related to front end development.
      - deleted 2y ago
barrenko 2y ago
[flagged]
- cambaceres 2y ago
  What does that mean?
  - nXqd 2y ago
    bros keep eating ...
sam_goody 2y ago
Looks good. I am glad that they support container-queries[1]. But all the real goodness is in contain[2] (which sounds the same but is not related). Tailwind really needs to support contain. I am disappointed by their statement that there will be no major additions, because contain is really that important - both from a dev perspective, and from a performance perspective. It belongs in v4 from the start. [1]: https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_containment/Container_queries https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_contain... [2]: https://developer.mozilla.org/en-US/docs/Web/CSS/contain https://developer.mozilla.org/en-US/docs/Web/CSS/contain
- hanneskt 2y ago
  Looks like the contain utility has been added here [1] and is also available in v4. [1]: https://github.com/tailwindlabs/tailwindcss/pull/12993 https://github.com/tailwindlabs/tailwindcss/pull/12993
deleted 2y ago
[deleted]
kookamamie 2y ago
Read some of the Getting Started documentation, for fun. First step: > Installing with Vite What the hell is Vite? Oh, it seems to be something you need to install via npm. I cannot help but to ask - why do we require npm, or Vite, for something that looks like it should "help" with CSS? Why is the webdev such a shitshow, that seems to get ever deeper into its own weird rabbit hole?
- lenkite 2y ago
  Generally use the standalone tailwind CSS CLI tool for keeping things lean. Sadly the download link from the "Getting Started" page https://github.com/tailwindlabs/tailwindcss/releases/tag/v4.0.0-beta-1 https://github.com/tailwindlabs/tailwindcss/releases/tag/v4.... is broken. Shows that the "bloated" way of doing things is now the norm.
  - 0x6c6f6c 2y ago
    This is a feature for projects already using Node and Vite (which is quite popular these days). It's also not a requirement. The binary still exists, you can run it standalone.
- deergomoo 2y ago
  I agree with you in the general case, but many people are going to be using Tailwind as part of a build step, and many of those people will be using Vite to do that build. Two options down is the option to install the CLI, which does not require any other build tools. As for why it requires npm: I dislike the Node ecosystem as much as the next guy, but it’s a tool used for web development. Where else are you gonna install it from?
  - jph00 2y ago
    npm is for designed primarily for js dev. Many (most?) sites aren't written in js -- they're written in Java, C#, Python, PHP, etc. Thankfully, tailwind is available directly as a downloadable binary. Unfortunately the link in their beta docs is buried, and also broken -- the correct link is here: https://github.com/tailwindlabs/tailwindcss/releases/ https://github.com/tailwindlabs/tailwindcss/releases/
croisillon 2y ago
i never used Tailwind but i can't wait for the release video clip for the curious: - v2 https://www.youtube.com/watch?v=3u_vIdnJYLc https://www.youtube.com/watch?v=3u_vIdnJYLc - v3 https://www.youtube.com/watch?v=TmWIrBPE6Bc https://www.youtube.com/watch?v=TmWIrBPE6Bc
going_north 2y ago
CSS first configuration is a good change! It seems like it would makes it easier to combine tailwind with regular CSS files which still uses the same design tokens. This is useful e.g. when creating a site with a component architecture where the components are styled with CSS, but some of the content comes from CSS or markdown.
deleted 2y ago
[deleted]
emmacharp 2y ago
I invite (for fun and learning!) anyone here still thinking native CSS provides no efficient solution to the problems Tailwind may have solved 5 years ago to challenge me: Bring up any said problem and I'll give you an efficient, robust, fast, simple and maintainable way to solve it in pure, native CSS (maybe even with further advantages!). The time has come to embrace good ol' CSS again! Heheh.
- Vinnl 2y ago
  Ok, my problem is that I don't know just by reading the styles that other contributors wrote, whether they are still relevant, or if the HTML they applied to was changed or removed. They didn't write clean atomic commit, and I can't get them to adhere to some sort of convention. The other problem is that I don't have a designer and tend to make things ugly given full freedom, but I do want things to have their own visual identity.
  - emmacharp 2y ago
    Great questions/problems! 1. I address the problem of relevance by inserting the CSS right into the component with a link tag. If the component is not used, the CSS isn't either. A positive side effect of this technique is that you always have an easy access to the CSS by following the link in your editor of choice. As for the relevance of the rules inside the component, the said component should be light/simple enough that this isn't harder that glancing a minute (max!) at both files. 2. You can use Stylelint to ensure adherence to specific rules. I have developed a config aiming to prevent these kinds of problems. You can find rules, guidelines and a link to the Stylelint config (still beta) at https://ecss.info https://ecss.info. 3. A CSS theme file with custom property design tokens is sufficient. As I understand, Tailwind 4.0 made the switch to CSS tokens. You can thus use the same naming convention for your tokens in native CSS. As complementary advantages you get future-proof code, no build step, and a lot less unused CSS (for instance, Tailwind's own homepage sports 85% unused CSS!). I'm happy to elaborate further or respond to any subsequent questions you may have!
    - Vinnl 2y ago
renerick 2y ago
After some experimenting I found that Tailwind works best with hybrid approach. The essay[1] is correct, that often you have one-of-a-kind blocks, like headers, footers, etc. that you can just fully implement with TW utilities, reducing cognitive load for class naming and structuring. But for more reusable elements, like buttons, links, inputs, popups, it's just much nicer to have them (and their variations) behind simple `btn btn-blue btn-small`. Even when using component-based approach, it's just much simpler to manage all those various states as explicit classes, rather than re-implementing CSS cascade in JS to determine how to combine corresponding TW utilities. I feel like if Tailwind Labs would be less radical in their marketing strategy, it'd receive a bit less of a backlash. Maybe :) And I do agree, that moving to better integration with native CSS is a step in the right direction, very curious about future of v4 [1]: https://adamwathan.me/css-utility-classes-and-separation-of-concerns/ https://adamwathan.me/css-utility-classes-and-separation-of-...
- floydnoel 2y ago
  I use DaisyUI on top of Tailwind to get the nice semantic classes like btn.

168 points by creativedg 2y ago

Tailwind threads usually include comments and questions that are answered in the documentation, so here's some useful links for people that haven't used Tailwind before. A core part of Tailwind is that you reuse styles by using a templating system vs using custom CSS classes e.g. you have a button.html file that contains the styling for your buttons for reuse, so you don't have to keep repeating the same utility classes everywhere. https://v2.tailwindcss.com/docs/extracting-components#extracting-template-components https://v2.tailwindcss.com/docs/extracting-components#extrac... > It’s very rare that all of the information needed to define a UI component can live entirely in CSS — there’s almost always some important corresponding HTML structure you need to use as well. > For this reason, it’s often better to extract reusable pieces of your UI into template partials or JavaScript components instead of writing custom CSS classes. @apply (e.g. .btn { @apply py-2 px-4 bg-indigo-500 text-white }) is only meant for reusing styles for simple things like a single tag and is generally recommended against because you should use templates instead: https://v2.tailwindcss.com/docs/extracting-components#extracting-component-classes-with-apply https://v2.tailwindcss.com/docs/extracting-components#extrac... > For small components like buttons and form elements, creating a template partial or JavaScript component can often feel too heavy compared to a simple CSS class. > In these situations, you can use Tailwind’s @apply directive to easily extract common utility patterns to CSS component classes. Inline styles can't be responsive and can't target hover/focus states e.g. there's no inline way to write "text-black hover:text-blue py-2 md:py-4 lg:py-5 lg:flex lg:items-center" and the CSS equivalent is very verbose. https://v2.tailwindcss.com/docs/utility-first#why-not-just-use-inline-styles https://v2.tailwindcss.com/docs/utility-first#why-not-just-u... > But using utility classes has a few important advantages over inline styles: > Designing with constraints. Using inline styles, every value is a magic number. With utilities, you’re choosing styles from a predefined design system, which makes it much easier to build visually consistent UIs. > Responsive design. You can’t use media queries in inline styles, but you can use Tailwind’s responsive utilities to build fully responsive interfaces easily. > Hover, focus, and other states. Inline styles can’t target states like hover or focus, but Tailwind’s state variants make it easy to style those states with utility classes. Opinion: As utility classes are quick to type and change, and it's easy to find where you need to edit to change the styles of a component, it's an order of magnitude quicker to iterate on designs compared to CSS that's scattered across files and shared between pages in hard to track ways. CSS specificity and cascading aren't often used, and mostly just cause complexity and headaches so are best avoided. Tailwind-style vs classic CSS is similar to composition vs inheritance in OOP with similar pros/cons, where complex inheritance is generally discouraged now in OOP languages. Yes, the Tailwind approach is going against the standard CSS approach, but CSS wasn't initially designed for highly custom responsive designs so it's not surprising if its "best practices" don't fit everywhere. Also, Tailwind is really for custom responsive UI and website designs. If your site is mostly Markdown documents and you don't need a custom design or complex mobile/desktop styling, the above isn't going to make any sense and plain CSS or something like Bootstrap is likely a better choice.

teaearlgraycold 2y ago
I see tailwind as a new form of CSS built for the component age. It’s not a framework or design system.
- sodapopcan 2y ago
  Yes! This sums it up perfectly. To the latter point, it's more so a tool for building design systems that comes with a [very large and thorough] default implementation.
- conradludgate 2y ago
  I prefer scoped css, eg svelte or react with CSS modules. This allows one to closely pair the styles with the component, but still separate out the styling from the html (I cannot stand tailwind/inline syles)
  - foretop_yardarm 2y ago
    My favourite way too and fwiw not mutually exclusive with Tailwind (in case anyone was wondering).
    - teaearlgraycold 2y ago
      Sometimes it’s necessary when using tailwind (I often use traditional CSS for animations). What’s the hip way to have CSS specific to a component? I remember StyledComponents from years ago. I wasn’t as much into front end then.
- tuzemec 2y ago
  I see it as a way of granular styling, because there's no cascading. And IMO works great if you style each element (or component) individually. But the moment you need to style real html and not some kind of component structure - you have to look for something else. If I switch to "old man yelling at the sky" mode I would say that's an example of a nice concept (utility classes) taken way too far.

that_guy_iain 2y ago

I'm really curious as to why they felt the need to work on improving performance.[1] Were people complaining it was too slow? Were the performance improvements just the benefit of refactoring they did for other reasons? Considering the build happens once during your build phase, taking under half a second doesn't seem like something I would even bother looking at. So it just jumps out to me, so I'm just curious. [1] https://tailwindcss.com/docs/v4-beta#new-high-performance-engine https://tailwindcss.com/docs/v4-beta#new-high-performance-en...

sodapopcan 2y ago
No idea if anyone was complaining, but if building in CI it shaves off some pennies (or more?) no?
- teaearlgraycold 2y ago
  Given its popularity this can actually get into measurable carbon emission savings. Not world changing. But maybe a few international flights over the lifespan.
  - Sesse__ 2y ago
    The carbon cost of a bloated CSS framework isn't the build time, it's the billions of times the resulting CSS has to be parsed and applied on the web pages where it's used.
    - yurishimo 2y ago
      Have you examined the build artifacts of a site using tailwind? The size of the CSS is often smaller than the same styling in "normal" hand written CSS. There are a dozen blog posts from large engineering orgs that have confirmed that switching to Tailwind slimmed their builds down. Shopify has been a big proponent of Tailwind and they are absolutely obsessed with shipping as little code as possible because of the scale they operate at. Also, browsers are insanely good at parsing and applying CSS. You need hundreds of thousands of unique selectors before the browser takes more than fraction of a second to parse and render an entire CSS file. https://www.trysmudford.com/blog/i-spent-a-day-making-the-website-go-2ms-faster/ https://www.trysmudford.com/blog/i-spent-a-day-making-the-we...

atsjie 2y ago

They are switching from sRGB to OKLCH. First time I heard of OKLCH tbh. Anyone know if that is part of a wider adoption trend or is Tailwind pioneering here? Looking at the examples it does seem to offer some advantages; but was primarily surprised that they now use it as a default.

block_dagger 2y ago
According to this article [1] OKLCH accounts for biases in human perception of color brightness. Seems useful, but I don't know the answer to your question. [1] https://evilmartians.com/chronicles/oklch-in-css-why-quit-rgb-hsl https://evilmartians.com/chronicles/oklch-in-css-why-quit-rg...
kevinsync 2y ago
OKLCH is a curve that makes everything look nicer lol https://abhisaha.com/blog/interactive-post-oklch-color-space/ https://abhisaha.com/blog/interactive-post-oklch-color-space...
CharlesW 2y ago
> Anyone know if that is part of a wider adoption trend or is Tailwind pioneering here? It's part of a wider adoption trend. https://bottosson.github.io/posts/oklab/#oklab-implementations https://bottosson.github.io/posts/oklab/#oklab-implementatio...
bryanrasmussen 2y ago
OKLCH has the main advantage of LCH, which is that the numbers make sense, meaning that if you have two colors that are the same lightness they will look like they are the same lightness, because the numbers make sense you can now do programmatic color manipulation - increase lightness by 5 etc. that in the past would have been too difficult to really do (so people would instead just have variables giving the different rgb values and switch them in) OKLCH just basically exists because there is a hue change from blue to purple in LCH when the lightness goes less which does not match how humans think of these colors (supposedly, don't know if there is any cultural difference) So in OKLCH the lighter blue does not look purple like it does in LCH, it looks like lighter blue.

notRobot 2y ago

I've never had as much fun doing front-end web stuff as I've had since I've picked up tailwind.

yieldcrv 2y ago
this is the honeymoon phase, wait until your package manager and transpiler is out of date, and your progressive web app framework is out of date, and your typescript version isnt compatible with the upgrade yet, and tailwinds isnt either or it is but none of the documentation is yet, but you have to upgrade because your CI/CD cant run your version of node anymore and now you have 100 flags across 5 configuration files and dont know which one to change to make everything work, but changing it might break the ability for a random dependency to compile, and even if you get that to work it turns out your project doesnt render anymore
- quantadev 2y ago
  Good rant! That's kind of what web-development seems like sometimes. Almost every part of the technology stack is there to fix some other part of the stack that never was ideal to begin with. TypeScript being the best example. It only exists because JavaScript sucks, and JavaScript only ever existed because in 1994ish some guy failed to get Java to run in the browser, and the only reason we're building apps in what was originally a "Document Rendering" system (HTML) was also not by design either but just an accident of history. One train wreck after another.
  - deleted 2y ago
    [deleted]
  - agos 2y ago
    no, it's not a good rant. this is the billionth "web dev is too complicated!" rant that is present under every. single. thread. about any technology vaguely related to front end development.
    - deleted 2y ago

barrenko 2y ago

[flagged]

cambaceres 2y ago
What does that mean?
- nXqd 2y ago
  bros keep eating ...

sam_goody 2y ago

Looks good. I am glad that they support container-queries[1]. But all the real goodness is in contain[2] (which sounds the same but is not related). Tailwind really needs to support contain. I am disappointed by their statement that there will be no major additions, because contain is really that important - both from a dev perspective, and from a performance perspective. It belongs in v4 from the start. [1]: https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_containment/Container_queries https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_contain... [2]: https://developer.mozilla.org/en-US/docs/Web/CSS/contain https://developer.mozilla.org/en-US/docs/Web/CSS/contain

hanneskt 2y ago
Looks like the contain utility has been added here [1] and is also available in v4. [1]: https://github.com/tailwindlabs/tailwindcss/pull/12993 https://github.com/tailwindlabs/tailwindcss/pull/12993

deleted 2y ago

[deleted]

kookamamie 2y ago

Read some of the Getting Started documentation, for fun. First step: > Installing with Vite What the hell is Vite? Oh, it seems to be something you need to install via npm. I cannot help but to ask - why do we require npm, or Vite, for something that looks like it should "help" with CSS? Why is the webdev such a shitshow, that seems to get ever deeper into its own weird rabbit hole?

lenkite 2y ago
Generally use the standalone tailwind CSS CLI tool for keeping things lean. Sadly the download link from the "Getting Started" page https://github.com/tailwindlabs/tailwindcss/releases/tag/v4.0.0-beta-1 https://github.com/tailwindlabs/tailwindcss/releases/tag/v4.... is broken. Shows that the "bloated" way of doing things is now the norm.
- 0x6c6f6c 2y ago
  This is a feature for projects already using Node and Vite (which is quite popular these days). It's also not a requirement. The binary still exists, you can run it standalone.
deergomoo 2y ago
I agree with you in the general case, but many people are going to be using Tailwind as part of a build step, and many of those people will be using Vite to do that build. Two options down is the option to install the CLI, which does not require any other build tools. As for why it requires npm: I dislike the Node ecosystem as much as the next guy, but it’s a tool used for web development. Where else are you gonna install it from?
- jph00 2y ago
  npm is for designed primarily for js dev. Many (most?) sites aren't written in js -- they're written in Java, C#, Python, PHP, etc. Thankfully, tailwind is available directly as a downloadable binary. Unfortunately the link in their beta docs is buried, and also broken -- the correct link is here: https://github.com/tailwindlabs/tailwindcss/releases/ https://github.com/tailwindlabs/tailwindcss/releases/

croisillon 2y ago

i never used Tailwind but i can't wait for the release video clip for the curious: - v2 https://www.youtube.com/watch?v=3u_vIdnJYLc https://www.youtube.com/watch?v=3u_vIdnJYLc - v3 https://www.youtube.com/watch?v=TmWIrBPE6Bc https://www.youtube.com/watch?v=TmWIrBPE6Bc

going_north 2y ago

CSS first configuration is a good change! It seems like it would makes it easier to combine tailwind with regular CSS files which still uses the same design tokens. This is useful e.g. when creating a site with a component architecture where the components are styled with CSS, but some of the content comes from CSS or markdown.

deleted 2y ago

[deleted]

emmacharp 2y ago

I invite (for fun and learning!) anyone here still thinking native CSS provides no efficient solution to the problems Tailwind may have solved 5 years ago to challenge me: Bring up any said problem and I'll give you an efficient, robust, fast, simple and maintainable way to solve it in pure, native CSS (maybe even with further advantages!). The time has come to embrace good ol' CSS again! Heheh.

Vinnl 2y ago
Ok, my problem is that I don't know just by reading the styles that other contributors wrote, whether they are still relevant, or if the HTML they applied to was changed or removed. They didn't write clean atomic commit, and I can't get them to adhere to some sort of convention. The other problem is that I don't have a designer and tend to make things ugly given full freedom, but I do want things to have their own visual identity.
- emmacharp 2y ago
  Great questions/problems! 1. I address the problem of relevance by inserting the CSS right into the component with a link tag. If the component is not used, the CSS isn't either. A positive side effect of this technique is that you always have an easy access to the CSS by following the link in your editor of choice. As for the relevance of the rules inside the component, the said component should be light/simple enough that this isn't harder that glancing a minute (max!) at both files. 2. You can use Stylelint to ensure adherence to specific rules. I have developed a config aiming to prevent these kinds of problems. You can find rules, guidelines and a link to the Stylelint config (still beta) at https://ecss.info https://ecss.info. 3. A CSS theme file with custom property design tokens is sufficient. As I understand, Tailwind 4.0 made the switch to CSS tokens. You can thus use the same naming convention for your tokens in native CSS. As complementary advantages you get future-proof code, no build step, and a lot less unused CSS (for instance, Tailwind's own homepage sports 85% unused CSS!). I'm happy to elaborate further or respond to any subsequent questions you may have!
  - Vinnl 2y ago

renerick 2y ago

After some experimenting I found that Tailwind works best with hybrid approach. The essay[1] is correct, that often you have one-of-a-kind blocks, like headers, footers, etc. that you can just fully implement with TW utilities, reducing cognitive load for class naming and structuring. But for more reusable elements, like buttons, links, inputs, popups, it's just much nicer to have them (and their variations) behind simple `btn btn-blue btn-small`. Even when using component-based approach, it's just much simpler to manage all those various states as explicit classes, rather than re-implementing CSS cascade in JS to determine how to combine corresponding TW utilities. I feel like if Tailwind Labs would be less radical in their marketing strategy, it'd receive a bit less of a backlash. Maybe :) And I do agree, that moving to better integration with native CSS is a step in the right direction, very curious about future of v4 [1]: https://adamwathan.me/css-utility-classes-and-separation-of-concerns/ https://adamwathan.me/css-utility-classes-and-separation-of-...

floydnoel 2y ago
I use DaisyUI on top of Tailwind to get the nice semantic classes like btn.