Our great sponsors
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
I was going reply at the top-level because my opinion is vastly different to the majority of comments so far, until I found yours. Years ago I very much enjoyed finding painkillers to make my work easier. I now only take vitamins.
I'm very much in agreement with the author (regarding Tailwind, I'm Web Component-curious but yet to be convinced to the degree is obviously is...). I started with Adam Morse's "Tachyons" library which is the pre-cursor to Tailwind. Conceptually that worked for me, particularly because I was all-in on the JS ecosystem, building a startup with React and Meteor (story for another time). I wrote up my thoughts on a now-extinct blog [1].
Over time though I found JS to be a fragile and brittle ecosystem to work in; I'm sure as many others have. I not only moved away from SPAs and JS as my backend language of choice to avoid npm dependency hell, but also any JS build tools because using the latter is functionally equivalent to the former.
When my choice of language/framework at the time (Elixir & Phoenix) added support for Tailwind by default, without a JS build tool (handled by an Elixir lib) I was conflicted. I had gotten used to vanilla CSS again with all the new additions such as custom properties and wasn't convinced I needed Tailwind. Even though it didn't bring the JS build chain I hated, it still represented a hard dependency to replace down the line if required, and still required a build tool. It was potentially a decision future me would regret. These days I'm all about not snookering future-me.
I think Tailwind has it's place where you're already using a build tool that can support it (JS or otherwise) and you're working in a team that needs a design system straight out of the box. It gets you up and running quickly (particularly with their TailwindUI components and themes) and provides a point of reference for everyone working on the project without coming up with a design/token system of your own. But that can be said of the older frameworks like Bootstrap or Zurb Foundation (remember that?!).
Personally I'm very happy writing HTML, CSS & JS without any build tools, bar a bit of templating to bring in partials here and there. Admittedly I'm working on very different websites now, but I spend years thinking that the foundations of the web needed augmenting and abstracting away (they probably did at that point...), but now I'm quite happy to work with it in it's natural state.
[1]: https://github.com/jamiedumont/personal_zola/blob/main/conte...
I don't quite get the hate for having CSS in another file. Do you also put all your react stuff in one single file ? That same logic and argument can be applied against all modularization.
And really 20-50 tailwind classes in a single element is VERY hard to read and keep in mind. No - it does not make things clear or understandable. One tends to need to re-read and scan over from the beginning and eyes glaze over. Esp if some elements only vary with a few classes missing. I guess it works for people with very high attention to detail and high amount of working memory. I only find it personally frustrating.
Maybe tailwind css works for some bright people. I did try it for a couple of projects and only felt pain.
However, the "atomic css" philosophy behind tailwind is great. I find framewroks like https://open-props.style/ far better to use.