Tailwind CSS v3.2: revisiting my “feature creep” warning
brycewray.com
brycewray.com
This misses the point of Tailwind entirely. The point of Tailwind is to give everyone a common vernacular of CSS phrases so that I can bust out something like "p-2 m-2 border-red" super fast and still be writing code which is immediately comprehensible to everyone else on my team. There's also the benefit that I no longer have to think about class names, which is shockingly large.
Using CSS does not give you that. I don't even address the "learn to use CSS" phrase because anyone who uses Tailwind obviously knows CSS! We do the translation back and forth in our head as necessary.
It's also why I'm not concerned about Tailwind getting more features:
* Tailwind needs to have all the features of CSS, otherwise it's incomplete.
* The notion of Tailwind being "bloated" makes no sense:
* The Tailwind compiler eliminates any styles you don't need.
* Tailwind stylesheets are always going to be much smaller than normal CSS for any decently-sized app.
This is how I see it too. If Tailwind doesn't bother adopting some CSS features, I have to jump between Tailwind and CSS files and syntax.
While I agree, sometimes I feel Tailwind users forget that writing regular CSS is also an option. I have seen examples where developers repeat Tailwind classes for every paragraph, every link. They repeat same typography styles over and over again instead of creating some base CSS. A great example is this checkbox[1] where developers used 71 Tailwind classes to style the input.
[1]: https://twitter.com/hovhaDovah/status/1461672155108806658
> Confession: The `apply` feature in Tailwind basically only exists to trick people who are put off by long lists of classes into trying the framework
> You should almost never use it
> Reuse your utility-littered HTML instead.
[0]: https://twitter.com/adamwathan/status/1226511611592085504
I've moved to using @apply in a few generalized classes and I love it, since my class names like "btn" "btn-success" "btn-success-outline" describes what I want, and I can easily go in and change them.
I'm not creating a new component for every tiny thing, like a button or a link, just so I can avoid using @apply...
I style things normally in CSS with exceptions or one-offs that are styled in tailwind classes. Usually try to avoid those.
OP seems to miss the point that most everyone - or at least everyone I know - that uses Tailwind already knows CSS to a large degree. In addition, everyone I work with would rather spend time writing code than messing around with CSS and trying to name classes (great point you make, and I fully agree)
Now if you are a hacker and are hacking together a website, that is fine. You don’t need to be a frontend developer to write a website, and if that is the case, use tailwind by all means. However in a team that maintains a webapp, you should expect there to be a frontend developer, and you should expect them to know and write CSS, if they are the only person on the team that knows CSS, then probably they will take some authority on that, and I would expect them to assert some authority on every code that contains some styling. If a contributor doesn’t know CSS, and writes a poor CSS code, that should be fixed during peer review. A team that is happy-go-lucky with their styles is surely not going to by writing a well crafted web-app.
This sentence:
>Now if you are a hacker and are hacking together a website, that is fine. You don’t need to be a frontend developer to write a website, and if that is the case, use tailwind by all means.
Would make more sense IMO if you replaced the word "tailwind" with "a component library"
JS (and programming in general) is actually quite complex, and you can't hide that complexity under a shiny veneer and hope it goes away.
CSS on the other hand is not complex at all. For that reason, it's a lot more plausible that you can make big strides by simplifying the language down to its core essence.
Something like "p-2 m-2 border-red" making sense relies on some imaginary grid or table layout being used. Web design should catch up at some point and get rid of that way of thinking. Websites are not bound to be aligned according to some grid. On a website things float and take as much space as needed and as available. There is no inherent need for inventing an imaginary grid. Yet so many "design systems" cling to that outdated notion. A website is not a sheet of paper in a magazine! It is like we still haven't left bootstrap behind us, or even table layout behind us, because web designers not actually knowing CSS.
Actually look at https://web.dev/state-of-css-2022/ (linked here on HN a few days/a day ago). CSS is easier to use than ever before! Now we can even specify our own specificity groups!
Once tailwind covers all needs for features of CSS, what will we have gained? We merely built another wrapper layer around the thing, that we should actually understand and learn. In my experience this will only lead to people thinking, that they should build something on top of tailwind, because they want something simpler, stacking yet another layer of abstraction, instead of actually learning CSS. At some point some sanity will return and do away with the whole stack of abstractions, because it indeed has become too bloated. (Note also, that no one will want to maintain your website based on tailwind, once the hype is gone and tailwind looks outdated.)
This kind of mentality of adding layer upon layer without watching out for the associated costs or realizing the power of already existing primitives is responsible for the tons of bloated websites we have today. For shipping megabytes of JS unnecessarily, instead of letting us enjoy the advantages of faster connections, like we should be able to.
About naming CSS classes: Surely not always a simple thing. Ideally the web design people would work together with the web development people and talk about their metaphors or abstractions on the website. Then find names for that and style accordingly. "How will we call this kind of thing here, with a picture and a label underneath and a rating? – Lets call it a product box." Or whatever else. They would build a common vocabulary and that would inform naming of CSS classes of the website. Additionally of course one would use a prefix, to avoid any name clashes with any other stylesheets.
The whole point of Tailwind is that the worry about naming CSS classes goes away for most part. It turns out you can safely skip the vast majority of those granular naming decisions and conversations - that’s a massive amount of saved time and brain cycles for everyone.
If you’re using eg. BEM you have to come up with all these granular names for subcomponents that really no one cares about apart from you (the frontender I mean). If you’re not using BEM or similar and going for longer selectors in the main, then you have a coupling issue between the structure of your CSS selectors and the structure of the HTML that may make maintenance in the future harder.
Adding a name for something is a weighty task that’s orthogonal to the task at hand. If you can avoid the name without losing understandability then it’s a win.
The other side of that coin is that if you add a name it has to be worth the effort.
In CSS, a number of techniques developed over the years in response to the maintainability challenges of even well thought out, traditional good practice CSS in large projects. These techniques (eg. BEM) required class names for almost every element you need to add styles to. This was to avoid long selectors that a) are hard to understand, even for experienced CSS developers and b) are tightly coupled to and generally not co-located with the HTML.
Tailwind gives us away to avoid those having to choose those names, which just took a long time and lots of conversation if you wanted to get them right.
Yes, it’s literally in the HTML so it’s coupled, but it’s co-located. The maintenance story is much simpler than with BEM and much much simpler than with trad CSS. Lower effort for a better long term result - it’s a win.
A well thought out class name would have helped understand, that new dev is actuall editing something, that is part of a group of things, which all have something in common.
Naming things is hard, but finding good names is worth gold. Avoiding the hard parts is not going to be the solution to all problems. We would all be working in some kind of modern version of lambda calculus, if naming wasn't important. There are good reasons, why we name things. To convey meaning and convention. Not naming things hides these and makes them implicit, instead of explicit.
Regarding the problem of a developer new to the codebase being told to change the text size in a specific place; Tailwind works well in this specific situation.
At the beginning of your project, you will have chosen a (or accepted the default) text size scale. The new developer will probably choose the next largest step in the scale and step back. The new size will be in harmony with the rest of the project because it matches the scale. If this specific element is repeated elsewhere in the project, then it will be part of a component and all instances of that component will receive the change.
The right place for a considered name in this example is at the component level.
Is this somehow not possible if you say “padding: 2px, margin: 2px, border: 1px red solid”?
By the way, not entirely related, but when testing Copilot when it was free I noticed it was amazing at generating styles for something based on a class name. To the point I felt more productive and more in control than when using Tailwind, Bootstrap, MUI, or any other CSS "framework".
You would have to adjust for the default units in Tailwind for the padding and margin: "padding: 0.5rem, margin: 0.5rem"
In practice, GP wouldn't use "border-red", they'd use a shade of red (border-red-100, border-red-200, etc). The higher the number, the darker the shade.
These defaults are an underrated feature. The defaults for spacing ensure things look cohesive, and the defaults for color are supposed to harmonize well. They're informed by the book Refactoring UI [https://www.refactoringui.com] to ensure your design has structure. They're designed to make it easy to adjust parts of your design, without guessing, when things look "off".
for us backend developers also doing database, caching, networking, storage, etc. being able to write "m-2 p-2 border border-red-600" is way easier to remember and doesnt take that much brain cpu cycles that we reserve for more important stuff.
If you’re already doing all that, CSS is peanuts.
But there‘s more important benefits (IMO):
- Media queries are done inline and become ridiculously easy to read
- Light/dark mode colors and selectors are done inline
- Gradients are easy as pie and actually readable
- Built in grid system
- Your code is somewhat future proof - if the idiomatic code for a gradient changes, you only need update your Tailwind version
- Plugin system for custom code generation
When you declare `py-4 px-2 bg-blue text-white rounded-lg` on five buttons in a row, doesn't this work almost exactly like inline strings when you compare to the semantic classname `button-secondary` that is maintained in one single place much like a constant? And wouldn't you just rely on constants to maintain consistency between components, in other words use CSS variables?
.button-secondary { background-color: var(--color-action-secondary); }
Inline media queries are not easy to read. What does this button do?
<button class="inline-block px-large py-medium rounded-large border-solid border-thin font-regular bg-core-yellow-100 border-core-yellow-300 bg-text-core-yellow-800 bp-medium:font-medium bp-medium:bg-core-green-100 bp-medium:border-core-green-300 bp-medium:text-core-green-800 bp-large:font-bold bp-large:bg-core-blue-100 bp-large:border-core-blue-300 bp-large:text-core-blue-800 bp-x-large:font-black bp-x-large:bg-core-red-100 bp-x-large:border-core-red-300 bp-x-large:text-core-red-800">Sign in</button>button>
It changes font size, background color, border color and text color when you resize. That's easy to tell if you don't inline it
.button { @apply inline-block px-large py-medium rounded-large border-solid border-thin; @apply font-regular bg-core-yellow-100 border-core-yellow-300 text-core-yellow-800; @media (--bp-medium) { @apply font-medium bg-core-green-100 border-core-green-300 text-core-green-800; } @media (--bp-large) { @apply font-bold bg-core-blue-100 border-core-blue-300 text-core-blue-800; } @media (--bp-x-large) { @apply font-black bg-core-red-100 border-core-red-300 text-core-red-800; } }
Edit: Hacker News did of course inline it, but that only proves the point.
The same goes for light and dark mode. These are by the way Custom Media Queries [1], but Tailwind has a `@screen` directive much to the same effect.
Gradients aren't much different in CSS nowadays, really, and the "built in grid system" is really just a super inflexible subset of CSS Grid that will run out of luck if you need something other than equal sized columns. If you use it for the core page layout, chances are low that you will want your sidemenu, main content and sidebar always appear in equal width columns. In Tailwind you don't, of course, but it is a wonderful feature of CSS.
Tailwind actually is future proof, but that's only because you remove Tailwind from the list of dependencies and check the generated CSS into your souce code repository. At some point all these websites will need an overhaul of the visual identity and people will realize all over again why presentational attributes were removed in HTML4 along with the introduction of CSS. You can update your Tailwind version, then, but nothing will happen. Fortunately, this "plugin system for custom code generation" can be replaced with a stylesheet.
Tailwind has certain qualities, but the things you mention are not some of them. I like that you can't simply copy the CSS from some textarea in Figma and paste it into the CSS, because that will soon make your website even more unmaintable even if it is vanilla CSS. You are in other words forced to think about the layout, the spacing system, the color variables and the breakpoint behaviors, ironically what the typical proponent of Tailwind would like to avoid. If all of these things are declared in a highly customized Tailwind preset, and if you elect to maintain complex components (eg. with synchronized breakpoint changes) in CSS files via `@apply`, it becomes an effective tool to enforce a "design system". Some might say that Tailwind's own creator advises against this strategy, but that should only encourage you, in my opinion.
Essentially, what he is saying [2] is that you should not use SQL to transform you date from one format to the other because the SQL will break when someone changes the database structure. Instead, you should just hardcode the result of this transformation directly into the database and now you won't need SQL at all. You could argue that this would be retarded since the abstraction layer enables different, future presentations of the data in question and that is exactly what I am trying to say.
My best advise is to go light on presentational attributes, which is what utility classes is, and move your Tailwind into proper CSS as soon as the implementation indicates moderate complexity [3]. Here you can make use of the `@layer components` stuff that bears an uncanny resemblance to semantic classnames, but more importantanly, now your Tailwind can easily break out into real CSS, for example to author your core page design with a Grid of uneven column sizing. Make sure to Use CSS variables for everything including your Tailwind preset so that `12px` are never mentioned in the JSON, but instead refers to `var(--base-unit-or-something)` which can be referenced equally in vanilla CSS. Keep the best of both worlds and Tailwind can add more value than it destroys.
[1] https://preset-env.cssdb.org/features/#custom-media-queries
[2] https://adamwathan.me/css-utility-classes-and-separation-of-...
[3] https://frameable.com/company/tech/how-we-found-sanity-in-a-...
With TW, it’s preferable to reuse whole components (JS+HTML+CSS). So in your example, you‘d have a button React/Vue/LiveView/etc component that is reused across the app. Only if _that_ is not feasible, you should fall back on @apply.
If you’re developing in an environment where HTML+JS+CSS code reuse is not possible, then I agree that OOTB TailWind is not that much better. But for a component-based architecture where you want to minimize outside dependencies, TW is IMO ideal. Meaning: React, Vue, Svelte, Elixir Phoenix (incl LiveViews) and many others.
.my-tab { @apply my-button bg-transparent; }
There is actually a very powerful CSS framework hidden in there somewhere, but they remain intent on appealing to developers who believe that real layout is coded with JavaScript, perhaps it is because Tailwind is a multi million dollar business that relies on selling components to teams that give up on making their own.
Your components don't minimize outside dependencies when they share the same global stylesheet, by the way, they would for example not work in my website even though I am using Tailwind (if highly customized). This shared dependency, or "global variables leaking into my scope" as programmers would phrase it, is the problem that CSS frameworks have been fighting for years, and now it's become a brilliant feature of Tailwind that components can share styles. Welcome to CSS! Now you only need to define your complex layouts via @apply and you can share them as well, that is what composability is all about.
I favour composition over inheritance, so I'm ok with that.
> Your components don't minimize outside dependencies when they share the same global stylesheet, by the way, they would for example not work in my website even though I am using Tailwind (if highly customized).
I think you just made the case for using vanilla Tailwind and restraining from customizations to cater to design extravaganza. The days of pixel perfectness are over, and designers can and should IMO get used to making compromises. Form follows function, and using vanilla TW can get you more "form" in the same amount of dev time.
Having said that, wouldn't you just have to merge the two Tailwind configs and generate a new CSS file? Apart from color naming clashes (which can't be avoided in any system) I don't see any issues there.
thing is, i despise writing the long ass version especially when im working with flexbox, grids, borders and everything else lengthy that i cant cram up in one liners
Instead the HTML content grows larger because of the long class= attributes. It is a bad tradeoff, because CSS gets loaded once and cached, but HTML gets loaded on every page load.
(And if it's just about "m-2" being shorter than "margin: 0.5rem" or whatever... I can't believe that after gzip that matters one whit.)
This is an incredibly silly argument because Tailwind has always required you know CSS, or at least understand how it works. The selling point of Tailwind is a more convenient and co-located way to write styles—the utility classes map pretty much 1:1 to CSS properties after all.
Covering more CSS features with Tailwind classes does not make Tailwind inherently more complicated, it just adds a way to express more CSS that you need already know about.
Also the biggest reason to use tailwind is apparently because naming css classes is hard...
The advantage of tailwind over a full design system is that it is piecemeal, you only pay for what you use. It really makes a lot of sense when combined with a component system like React because you get re-usability at the component level instead of the style level. I like this a lot, but it may not resonate with everyone.
Give me a picture of a dream website and I can easily write all the CSS and HTML to create it identically and responsively as I have done for years.
But give some general product description, and no amount of CSS knowledge will save the monstrosity I create
The idea of utility classes is super helpful.
I was actually pretty into tailwind at first for these reasons.
There were some issues, most of which were fixed with the JIT.
That said, most of the hate for tailwind is due to the 'community'. People saying to just take the best parts are the minority of opinions you see on tailwind.
I find organising CSS files to be pretty hard, and I've been using it since 2001, predominantly as a backend dev who needed to churn out a decent enough front end. Tools like Compass, SASS, Bootstrap, LESS have helped with all of that. Tailwind is the best integrated version of all that tooling that I've worked with.
Personally, I usually just look through component sites for something like I want, then modify it to my needs. 95% that works, sometimes I go build it out myself.
I'm fullstack, but more backend and that's where I'm most comfortable so the less I worry about design the better it is for my sanity, except I do like dabbling w/ the js layer in vue, alpine, or react.
All arguments I've seen are about consistency and maintainability.
OT: I often see someone make a dubious claim, someone else asks for proof, and they say "that's what I keep hearing on Twitter."
It's just another logical fallacy, especially since Twitter is known for bad and hot takes.
It doesn't support your argument the fact that you heard a random person on social media say something dubious.
/rant
It's like you can know how to unclog a toilet or change a faucet, you're no plumber, you don't know what a plumber does, but you can do enough for 80% of your needs, and when you can't you either call the plumber or you pick up a plumbing book or go to google/youtube.
I don't think you need to be a CSS expert to use tailwind, that's why I stuck w/ bootstrap for so long, but I also think you need to maybe think more about the underlying css so at least be willing to keep more CSS knowledge in your RAM or SwapFile in your brain, but there's things like daisy-ui that sort of wrap TW in bootstrap like niceties so you can kind of have both worlds, and come with nice themes to boot.
I also think the listed sentiments would not be strongly reflected in actual tailwind dev polls.
I don't think people who made css were webdevs at heart but typographists or artists, and as a result css feel unnecessary convoluted.
It's nice that some folks are using Tailwind to shortcut a need for more comprehensive learning, but let's not misrepresent that for one moment as being a fundamental purpose. The organising principle of Tailwind is to refactor styles at the abstraction level of on-page components, not supplying an off-the-shelf design system for front-end novices a la bootstrap/material design.
So you need 1-unit padding? `p-1`. Double that? `p-2`. Still not enough? `p-3`. More? `p-4`. I don't have to think and do math in my head like 0.25rem, 0.5rem, 1rem,... and IMHO, it's a big enough win for me to keep using Tailwind CSS.
The features that were introduced in recent versions are just about supporting more CSS features to be more complete and not about feature-bloat.
This is the problem with Tailwind, it doesn't offer enough nor does it move faster than CSS to justify its existence. The only real use case for it seems to be solo developers that do not have the time or resources to set up their own baseline set of variables, or those that use it with a component library that's based on TW.
Personally doubt the better performance, I have yet to see a case where that is true unless they were comparing it unevenly to some behemoth like Styled-Components. When you compare it to SASS the performance difference ceases to exist. Same with "improves the dev exp", I don't see how this is the case at all especially when you have to install an additional extension to get full proper support in your IDE of choice. You are still working with variables, if you are on a tiny team/solo, it makes sense to use Tailwind defaults but on a large team where your design team should be creating their own? What use does Tailwind have then when the utility classes are just going to be overwritten? You're still creating the components yourself.
.button { background-color: blue; color: white; padding: 0.5rem 0.75rem; border-radius: 0.25rem; }
Then the browser will need to download less bytes:
<button class="button">Click</button>
Compared to:
<button class="bg-blue text-white px-3 py-2 rounded-sm">Click</button>
And this does make a difference when your entire layout is done with Tailwind. Consider that the HTML, unlike the CSS, might typically not be cached, and that the server is now also charged with emitting higher loads of data. Consider also that all these utility classes are all loaded in the CSS on the front page even if some or most of them is used on everything except the front page. The performance win is not as unquestionable as Tailwind would like to suggest.
We already get massive benefits from it that I wouldn't get as a solo dev. If someone else writes a bunch of new components that make up a new menu and I need to grok them quickly and then start working on them quickly, Tailwind brings the time I need to spend understanding the styling down to nearly zero. It's a massive timesaver for teams of any size.
Yes, you can get some of the benefits with other systems like CSS variables. But not nearly to the same degree, and you'll also need to organize a bunch of CSS/SCSS files besides you main code.
With Tailwind we have something like five small CSS files across a large monorepo that contains several apps.
Imagine being a computer programmer and not thinking nor doing math in your head.
Good thing there are other people to do the thinking and math for you, huh?
Because the multiplication table for 0.25 is too complicated...
Next you'll need an enterprise-grade library for adding numbers together. Because sums are hard, man. Who's got time to remember what 1+1 is?
So why not just bite the bullet and learn to use CSS without the additional tooling (and weird, often lengthy additions to your HTML) that Tailwind and other utility-first styling frameworks require?
(EDIT: there seems to be some confusion by what I mean here. What I meant is that knowledge of plain CSS does not enable me to create clean designs like Tailwind does.)
Really though a huge benefit of Tailwind is their UI package https://tailwindui.com/ which I routinely use
Aside from that, I also like how their components are all very lightweight normal HTML. Compare to Material UI, etc. which are so heavy that you can't even use them with many 3rd party libraries because they're more than just CSS.
Often times, third party components accept some class lists, which fundamentally means they are only compatible with simple CSS libraries like tailwind rather than component libraries.
Anyway I get the concern but I also feel like the concern is still very, very far away from becoming reality.
And if you're going to use tailwind utility classes, they're mostly one for one with a single css property, so you're learning something that is functionally similar to, but not css.
When Tailwind feels dated I'll be here to champion the new hotness too.
The advantage to the tailwind approach is that all the utility classes are right there, ready to be adjusted. It's designed to expose all the "buttons, dials, and levers" needed to customize in whatever direction you want to go.
(Not that bootstrap don't have customization options too, but the barriers are higher and the directions you can move in are less flexible.)
If the (print) designer is expecting pixel perfection, but knows nothing about css, and hands me an illustrator file, I'm walking away. You likely have things that are either unimplementable, or overly complicated. Examples would be 'this image should be 3", but you made it 5" on my laptop and 2" on my 4k monitor.'
If a (normally print) designer hands me a figma file but can't pull it off themselves, rock on. They likely have some idea of whats possible and what's dumb to try and do.
But honestly, if you're full time web designer specifically, I expect you to be designing in the browser, with some occasional help.
This feels like a weak argument. Yes, naming things are hard - but we name classes, variables, dom elements & everything else every day. There are also really good naming patterns for CSS out there too (BEM, etc.).
Tailwind is essentially inline styling done right + a set of constraints to keep your design consistent even if you are not a designer. Pretty sweet setup if you ask me.
But Sass has been recently introducing seemingly unnecessary changes in syntax, making their documentation incompatible with existing compiler implementations - and I'm getting tired of trying to catch up.
I'm thinking of moving to PostCSS with a small subset of features, like nested selectors, to stay close to the CSS specs and hopefully one day we can do without any preprocessor.
---
Edit: The author of the posted link has an in-depth article on Sass, with much of which I heartily agree.
https://www.brycewray.com/posts/2021/04/speaking-up-for-sass...
And most importantly I had only 7 days to develop it. And I just breezed though the frontend development thanks to tailwind which I won’t be able to do had I used a different framework like bootstrap or vanilla css
I think developers can select the features they want to use, and if they don’t want to use the new features they can just use the existing ones and leave the new ones alone.
For the moment I don’t find a reason to skip tailwind
That’s interesting because I had the exact opposite experience with Tailwind. We were in a hurry to but Tailwind’s lack of standard component classes meant we spent a lot of time trying to find components to do basic things, we even paid for Tailwind UI but we found the experience really weird that all you get is code samples that you just paste into your code and tweak?
We ended up going with bootstrap because there’s plenty of open source libraries that have all the components and it’s easy enough to tweak the bootstrap theme to look how our marketing and branding needed.
Where we needed more customization, bootstrap has a lot of nice utility classes too now.
Bootstrap a great for breezing through frontend development in my experience. The only issue is your site looks very much like a bootstrap site... which is completely fine for many kinds of projects (In fact, you might as well grab one of those decent bootstrap templates and breeze through even faster).
I've been using tailwind for cases where a bootstrap site isn't OK. I can't breeze through so fast, but the site can look and act exactly as I need it to without fighting the framework.
I love tailwind for small things but when I have to maintain it, it's pretty awful.
In fact, maintainability is by far the #1 reason I use Tailwind. IMO it's actually quite a bit more clunky and slow for the initial styling process.
> the idea behind Tailwind, like every other utility-first CSS framework, is to make styling easier, especially for front-end developers who dislike getting under CSS’s hood.
> The more features that get added to Tailwind, the more you have to know about CSS before you can use those features. Right? So why not just bite the bullet and learn to use CSS without the additional tooling
Tailwind is not an alternative to learning CSS, or "getting under CSS's hood", and I don't think I've ever seen anyone promote it as such. Tailwind is explicitly very low-level. It's an alternative way to write CSS, not an alternative to knowing CSS. All of its class documentation starts with the exact equivalent CSS declarations for a reason.
What Tailwind does give you is a way to build on top of a design system. The Tailwind config gives you a pretty good default design system in terms of spacings (padding and margins), colours (palettes and shades), etc. And you are free to modify or make your own design system, but once you do your design is much more likely to be consistent.
You can of course achieve the same design system with css custom properties (aka variables), but you have to be much more cognisant of using them. With Tailwind the design system is the default and you have to go out of your way to use custom values.
Feature creep does not mean that you need to use the features.
Tipping point of being too complex? For what? Doing more harm then good? Is that the argument? I am not a Tailwind fan, I don't use it, but I think, it did not reached the tipping point (of being useful) just at the 3.2 release.
Real cool I can style based on whether an element is being pressed in a cross browser compatible way without ever touching the config now.
Way easier and clearer than writing normal css
https://tailwindcss.com/blog/tailwindcss-v3-2#browser-suppor...
@supports(backdrop-filter: blur(6px)) {
.card {
background-color: rgba(0,0,0,0.75);
// Why would you not also be using backdrop-filter here anyways?
}
}
Shameless plug: https://gimli.app/tailwinddx.html - A Chrome DevTools extension enabling smart Tools for Tailwind CSS :)
Preventing bad devs from doing horrible mistakes should be your team leader's job.
https://web.archive.org/web/20220516010347/https://www.bryce...
Oddly, the sentiment I see most often in HN threads about website complexity is that a simpler look is better, but perhaps your experience is different. I definitely have done more complex things in 25 years of web dev, but I simply choose not to do so now.
Otherwise, I will let your reply stand for itself.
Simpler is better, but you still need to do well on the things you keep.
The whitespace on the navbar isn't great, the logo looked stacked on and doesn't fit well, don't use gradient backgrounds on content, the note color doesn't match with the background, the bottom section is too vertically long, you could simplify, or move it to use horizontal space instead, and the black bar for "Previous" looks out of place.
What I like: - Title is strong and centered - Date is very easy to find (especially for technical blog posts, they can tell you if it's outdated or not) - Good choice of fonts
This is why people could say "Don't learn CSS, just learn Tailwind". Tailwind is the only decent way to use and to learn CSS.