6 ms·

First up, agree with the author. Now if I may, a rant. It boggles the mind that we style bikeshed over CSS. Is it honestly, truly, and pragmatically worthwhile

by ehnto 4y ago

First up, agree with the author. Now if I may, a rant. It boggles the mind that we style bikeshed over CSS. Is it honestly, truly, and pragmatically worthwhile to spend all this engineering effort manipulating, culling, tree shaking, modularizing our CSS? Pre-load that, inline this, async-load that, and what have we got for it? A web full of wiggling content, slow CDNs, dozens of requests, and an experience of a mis-timed, slow loading web of bullshit. Deliver less CSS in the first place, be pragmatic, load it as one file when the user hits the website, from the same server they got the HTML from. Bam, lightning fucking fast, like it was before we invented all these new problems. The brief flash of your half-styled website is useless to me. Block rendering until the CSS is done. I don't enjoy looking at half an interlaced video frame, or 100px of a 200px image, just show me the finished product. The content wiggles and asynchronous bullshit is what makes your website -feel- slow, even if you managed to trick Google into thinking it loaded quickly.

dpacmittal 4y ago
This is the reason I love tailwind. There's no bloat, no headache of naming conflicts (in fact they completely did away with naming), no orphan css. CSS for a full blown website can be less than 5kb. It takes away the pain of thinking about CSS architecture, naming things, conflicts etc and you can just focus on styling.
- ehnto 4y ago
  I did not expect to like tailwind, and it still irks my past-self's approach to CSS. But I can't argue that as a wholistic approach to CSS, it is very capable and once you learn the lexicon, very fast to develop with. I really did enjoy it.
  - dmitriid 4y ago
    It's also one of the very few frameworks that cares about accessibility by default in their examples: no buttons-as-links, no divs-as-lists, clear contrast everywhere.
  - speedgoose 4y ago
    Tailwind goes against all old CSS best practices, so I was strongly against it. But I eventually tried it after reading everyone recommending it and it’s great.
  - inopinatus 4y ago
    We have to have Tailwind because we got CSS instead of DSSSL.
- dotancohen 4y ago
  Tell us a bit more about Tailwind. Last I looked at it a few years ago it seemed a conglomeration of antipatterns. Quick googling is not convincing. Assume that I know _nothing_ about Tailwind, sell it to me. I'd appreciate it. Thanks.
  - deergomoo 4y ago
    The author of Tailwind wrote a blog post explaining his rationale just after the very first version was released: https://adamwathan.me/css-utility-classes-and-separation-of-concerns/ https://adamwathan.me/css-utility-classes-and-separation-of-... It may be a longer read than you were looking for, in which case I’d say just try it on a small project next time you get the chance. It looks like it wouldn’t work, but it really does.
  - christophilus 4y ago
    Been developing websites and apps since the days when we are worrying about the y2k bug. Tailwind is my favorite thing. Almost everything that I disliked about CSS is solved by it. Once you really kick the tires, you become way more productive: Naming is hard. No more naming. Switching between your markup and your CSS added friction to your flow. No more friction. Avoiding problems caused by overly aggressive rules / cascade/ whatever is mostly a thing of the past. I could go on, but if it’s not obvious, I absolutely love it. And the Tailwind UI project is 100% money we’ll spent, too.
    - danielvaughn 4y ago
      I feel the same way about Tailwind, but haven't taken the plunge on Tailwind UI. Though I kinda want to buy it just to support the team. Do you feel like it constrains you too much, or no?
      - pbowyer 4y ago
        > Though I kinda want to buy it just to support the team. That's kind but they have earned shedloads already (over $2m USD as of Jan 2021 [1]). That's on top of the $2.3m for the Refactoring UI ebook [2]. 1. https://www.smalltechbusiness.com/monetizing-open-source-tailwind/ https://www.smalltechbusiness.com/monetizing-open-source-tai... 2. https://twitter.com/adamwathan/status/1289702466754211842 https://twitter.com/adamwathan/status/1289702466754211842
- cageface 4y ago
  I'm a huge fain of Tailwind but if you're using react you can also consider styled-system: https://styled-system.com https://styled-system.com It seems to have a lot of the benefits of Tailwind but better integration with Typescript.
