3 ms·

It pushes you to componentize common UI elements. Feel bad to have long utility classes that look like <button class="bg-blue-700 border border-transparent hove

It pushes you to componentize common UI elements. Feel bad to have long utility classes that look like <button class="bg-blue-700 border border-transparent hover:bg-blue-900 ring-2 ring-offset-2">. Change it to: <submit-button>Submit</submit-button> using whatever tooling you prefer. If you don't use this style, maybe you won't like it. I've found it's a waste of time to extract classes for items that are not repeated. And putting utilities in components lightens your "master" CSS file and makes it a lot easier to work with CSS. I've found that the "cascading" part of style sheets almost always breaks down in larger projects. Small components seem to avoid those breakdowns while allowing for reusability.

moray 4y ago
That is called Class in CSS...
- aidos 4y ago
  This is all so played out now. People that haven't used Tailwind come along and say, "this is silly, just use css". The people who have used it say, "you should try it, it's not what you think." There are a bunch of subtle differences with Tailwind that make it quite a different experience. Really, it's closer to inline-styles++ than anything else. The style only applies to the element you're styling. This is by design as it means you can change that one style without wondering what else you've broken across your app. But you get variations that inline styles can't do (and aren't fun to do in css either): `text-green hover:text-red dark:hover:text-white` (interaction states, light/dark mode, responsive etc etc). This makes a huge difference when you're actually building this stuff. Personally, from a DX point of view, I really like it. I find it faster than anything else when I'm building and it's easy to debug too; no need to fish for the styles, they're inline on the element I'm styling. The biggest wart is the inability to functionally build up styles. For example, you have a bunch of js and you need to flip between several different colour states (say for an input that has "disabled | errored | valid | pristene"). There's no great way to force one of your classes to "win" because they're all just classes and the way they were added to the page will determine which border colour wins, for example.
the_other 4y ago
> It pushes you to componentize common UI elements. Feel bad to have long utility classes that look like <button class="bg-blue-700 border border-transparent hover:bg-blue-900 ring-2 ring-offset-2">. Change it to: <submit-button>Submit</submit-button> using whatever tooling you prefer. Even when you do that, you're still delivering the long, repetitive mark-up to the browser, rather than relying on the CSS engine to handle this for you. You're making the DOM MUCH MUCH heavier than it needs to be and ignoring the rendering engine that's optimised to handle this role. It seems wasteful all 'round. I confess I'm guessing here, and haven't tested it, but I suspect a simple, axiomic CSS file and simpler HTML file would produce faster rendering than Tailwind, and travel over the network faster. Tailwind improves the developer experience at the expense of badly optimised code bloating and slowing the user experience. The developer experience benefits are debatable, too: I freaking hate using CSS toolkits and would much rather just write CSS or SASS bespoke to my apps. I have more control and can tailor a solution for the problem.
- pocketsand 4y ago
  The overhead from processing class names is trivial. Things like ads or heavy images actually slow the user experience. This type of thing isn't worth worrying about.
- jolux 4y ago
  > I confess I'm guessing here, and haven't tested it Maybe you shouldn't make unsubstantiated claims like this then? > Tailwind improves the developer experience at the expense of badly optimised code bloating and slowing the user experience. I only say this because if your claims about performance are wrong, your comment seems to boil down to "I don't like CSS frameworks," which is fine, nobody's forcing you to use Tailwind.
- nojs 4y ago
  > Even when you do that, you're still delivering the long, repetitive mark-up to the browser, rather than relying on the CSS engine to handle this for you. The crazy repetition of classes gzips away though so there really isn’t any extra overhead.
RyanGoosling 4y ago
I wonder if this new element is compatible with a blind person’s screen reader. Any input?

moray 4y ago

That is called Class in CSS...

aidos 4y ago
This is all so played out now. People that haven't used Tailwind come along and say, "this is silly, just use css". The people who have used it say, "you should try it, it's not what you think." There are a bunch of subtle differences with Tailwind that make it quite a different experience. Really, it's closer to inline-styles++ than anything else. The style only applies to the element you're styling. This is by design as it means you can change that one style without wondering what else you've broken across your app. But you get variations that inline styles can't do (and aren't fun to do in css either): `text-green hover:text-red dark:hover:text-white` (interaction states, light/dark mode, responsive etc etc). This makes a huge difference when you're actually building this stuff. Personally, from a DX point of view, I really like it. I find it faster than anything else when I'm building and it's easy to debug too; no need to fish for the styles, they're inline on the element I'm styling. The biggest wart is the inability to functionally build up styles. For example, you have a bunch of js and you need to flip between several different colour states (say for an input that has "disabled | errored | valid | pristene"). There's no great way to force one of your classes to "win" because they're all just classes and the way they were added to the page will determine which border colour wins, for example.

the_other 4y ago

> It pushes you to componentize common UI elements. Feel bad to have long utility classes that look like <button class="bg-blue-700 border border-transparent hover:bg-blue-900 ring-2 ring-offset-2">. Change it to: <submit-button>Submit</submit-button> using whatever tooling you prefer. Even when you do that, you're still delivering the long, repetitive mark-up to the browser, rather than relying on the CSS engine to handle this for you. You're making the DOM MUCH MUCH heavier than it needs to be and ignoring the rendering engine that's optimised to handle this role. It seems wasteful all 'round. I confess I'm guessing here, and haven't tested it, but I suspect a simple, axiomic CSS file and simpler HTML file would produce faster rendering than Tailwind, and travel over the network faster. Tailwind improves the developer experience at the expense of badly optimised code bloating and slowing the user experience. The developer experience benefits are debatable, too: I freaking hate using CSS toolkits and would much rather just write CSS or SASS bespoke to my apps. I have more control and can tailor a solution for the problem.

pocketsand 4y ago
The overhead from processing class names is trivial. Things like ads or heavy images actually slow the user experience. This type of thing isn't worth worrying about.
jolux 4y ago
> I confess I'm guessing here, and haven't tested it Maybe you shouldn't make unsubstantiated claims like this then? > Tailwind improves the developer experience at the expense of badly optimised code bloating and slowing the user experience. I only say this because if your claims about performance are wrong, your comment seems to boil down to "I don't like CSS frameworks," which is fine, nobody's forcing you to use Tailwind.
nojs 4y ago
> Even when you do that, you're still delivering the long, repetitive mark-up to the browser, rather than relying on the CSS engine to handle this for you. The crazy repetition of classes gzips away though so there really isn’t any extra overhead.

RyanGoosling 4y ago

I wonder if this new element is compatible with a blind person’s screen reader. Any input?