Crypto and NFTs are just easier, less risk, less chances of being caught.

Maybe we should talk diamonds. Inherently worthless objects, easy to hide and transport, easy to make part of jewelry, and thus free to transport almost anywhere. Yet that one tiny rock can cost tens of thousands and will allow the corrupt politician to sell for cash money perfectly fine.

I suspect in most cases Wise or similar would be cheaper and safer.

Today, I can buy USDC/USDT in the US, head to any country in SE Asia and sell it locally there, paying less in fees than I would with USD. No KYC on the receiving end.

Wise is a pain the KYC ass and has a lot of limits.

Setting all that CI/CD stuff up took me maybe 6 hours. Building the website (front and back-end) took me a few weeks. It's a complicated piece of software, but fun to build.

I avoided using unnecessary tools. I only added what was absolutely necessary. And based on my 22+ years of experience (including some FAANG companies and the likes), in any professional setting, this project would've taken 5 front-end developers, 3 back-end developers, 2 testers, 1 project manager, 1 scrum master, 1 product owner, 1 UX and 1 UI designer, and perhaps one or two interns.

And it would've taken 2 years or longer.

I've done projects with teams like that in the past where trivial work was drowned in red tape, office politics, endless opinions and meetings, weekly time-wasters (Scrum... fuck I hate Scrum!), endless "documentation" that nobody reads...

And I remember being put on a dashboard page. The team was taking 4 hours to plan all the stories. During that time I just started working (remotely, muted, camera off) and I finished the entire dashboard completely to specs, no bugs, in the time it took them to write the stories and tasks and estimate them.

"Done."

"What?"

"I'm done. It's all done. I pulled all 18 tasks to myself, verified them, and the entire story and epic is now done."

"What?"

"I also wrote all the e2e-tests."

"What?"

"Scrum is a huge waste of time."

"Actually, I disagree, because..."

Yeah, consultant who is paid by the hour. It makes perfect sense to pull all 20+ people into a 6-hour long retrospective every single week. Because 12 of those people are from your employer, and that's a lot of money for doing fuck all.

When I worked at Apple, we had a small team and we just did standups on Slack. Just write "I did X, I will do Y, no impediments," and that's it. No scrum bullshit, no sprints, no retrospectives. We just communicated using words (written, preferably) and got shit done.

Now I'm working for a large corporate company that follows all the things by the book. And the book sucks. I counted: 16 hours per week in unnecessary meetings. Then another 10 hours in meetings where most people are unnecessary. And when I speak up against it, people don't trust me. Scrum is their God.

I hate my job so much.

The real question should be: would most developers WANT to use a Mac, if given the choice?

Personally, I think OSX is the superior of the two simply because it's stable as can be, takes no (and allows almost no) tinkering to get working. Controversial opinion, I'm sure.

Felt relieved when I sold my Mac hardware on and could get on with computing, may well just be my usage pattern was incompatible with OSX but that was my experience.

If the decision is between Ubuntu and Mac, they will go with Mac because it usually means better hardware and build quality. I don't think that non-mac laptops have screens that can compete with XDR displays.

> (and allows almost no) tinkering to get working

I think that we tend to overlook or dismiss the amount of tinkering we do in MacOS. Installing certain toolchains can be a real PITA, we have to deal with homebrew, outdated utilities (thank god for coreutils in homebrew), and so on.

The XDR display is nice I’m sure, but there are laptops out there with 4K OLED displays…

I dunno. From what I’ve observed, Apple products are mostly nice due to the attention to detail and the fact that the purchaser can be pretty sure that nothing will be truly deficient. Other than that one time with the MacBook keyboards.

So many products are like: fantastic but here‘s some crippling issue. Apple skips that.

- chassis flex / build quality

- battery life

Just because a panel is oled and 4k doesn’t mean that it is a good panel. I have a 4k oled tv and its contrast ratios are garbage compared to the laptop.

The panel in the 16inch mbp has variable refresh rate, 10k dimming zones due to the 10k mini leds, 1600 nits peak brightness, 1000 sustained.

For me, I prefer a screen which can go truly black on a pixel-by-pixel basis. You might like the MacBook screen better, and there are surely some metrics by which is can beat an OLED panel (for example some people like really bright screens which OLED can have trouble providing). But it is not true to say that non-Mac laptops can’t compete with the XDR display. For any given metric, there exists a screen out there that is better, and choosing which metrics to prioritize is a matter of preference.

