I'm waiting for the day developers realize the fallacy of sticking with pixels as their measurement for Things on the Internet.
With a deeper understanding of CSS, one would recognize that simply parsing it out for only the components "above the fold" (which, why are pixels being used here in such an assumptive manner?), completely misses what is being used in modern CSS today - global variables, content-centric declarations, units based on character-widths, and so many other tools that would negate "needing" to do this in the first place.
The difference is that the internet can exist (and did) quite well without JavaScript. Without HTML there is no internet. Furthermore, ECMAScript is a language and W3C/WHATWG are a consortium that maintain HTML.
Except when using Tailwind, you're learning Tailwind nomenclature and syntax and approach - which really isn't modern CSS, at all.
Today's CSS - if anyone would take the time to actually learn it as they do JavaScript - doesn't need something like Tailwind to make it powerful, scalable and manageable.
I write plain CSS today, which is then scoped to components or bundles of interactivity, and all of those point to major, top-level control sheets that help determine the mode (light/dark/high contrast) and the theme. We tweak small changes up high to effect large platform changes throughout, saving time, energy and headache of the hunt/peck exercise.
I don't understand the statement "no one is going back to writing plain CSS" because plain CSS today _is complex_. It is a beast. But it is still "plain" CSS. Yes, it has evolved, it has grown, and it meets today's modern needs with excellent results.
CSS nesting is coming up soon: https://caniuse.com/css-nesting That will more than likely allow me to migrate any projects I have with Sass still in play, to remove Sass. One more dependency removed. Done.
So there's really no need for Tailwind if you know how to build with modern CSS - with the one caveat that if a project _already_ has Tailwind in it, it is a bear to work with/alongside.
That to me is the biggest con with Tailwind: it gets in your way when you don't need it.
Except if you bundle your styling with the component, like you should be doing with React or Vue, and you have two _maybe_ three over-arching foundational style directives being implemented across your build, you do not need Tailwind.
I believe both React and Vue have the capability to scope your CSS along with the components. Modular CSS has been much easier to maintain over years than fixing when Tailwind updates or finding (again) that one !important that happens to conflict with a new released component set.
I save my teams time and money by applying CSS in the manner that it should be; which means not as an inline style mechanic.
In today's uses, cascade _with_ custom properties (the vars defined within :root ) are powerful and are what I leverage when providing theme-able ui libraries. Dark mode, light mode, large mode can all be solved using custom properties which to me most exemplify the power of the cascade.
I vehemently disagree. When you're using tailwind, you're learning Tailwind, which is using CSS in absolutely the unequivocally anti-CSS way.
CSS was meant to cascade; it's what the damn 'C' stands for, and if you cannot understand the efficiency of the cascade, at scale, you are most definitely missing the entire point of CSS.
I have personally built ui libraries for boutique firms and enterprise (Apple) firms and guess what we did _not_ use in any of those instances? Tailwind. Because it's an utter toddler to manage and very definitely not efficient in its application.
Disagree. Have been using and developing with CSS as my focus for ten years now. If you take the same amount of time you would take to learn the ins and outs of [pick any other language], you would have a better time of it.
I'd like to add a reason that you do not list and one that I constantly run into is that due to the lack of understanding, large applications have been built and it is simply not cost-effective to re-wire the whole thing using better approaches. The only time I get to apply features and structures that are less than five years old to projects is when it's a green field opportunity. Otherwise, the budget just doesn't cut it.
Personal comment/response:
I will say that CSS seems to be for a particular _breed_ of developer. Almost designers, but not quite. My perspective of this comes with also using JavaScript for the same amount of time. The thinking I use in both of those domains differs at times quite dramatically.
I'll use the number of pages of OReilly's foundational programming books as an example of anecdotal complexity of three languages: JavaScript - 704 pages, PHP - 842 pages, and CSS - 538 pages (the new one coming out will be 1090).
No frontend co-worker that I have had spanning the past ten years has ever worked through the _old_ CSS one from 2006, at all. Even those that loved CSS, did not own a copy of that one. It covered everything CSS and I read it cover to cover.
Without a commitment to CSS on par with commitments that developers make everyday to any given framework or other programming language, anyone trying to wield CSS on the same level as the other tools will continue to be disappointed.
And as long as the culture of web development continues to de-value solid in-depth understanding of both HTML and CSS, then yes, quite a lot of us will remain over-burdened in our day-to-day responsibilities.
That's just my take. As I am also a musician who plays both piano and oboe - I can use that as an analogy as well. I can teach _anyone_ piano. I cannot, at all, simply teach anyone oboe. They _must_ have an inclination towards it and I can literally bet my life savings every time that really good oboists also seem to be really quirky humans. I would put passionate CSS developers at the same table and I would expect them all to get along.
Your belief that you must use classes to apply CSS is false.
CSS is a generalization programming language, with specificity meant to be used for _exceptions_. Therefore, CSS should be used with general statements first, contextual statements next, utilitarian statements following, and then and only then exception-specific declaration in the edge cases they are needed.
Programming with CSS the way it was intended: Cascade, Inheritance, and then specificity, generally produces a quite DRY experience.
The one thing engineers/other programmers seem to have missed, continue to miss and seem intent on missing into the future is this: CSS is a static programming language that must account for being in and rendering dynamic contexts.
When I'm in JavaScript, I _depend_ on having the one thing, be the one thing, whenever I reach for it. I depend on immutability to keep my life sane.
When I'm in CSS, I _must_ account for flexibility, because I cannot predict the future, and I cannot predict all the various contexts in which my declaration might exist. Therefore, each CSS statement I create is based on how I would _like_ my thing to behave based upon a variety of circumstances, and to have static fallbacks when all else fails. My sanity is in producing the most responsive yet stable experience for the unknown.
Tersely, but without apology: Tailwind is for developers who do not want to take the time to learn CSS the same way they took time to learn JavaScript [or insert language of choice].
CSS is scalable. You have to actually know CSS in order to accomplish it. I've been here since mid-90s, when CSS first existed. It isn't until the past four or five years that things have really blossomed into (imho) what it should have been from the outset.
Unfortunately, since we have had to use filler tools for things like layout (tables, hacked flexbox for grid), CSS itself has taken a beating in perceived usefulness/weildability. I believe because of THAT, fewer and fewer people have decided to actually learn CSS.
CSS is a robust language. It is programmable. It is scalable. You just have to learn it, practice it, and approach problem solving from the top down, bottom up, and sometimes sideways. :-)
Yes - it came out earlier this week or end of last week. But CSS Grid has been available since 2017. So, we are able to still solve a lot of layout issues with grid, than leaning 100% on flexbox.
Every tool for its purpose! We have nearly a full toolbox on the CSS side of things. Happiness.
To be fair, we didnt get Grid till 2017. So.. we finally have (nearly) all the tools we need. Maybe. lol
Float is still very useful for paragraph wrapping around media, for basic alignment etc, when you do not need an entire flow of content to be under the management of flexbox. Less is more.
Oof. You are definitely missing the entire point of CSS Grid.
CSS Grid is a two dimensional layout tool. Flexbox is one.
CSS Grid is for architectural layout. Flexbox is for alignment and flow layout.
CSS Grid was enabled across all major platforms by October 2017. You've had two years to figure that out. You want it on IE? Then use CSS Grid's original syntax because Microsoft supported Grid first.
The browsers haven't "started implementing some layout tools" --- they literally did it, en masse, in 2017. Grid was available for everyone's use by October.
Do yourself another favor, and stop trying to make different layouts for all the different sizes. Or, go with insanity - your call. Grid is for responsive layout, out of the box; no negative margins, no weird padding, no inane extra workarounds just to get something to line up.
Once you understand that CSS Grid is the tool we have been waiting for since the late 90s, and that it, NOT Flexbox, is the sane, maintainable, future-proof layout tool for pages, and then using Flexbox within it to adjust flow and tempo -- you will/can spend a lot more time playing with things for the sake of play, and not for the sake of debugging.