Tailwind Labs relied on a weird monetization scheme.
Revenue was proportional to the pain of using the framework. The sudden improvement in getting desired UI without relying on pre-built templates killed Tailwind Labs.
There are many initiatives in a similar spot, improving your experience at using Next.js would hurt Vercel.
Making GitHub actions runners more reliable, stable and economical would hurt Microsoft.
Improving accessibility to compute power would hurt Amazon, Microsoft and Google.
Improving control and freedom over your device would hurt apple and Google.
Why should we be sympathetic to the middleman again?
If suddenly CSS became pleasant to use, Tailwind would be in a rough spot. See the irony?
"Give everything away for free and this people will leave technology", geohot said something like this and I truly appreciate. Technology will heal finally
> If suddenly CSS became pleasant to use, Tailwind would be in a rough spot.
CSS is pleasant to use. I know I find it pleasant to use; and I know there are quite a few frontend developers who do too. I didn't pay much attention to tailwind, until suddenly I realized that it has spread like wildfire and now is everywhere. What drove that growth? Which groups were the first adopters of tailwind; how did they grow; when did the growth skyrocket? Why did it not stay as niche as, say, htmx?
People like tailwind because it feels like the correct abstraction. It helps you colocate layout and styling, thereby reducing cognitive load.
With CSS you have to add meaningless class names to your html (+remember them), learn complicated (+fragile) selectors, and memorise low level CSS styles.
With tailwind you just specify the styling you want. And if using React, the “cascading” piece is already taken care of.
The point of CSS is specifically to separate styling and semantics, so that they are not tightly coupled.
If you were writing a blog post you would want to be able to change the theme without going through every blog post you ever wrote, no?
If I'm writing a React component I don't want it tightly coupled to its cosmetic appearance for the same reason. Styling is imposed on elements, intrinsic styles are bad and work against reusability, that's why we all use resets is it not?
I do agree that the class name system doesn't scale but the solution is not to double down on coupling, but rather to double down on abstraction and find better ways to identify and select elements.
Content should come from your database, Markdown, JSON, models etc.
Presentation is determined by the HTML and CSS together.
So your content and presentation is already separate enough to get the benefits. Breaking up the presentation layer further with premature abstractions spread over multiple files comes at a cost for little payback. I'm sure everyone has worked on sites where you're scared to make CSS file edits because the unpredictable ripple of changes might break unrelated pages.
Styling code near your semantic HTML tags doesn't get in the way, and they're highly related too so you want to iterate and review on them together.
I've never seen a complex website redesign that didn't involve almost gutting the HTML either. CSS isn't powerful enough alone and it's not worth the cost of jumping through hoops trying because it's rare sites need theme switchers. Even blog post themes for the same platform come with their own HTML instead of being CSS-only.
> If you were writing a blog post you would want to be able to change the theme without going through every blog post you ever wrote, no?
Tailwind sites often have a `prose` class specifically for styling post content in the traditional CSS way (especially if you're not in control of how the HTML was generated) and this is some of the simplest styling work. For complex UIs and branded elements though, the utility class approach scales much better.
> I'm sure everyone has worked on sites where you're scared to make CSS file edits because the unpredictable ripple of changes might break unrelated pages.
CSS gives you multiple tools to solve this problem, if you don't use any of them then it's not really CSS's fault.
> Styling code near your semantic HTML tags doesn't get in the way
It does. When I'm working on functionality I don't want to see styles and vice versa. It adds a layer of noise that is not relevant.
If I'm making e.g. a search dropdown, I don't need to see any information about its cosmetic appearance. I do want to see information about how it functions.
Especially the other way around: if I'm styling the search dropdown I don't want to have to track down every JSX element in every sub-component. That's super tedious. All I need to know when I'm styling is the overall structure of the final element tree not of the vdom tree which could be considerably more complex.
> I've never seen a complex website redesign that didn't involve almost gutting the HTML either
Perhaps for a landing page. For a content-based website or web app you often want to adjust the design without touching your components.
> I've never seen a complex website redesign that didn't involve almost gutting the HTML either. CSS isn't powerful enough alone
I recognize your experience. But I would also like to argue that good semantic CSS class names require active development effort. If you inherit a code base where no one has done the work of properly assigning semantic CSS names to tags, then you can't update the external stylesheet without touching the HTML.
https://csszengarden.com/ shows how a clean separation between HTML and CSS can be achieved. This is obviously a simple web site and there is not much cruft that accumulated over the years. But the principles behind it are scalable when people take the separation of content and representation seriously.
I'll add to my sibling commenters and say that there is a long history of critiquing the value of separation of concerns. One of my favorite early talks that sold me on React was "Pete Hunt: React: Rethinking best practices -- JSConf EU" from Oct 2013 [1] that critiqued the separation of concerns of HTML templates + JS popular in the 2000s and early 2010s and instead advocated for componentization as higher return on investment. I think people already saw styling separation of concerns as not particularly valuable at that point as well, just it wasn't clear what component-friendly styling abstraction was going to win.
I do want styles tightly coupled to my React components. The product I work on has tens of thousands of React components.
I don't want to have to update some random CSS file to change one component's appearance. I've had to do this before and every time its a huge pain to not affect dozens of random other components. Other engineers encounter the same challenge and write poor CSS to deal with it. This compounds over time and becomes a huge mess.
Having a robust design system that enables the composition of complicated UIs without the need for much customization is the way.
Front end development got taken over by the Enterprise Java camp at some point, so now there is no html and css. There’s 10,000 components, and thus nothing that can be styled in a cascading way.
All these arguments are just disconnects between that camp and the oldskool that still writes at least some html by hand.
When I get sucked into react land for a gig, it starts making sense to just tell this particular div tag to have 2px of padding because the piece of code I’m typing is the only thing that’s ever going to emit it.
Then I go back to my own stuff and lean on css to style my handful of reusable pieces.
I think the problem is simply that css is too restricted that you can style a fixed piece of html in any way you want. In practice, achieving some desired layout require changing the html structure. The missing layer would be something that can change the structure of html like js or xslt. In modern frontend development you already have data defined in some json, and html + css combined together is the presentation layer that can't really be separated.
You’re kinda late to the party. 15 years ago that was the way to build UIs, but componentization changed that. Now we reason about UIs as blocks, not as pages, so collocation of logic, markup, and style makes the most sense.
Not to say that every component should be unique, generic components can be built in an extensible way, and users can extend those components while applying unique styling.
Theming is also a solved issue through contexts.
Reducing coupling was never a good idea. Markup and styling are intrinsically linked, making any change to the markup most likely will require changes to the styling, and vice versa. Instead of pretending we can separate the two, modern UI tools embrace the coupling and make building as efficient as possible.
In the webdev world being late is the same as being early. Just wait for the pendulum to swing back.
Tailwind is like GenZ has discovered the bgcolor="" attribute.
> Markup and styling are intrinsically linked, making any change to the markup most likely will require changes to the styling, and vice versa.
No, not vice versa. It's only in one direction. Changing the component requires changing styles, but changing styles doesn't require changing the component if it's merely cosmetic. If I have a button and I want to make it red the button doesn't have to know what color it is.
There’s nothing “gen z” about Tailwind, and there’s no pendulum effect either, and dismissing the very real benefit thousands of people report from Tailwind based on that is very small minded.
That kind of lack of intellectual curiosity is not a great trait for an engineer.
> The point of CSS is specifically to separate styling and semantics, so that they are not tightly coupled.
That was the original point, and it turned out that nobody cares about that 99% of the time. It's premature optimization and it violates "YAGNI". And in addition to not being something most people need, it's just a pain to set and remember and organize class names and organize files.
Remember CSS Zen Garden from the late 90s? How many sites actually do anything like that? Almost none.
And the beauty of Tailwind is, when you actually do need themes, that's the only stuff you have to name and organize in separate CSS files. Instead of having to do that with literally all of your CSS.
Not only does no one care, but it's not even true. There are effects you simply cannot achieve without including additional elements. So separation of styling and sementics is dead on arrival.
You're talking about separation of concerns (SOC), as opposed to locality of behavior (LOB).
This is the insight that Tailwind and others like HTMX made clear: Separation of concerns is not a universal virtue. It comes with a cognitive cost. Most notably when you have a growing inheritance hierarchy, and you either need 12 files open or tooling that helps you understand which of the 482 classes are in play for the specific case you’re troubleshooting. Vanilla CSS can be like that, especially when it’s not one’s primary skillset. With Tailwind you say ”this button needs to be blue”, and consolidate stuff into CSS later once the right patterns of abstraction become clear. Tailwind makes exploratory building way faster when we’re not CSS experts.
SOC is usually a virtue when teams are split (frontend/bavkend, etc), but LOB is a virtue when teams are small, full stack, or working on monoliths (this is basically Conway’s law, the shape of the codebase mirrors the shape of the team).
People who have tried both throughout their careers are generally sticking with Tailwind. I didn’t get it at first either, but after using it extensively I would never go back to the old way.
Those are the same selling points as CSS-in-JSS libs like Styled Components. Or CSS Components.
Except your last point about "low-level CSS styles" which I'd argue is a weak point. You really should learn the underlying CSS to gain mastery of it.
Not arguing for one thing over another, just saying Tailwind really never had anything to offer me personally, but maybe if I wasn't already proficient in CSS and the other 2 options didn't exist it might hold some appeal for me.
It’s more about cognitive load, and abstraction level. If you’re trying to make an object spin, it’s much easier to use the tailwind class than it is to remember css keyframes.
Sure, when debugging a complex issue, it’s worth knowing the low-level, but CSS is not a great abstraction for day-to-day work.
You’re right that it’s not much more than a css in js library, but I’ve found myself pleasantly surprised at how efficient I am using it, despite also having years of css experience.
Things like remembering what the flex syntax is, or coming up with a padding system or a colour scheme become very very easy.
I think the editor tooling for tailwind is where most of the benefit comes from.
I also prefer the syntax over direct css in js systems. It’s less characters, which means it’s easier to parse.
Imo CSS is not pleasant to use, but Tailwind is at least as bad and furthermore is bad in addition to the CSS badness which it does not fully replace. It is a mystery to me as well how it got so popular.
(I know many people disagree, which is fair enough.)
Debugging CSS nowadays is way easier than even 5 years ago. There are a lot of cool browser debugging tools for animations, z-indexes. The browsers have come a long way since firebug. Definitely look into both chrome or firefox, their tooling is great. Especially firefox, they have debugging tools where you can create css shapes in the browser and save them. Very handy for those artsy fartsy sites.
I used plain CSS for more than a decade and felt the benefits of Tailwind within 10 minutes of getting started. What fueled the growth of Tailwind is that it makes web development palpably easier.
I first took a css courses to get the basics then didn’t do much with it, then tailwind came out. I had used bootstrap, but always struggled to get stuff to look nice. I’m not doing web dev most of the time. So it was much easier to memorize tailwind utility classes than css. These days with ui frameworks like daisy, shadcn, tailwind is pretty easy for doing something simple for an IT dev tool but still customize it.
For creativity, I wished I had the time to get really good with css. It really seems to have grown a lot. Using sveltekit, its really easy to get component scoped css
It lets you apply styles to a single element without it messing up the whole rest of the page/site/app. i.e. it disabled the primary feature of CSS, the thing most people don't want from it.
I agree that the primary feature of CSS is what people don't want from it anymore. If you're building your app with components (web components, react, etc), those become the unit of reuse. You don't need CSS to offer an additional unit of reuse, it only complicates things at that point.
This is technically true, but misses the point. Tailwind classes are fine grained utility classes, the fact that they are CSS classes at all is pretty much an implementation detail.
Compare tailwind classes to bootstrap classes and you'll see what I mean.
Why do people prefer it over CSS modules? They also solve the style containment problem, and do not require any effort to set up, or any additional library to learn?
You're probably confusing something with something?
CSS Modules are a JS-only third party solution re-invented/re-implemented in a dozen different ways for various JS frontend frameworks. Requires setting up, requires learning an additional library.
If you mean these CSS modules: https://github.com/css-modules/css-modules?tab=readme-ov-fil... then they need to be supported by whatever build chain you use. And you literally need to use them slightly different than normal CSS. E.g. for Vite yuo need to have `.module.css` extension. And they often rely on additional libraries to learn. E.g. you can enable Lightning CSS with aforementioned Vite which comes with its own CSS flavour: https://lightningcss.dev/css-modules.html
If you mean CSS import attributes, they only appeared in 2024 in Chrome and Firefox, early 2025 in mobile Android etc. and they don't provide magical local scoping out of the box: https://caniuse.com/wf-css-modules
I meant the CSS modules that are implemented by a build tool. And yes, mea culpa, they are probably a js-only solution, requiring a build tool to correctly interpret a css import (.module.css in the file name is a common convention; but it is tweakable), and the author to use the imported object instead of plain strings, when referring to the class names. But I don't know if having to write `class="styles.foo"` as opposed to `class="foo"` counts as learning. And apart from that, there isn't anything else to learn.
But, given that one would need build tools for tailwind as well, the requirement for build tools couldn't have played a role in the choice between the two.
The problem is having to look in a different file for styling a component, and having to come up with a name for (at least one) CSS class per component. In traditional CSS, classes are intended to be reusable. You write a class definition once, and then use it in a bunch of different elements.
When working with a component-based UI (like in React), the components are typically the unit of reuse. Those CSS classes are used in one place: the component they're defined for. It's annoying to have to come up with a name for them, and to have to work in a separate file, especially if I just want `padding-inline: 4px` or `display: flex`.
Some argue separation of concerns, but CSS is inherently tightly coupled to the structure of your HTML: there's no getting around that. `.foo > ul` breaks if you replace that `ul` child with an `ol`.
I do agree that more intricate styling is harder to read with Tailwind, and I have some other gripes, too, but in general it's a good trade-off for component-based UIs.
> CSS Modules are a JS-only third party solution re-invented/re-implemented in a dozen different ways for various JS frontend frameworks. Requires setting up, requires learning an additional library.
I mean, Tailwind is not that different here - you must use a build tool to tree shake the styles, etc.
The above is an unrealistic example, but, you can't achieve that with the style attribute. You'd have to go into your stylesheet and put this inside the @media query for the right screen size + dark mode, with :hover, etc.
And you'd still need to have a class on the element (how else are you going to target that element)?
And then 6 months later you get a ticket to change it to blue instead. You open up the HTML, you look at the class of the element to remind yourself of what it's called, then you go to the CSS looking for that class, and then you make the change. Did you affect any other elements? Was that class unique? Do you know or do you just hope? Eh just add a new rule at the bottom of the file with !important and raise a PR, you've got other tickets to work on. I've seen that done countless times working in teams over the past 20 years - over a long enough timeline stylesheets all tend to end up a mess of overrides like that.
If you just work on your own, that's certainly a different discussion. I'd say Tailwind is still useful, but Tailwind's value really goes up the bigger the team you're working with. You do away with all those !important's and all those random class names and class naming style guide discussions.
I used to look at Tailwind and think "ew we were supposed to do CSS separate from HTML why are we just throwing styles back in the HTML". Then I was forced to use it, and I understood why people liked it. It just makes everything easier.
Honestly, for me, tailwind was just pleasant to work with and pure css definitely was not.
And I was super skeptical about it at first. I almost said no to it, but I trusted our main ui guy and wanted to allow him autonomy. And I ended up loving tailwind after working with it.
CSS requires discipline, or you end up accidentally styling something completely unrelated because you were overly general, or overly specific, or accidentally reused a class name. CSS disallows local reasoning. If you’re writing markup for a component, you have to jump between two files.
There are plenty of other problems Tailwind solves, but these two alone make me never want to go back.
Ignoring that Tailwind requires that same discipline... Pay close attention how often you end up in a situation where a different color was used, or how dark theme tags have been missing, and so much more.
What if you need to copy a element with tailwind, this later gets altered to include a slightly different style, but wait, now you have a original somewhere else in your code base, that is missing those updates. So you require the discipline just like CSS to keep things up to date.
Tailwind is great if you use it sporadically ... but have you looked at the source code of so many websites that use tailwind? Often their entire html file is a horrible mess million miles long tags.
I am amazed how often people do not even realizes that CSS supports nested Selectors? With nested Selectors, you get the benefit of creating actual component level structures, that can be isolated and shareable. Yet almost nobody uses them. I noticed that most people lack a lot of CSS knowledge, and they find it hard because they never stepped beyond the basics. Nor do they keep up to date.
> What if you need to copy a element with tailwind, this later gets altered to include a slightly different style, but wait, now you have a original somewhere else in your code base, that is missing those updates. So you require the discipline just like CSS to keep things up to date.
You solve these problems by creating abstractions in JavaScript (most likely react components), exactly the same way you'd solve any other sort of code duplication.
By using tailwind (or inline styles), you go from two system of abstraction (CSS, JavaScript) to one (just JavaScript).
I agree with you about discipline; but... was it not interesting to discover how to build such a discipline? Was it not intriguing to learn how people who had been writing CSS for years had made it tolerable?
Besides, there recently have been several crucial improvements to CSS to address these pain points. One is CSS layers, which lets define custom layers of specificity that help with the discipline (e.g. resets or some baseline styles go in a low layer, component styles go in a higher layer, and finally overrides end up in the highest layer). The other is CSS scope, which prevents the leakage of the styles. These should greatly help with the specificity issues; and @layer is now sufficiently broadly supported that it is safe to use.
> If you’re writing markup for a component, you have to jump between two files.
Yeah; one of the reasons for my question about the groups in which tailwind saw the biggest growth was that in some ecosystems jumping between files was not a problem to begin with. Vue, for instance, had single-file components, where css could be written in the same file as javascript. So did svelte. So does astro.
> was it not interesting to discover how to build such a discipline? Was it not intriguing to learn how people who had been writing CSS for years had made it tolerable?
As someone who writes tiny amounts of CSS these days (having known it reasonably in the late 90s and early 2000s with all the hacks and IE related bullshit), I have _zero_ interest in it.
If I'm doing it, it's only because there's no serious cross-platform equivalent to Windows Forms to power small experiments, and curiosity is certainly not there to improve the experience.
I’ve been building web sites and applications since 2000. I’ve done just about everything you can imagine SCSS, BEM, whatever. Tailwind is the best thing I’ve seen in that time.
We can agree to disagree about that, and that’s OK.
I should note that other than Clojure, I absolutely hate dynamically typed languages. I suspect (though dunno how to prove it) that folks who like Tailwind probably like statically typed systems and maybe functional programming- it seems to fit into that philosophical niche. And probably people who like vanilla CSS are in a different category.
I’d love to hear from both camps to find out whether or not that tracks.
> I suspect ... that folks who like Tailwind probably like statically typed systems and maybe functional programming- it seems to fit into that philosophical niche. And probably people who like vanilla CSS are in a different category.
I love vanilla CSS, love typescript, have a huge respect for functional programming, but also don't mind OOP ¯\_(ツ)_/¯
It is a natural fit with component-based frontend frameworks like React. You keep the styles with the component instead of having to work in two places. And it’s slightly nicer than writing inline styles.
The core CSS abstraction (separating “content” from “presentation”) was always flimsy but tailwind was the final nail in that coffin.
Then of course LLMs all started using it by default.
You've been able to keep the styles in the component well before tailwind turned the class attribute into ersatz inline styling. CSS-in-JS has been around for a decade, and there are myriad options for react. Vue and Svelte have them built in.
Fe devs who refuse to learn css and instead use tailwind have always struck me as incredibly odd. It's like a carpenter who refuses to use a hammer because they hit their thumb once as an apprentice
It’s interesting to me because CSS is very stable. It doesn’t really change that often. It’s great foundational knowledge to have for people who build for the web.
And nearly every step it's made has been for the better. I used sass on that blog, because a few corner case features weren't widely available when I last did work on the style, but for the last 3 projects I've worked on, I don't use it anymore. Pure css can do basically everything I needed before. Sure, I bundle using bun's bundler, but that's for performance optimization, nothing more
I'll give my guess - it's because of rhe "fullstack" bullshit.
I am a backend developer. I like being a backend developer. I can of course do more than that, and I do. Monitoring, testing, analysis, metrics, etc.
I can do frontend development, of course I can. But I don't like it, I don't approach it with any measure of care. It's something I "unfortunately have to do because someone who is not a developer thought that declaring everyone should be doing everything was a good idea".
I don't know how to do things properly on the front end, but I definitely can hammer them down to a shape that more or less looks like it should. For me, shit like Bootstrap or Tailwind or whatever is nice. I have to spend less time fiddling with something I think is a waste of my time.
I love working with people that are proper front end developers for that reason, and I always imagined they would prefer things more native such as plain CSS.
So is SQL. To me. But some otherwise rational people have an irrational dislike of sql. Almost like someone seeking to seal a small bruise with wire mesh because bandaids are hard to rip off. The consequence shows with poorly implemented schema-free nosql and bloated orm tools mixed in with sql.
But some folks just like it that way. And most reasons boil down to a combination of (1) a myopic solution to a hyper specific usecase or (2) an enterprise situation where you have a codebase written by monkeys with keyboards and you want to limit their powers for good or (3) koolaid infused resume driven development.
I would have understood if tailwind got popular primarily among full-stack or backend developers: people who have neither time nor interest to learn CSS deeply. But, what contradicts this expectation is that one still needs to acquire CSS knowledge to use tailwind, and that some front-end developers seem to prefer it as well. Although I still cannot tell whether there are more front-end developers who prefer tailwind over plain CSS than the other way around.
I was too subtle but the issue is less understanding CSS and more collaborating in a team where someone decides to add a specific rule that fixes something applies on every page but makes no sense semantically.
Then do that 100 times to create spaghetti. CSS rule anywhere can affect anything whereas tailwind is more local.
You can also bricklay it along lines of components in React, so you know how X component renders always and it wont look like a pig when tranplanted to the legacy billing screen.
I now recall why I like tailwind! Been backending for a while now (zero regrets lol)
I haven’t seen this mentioned much, but Tailwind’s rise closely followed a shift away from runtime CSS-in-JS toward build-time, deterministic styling.
Many JSX-era libraries (MUI, styled-components, Emotion) generate styles at runtime, which works fine for SPAs but creates real friction for SSR, streaming, and time-to-first-paint (especially for content-heavy or SEO-sensitive domains).
As frameworks like Next.js, Vue, Svelte, Angular, and now RSC all moved server-first, teams realized they couldn’t scale entire domains as client-only SPAs without performance and crawler issues.
Tailwind aligned perfectly with that shift: static CSS, smaller runtime bundles, predictable output, and zero hydration coupling. It wasn’t about utility classes. It was about build-time certainty in a server-rendered world :)
That’s not at all why I bought Tailwind Plus. I bought it (at work) to have a solid collection of typical components and UI patterns, mostly expertly designed with a lot of attention to detail, to use as inspiration and as a shared language with other frontend devs and designers. I rarely (if ever) actually copy pasted any of their HTML or Tailwind styles. It’s mostly used as reference and inspiration. The fact that it’s implemented in Tailwind is mostly irrelevant (Tailwind really isn’t hard to use, especially after your first couple of small projects).
Not being sarcastic, but this will never be. CSS is a perfectly functional interface, but the only way it becomes less annoying is when you abstract it behind something more user friendly like tailwind or AI (or you spend years building up knowledge and intuition for its quirks and foibles).
We have decades of data at this point that fairly conclusively shows that many people find CSS as an interface inherently confusing.
I agree. I actually think CSS (and SQL or other “perfectly functional” interfaces) hold some kind of special power when it comes to AI.
I still feel that the main revolution of AI/LLMs will be in authoring text for such “perfectly functional”-text bases interfaces.
For example, building a “powerful and rich” query experience for any product I worked on was always an exercise in frustration. You know all the data is there, and you know SQL is infinitely capable. But you have to figure out the right UI and the right functions for that UI to call to run the right SQL query to get the right data back to the user.
Asking the user to write the SQL query is a non-starter. You either build some “UI” for it based on what you think is the main usecases, or go all in and invent a new “query language“ that you think (or hope) makes sense to your user. Now you can ask your user to blurb whatever they feel like, and hope your LLM can look at that and your db schema, and come up with the “right” SQL query for it.
Hey! Don't you dare to compare SQL and CSS. SQL is not a cobbled together mess of incremental updates with 5 imperfect ways of achieving common tasks that interact in weird ways. Writing everything in SQL-92 in 2026 is not gonna get you weird looks or lock you out of features relevant for end users. If writing SQL for your problem feels difficult it's a good sign you ought to look at alternatives (eg. use multiple statements instead). Writing the right CSS being difficult is normal.
> Don't you dare to compare SQL and CSS. SQL is not a cobbled together mess of incremental updates with 5 imperfect ways of achieving common tasks that interact in weird ways.
Reminds me a little bit of Sascha Baron Cohen's democracy speech [1] in The Dictator ;-)
Both SQL and CSS have evolved through different versions and vendor specific flavors, and have accumulated warts and different ways to do the same thing. Both feel like a superpower once you have mastered them, but painful to get anything done while learning due to the steep learning curve.
I was already using flexbox ten years ago. And if the goal was pixel-perfect layout, I could do that twenty years ago using `position: absolute`.
I would instead characterize the recent developments in CSS as enabling good layout even when there are major unknowns in your content. It was always easy to write CSS tailored to one set of content (say, one style of toolbar in your UI), but it has become possible to write generic CSS (say, a generic toolbar component where the icons are unknown, the width and height are also unknown).
It's getting better (in a C++ kinda way), certainly, but...
It's ultimately still driven my matching "random" identifiers (classes, ids, etc.) across semantic boundaries. Usually, the problem is that the result is mostly visual which makes it disproportionately hard to actually do tests for CSS and make sure you don't break random stuff if you change a tiny thing in your CSS.
For old farts like me: It's like the Aspect-Oriented Programming days of Java, but you can't really do meaningful tests. (Not that you could do 'negative' testing well in AOP, but even positive testing is annoyingly difficult with CSS.)
EDIT: Just to add. It's an actually difficult problem, but I consider the "separate presentation from content" idea a bit of a Windmill of sorts. There will always be interplay and an artificial separation will lead to ... awkward compromises and friction.
> Making GitHub actions runners more reliable, stable and economical would hurt Microsoft.
Can you explain this one a bit? I know some folks who would absolutely increase their spend if Actions runners were better. As it stands I've seen folks trying to move off of them.
Gh actions runners had a dubious implementation of sleep that would cause runners to hang on 100% usage for weeks/months. A simple fix was proposed and neglected for 10 years.
This discussion resurfaced recently with zig abandoning GitHub entirely and criticizing this specific issue.
A fix was them merged following an announcement that self hosted runners will now be charged by the minute. Of course this two facts are totally independent but yeah, yeah, sure.
How does this support your point? If we're saying "they fixed it because there was pressure to"... okay? That's the parents point - tons of people are going to move off over bad performance, and Github was incentivized to fix it when people started moving off.
If Github's incentive was to keep it slow... we wouldn't have seen exactly what you're describing.
The fix already existed and was neglected for a decade. It was a 3 lines of bash code.
The big would commonly make a runner hang forever unnoticed, on a platform that charged by the minute.
One minute hanging, was one minute charged.
The fix that would drop considerably the amount of total minutes charged was immediately followed by charging self hosted runners by the minute.
>GitHub incentive was to make it fast.
They charge by the minute. The faster it completes the action, less money. Runner go fast pocket go low
> "Give everything away for free and this people will leave technology"
This is more interesting, although somewhat generally understood (can be conflated with people seeing "free" and "cheap" and therefore undesirable). It depends on your definitely of longevity but we certainly have a LOT of free software that has, so far, lasted the test of time.
—-
I find it really crazy that they think would be good idea. I wonder how many false positive css stuff is being added given their “trying to match classes”. So if you use random strings like bg-… will add some css. I think it’s ridiculous, but tells that people that use this can’t be very serious about it and won’t work in large projects.
——
> Using multi-cursor editing
When duplication is localized to a group of elements in a single file, the easiest way to deal with it is to use multi-cursor editing to quickly select and edit the class list for each element at once
Instead of using a var and reusing, you just use multi cursors. Bad suggestions again.
—-
> If you need to reuse some styles across multiple files, the best strategy is to create a component
But on benefits says
> Your code is more portable — since both the structure and styling live in the same place, you can easily copy and paste entire chunks of UI around, even between different projects.
—-
> Making changes feels safer — adding or removing a utility class to an element only ever affects that element, so you never have to worry about accidentally breaking something another page that's using the same CSS.
> Tailwind Labs relied on a weird monetization scheme. Revenue was proportional to the pain of using the framework.
Really? To me, Tailwind seemed like the pinnacle of how anyone here would say “open source software” should function. Provide a solid, truly open source, software and make money from consulting or helping others use it and selling custom built solutions around it. The main sin of Tailwind was assuming that type of business could scale to a “large business” structure as opposed to “a single dev”-type project. By a “single dev”-type I don’t mean literally one guy, but more a very lean and non-corporate or company-like structure.
Vercel (and redislabs, mongo, etc) are different because they are in the “we can run it for you” business. Which is another “open source” model I have dabbled in for a while in my career. Thinking that the honest and ethical position is to provide open source software, then offer to host it for people who don’t want to selfhost and charge for that.
From the developer perspective not much changes despite organization structure being completely different in this comparison (trillion dollar company vs 10 individual contributors).
Tailwind Labs revenue stream was tied to documentation visit, that was the funnel.
The author's argument was this revenue stream was destroyed by a slight quality of life improvement (having llms fill in css classes).
Tailwind Labs benefits from:
a) documentation visit
b) inability to implement desired layout using the framework (and CSS being unpleasant).
It seems there is a conflict of interest between the developer expecting the best possible experience and the main revenue stream. Given that a slight accidental improvement in quality of life and autonomy for users destroyed the initiative main revenue stream, it would be fair to say it doesn't just "seems like a conflict of interest".
Definitely disagree with it being the "pinnacle" of how open source should function but I also won't provide any examples because it is besides the point. I will point out that fsf is fine for many decades now, and a foundation with completely different structure like zig foundation seems to be ok with a somewhat proportional revenue (orders of magnitude less influence, adoption and users, maybe 10-20x less funding)
Your synthesis points to software in the public interest. Governments need to start forking projects and guiding them through maturity, the same as other public utilities.
There are many initiatives in a similar spot, improving your experience at using Next.js would hurt Vercel. Making GitHub actions runners more reliable, stable and economical would hurt Microsoft. Improving accessibility to compute power would hurt Amazon, Microsoft and Google. Improving control and freedom over your device would hurt apple and Google.
Why should we be sympathetic to the middleman again?
If suddenly CSS became pleasant to use, Tailwind would be in a rough spot. See the irony?
"Give everything away for free and this people will leave technology", geohot said something like this and I truly appreciate. Technology will heal finally