Poor areas will just default to yarr matey windows xp due to how easy it is to set up… and become gold mine for hackers to abuse

Microsoft does not care anymore. You can use no product key, and you only lose some stuff in the "Personalize" menu and have a watermark. It will get Windows updates still.

LTT video showing it https://youtu.be/M3bezYerYxQ?t=474

or just crack it as you say. Cracked using massgrave activator gets Windows updates just fine. I use it in a VM.

Now, I just tell Copilot what I need to do, and I simply curate multiple solutions.

ChatGPT also understands what I need to do and changes things based on human instructions. It gets things right much more quickly.

"There are 42 people watching this hotel right now! Only 3 rooms available for your dates! We'll murder ANOTHER puppy if you don't book right now!"

Yes, I worked for Booking.com. They don't do it everywhere, in some places it's illegal, and sometimes they simply change the words slightly to make it suggest urgency.

Become an Etsy seller and sell something what wouldn't be even show up in search

Observe if "N people have this in their carts right now" shows up

...

PROFIT

The best arguments against it:

1. Spamming utility classes causes horrible git commits, git history, git difference checks;

2. Conflicting utility classes aren't clear, and sometimes the order cannot be trusted;

3. Replacing `p-4` with `p-4` will require you to replace its occurrence all over your app, sometimes affecting thousands of matches. And since there is no context to it, it'll be hard to JUST replace them where you would want them to.

Vanilla CSS using `:root` declaration, a fixed base size (using `rem` and `em`), CSS variables and `calc()` are SO powerful.

In almost every single use case, using vanilla CSS or SCSS is far superior. For React projects (and Vue.js, and Svelte, and Angular), I'd recommend anyone to just use (S)CSS modules. It's so elegant and doesn't come with any of the disadvantages.

Except maybe a slightly larger package size. Minimally so. Your framework of choice should be (or allow) code splitting to take place. And a few bytes more or less aren't going to make or break most websites.

I've been a frontend dev for 25 years and I quite like Tailwind. I'm not sure which category I fit into. I think it might be both.

Replacing `p-4` with `p-4` will require you to replace its occurrence all over your app, sometimes affecting thousands of matches.

This is a really good example of where Tailwind is actually quite nice. Imagine if you didn't use a utility class, and instead you'd written your styles in plain old CSS or SCSS with "padding: 8px;" everywhere on your years-old-built-up-to-thousands-of-styles design. Replacing those is easy enough, but what about your SCSS mixins? Your CSS calc()s? The places where someone thought an element needed a bit more padding and used "padding: 9px" instead? Manually managing styles is hard. Tailwind makes it a bit easier, mainly because it encourages consistency and removes variability. Finding and replacing a "p-4" everywhere is trivial, and if you've used a library well rather than rolling out an ad hoc mix of things you can be quite confident your change will work everywhere. It's far from perfect but it's quite a well-thought out approach.

I have around 10 years experience, tailwind is a godsend for maintainability and speed.

If you're applying `p-4` to all your component classes you're only marginally improving on applying `padding: 8px` on all of your component styles. Both are terrible solutions even if one is slightly better than the other.

I generally agree with OP. Tailwind is horrible for larger projects and I have no idea why it's so well liked. The utility class approach is bad, and naming of their utility classes is even worse.

For smaller projects or for prototyping it's okay, although even then it's only slightly better than inlining styles.

That solves the exact problem you and OP complain about, in a neat, configurable, safely replaceable way. Tailwind allows you to separate design intent from implementation values.

The problem is that I think we are outnumbered. Most engineers want to avoid CSS, pretend it doesn't exist, and if all else fails, build a complicated mech suit they can climb into to manipulate it without coming into contact with it directly. That's why things like Tailwind and Bootstrap and CSS-in-JS solutions took off.

My solution on the teams I worked with was to say "hello, I will do all of the CSS in the entire application if it means we don't have to add another dependency just to indulge the team's distaste for CSS."

Near the end of my career I was pretty much just doing CSS all day. I liked it, but probably what I did was create a terrible situation for whoever came after me. They still hated CSS, were bad at using it, but now had to maintain a lot of it. We probably should just have consented to the convenience of the majority even if (as I still maintain) they are wrong.