- cantSpellSober 4y ago
  Any system using PurgeCSS (like Tailwind) would have the same bloat removed right? (minus the bloat Tailwind adds to your HTML) Is there a replacement for CSS Modules' "composes" keyword? Tailwind has @apply, but that defeats the purpose of a utility framework somewhat.
dmix 4y ago
> worthwhile to spend all this engineering effort manipulating, culling, tree shaking, modularizing our CSS? You don't have to ever think about this stuff if you use a component-driven frontend framework like Vue w/ Vite (or Webpack). The general design: you use one global .css file for your shared styles (app.css) and then each component has their own inline CSS. Vite will automatically extract each component JS and CSS in tiny files and only load them when you visit a page with the specific component. This all happens automatically and you can cleanly organize your project by keeping the styles close to the view template and logic (often the same file has the template, <style> and <script> which each get extract automatically into bundles). The .css/.js filenames match the component name which makes debugging easier too in dev console. HTTP2 handles loading 20-100 small files like nothing and with large SaaS apps usually only have tons of components that rarely get used, so no need to load them all for every page. If you had to think about this stuff, manage the tooling, and customize then it would be overhead, but otherwise with frameworks it's pure benefit.
- troysk 4y ago
  The way SPAs work is very performant but are also poor for indexing. Critical Path CSS is mostly used in user facing sites which one wants to get indexed by Google. As page speed is one of the factors considered in SEO, and rightly, one tries to optimize that. Vue, React, etc. are poor at SEO as they do not even try to do solve the problem as they are used to build apps and not sites.
  - cercatrova 4y ago
    I see you haven't used these libraries in at least a few years, because they all have frameworks that work with SEO by server side rendering content. React has NextJS while Vue has NuxtJS.
    - troysk 4y ago
      I have from its days of bleeding edge. They still can't match the speed unless you have huge caching budgets; in my experience.
dspillett 4y ago
>* is what makes your website -feel- slow, even if you managed to trick Google into thinking it loaded quickly.* I assume this is why a lot of pages do it: SEO over UX. If they cared that much about user experience the ads and tracking would be gone before worrying about CSS in this way.
Forge36 4y ago
The more CSS you load the slower some rendering becomes. Even when the styles aren't used. If you use a static page this isn't as relevant. It can become significant for single page apps, especially if you dynamically load CSS.
- ehnto 4y ago
  An SPA has all the tools in their tooling chain necessary to minimize delivered CSS, yet they're often still slower than a static page web application with a 5000 line CSS file. The issue isn't the CSS rendering, it's in the timing of the resources and their delivery. If you load CSS in 12 different files, especially if you're doing it as the user interacts with the site, then the browser has to combine, reprocess and repaint every line of CSS it has been given so far, each time it gets new CSS. That's after waiting for the network request. I know I'm talking against industry opinion, but I don't believe browsers are the right platform to be loading things on the fly as the user needs them. It's 50-300+ms absolute best case, plus processing time. It's going to feel bad.
cantSpellSober 4y ago
> Is it [...] pragmatically worthwhile YES! It affects e-commerce conversion rates measurably. Great point by the author: "make sure it’s the right thing to focus on." Hobby site? Don't care about FOUC. E-commerce? It's a game-changer. > The brief flash of your half-styled website is useless to me Not to the rest our users though! Are you on a 3G connection in a third-world country? If not your experience may be not be shared but every user.
- ehnto 4y ago
  I am confused, are you for or against FOUC? Or for optimizing against it? My core industry is e-commerce, have been doing it for over a decade. Our fastest sites are the fully cached, single CSS file sites. You get sent a small amount of CSS and HTML, and you are off to the races. Javascript comes later, and is not necessary to operate the site until checkout. What kills a sites speed for us is usually shitty CDNs and bloated assets, we don't have those. There isn't a single e-commerce platform popular today that I feel does this well, but that is because they are all enterprise platforms full of enterprise features.
  - cantSpellSober 4y ago
    I'm against FOUC when it matters, and for optimizing CSS when it's the right thing to focus on. On hobby sites it doesn't matter. On high volume e-commerce it does.
