Colton Voege

Listen to Me Yap about AI on Better Offline w/ Ed Zitron!

2025-09-20T00:00:00Z

My last post went more viral than I could have expected! I got a lot of emails from people saying how much they appreciated my thoughts on the subject. I hope I made some people feel like they were not falling behind.

Ed Zitron (host of Better Offline and writer for Where's Your Ed At) invited me onto Better Offline to talk more about what AI is and isn't in coding. Pop over there to hear me yap more!

On Spotify

On Apple Podcasts

No, AI is not Making Engineers 10x as Productive

2025-08-05T00:00:00Z

A few months ago I went through a bit of a mental slump. I've always been confident of my abilities as an engineer, but I couldn't help but feel like my skills were falling hopelessly behind as I scrolled places like LinkedIn and Twitter. If these sources were to be believed, engineering had moved on from the medieval practice of typing code into an editor. Real engineers were now 10-100x more productive than I was. I'm writing this hoping to help others who are feeling similar anxieties.

I'm a skeptical person so I don't usually fall over myself immediately when I hear a claim like that. I usually roll my eyes in the same way I do when someone tells me a simple herbal remedy cures all disease. But the sheer volume these engineer productivity claims are reaching right now started to hit a nerve. What if I'm wrong? Will I miss the bus and become unemployable if I don't learn to use AI right now? After all, there are a lot of fancy words going around that distance the "AI" these people are talking about with the "AI" I was familiar with.

These people were using ✨agentic✨ AI. They were using ✨thinking✨ models that surfed the internet, ran tests, and corrected their own mistakes. Sure I popped into a chat window here and there and asked it to write some code, then promptly discarded most of the output once I got the idea that I needed. But these engineers were letting Claude fully take the wheel and had agents ripping 5 PRs for them while they made morning coffee. Was I becoming a dinosaur, an old man yelling at cloud?

Part of what made me feel so anxious was that it was entirely possible AI changed without me knowing it because I didn't use AI very much. Because I didn't like using AI that much. Reviewing code is vastly less enjoyable process than writing it. Had my stubborn desire to enjoy coding set me up to be left behind?

Diving In

Eventually I hit a breaking point and decided I simply had to dive in head first to AI coding. I tried Claude Code, Cursor, Roo Code, and Zed for their agentic coding promises. I started asking AI to write all sorts of code in all sorts of projects. I tried the different models and compared them. I even vibe coded a few things, not editing the code manually once.

And it was... Fine. Despite claims that AI today is improving at a fever pitch, it felt largely the same as before. It's good at writing boilerplate, especially in Javascript, and particularly in React. It's not good at keeping up with the standards and utilities of your codebase. It tends to struggle with languages like Terraform. It still hallucinates libraries leading to significant security vulnerabilities.

AIs still struggle to absorb the context of a larger codebase, even with a great prompt and CLAUDE.md file. If you use a library that isn't StackOverflow's favorite it will butcher it even after an agentic lookup of the documentation. Agents occasionally do something neat like fix the tests they broke. Often they just waste time and tokens, going back and forth with themselves not seeming to gain any deeper knowledge each time they fail. Thus, AI's best use case for me remains writing one-off scripts. Especially when I have no interest in learning deeper fundamentals for a single script, like when writing a custom ESLint rule.

Dark warnings that if I didn't start using AI now I'd be hopelessly behind proved unfounded. Using AI to code is not hard to learn. Obviously? Well, the AI coding community seems split on whether AI makes coding so easy a caveman can do it or that it requires an advanced, dedicated prompt engineer skillset. There are a few things you need to learn but they come quickly. You learn how to split up tasks into smaller pieces so the AI doesn't lose its mind late in the context window. Tools like Claude Code can do a bit of this themselves, even, though not always reliably. And you learn to identify when the AI is too far off and it's time to take the wheel.

A competent engineer will figure this stuff out in less than a week of moderate AI usage. Further, if AI is about to get 2x, 10x, or 100x better at any minute (as everyone keeps saying it will), then any lessons about how to use it now are moot for the future.

Every time I encountered AI working "just okay", it strangely made me more anxious, not less. It meant I couldn't find the spicy secret sauce that made everyone else so productive. I just didn't have what it takes: dinosaur, meet asteroid, thy name is AI. Eventually, a few things shook me out of this slump. One of those was this article from Ludicity, directly countering the claims of the AI pumpers. I write this article to share more things that helped me get out of the AI 10x engineer imposter syndrome.

The Math

Let's start by looking at the simple math of 10-100x productivity. 10x productivity means ten times the outcomes, not ten times the lines of code. This means what you used to ship in a quarter you now ship in a week and a half. These numbers should make even the truest AI believer pause. The amount of product ideation, story point negotiation, bugfixing, code review, waiting for deployments, testing, and QA in that go into what was traditionally 3 months of work is now getting done in 7 work days? For that to happen each and every one of these bottlenecks has to also seen have 10x productivity gains.

Any software engineer who has worked on actual code in an actual company knows this isn't possible. You can't compress the back and forth of 3 months of code review into 1.5 weeks. When you code review you:

Tag your reviewer
Hope they will get to it sooner rather than later (which will be tough because they are apparently code reviewing 10x as much code as before)
Context switch to something else while you wait
See a notification (perhaps immediately, perhaps 2 hours after your reviewer went offline for the day)
Context switch back to the review
Read their comments
Respond accordingly
Rinse and repeat.

This process can be made fairly efficient at a competent company with good standards and communication practices. But you're telling me you made this process 10 times as efficient to handle 10x the work? This simply can not be done.

The human processes involved in actual corporate software engineering have not changed significantly. Product managers might use ChatGPT to do "research" but they aren't suddenly pumping out ten times as many well vetted, well justified, well estimated stories as they did before. They can not do 10 user interviews all at once. The same goes for Designers and QA testers. Hiring 10x the number of PMs to keep up isn't feasible. Each hire has diminishing returns as network effects and bureaucracy take hold.

Even if we assume people mean only the actual code writing process is now 10-100x faster, we should still be skeptical of how this maths out. When you write code, how much of your time do you truly spend pushing buttons on the keyboard? It's probably less than you think. Much of your prime coding time is actually reading and thinking, often while waiting for compiling, a page refresh, or for tests to run. LLMs do not make rustc go faster.

What LLMs produce is often broken, hallucinated, or below codebase standards. The frequency of these errors go up with the size of the codebase. When that happens you have to re-prompt, which could instantly fix the problem or could be a huge waste of time. Or you can go in and fix the code yourself. But then you're back to measly 1x engineer status, perhaps worse if you've gotten so used to vibe coding you forgot how to code. If you're "embracing the vibes" and not even looking at the code produced, you're simply going to hit a productivity wall once the codebase gets large enough. And once you do you'll have to reckon with the complete lack of standards and proper abstractions.

I think sometimes people lose the scale of just how big a 10x improvement is. 10x is the difference between your mini-van and a record setting supersonic land jet. Imagine trying to drive your 10 minute commute down your city streets in a car that goes 600mph. Will you get to the other side of town in one tenth the time? No, because even a single 60 second stoplight will eat up your entire time budget. F1 cars slow down to mini-van speeds in basic turns. It turns out that most of any activity is not spent going at top speed.

100x productivity means you now do what used to be one year of work in two days. I shouldn't even need to touch the ludicrousness of numbers at that scale.

Do 10x Engineers Exist?

This debate isn't something I want to weigh in on but I might have to. My answer is sometimes, kinda. When I have had engineers who were 10x as valuable as others it was primarily due to their ability to prevent unnecessary work. Talking a PM down from a task that was never feasible. Getting another engineer to not build that unnecessary microservice. Making developer experience investments that save everyone just a bit of time on every task. Documenting your work so that every future engineer can jump in faster. These things can add up over time to one engineer saving 10x the time company wide than what they took to build it.

Work of this nature is not always available, so great engineers will only find themselves being 10x as productive in certain situations. At a certain point every engineer just needs to build features, which a great engineer might do twice as fast as a junior engineer, but they'll still hit the same bottlenecks as before. Flawed as story points are, I've never seen an engineer actually complete ten times as many as an average engineer consistently.

Notably, AI coding assistants do very little to prevent unnecessary work. On the contrary, AI often seems to encourage hastiness and over-building. When I ask architectural questions, it often recommends something that I realize is not necessary after a good night's sleep or a talk with a great engineer. All other things held the same, is a faster coder a better engineer? Yes, but it's not the 10x difference maker and it's hard to hold everything else constant. The more you focus on pumping out tasks as fast as possible the easier is to miss the important time savers that reduce total work.

So are the AI-posters lying or what?

I think the AI-posters are a mix of the following, in order of least to most malevolent:

Good-natured folks who are mismeasuring themselves and others
People heavily invested, personally or financially, in the success of AI (AI startup founders, investors, etc.)
Bosses outright trying to make their engineers feel precarious so they don't quit, look for other jobs, or ask for raises

The good-natured engineer with bad math skills

In my experience, AI delivers rare, short bursts of 10-100x productivity. When I have AI write me a custom ESLint rule in a few minutes, which would have taken hours of documentation surfing and tutorials otherwise, that's a genuine order of magnitude time and effort improvement. Moments like this do happen with AI. Many career non-coders have felt the magic in the first few days after spinning an app up with Lovable.

The problem is that productivity does not scale. I don't write more than one ESLint rule per year. This burst of productivity was enabled solely by the fact that I didn't care about this code and wasn't going to work to make it readable for the next engineer. If constantly writing ESLint rules became a core job requirement I'd sink the one-time cost to learn how ESLint internals work. After that, there simply wouldn't be a big difference in the time it takes to vibe code a rule vs. write it myself, especially when you add in the extra time to make my code human readable for when I come back to this file in 6 months.

Eventually every vibe coder reaches the point where the returns start heavily diminishing. Their site gets hacked and they need to actually sink the time to learn how security works. The app gets too big for context windows and things start looking and functioning inconsistently. Real frontend engineers who know what they are doing are hired to implement a consistent design system and UX.

There's also a lot of simple biases and blind spots that can cause a productivity illusion. If you leave the depths of big corporate for a startup you will genuinely be shocked at how much more productive each engineer is. It's easy to credit this to AI. Some people really enjoy the technological novelty of AI coding and when you are working in something new you often feel like you're doing more than you ever did. I know the first time I used Python I felt like I was "sipping rocket fuel", but, as with all other technologies, it always comes back down to earth.

I think a lot of the more genuine 10x AI hype is coming from people who are simply in the honeymoon phase or haven't sat down to actually consider what 10x improvement means mathematically. I wouldn't be surprised to learn AI helps many engineers do certain tasks 20-50% faster, but the nature of software bottlenecks mean this doesn't translate to a 20% productivity increase and certainly not a 10x increase.

Incentives matter

Look, I'm not an AI startup hater. If you want to plug OpenAI's API into your healthcare startup I might raise an eyebrow of concern over the risks, but I'd do the same for any startup desiring to move fast and break things in the medical field. My goal here isn't to say AI startup founders or investors are evil or even dishonest. My point is to say in the droll voice of your high school Econ 101 professor, "Incentives Matter".

If you are running an AI startup and every other AI startup is telling investors they are seeing 10x more productivity thanks to AI, the incentives are plain and simple: you should say the same publicly and privately. If your company is built on the back of AI, you are incentivized to sell AI as a miracle solution in every part of life. If you are an engineer and your boss asks you:

Hey, you're getting 10x the productivity thanks to AI, just like all the other engineers, right?

You are strongly incentivized to say yes. And when every other engineer also says yes for the same reason, that CEO isn't lying, they are just relaying what they heard.

What I'd like to stress to those feeling anxiety like me is that this is nothing new. CEOs are not unbiased sources. Executives have been claiming that everything from Agile to Meyers-Briggs have unlocked limitless productivity. There will always be a new synergistic buzzword on LinkedIn, don't let it get you down. In fact, stop scrolling LinkedIn at all. It's a silly place.

Outright Malice

When something is said that makes people feel anxious, at least some of the time you should conclude it's because that's what the speaker wanted to happen. Bosses trying to make their engineers feel like their position is precarious is also nothing new. We all remember the narrative that a 3 month coding bootcamp could churn out 4-year-degree quality engineers, so you'd best not get too uppity or you'll be replaced with a bachelor of arts doing a career pivot. Then a few years went by and people realized that bootcamp grads were usually woefully underprepared for actual software engineering since they were not given the proper foundation.

Bootcamps and AI are just examples in a long series of poorly born out threats to commoditize the highly expensive, highly professionalized field of software engineering. They are rhetorical devices designed to imply precarity. Your boss can't actually fire you and replace you with AI, but he can make you feel like he could, and maybe not ask for that raise.

Some amount of the 10x AI engineer story is likely being told by people who simply want you to feel bad for this purpose. How much of it, I don't know. Despite how highly distrustful we've become of each other in these times, I still believe most people are fundamentally decent, so I'm not inclined to believe it's a high percentage.

Degrees of separation

One thing I've noticed about all these characters in AI coding hype pieces is there is almost always a degree of separation from the writer to the actual productivity benefits. The poster is a founder, or a manager, or an investor, making grandiose claims about someone else's productivity. There's nothing wrong with secondary sources but if you can't find a primary source, you might start questioning the reliability of the information.

Presentations from actual engineers demonstrating how they achieve more productivity with AI are much more varied and much more muted in their praise. These demos show largely AI as the same technology you and I were familiar with before we got so anxious: a neat text generator that sometimes does magic but often requires you to take the wheel.

AI usage on open source projects, where the productive process can be publicly witnessed, has famously been a hilarious failure. I have learned things about how to use AI better from a few youtube videos. Here's a good one referenced in that Ludicity article above. I'll spoil it for you though, this engineer has not found the fountain of coding productivity.

It's okay to be less productive

Even after I got over the idea that there was a secret clade of engineer who was now ten times as productive and strong and tall and sexy as I was, I still felt some anxiety over the fact that I still didn't enjoy using AI very much. Vibe coding is a complete bore once the magic wears off. Reading LLM generated code sucks. Asking it politely to use a not hallucinated library is painful. But what if I was, despite all that, 20% more productive vibe coding than regular coding? Would it be wrong for me to do "normal" coding if a higher output path is available?

No. It's okay to sacrifice some productivity to make work enjoyable. More than okay, it's essential in our field. If you force yourself to work in a way you hate, you're just going to burn out. Only so much of coding is writing code, the rest is solving problems, doing system design, reasoning about abstractions, and interfacing with other humans. You are better at all those things when you feel good. It's okay to feel pride in your work and appreciate the craft. Over the long term your codebase will benefit from it.

It doesn't matter if digital music sounds objectively better than vinyl. It doesn't matter if flipping the record is less "productive" than letting the streaming service automatically roll over to the next song in 100x less time. If listening to a 70 year old disk makes you happier, just do it. You'll listen to more music if you do that than you would by forcing yourself to use the more "productive" streaming service. You will spend more time writing code and you'll write better code if you do it the way you like to.

Oh, and this exact argument works in reverse. If you feel good doing AI coding, just do it. If you feel so excited that you code more than ever before, that's awesome. I want everyone to feel that way, regardless of how they get there.

How to be a good AI leader

Making all your engineers feel constantly anxious about their performance is bad for your company. It will make your engineers not want to work for you. This is a recipe for short term thinking that will encourage engineers to max out bad metrics, like lines of code. Code review will get neglected, tech debt will compound, and in the long term the whole company will be footing the bill of those errors.

Unrealistic 10x expectations will result in rushed and thus subpar work without fail. Engineers need to have room to breathe. Room to take a little bit more time to do the thing right. Good codebases and good companies are built on a healthy balance of thinking for today and tomorrow. I'm thankful to work at one of these companies right now, but many aren't so fortunate.

Do not scold engineers for not using enough tokens. Your engineers are highly educated professionals in an extremely competitive field. Software engineers are already infamous for an over-eager cycle of embracing and abandoning new languages and tools. If you are paying these people this much, you should have the trust in them that if a super amazing productivity boost becomes available, they'll come to you asking for the pro plan. If you're worried about missing out on all the AI coding gains everyone else seems to be getting, sign up for a LLM team plan, host a training session, and see what comes out of it. That's all you need to do.

Conclusion

There is no secret herbal medicine that prevents all disease sitting out in the open if you just follow the right Facebook groups. There is no AI coding revolution available if you just start vibing. You are not missing anything. Trust yourself. You are enough.

Oh, and don't scroll LinkedIn. Or Twitter. Ever.

Tailwind is the Worst of All Worlds

2025-07-21T00:00:00Z

Tailwind is the worst of all worlds. It is a regrettable step backwards that takes everything bad about CSS and modern web development and brings it all together in one library.

CSS's Successes and Failures

Of all the web technologies that underlie the modern web, the one that has received the fewest fundamental changes is CSS. We've gotten amazing things like flexbox, grid, container queries, and more which have supercharged the ability to quickly build responsive styles. While we're far from the days of using tables for layout and googling "how to vertically center css" once a week, the language semantics themselves hasn't had to change much. This is because CSS offers two well rounded ways of applying styles that work pretty well: inline styles and stylesheets.

Inline styles let you quickly add targeted rules to a single element. Much maligned historically due to the fact that many abused them and thus failed to keep their code DRY, there's really nothing wrong with inline styles. If there is something wrong with them, it's simply that an HTML attribute is a kind of clunky place to write out styles. They'll wander off screen on your editor once you have enough rules and it's harder to get nice formatting or static analysis. But if you're a good developer you won't use inline styles this way very often. (This is what we call foreshadowing).

Stylesheets are the much more powerful feature. They let you assign a set of rules to zero, one, or many elements at once with the minimum amount of code. They also include all the fancy features like media queries, container queries, and pseudo-elements, which are not available inline. Flaws that existed in the early days of stylesheets have largely been remedied, albeit not always in the most desirable way. SCSS variables had broader support (since they simply compiled to basic CSS) and were prettier than CSS variables, but eventually SCSS started losing steam in the face of an improving CSS.

CSS definitely isn't perfect. Like JavaScript's == operator, some ideas were bad then and are still bad now. CSS chooses which styles overwrite others based on selector specificity, leading some style debugging to be a bit of a rat's nest where the developer ends up bailing out to !important tags, which just kick the can down the road. Worse yet, when two rules have the same specificity, the default functionality is to pick whichever is defined last in the stylesheet. So, in this example, the styles of two win out over one, because the .two rule is declared after the .one rule, even though the one class comes second on the div.

<style>
.one {
	text: red
}
.two {
	text: blue
}
</style>
<div class="two one"></div>

With modern multi-sheet websites and bundlers, this can get confusing fast as it can be hard to keep track of which sheet was loaded first on every page.

Additionally, CSS's status as a separate language from JavaScript is a blessing and a curse. It's a blessing in that CSS can be downloaded, parsed, and rendered in parallel extremely quickly by modern browsers, sidestepping the single-threadedness of JavaScript. But a curse in that modern apps simply require some amount of JavaScript-CSS interop since CSS is not a general purpose language. Sharing variables to keep styles consistent betweent he two means duplicating code between the two languages.

Much of these problems are solved with modern tooling, albeit often with their own caveats. Tools like styled-components brought JS and CSS together fairly seamlessly, giving you all the power of JavaScript (functions, etc) in your CSS. The caveat is that styles are compiled into Javascript (slow, single threaded) rather than CSS (fast, parallel). Tools like vanilla-extract have done an admirable job giving you fully typed CSS-in-JS-in-CSS, compiling JS created styles into CSS files. Lastly, tools like React have made inline styling much better with objects that are linter, type system, and formatter friendly.

Okay, now can we dunk on Tailwind?

For reasons we'll get into later, Tailwind decided to burst on to the scene and become the default styling solution for all modern web development despite taking each and every one of these problems, exacerbating them, and applying them to places that didn't have them before. Lets see how Tailwind replicates CSS's main paradigms. Remember, inline styles let you control single element styles simply and fairly explicitly: style="background: red; color: blue;". Classes let you control multi-element styles simply, with the slight annoyance that it's easy to misspell your class name and spend way too long debugging before realizing it: class="todo-item".

Tailwind exclusively offers inline styles via classes. Classes are single strings separated by spaces, not key-value pairs. So the classes must be something like class="bg-red txt-blue". Key and value must be obscured into a plain string, lowering readability and writability. If you misspell one of these plain strings your editor is not going to tell you. You'll just have to find out once you get into the browser. Did you notice that txt-blue is wrong, and it should actually be text-blue? No? Get used to it, you'll make that mistake daily because Tailwind is inconsistent in how it names things.

Rule sets

What about applying a set of rules to multiple elements, as you do in style sheets with class rule sets, what does Tailwind offer for that?

Nothing. The answer is nothing. Tailwind's official recommendation for this is to ignore everything you've ever learned about constants and duplicate your class names. Then simply remember to always use multi-cursor editing any time you touch them:

You can, of course, disobey the Tailwind overlords and create constants or components, but those solutions end up clunky because you are dealing purely with strings instead of objects. An element with a mere 10 CSS rules, will inevitably wrap in your editor and be more difficult to read and extend than a simple object would be:

const sharedClass = `mx-auto max-w-md overflow-hidden rounded-xl bg-white shadow-md text-black border border-black border-solid`;
return <div className={
	clsx(sharedClass, {'display-none': !visible})
}></div>

vs.

const sharedInline = {
	marginLeft: 'auto',
	marginRight: 'auto',
	maxWidth: MEDIUM_WIDTH,
	overflow: 'hidden',
	borderRadius: EXTRA_LARGE_ROUNDED,
	background: 'white',
	boxShadow: MEDIUM_BOX_SHADOW,
	color: 'black',
	border: '1px solid black',
};
return <div styles={{
	...sharedInline, display: visible ? 'block' : 'none'
}}></div>

CSS's Problems are Tailwind's Problems

Tailwind offers no solution to the built in problems of CSS. Tailwind classes are generated dynamically outside of your purview by the bundler and thus make it even harder to understand who will win a specificity conflict. For example:

<div className={clsx('text-red bg-blue', {
	'text-blue bg-red': currentPage === activePage
})}></div>

This seems straightforward. Red when inactive, blue when active, right? Nope. Which class comes first in the generated stylesheet is not predictable. Tailwind's recommendation is to, once again, ignore basic coding principles and recommend you duplicate your business logic:

<div className={clsx('text-sm', {
	'text-red bg-blue': currentPage !== activePage
	'text-blue bg-red': currentPage === activePage
})}></div>

As a result, tailwind developers fall back on the same trick as the CSS developers of yore: spamming important tags (in the form of ! suffixes on their class names) every time things don't work out nicely.

Did you really say bundler?

Yes. Despite offering no real solutions to CSS's problems and instead making them worse, Tailwind requires a plugin and a bundler to function. It can not be simply dropped into a plain web page. This bundler is doing code processing so basic it's almost admirable. It simply searches all your files and looks for things that look like Tailwind classes, and then it makes a CSS class rule set for each one.

The oft-touted benefit of this system is that Tailwind will minimize your bundle sizes by only including what you need. Unfortunately this benefit does not hold up to basic scrutiny on medium-to-large codebases. By the time your codebase gets big enough to actually worry about how much CSS you have, you will have one class for every individual possible CSS rule you'll ever use. Still, this isn't much of a problem since CSS loads in parallel and it loads fast.

The problem is what it does to your JavaScript bundle sizes. Tailwind expects you to define styles via several classes on basically every element in your codebase. Meaning every time you use it you are writing out long strings which increase your slow, single-threaded, fully blocking JavaScript bundle size. Consider the following simple example with plain CSS:

.todo-item {
	color: var(--warning-color);
	background: blue;
}

<div className='todo'>1</div>
<div className='todo'>2</div>
<div className='todo'>3</div>

And this one with tailwind:

// CSS (Generated by Tailwind)
.text-warning {
	color: #ffcc00;
}
bg-blue: {
	background: blue;
}

<div className='text-warning bg-blue'>1</div>
<div className='text-warning bg-blue'>2</div>
<div className='text-warning bg-blue'>3</div>

In this simple but common example, tailwind generates a larger CSS bundle and a larger JS bundle! Lets give Tailwind the benefit of the doubt and say the codebase designed around the first style, with plain CSS classes, is going to end up with more CSS due to the same rules being duplicated across different selectors. That color: var(--warning-color) rule may be repeated hundreds of times in a mature codebase. This will generate more CSS. But that's just fine.

CSS bundle size matters an order of magnitude less than JavaScript bundle size. On the React projects that Tailwind is typical on you will be writing your CSS in className attributes. That means hundreds of repeats the string txt-warning strewn about your JSX files. This is increasing your Javascript bundle size, halting your entire app while that larger file is downloaded, parsed, and run.

Developer Friendliness

Tailwind does nothing to reduce the mental load on your developers to understand, read, and write in your codebase. In fact it does the opposite. Your developers are not spared the hassle of learning CSS by instead learning tailwind's abstractions. Developers have to understand not just that background-color is the CSS key to set a background color, but they also must understand that classes prefixed with bg- mean background color. Every feature of CSS, such as media and container queries, will need to be learned twice, CSS style and Tailwind style.

Tailwind offers no type safety and little in the way of developer tooling outside of editor extensions that let you hover over a class to see the actual CSS that it translates to. Writing code with Tailwind means constantly hovering your cursor over class names and waiting a moment to see that your class translates to align-items: center. And when no hover comes up you know you mistyped (or your VSCode extension crashed) and now you have to Google "tailwind flexbox align items center" to remember it's not align-items-center or even align-center, it's items-center. All problems in tailwind must be solved this way.

When Tailwind does a major version update, it will sometimes rework its class names a bit. Every time this happens you need to use the codemods that Tailwind distributes with each update. These can only do so much to understand your codebase and realize what is a tailwind class and what is a plain string so you have to review every one of the thousands of changes carefully. This is entirely a manufactured problem for Tailwind. When other libraries change APIs they can make the process straightforward through type systems, deprecation warnings, and clear error messages because they did not decide to base their entire library on parsing arbitrary strings.

But what about using media queries inline?

One decent thing about Tailwind is the relative ease with which CSS's "stylesheet only" features can be accessed inline. For example you can set up a CSS rule that only applies to an element on large screens with the simple matter of prefixing that class with lg:. This is something that is annoying to do in raw CSS. However, every other CSS-in-JS tool I've used also offers a convenient way to do the same. More importantly, those solutions scale better. If you have five rules that should be different on large screens, you must write lg: five times and hover each one to make sure it's working. In a tool like vanilla-extract you would define one type checked media query with all your type checked rules underneath.

There are some things that Tailwind simply can not do and in this case developers simply fall back to plain CSS or inline styles with JavaScript. Meaning that, once again, the mental load of understanding the codebase is increased. You need to understand not only that you might be reading tailwind classes or plaain CSS classes and you'll need to track down where those are in your stylesheets when you do.

Do you see what I mean when I say the worst of all worlds?

Okay, so why does everyone use tailwind if it's the worst of all worlds?

There are only two kinds of languages: the ones people complain about and the ones nobody uses.

I think the most important factor in Tailwind's success is that it does one thing very correctly: it demands the developer who installs it set up a config file that lays out all codebase-wide style constants: colors, margin sizes, fonts, border radii, etc. Writing individual styles that do not use a pre-configured constant from the config file is clunky in Tailwind. This is a good thing, an unironic win for Tailwind. More than anything else, this is what a large codebase with multiple frontend devs needs: a rigid set of global constants that everyone is strongly incentivized to use.

I believe this is where Tailwind has succeeded and other libraries have struggled. Libraries like vanilla-extract are legitimately great. But when I set up vanilla-extract in a new codebase I have to set up my own structure for global constants and make sure everyone is importing from that. For me, this works: I like to set up my own structure. I like having Javascript available in those files, for example to generate colors by inverting or tinting other colors. But creating this kind of structure requires foresight and discipline to do it right and ensure it is followed. You must write docs and every developer must read and understand them.

Since Tailwind has a single magical config file that instantly makes all items inside it globally available, the documentation of how constants work is outsourced to the tailwind docs. Questions of "why do we structure our constants this way?" can be answered simply: that's just how Tailwind works. There's no room to bicker about little things, the way we all used to quarrel about where the line breaks should be before prettier came along and let us defer that decision making to the tool. This is great. I like that I no longer format JS manually and I like that I rarely see one-time-use colors in tailwind.

Most companies adopting Tailwind do so because it offers an out of the box solution for a lack of standards and consistent colors. I think there are better libraries than Tailwind. Libraries that lead to smaller file sizes and better consistency. But to succeed some of these libraries may need to start being more authoritative. I love that vanilla-extract lets me do my own thing, but providing an easy to use default structure, that can be replaced if desired, would help adoption.

Lastly, Tailwind has also been buoyed by being by being the default styling that just about any LLM or vibe coding tool will produce unless it is explicitly asked not to. This feels like both uncharted and charted territory. Plenty of developers started using jQuery because the first StackOverflow result in their search explained how to solve that problem with jQuery.

But today we have a much larger set of decisions about codebase design being made all at once by a single tool. Developers who outsource these crucial decisions to LLMs are going to keep getting the worst of all worlds once the codebase becomes to unwieldy for vibes and needs actual developers.

So what's the best of all worlds?

I like vanilla-extract. It's a fairly light type safe abstraction that gives you CSS in JS in just about the best way. It's not the best of all worlds but it's great at almost everything. I also don't mind writing apps with plain CSS, though this has problems as it can get hard to keep track of which styles are applying to what. I've also written decently sized apps purely using inline styles in React with some basic constants and it works pretty well, though that too has problems like the lack of media queries and increasing JS bundle size. My point here isn't to say that there is a best of all worlds. My point is to say that Tailwind is the worst of all worlds.