Things like CSS Zen garden made it seem like they were, but that was only a separation of control. If the HTML structure changes, then the CSS likely needs to change. That's a tight coupling.

CSS-in-js embraces the coupling and makes it explicit instead of implicit, which makes refactoring safer and speeds up development.

edit for typo

I agree both with your interpretation, and with the sentiment. I think, in many contexts, using the Cascading part of CSS is a mistake. It's great for low-level design system kinds of work (e.g. setting matching text and BG color, then override font size or decoration later). But, it's pretty problematic when you start styling specific components in a web app. (This is less of an issue with static documents).

If we're using SASS instead of a css-in-js, we end up doing things like:

``` .my-custom-hero { h1 { // override necessary styles } } ```

That's essentially the same encapsulation. It's just hidden in a one-off class in the CSS rather than embedded with the HTML - which makes it even less legible. It also has a dependency on the root-level `h1` styles. If someone change those, they inadvertently change the hero's styles.

We could get around that by having a `.my-custom-hero .my-custom-hero-title`. But, that's essentially a worse version of css-in-js encapsulation: I have to come up with names for everything, and my component's internals are split across multiple files.

I've done a lot of thinking about this - like "How would we adopt what we have done in frameworks into web standards"? And the closest I have come up with is Svelte.

In Svelte your file is a component. It can have a <script> tag which defines state that can be passed to it or any other arbitrary javascript. You can have a <style> tag which scopes specifically to that component. And the rest is just regular HTML markup with the ability to do light interpolation for dynamic values.

That's how it should be, in my opinion. That's what we should be moving towards as an industry. I think CSS-in-JS was a side effect of JSX being in JavaScript. Hopefully we are moving away from that trend now.

I don't find this to be the case with styled-components. To me styled components feels just like writing CSS (which I like), but with a slightly obscure variable syntax (if I need a prop or theme value).

This is an incredibly silly take. As a senior frontend dev with almost 20 years of experience and a solid resume, I will take Tailwind over anything else in most cases. Obviously there is always exceptions based on the project needs, but to have such a hard take like this just cracks me up at how narrow minded it is.

It doesn't enable you to do anything that CSS didn't already do. It's just a different way of writing it. Knowing CSS is a prerequisite to being able to use Tailwind.

"Tailwind is for beginners" just sounds to me like "I don't like this thing because I'm too smart for it"

Tailwind does not require knowing CSS. It'll get you around tailwind faster if you do know it, but you do not have to care about what Tailwind is really up to when adding "outline outline-2 p-4 outline-offset-2". This is a major reason why people pick it up in the first place, to ignore CSS as much as possible.

Where are do you so frequently see that being suggested? I would never suggest that and I've never seen anyone say something like that before.

Tailwind is not an alternative to CSS, it's a way of writing CSS.

Your HTML will be uglier and it will be more difficult to look at the elements panel to find the element you're looking for. Both of those things are super minor for me, and have almost no impact on my day-to-day.

Or, if you're using containers/writing components you can literally do something like this: https://pastebin.com/qkdzGWNT