7sidedmarble 4y ago
>The brief flash of your half-styled website is useless to me. Block rendering until the CSS is done. I have good news for you: https://web.dev/critical-rendering-path-render-blocking-css https://web.dev/critical-rendering-path-render-blocking-css CSS is already a render blocker.
- ehnto 4y ago
  Which I think is the correct way to handle a CSS file, but it's not render blocking if you dynamically load it in with JS. That is what Critical path CSS is combatting against, the "FUIC" or flash of unstyled content, which of course is because people are loading in CSS asynchronously. A problem we created for ourselves. A lot of new approaches atomically separate the CSS and JS into dozens of smaller files that load in as the parts of the website that need them load in. Critial CSS is likely also a response to the issues that this approach creates. As the article alludes to, they're ideas that makes total sense clinically, but falls short really quickly in practice.

by ehnto 4y ago

dpacmittal 4y ago

This is the reason I love tailwind. There's no bloat, no headache of naming conflicts (in fact they completely did away with naming), no orphan css. CSS for a full blown website can be less than 5kb. It takes away the pain of thinking about CSS architecture, naming things, conflicts etc and you can just focus on styling.

ehnto 4y ago
I did not expect to like tailwind, and it still irks my past-self's approach to CSS. But I can't argue that as a wholistic approach to CSS, it is very capable and once you learn the lexicon, very fast to develop with. I really did enjoy it.
- dmitriid 4y ago
  It's also one of the very few frameworks that cares about accessibility by default in their examples: no buttons-as-links, no divs-as-lists, clear contrast everywhere.
- speedgoose 4y ago
  Tailwind goes against all old CSS best practices, so I was strongly against it. But I eventually tried it after reading everyone recommending it and it’s great.
- inopinatus 4y ago
  We have to have Tailwind because we got CSS instead of DSSSL.
dotancohen 4y ago
Tell us a bit more about Tailwind. Last I looked at it a few years ago it seemed a conglomeration of antipatterns. Quick googling is not convincing. Assume that I know _nothing_ about Tailwind, sell it to me. I'd appreciate it. Thanks.
- deergomoo 4y ago
  The author of Tailwind wrote a blog post explaining his rationale just after the very first version was released: https://adamwathan.me/css-utility-classes-and-separation-of-concerns/ https://adamwathan.me/css-utility-classes-and-separation-of-... It may be a longer read than you were looking for, in which case I’d say just try it on a small project next time you get the chance. It looks like it wouldn’t work, but it really does.
- christophilus 4y ago
  Been developing websites and apps since the days when we are worrying about the y2k bug. Tailwind is my favorite thing. Almost everything that I disliked about CSS is solved by it. Once you really kick the tires, you become way more productive: Naming is hard. No more naming. Switching between your markup and your CSS added friction to your flow. No more friction. Avoiding problems caused by overly aggressive rules / cascade/ whatever is mostly a thing of the past. I could go on, but if it’s not obvious, I absolutely love it. And the Tailwind UI project is 100% money we’ll spent, too.
  - danielvaughn 4y ago
    I feel the same way about Tailwind, but haven't taken the plunge on Tailwind UI. Though I kinda want to buy it just to support the team. Do you feel like it constrains you too much, or no?
    - pbowyer 4y ago
      > Though I kinda want to buy it just to support the team. That's kind but they have earned shedloads already (over $2m USD as of Jan 2021 [1]). That's on top of the $2.3m for the Refactoring UI ebook [2]. 1. https://www.smalltechbusiness.com/monetizing-open-source-tailwind/ https://www.smalltechbusiness.com/monetizing-open-source-tai... 2. https://twitter.com/adamwathan/status/1289702466754211842 https://twitter.com/adamwathan/status/1289702466754211842
cageface 4y ago
I'm a huge fain of Tailwind but if you're using react you can also consider styled-system: https://styled-system.com https://styled-system.com It seems to have a lot of the benefits of Tailwind but better integration with Typescript.
cantSpellSober 4y ago
Any system using PurgeCSS (like Tailwind) would have the same bloat removed right? (minus the bloat Tailwind adds to your HTML) Is there a replacement for CSS Modules' "composes" keyword? Tailwind has @apply, but that defeats the purpose of a utility framework somewhat.

dmix 4y ago