But that a { could just as easily be "tag"

Personally, I've always found BEM to be tedious and the sort of "roll your own" class names just doesn't scale. This approach scales. This is what we should be moving towards as an industry.

If it's being asked repeatedly, it should probably be addressed somewhere. I see no mention of it in the tutorial or any of the amazing starter videos I've seen. I also have never used PostCSS directly before, so that's not an obvious solution. I appreciate the example you shared. I've asked (the OP in particular) in good faith, so I'm sorry that the question frustrated you.

> Personally, I've always found BEM to be tedious and the sort of "roll your own" class names just doesn't scale. This approach scales. This is what we should be moving towards as an industry.

Can you please elaborate on this? We've had well-functioning applications that predate Tailwind or CSS in JSS, so I'm not sure what doesn't scale. Descriptive names might get messy if you jam everything into in a single stylesheet, but using the cascading part works pretty well. If we're going to say "no, actually we were completely wrong when we said class names based on styles like 'red', 'big', and '2spaces' were bad", I'd like to understand what fundamentally changed. If it's just a case of convenience, that's fine. But, what about this scales better? How does this approach improve maintenance?

Your PostCSS example where you compose rules looks like a good approach, but I don't see that widely in use. Instead, I see the same rules repeated across elements in a document. That's the style the Tailwind docs use, so I'm operating under the notion that this is the prevailing way to write frontend code with Tailwind. While I can see that as an improvement over inline styles by ensuring consistent spacing definitions and such, that was never the recommended approach anyway. The style used in the Tailwind docs strikes me as being more problematic for ensuring consistency across pages or an app, which I see as hampering scalability.

Anyway, I'm trying to better understand why and how this shift is better. The only clear answer I've had thus far is that it's faster to get started because you get nice styles out of the box without having to adopt something like Bootstrap. That makes sense to me for small projects. At least I can see why someone would make that trade-off. I'm less clear on the long-term maintenance aspect and how utility classes help that.

https://tailwindcss.com/docs/reusing-styles#extracting-class...

"Whatever you do, don’t use @apply just to make things look “cleaner”. Yes, HTML templates littered with Tailwind classes are kind of ugly. Making changes in a project that has tons of custom CSS is worse."

Then it lists a bunch of reasons that seem to just be the author's preferences on things like naming and workflow productivity. I guess I don't think naming things is that hard. I generally need a name of some sort anyway so I can interact with the thing from JS. I haven't seen anyone argue not to use React or Web Components because naming a component is hard. I wonder if it's just a granularity thing. I tend to give a class name to a logical entity and then use ancestry selectors for nested tags, with SCSS mixins to avoid duplication.

With that said, I think it's reasonable to roll some things up into general classes. They remain very easy to change.

>I haven't seen anyone argue not to use React or Web Components because naming a component is hard.

I think the whole point is that that UI element, or "interface", or "component" is the thing that should have a name. That entity doesn't need to have a unique CSS classname.

Thanks for taking the time to clarify that for me. It does indeed change my perception on utility classes.

The point is that HTML elements don't need to have semantic class names at all. So even the top most element in the component would still use utility classes.

Also, I think I am wrong. It's possible to use Tailwind without implementing a build step like PostCSS, which would necessitate using it much like the documentation describes.

>We've had well-functioning applications that predate Tailwind or CSS in JSS, so I'm not sure what doesn't scale.

CSS has fallen victim to the same "cult of semantics" that HTML has, and it's disingenuous bullshit just like it is in HTML (mostly).

Yes, if you have someone who really cares and writes great CSS they will have everything broken out into custom variables and well designed and named classes. You still have the problem of how you scale that, right? After all, if you have a .card that is formatted one way on one page but laid out differently on another, you have to think up a different class name or refactor.

Enter BEM. Block, element, modifier. A consistent naming system for your large application. That is both subjective, requires a lot of extra mental bandwidth in a time when you're lucky if half the "front-end developers" you're working with know more than the basics of CSS to begin with.

I have seen some truly tortuous HTML that uses BEM classnames. It was awful.

So when I say it doesn't scale, it's that most large codebases end up with !important everywhere and z-index:9999999 etc...

So throw it out completely. Utility classes make sense when you accept that you are probably styling a component and that markup will be inserted everywhere the component is. You never have to think about what your class name should be, and if it makes sense, or if it conflicts with other scopes.

Yes, an HTML element with 15 classes is not ideal.

The example I posted would hopefully be the logical end (and is if you're using Svelte with PostCSS configured) - where we're no longer writing html documents full of elements and then a stylesheet styling them. Each discrete UI element has one document, markup, state and styling are tightly coupled, and it can be reused many times.

It gets rid of nesting being very important, it gets rid of having to write verbose media queries for responsive. It makes changing things really fast.

The part about Tailwind providing sensible defaults in terms of sizing, spacing etc... is just icing on the cake. The problem that Bootstrap had is that it tried to do too much. It came about in an era when doing layout in CSS was really hard. So it rolls its own stuff like modals, dropdown menus, grid etc... it also takes it upon itself to style actual HTML elements, which to me is a very poor choice. Including bootstrap will get you default styles for headings etc... but I believe in Tailwind it's all done through utility classes.

Tailwind doesn't do that. The focus is on removing semantics from styling. Look at the API surface: https://tailwindcss.com/docs/

There's a "Components" link, but that's to a paid resource showing common UI patterns built with Tailwind.

Of course, the trade-off is if you completely change the structure of that "component" you'll need to update any ancestry rules. But on the naming front, I'd need to come up with an identifier or logical class name to find the element in JS anyway, absent something like React that sort of controls the world.

If you haven’t read and understood the spec then like most people you don’t know CSS, which is fine. It’s not a question of knowing what say conic-gradient does, but how browsers use CSS in depth.

As a long term front-end dev who likes tailwind, I find this fairly offensive. Your second and third points sound like problems with CSS in general.

> Vanilla CSS using `:root` declaration, a fixed base size (using `rem` and `em`), CSS variables and `calc()` are SO powerful.

If I'm using tailwind on a project, I don't want more power. I want less. I want simple constraints that give me solid basic styling without constant adjustment. The adjustments I _do_ want to make should be easy. The options available should be good options, not all options. I don't feel like fussing with box-shadow for the umpteenth time to get something that looks nice, or poking at my margins or padding or gap until it works with the rest of the page. I don't want to come up with a grid system again, or a color set, or a bunch of variables to extract these from the custom classes so they see proper reuse and are easily available; I want them already done.

Before Tailwind came along I very often found myself just wanting to put some inline styling in various places. It's so much easier to just add some CSS to an element than having to think of a class name, think of where the best place would be to put the class, etc.

Unlike the yet-another umpteenth bespoke `.card-header__buttons .card-header__button--secondary` that no one can remember and create an umpteenth+1

Tailwind works great when your site/app is a collection of components

So why bother with a DSL like Tailwind over Component CSS/SCSS for example?

Everywhere I've seen CSS-in-JS used, everywhere it's people busy writing bespoke styles in every file.

https://stitches.dev/

I may run into the same issues as the other CSS-in-JS solutions (I only encountered stitch once, and not for a long period of time)

Doubly so when using TypeScript, as with Vanilla-Extract: https://vanilla-extract.style

The link literally has this:

``` export const className = style({ display: 'flex', flexDirection: 'column', selectors: { '&:nth-child(2n)': { background: 'aliceblue' } }, '@media': { 'screen and (min-width: 768px)': { flexDirection: 'row' } } }); ```

Which is indistinguishable from any other CSS-in-JS which has hundreds of these one-off things scattered everywhere. With a theme somewhere exposing another hundred or so variables of varing quality. And all these solutions basically converge on Tailwind (or other utility-first CSS approaches):

``` export const hero = style({ backgroundColor: vars.color.brandd, color: vars.color.white, padding: vars.space.large }); ```

is nothing more than `bg-brand color-white p-4`

But TypeScript support is definitely nice.

Re-typing/re-quoting:

--------

The link literally has this:

    export const className = style({
      display: 'flex',
      flexDirection: 'column',
      selectors: {
        '&:nth-child(2n)': {
          background: 'aliceblue'
        }
      },
      '@media': {
        'screen and (min-width: 768px)': {
          flexDirection: 'row'
        }
      }
    });

    export const hero = style({
      backgroundColor: vars.color.brandd,
      color: vars.color.white,
      padding: vars.space.large
    });

But TypeScript support is definitely nice.

----

    /// Define variants for a specific component, such as a button
    export const button = recipe({
      base: {
        borderRadius: 6
      },
    
      variants: {
        color: {
          neutral: { background: 'whitesmoke' },
          brand: { background: 'blueviolet' },
          accent: { background: 'slateblue' }
        },
        size: {
          small: { padding: 12 },
          medium: { padding: 16 },
          large: { padding: 24 }
        },
        rounded: {
          true: { borderRadius: 999 }
        }
      },
    
      // Applied when multiple variants are set at once
      compoundVariants: [
        {
          variants: {
            color: 'neutral',
            size: 'large'
          },
          style: {
            background: 'ghostwhite'
          }
        }
      ],
    
      defaultVariants: {
        color: 'accent',
        size: 'medium'
      }
    });

    /// Use in code
    <button className={
      button({
        color: 'accent',
        size: 'large',
        rounded: true
      })
    }>
      Hello world
    </button>

Notice how `button()` takes in certain properties and only those properties with their corresponding values (enforced by TypeScript). If you try to put in `button({ color2: 'testColor', ...})`, TS won't compile.

In this way, you can take the design team's ButtonSmall, ButtonLarge, NeutralButtonLarge etc and codify them into TypeScript such that you literally can't make a mistake. You simply can't do that in Tailwind, unless you use some outside plugin I assume.

(Note that VE also has a Tailwind-like atomic CSS API called Sprinkles, but since I don't like Tailwind I don't use this either).

[0] https://youtu.be/Gw28VgyKGkw?t=1867

I prefer a global set of styles and more specific selectors to override styles where needed. It may not work well on projects with many teams but for the projects I typically work on it's fine.

The thing with Tailwinf is that it already has a decent design syste encoded in its utility classes. It's very easy to slap a p-2 for a standardized padding than trying to remember what it was when you write the next component with `{ padding: 2 2 2 2 }`

> I prefer a global set of styles and more specific selectors to override styles where needed.

That's kinda what I mean. In all projects I've seen you have a global stylesheet with a bunch of classes that no one remembers, and hundreds of one-ofs in every component either reimplementing stuff from scratch or serving as an `!important` of sorts

As opposed to what? This is still an issue with any kind of utility class, where the alternative is inline styles or CSS-in-JS, both of which are substantially worse.

> Conflicting utility classes aren't clear, and sometimes the order cannot be trusted;

This is fixed in the IDE with tools like ESLint. I have VSCode setup to automatically reorder Tailwind classes, and it works great. (It even moves broken classes to the front of the list, so you can immediately identify if they're working or not)

> Replacing `p-4` with `p-4` will require you to replace its occurrence all over your app, sometimes affecting thousands of matches. And since there is no context to it, it'll be hard to JUST replace them where you would want them to.

This is an issue with CSS in general, especially CSS modules. Plus, if you use tailwind correctly (with @apply) you only have to update it once.

> Vanilla CSS using `:root` declaration, a fixed base size (using `rem` and `em`), CSS variables and `calc()` are SO powerful.

With tailwind, you still have access to `calc()` and variables with their bracket `[]` syntax. It's just much easier to do everything else.

"Whatever you do, don’t use @apply just to make things look “cleaner”. Yes, HTML templates littered with Tailwind classes are kind of ugly."

That is straight from the Tailwind docs: https://tailwindcss.com/docs/reusing-styles

Using @apply a lot just reinvents CSS; that's not the point of Tailwind.

I can write similar comments about the rest of your statements, but I think you're too narrow minded to accept any input so I won't bother.

I would say the documentation adequately responds to your complaints about re-usability then? Use a component, use the IDE, or use @apply. The notion about needing to change classes 1000 times for a small edit just isn't true (I've never had to do this w/ 2+ years of tailwind).

> I think you're too narrow minded to accept any input so I won't bother.

Making some sort of ad hominem attack about how I'm narrow minded is useless. I'd love to hear your input.

Yes, you can do this sort of thing in CSS and SCSS, but you're already using a templating language that can do this job, so why are you pulling in yet another tool (SCSS), or why are you requiring the mental context switch to yet another language and another file (CSS) when you can stay directly in template you're actually working on?

In other words, by removing CSS from the full stack of template language+programming language+HTML+CSS+JS, you reduce the cognitive overhead and context switching needed to actually get stuff done. If you add htmx you can also remove most of the JS too, thus reducing cognitive load even further.

I can't say I've really had many issues with git diffs or conflicting classes. I'm not entirely sure why you'd replace blanket `p-4` all over your app. Are you making some changes to the spacing in your design system? Why not change it globally and let it propagate?

I'd tend to agree with you that (S)CSS modules are a great improvement over the completely detached styling of the past, but I still think Tailwind has a lot to offer with its prebaked system and dead code elimination.

Like, I thought we were supposed to keep our content and styles separate, not mismatch them all together with a thousand utility class imports.

Basically it's a component-mindset; create some file with everything in it so that in the rest of the app you can just use `<MyButton>...</MyButton>`.

The `<MyButton />` file takes responsibility for everything it does (logic, handlers, markup, style).

However; this does not mean these files should grow large. Instead when things become too big (say over 250 LoC) you split up responsibilities by sub-components.

It's basically dividing problems in ever-smaller problems, but NOT by separating by technology (html/css/js).

Separation of concerns is horizontal slicing of the app architecture, components however slice the architecture vertically.

I'm not necessarily a big fan of Tailwind, but this is a total strawman. Nobody would advocate having one big file with thousands of repeated classes or something. Just like it would be a strawman against the use of css variables to say that you'll end up with a bunch of global variables used in thousands of places that become impossible to change because you can't be sure you won't break something unintentionally. And in the extreme cases where it does happen, the latter scenario is often much worse of a problem IMO than having too much repetition, you can always get clever with find and replace to get through repetition.

Tailwind works when you use it with a component framework, you're not getting rid of all abstractions completely you're just moving them all to a single layer within the component class.

But both approaches still make it possible to shoot yourself in the foot and end up with a mess of unmaintainable code if you don't abstract things well.

It lets me design things in browser in a way that nothing else I've ever used has. Precisely because of my CSS knowledge, I know how to do everything, it's just a matter of finding the class name for it (referenced post talks about having to look up docs a lot, I relate.)

There's also a lot of established UI patterns, so I don't have to reinvent the wheel. And I often do roll something up into a semantic class name when I know I'm going to reuse it a lot. For example, I have a .container that is a list of @apply'd tailwind classes. PostCSS gives a lot of flexibility.

But I mixed things. So I have media queries that affect that :root font size and that decreases the amount of element specific responsive work I have to do.

I should mention I'm also working in Svelte, which has the ability to scope local CSS at the component level. It's a delight. So I mix and match between utility classes and scoped (dynamic classnames get generated) styling.

Plenty of very experienced developers like it just fine.

But I will also say – you need to get over that. It's probably going to be ubiquitous, whether you like it or not. There is some justification for it, it offers some advantages for particular users and use-cases, and it's likely that those advantages are enough to outweigh the downsides in general use. It's not worse enough in the ways that matter. So I've embraced it in the past couple of projects and it's fine – at worst vaguely annoying, and I'm much happier not having to bother hating it any more. Life's too short.

I've been writing CSS since IE 5.5 and I was tired of the whole horrible mess. Tailwind goes against everything I learned about the reasoning and benefits of CSS' styled web page design. Tailwind is right. Tailwind is how CSS should have been.

I (and more importantly my customers) do no care about minor differences in padding, or that the markup looks ugly, or that it takes a few extra minutes to parse the git commit (made up for by massive time savings elsewhere). Tailwind gives you a quick way to get a design that looks good enough while maintaining control over the layout of the page.

Need something custom? No one is stopping you from writing your own classes to compliment the utility classes or from moving common combinations of utility classes into their own class.

https://vanilla-extract.style/

How much passion does your standard sun contain?

I wouldn't touch SCSS with a ten foot pole in 2022, especially not for React where literally any CSS-in-JS library is better, and I used to love SCSS.

I considered using it for a few projects but once I start I feel it too much work with no payoff.

You shouldn't use Tailwind if you don't already know CSS.

Take the example `block`. Ok so a junior FE dev is supposed to use this class without understanding CSS? How?! It just maps to `display: block;`. It hides literally none of the complexity.

That said -- you need to know the average amount of CSS to be successful using tailwind.

If it didn't hide any of complexity you'd be writing CSS.

There are plenty of people bumbling through with both.

But understanding the CSS is needed to use it reasonably well.

Adam Wathan, the creator of Tailwind

I started with Tailwind and as I learned CSS along the way. Obviously people will look up stuff on MDN when they are stumbling on terms they didn't know about.

The tailwind docs + tw-intellisense plugin [1] are pretty good, too. Especially since the extension shows the raw CSS behind the abstraction when you hover over a class name.

[1] https://marketplace.visualstudio.com/items?itemName=bradlc.v...

*EDIT* for the above.

What are some typical defaults that I should start with for things like margin, padding, font size? What sort of items should I be initializing in ::root then overriding later?

https://gist.github.com/bdougherty/404b4ca33dfdbff48614b454f...

https://necolas.github.io/normalize.css/

Design decisions, though, are ultimately up to your taste and judgement.

I use the word 'components' because that's familiar to people, but there is a related concept in most modern frontend frameworks. In this world, tailwind makes so much sense. If you do it right, there is very much less in the way of shared stuff that needs find-and-replacing and you're keeping all the information you need to see how something is going to render all in one place.

    <looks at TypeScript>

Then again, when I look at old projects I do find it extremely verbose and JSX makes me so much happier.