> worthwhile to spend all this engineering effort manipulating, culling, tree shaking, modularizing our CSS? You don't have to ever think about this stuff if you use a component-driven frontend framework like Vue w/ Vite (or Webpack). The general design: you use one global .css file for your shared styles (app.css) and then each component has their own inline CSS. Vite will automatically extract each component JS and CSS in tiny files and only load them when you visit a page with the specific component. This all happens automatically and you can cleanly organize your project by keeping the styles close to the view template and logic (often the same file has the template, <style> and <script> which each get extract automatically into bundles). The .css/.js filenames match the component name which makes debugging easier too in dev console. HTTP2 handles loading 20-100 small files like nothing and with large SaaS apps usually only have tons of components that rarely get used, so no need to load them all for every page. If you had to think about this stuff, manage the tooling, and customize then it would be overhead, but otherwise with frameworks it's pure benefit.

troysk 4y ago
The way SPAs work is very performant but are also poor for indexing. Critical Path CSS is mostly used in user facing sites which one wants to get indexed by Google. As page speed is one of the factors considered in SEO, and rightly, one tries to optimize that. Vue, React, etc. are poor at SEO as they do not even try to do solve the problem as they are used to build apps and not sites.
- cercatrova 4y ago
  I see you haven't used these libraries in at least a few years, because they all have frameworks that work with SEO by server side rendering content. React has NextJS while Vue has NuxtJS.
  - troysk 4y ago
    I have from its days of bleeding edge. They still can't match the speed unless you have huge caching budgets; in my experience.

dspillett 4y ago

>* is what makes your website -feel- slow, even if you managed to trick Google into thinking it loaded quickly.* I assume this is why a lot of pages do it: SEO over UX. If they cared that much about user experience the ads and tracking would be gone before worrying about CSS in this way.

Forge36 4y ago

The more CSS you load the slower some rendering becomes. Even when the styles aren't used. If you use a static page this isn't as relevant. It can become significant for single page apps, especially if you dynamically load CSS.

ehnto 4y ago
An SPA has all the tools in their tooling chain necessary to minimize delivered CSS, yet they're often still slower than a static page web application with a 5000 line CSS file. The issue isn't the CSS rendering, it's in the timing of the resources and their delivery. If you load CSS in 12 different files, especially if you're doing it as the user interacts with the site, then the browser has to combine, reprocess and repaint every line of CSS it has been given so far, each time it gets new CSS. That's after waiting for the network request. I know I'm talking against industry opinion, but I don't believe browsers are the right platform to be loading things on the fly as the user needs them. It's 50-300+ms absolute best case, plus processing time. It's going to feel bad.

cantSpellSober 4y ago

> Is it [...] pragmatically worthwhile YES! It affects e-commerce conversion rates measurably. Great point by the author: "make sure it’s the right thing to focus on." Hobby site? Don't care about FOUC. E-commerce? It's a game-changer. > The brief flash of your half-styled website is useless to me Not to the rest our users though! Are you on a 3G connection in a third-world country? If not your experience may be not be shared but every user.

ehnto 4y ago
I am confused, are you for or against FOUC? Or for optimizing against it? My core industry is e-commerce, have been doing it for over a decade. Our fastest sites are the fully cached, single CSS file sites. You get sent a small amount of CSS and HTML, and you are off to the races. Javascript comes later, and is not necessary to operate the site until checkout. What kills a sites speed for us is usually shitty CDNs and bloated assets, we don't have those. There isn't a single e-commerce platform popular today that I feel does this well, but that is because they are all enterprise platforms full of enterprise features.
- cantSpellSober 4y ago
  I'm against FOUC when it matters, and for optimizing CSS when it's the right thing to focus on. On hobby sites it doesn't matter. On high volume e-commerce it does.

7sidedmarble 4y ago

>The brief flash of your half-styled website is useless to me. Block rendering until the CSS is done. I have good news for you: https://web.dev/critical-rendering-path-render-blocking-css https://web.dev/critical-rendering-path-render-blocking-css CSS is already a render blocker.

ehnto 4y ago
Which I think is the correct way to handle a CSS file, but it's not render blocking if you dynamically load it in with JS. That is what Critical path CSS is combatting against, the "FUIC" or flash of unstyled content, which of course is because people are loading in CSS asynchronously. A problem we created for ourselves. A lot of new approaches atomically separate the CSS and JS into dozens of smaller files that load in as the parts of the website that need them load in. Critial CSS is likely also a response to the issues that this approach creates. As the article alludes to, they're ideas that makes total sense clinically, but falls short really quickly in practice.