loading...

re: What are your thoughts on Tailwind CSS? VIEW POST

FULL DISCUSSION
 

None had mentioned yet that it enables non-css devs to do css. I'm a backend dev who wrote a beautiful Web app not knowing css language.
Being a css hater I'm a tailwind lover. ❤️

My .vue files do not have <style> blocks. All visual styling is in <template> part.

 

As a backend dev, don't you find this violates separation of concerns? The HTML should have no knowledge or care about the appearance it has, which Tailwind classes do. However, Tailwind could be used if you're using a preprocessor like SASS or LESS, using classes in the HTML that describe the element/component and then building your CSS based on extending the Tailwind styles.

 

I find that most developers misuse the word "concern". Often Frontend devs think that technology is concern. But CSS or HTML or JavaScript are not concerns. They are technologies, languages.

Here is what Wikipedia says:

When concerns are well-separated, there are more opportunities for module upgrade, reuse, and independent development. Hiding the implementation details of modules behind an interface enables improving or modifying a single concern's section of code without having to know the details of other sections and without having to make corresponding changes to those other sections.

The less files you need to edit to make a necessary change - the better your concerns are separated. (Hence I like Vue.js.)

In other words a concern is: a searchable drop down component, or a user profile page, or a login form, or feature of some kind. But not a programming language.

Tailwind is the next step in the concern separation game. My HTML and classes (and some JavaScript) are blended together within the <template>. It allows me to drop <style> and the css language altogether. Thus concentrating my concern more within the <template>.

Having fewer files to update doesn't really mean you've separated concerns. An extreme example is the typical spaghetti code where your entire app logic is within 1 or 2 files.

Blending multiple languages together into a single file feels very much like the opposite of SoC. The code is tightly coupled both ways, the HTML depends on the specifics of Tailwind, making it very difficult to move or change in the future. Think about it in terms of dependency injection. You should remove tight coupling, and ensure that each layer only knows about the it's immediate relations.

the HTML depends on the specifics of Tailwind, making it very difficult to move or change in the future.

It's actually vice versa. It was very easy to move and change a component written with Tailwind. Extremaly easy. 😉

But you're putting the responsibility of appearance on the HTML, which it shouldn't care about. I realise it makes things easier for a backend dev that doesn't know much about the front end, but it's basically the equivalent of not using dependency injection because you prefer each class to create all the instances of everything it needs by itself. Sure, it works, and it can be done very quickly, but it's not clean, and it isn't going to be very maintainable at scale.

If you Google other people opinions on Tailwind you'll find numerous claims that it is actually more scalable, more maintainable.

To believe all those people you'd need to try it yourself.

Let's close this thread until you compare the traditional semantic CSS with Tailwind yourself on a real project.

Cheers! 😀

twitter.com/lesliecdubs/status/122...
I found this just now. A poll on twitter. 😀

Hi @ashley , I like that you are fond of separating the concerns but when it comes to HTML and CSS whether you put them in a different file or not when you make changes you'd have to touch both of them as the HTML fully relies on the specifics of its design from CSS.

Tell that to the people who produce the wonderful designs at CSS Zen Garden. The HTML absolutely does not need to change with the CSS whenever there are changes.

It certainly does not!

But the reality is that 80% of the time HTML and CSS have to be changed simultaneously.

That's usually down to developers not separating concerns correctly. If it's adding/removing content, sure, that makes sense, but if it's just because you need to change the appearance of something, then it's a sure sign that something wasn't done in the cleanest way.

I think this can stem from two scenarios: devs who are up against the wall with a tight deadline (this is probably the number one reason for unclean code), or devs who aren't as experienced with frontend and don't know the best approach to a particular task. These scenarios happen, and they will always happen. What we should constantly try and do though is always learn and strive to do things the best way possible. Tailwind voids separation of concerns, and contributes (in a bad way) to the overall file size of the page. That's absolutely not the best thing to do for the web.

Tailwind improves separation of concerns IMO.

AND
Maaate, your are so very wrong by saying that Tailwind increases page size. Actually, it's quite the opposite. Full gzipped CSS is 10-20kb for large websites. And 5kb for my entire medium website (~20 pages).

Again, you have no ideas what you are taking about until your try it.

I can't explain what is a red colour to a blind person who never saw it.

If you're counting page size only on the Gzip version, then you're missing the point. Total bytes downloaded is a metric, but not the only important one. Lots of repeated code makes for absolutely amazing gz compression resulting in very small downloaded bytes, but it still has to be uncompressed, parsed, etc, all of which can have a pretty major impact on devices on the lower end of the capability spectrum. Look at both compressed and uncompressed. It's not an absolute 1:1 match against required processing power on the end users device, but it's a fairly good indicator.

What's the point of measuring uncompressed if the entire internet delivers compressed?
Also, uncompressed Tailwind is also much smaller than the classic Semantic CSS approach.

I feel like you're looking for any excuse to prove that I'm wrong just to prove that I'm wrong without even googling anything about Tailwind. 😂

We measure compressed for transport performance, and uncompressed for performance on lower end devices. If a file is 50kB uncompressed, that's alright (although still very high for something like a blog or personal website), but if it uncomressed to 1MB, then it has a big impact on devices with less power (basically what a huge chunk of the world is using). The bigger the file, the more memory it requires to hold (a low end device doesn't have an unlimited amount of memory), and it requires more processing power to parse, thus leading to longer delays on First Meaningful Paint (FMP), more impact against battery life, etc.

You say I need to Google things before replying, but I feel that you don't actually understand the points I'm making. I understand what you're saying, but your arguments aren't refuting my points, so there's nothing yet for me to "Google".

Tailwind final CSS file (unzipped) is about 10-20 times smaller comparing to traditional semantic CSS approach.

Again, try Tailwind before bashing it.

Tailwind final CSS file (unzipped) is about 10-20 times smaller comparing to traditional semantic CSS approach.

Is it really? That number seems like it might be a wild guess without substantiation. Just by looking at a few sites using it, you can see that most often, the produced files are large (taken from a list of top sites using Tailwind, and Tailwinds own site):

Site Compressed Uncompressed
tailwindcss.com 19.15kB 110.21kB
support.zwift.com 127.85kB 1.84MB
loyalcompanion.com 57.77kB 390.61kB
fri.uni-lj.si 186.62kB 1.84MB
quad.hw.com 127.85kB 1.84MB
holstee.com 95.82kB 694.33kB
dmc-modesto.com 61.5kB 329.36kB
delraymedicalctr.com 61.5kB 329.36kB
wigwamwonderland.co.uk 52.81kB 301.19kB
askfavr.com 113.43 1.02MB

If a websites CSS file is in the hundreds of kB uncompressed, that's not great, but if it reaches MB, then something is awfully wrong.

Now, you could argue that this is just because they haven't got any kind of purge/pruning as a part of their build process, but that same argument could be made of any CSS, it's not a unique thing that only Tailwind has, so it's not a factor. What absolutely is a factor is the default, and as you can see from a couple of these websites that include the default (non custom) Tailwind CSS, the result is in the MB end of the scale.

You can ignore this if you don't know or care about the impact this has on low powered devices (e.g. mobiles, which is what most of the worlds web browsing is performed on these days) but that doesn't actually make the problem go away.

So, you can keep on requesting that I "try Tailwind before bashing it", but I think I have shown that I do understand what I'm arguing. I'm not trying to downplay your own development experience, but I am not wholly certain you understand the point I'm trying to make.

Mate. PurgeCSS is built into Tailwind-css. No one uses Tailwind without PurgeCSS.

Also, that number is coming from my two large projects.

I'm trying to tell that your point is based on false (or lacking) info.

Before bashing anything your should study it.

Ehm. Ashley just provided you exact numbers - so your assertion, that "no one uses Tailwind without PurgeCSS" is already proved to be wrong, before you wrote that. And your main argument is, that Ashley is false because YOU think he hasn't tried it. Thats not an argument for (or against tailwind), thats just bad argumentation style.

I want to pick up one main point in your argumentation:
"The less files you need to edit to make a necessary change - the better your concerns are separated."

If this is true, than tailwind is really bad in separation of concerns. Let's think about a simple example: Lets say we have a website with multiple forms on it. We decide to make all form elements have a grey text color and round corners so we add to douzens of files (doesn't matter if its HTML, Vue, Blade, Twig or whatever) these tailwind classes. Some days later, a designer (or the CI team) decides, that all form elements should be with green text color and without a border.

Now the 1000$ question - how many files do you have to update if you use tailwind? How many if you use for example bootstrap?

And if you are talking about file sizes and performance - CSS (zipped or unzipped) is just one messurment (and tailwind isn't that great in this category either). What about HTML size? Surfing on a website visiting 30 pages of it, I will only download (and parse) the css one time, but the HTML 30 times. So what is smaller and faster:

Tailwind:

<button class="bg-blue-500 hover:bg-blue-700 text-white 
    font-bold py-2 px-4 rounded">
  Button
</button>

Traditional aproach

<button class="btn btn-primary">
  Button
</button>

May I ask you to watch this 17 min video before making any more false statements?
youtube.com/watch?v=R50q4NES6Iw

image

First of all - this comparison isn't a very good argument for your point. It shows, that uncompressed html with utility-first is just trash. Gzip is worse and only with brotli it is minimal better (0.8 kb).

You also mentioned, that utility first is soooo easy, but it only perform well, if you add extra steps to it, so you weaking your own point.

Second: This comparision isn't fair at all. She compares an "old" version of a side, which grews over time with a completle new created, optimzied version. Its like you would say - hey, my new Honda is much better then my 30 years old BMW.

To be fair, a lot of the arguments in the video are true or some kind of true. But she basically only picks aspects, where utility-first aproach is performing well. The aspects which dont fit well for her point are ignored or she just says "its ugly, but live with it". She also compares more or less "hardcore" sematic vs "utility first" mixed with semantic ("create button classes") and promote it as a feature of utility first only.

I totally understand, that the new kid in the block has to show his muscles, but this "I am the new super hero for all cases and everything what we have done till now is wrong," behavior is just stupid.

Let's just see if it's better than the existing CSS frameworks. Time will tell.

twitter.com/GuamHat/status/1316845...

 

Hey mate. Just found this little tweet for you. It's doing a better job to explain things than me in this thread.
twitter.com/drewm/status/122940127...

It's explaining the same things in slightly different ways. I still don't think that my points are fully addressed within the first few dozen comments. In-fact, one of the prevailingly common comments in that thread is that it makes styling easier for non-CSS developers, which to me is an indication that those developers don't care about the quality of the CSS (how can they if they don't know CSS and aren't actually writing it?).

It might work fine for them, but it's a bit like using a hammer to force screws into wood. Over time the workmanship of the whole thing will suffer.

However, I see we will never agree about the merits of Tailwind, and that's the great thing about this kind of technology, the very fact that we can disagree on the tech ultimately means that we get better tech in the future.

Yes, It is good to separate concerns.

But if you look at bootstrap the most popular css framework, you will notice that it is mixing the styles and the html template too.

When using bootstrap, you put bootstrap's style classes into the html. So it is not fair to say that tailwind is bad because it is violating the separation of concerns.

Being a hard core backend developer and trying to write clean code, you may hesitate to use tailwind and its utility approach. But more and more people, are coming to enjoy utility approach. Most ui frameworks are based on utility first approach.

However, when building my own site, I did not use any ui framework. I tried to do it in the cleanest way so chose to do it with scss + flexbox + BEM. Not many irrelevant style classes. But I have to say this approach may take more time.

Again and again and again people think that CSS or HTML are concerns. Remember.

  • CSS is not a concern.
  • HTML is not a concern.
  • JS is not a concern.
  • Any other technology is not a concern.

A concern is synonymous to the word feature. (See Wikipedia for example.)

Your need to separate FEATURES, not technologies.

Not quite. Dependecies of anything should be limited to one way. It's quite ridiculous to be specifying so many classes in the HTML for styling, and it means that it a) doesn't lend itself very well to a component based system and b) ties itself too closely to Tailwind, meaning it's almost impossible to break from it cleanly in the future unless you create something that mirrors the exact behavior of Tailwind.

Oh, and as for the filesize of Tailwind: over 1½MB uncompressed. That's way too much for the browser to be expected to parse on a low end mobile device.

50kb is my uncompressed Tailwind file. Because Tailwind goes together with PurgeCSS.

Mate, I beg you. Just google it before writing this nonsense. This is basics.

Ashley Sheridan, I find your angle about saying that hmtl/css/js to be separated is fairly incomplete. If you think about everything that exists in any decent piece of software, then everything is a tree of components (or views, or divs or whatever you call them) and these things will have some associated styling perhaps, some logic perhaps etc)

It makes most sense for these things, if they exist in one place, to be defined in the component. What you then want is a mechanism for moving styling or logic to a more global place, if it makes sense to. But lots of the time, it makes sense to have it next to the place that it's needed.

Separating for the sake of it is like just introducing a service orientated architecture or micro services, just because.

Also, it's like organising by technology, rather than by feature, which I think makes a lot more sense. A big folder of all controllers or views (as many frameworks organise) doesn't really make sense to me, once you've done a lot of organising by feature.

Ashley, this talk clarifies Vasyl's points. They specifically address separation of concerns, clarifying that even CSS garden isn't separated as you believe. Because although the html has no awareness of the css, the css is fully aware of the html. Should the html change, the css breaks.

I started listening to the talk as a skeptic, and it really cleared things up for me.

youtu.be/R50q4NES6Iw

 

If you dislike CSS then should you really be working with the frontend at all?, tailwind is also a complete violation of separation of concerns

 

Separation of concerns is not separation by technology.
Concern is a synonym to feature, or page, or component.
See Wikipedia.

See Wikipedia.

"A concern can be as general as the details of database interaction or as specific as performing a primitive calculation, depending on the level of conversation between developers and the program being discussed. IBM uses the term concern space to describe the sectioning of conceptual information."

Separation of concerns is not separation by technology.

The separation was never about "technology" (or file types, though unfortunately it's an extremely common misconception even in the Vue documentation). The separation comes from the web browser's approach to fault tolerance and resilience. That approach ultimately lead to the practice of progressive enhancement.

Aside: The Resilient Web, Chapter 5: Layers

As Aaron Gustafson put it:

  1. Content is the foundation
  2. Markup is an enhancement
  3. Visual Design is an enhancement
  4. Interaction is an enhancement

(And then SPAs (with native-envy; initially targeting desktop) made it all about JavaScript)

So in terms of concerns

  1. Structured Content (HTML)
  2. Visual Design (CSS)
  3. Interactivity (JavaScript)

The technologies are simply a consequence of the intentional layering of making content the top priority.

And if you look at OOCSS you'll find that even within CSS there are multiple concerns - for example: separate structure and skin - i.e. while a module/block should have autonomy over it's structure, the definition of it's skin should be separate (otherwise theming the module in accordance to the page/site as a whole becomes impossible).

Modern JS frameworks tend ignore this separation because they are all about JavaScript. To this day browsers still process HTML, CSS (layout), and JavaScript (behaviour) separately and a lot of the performance strategies focus on preventing JavaScript from blocking the other two layers from doing their job.

  • JSX isn't markup. It's a domain specific language with an XML-style syntax which only exists to generate JavaScript.
  • Similarly the template in Vue's single file component simply exists to generate JavaScript. At least the CSS styles can be extracted separately.

So none of these technologies conform to the "browser layers" because everything is just collapsed into the JavaScript layer. That is why SSR has to be used to get some of the performance benefits of "the layers" back.

Some argue that it's time to build the "application web" but the current layering acknowledges that the network is never going to be perfect. For the "document web" the tradeoffs are clear - content is king while visual design and interactivity are expendable. What are the tradeoffs that the "application web" can make when things start going south? Many "modern web apps" will only work under near perfect conditions, don't degrade gracefully, much less have their own vision of what progressive enhancement should look like.

Douglas Crockford wrote in 2008: "JavaScript is most despised because it isn’t some other language. If you are good in some other language and you have to program in an environment that only supports JavaScript, then you are forced to use JavaScript, and that is annoying."

These days "the web" is similarly despised. Seems many want to develop for the web as if they're developing a desktop application or at least some native application. That ignores that the web by its nature is distributed - there is no abstracting that away. And while native apps may use the network they are typically much less constrained by it. The browser's ServiceWorker API tries to make "the network an enhancement" by creating the opportunity to cache all essential parts of a web site for offline use but in general browser-based apps have to operate under more severe constraints than native apps.

Aside: Web vs. native redux (2015)

Another issue is that while the web strives to be a universal platform it isn't one platform - which is why people coming from (or wishing for) a more monolithic environment judge many web technologies (including CSS) as weird.

Aside: Front end and back end (2015)
Aside: Web development as a hack of hacks (2016)

CSS seems especially weird to software developers as visual design composes very differently from software. Object orientation values encapsulation, functional programming values functional purity and immutability. In contrast a "visual component" has to maintain its structural integrity while also having to adapt to its surroundings in order to become a "harmonious part of the visual whole" - so defining styles to compose visually is very different from composing software behaviours.

Aside: Don't QWOP Your Way Through CSS (2017)
Aside: You'd be better at css if you knew how it worked (2019)

Point being: The familiarity heuristic will lead you to favour tools aligned with your current mindset. However when the domain requires a significant shift in thinking (e.g. from software development to visual design, styling) then a shift in mindset is required to become truly effective (rather than subjectively productive; many paths to "apparent productivity" can compromise quality) - no tool can replace that necessary shift in mindset.

Perhaps that may explain statements like:
"I don’t think it’s a coincidence that back-end developers have written most functional CSS libraries."

Other more design-minded opinions seem to range from "it's useful for prototyping" (not for the final product) to "if it works for you, why fix it". But that's hardy a universal endorsement and doesn't explain the "best thing since sliced bread" popularity. That is explained by:

  • Editor support for choosing utility classes
  • Dispensing with (ignoring?) the need to identify appropriate abstractions and names (don't make me think)
  • Leading to a sense on increased productivity

I'm still skeptical that this approach is maintainable in the long run as style-centric classnames convey no intent behind (or provide any meaningful organization of) the selected property values - just because the values are right in front of you doesn't explain what particular aspect of the visual design/component they support.

This is a deep write up.
Has to be an article.
Do you want to post it separately (as a post, not a comment) for further discussion?

Not sure it's worthy of an article - right now it's more a collection of thoughts (and links to background information) that highlight some inherent characteristics of the web that a lot of people (and tools) just want to make "go away" (whether that's reasonable or not).

While I may have given a different perspective of what "separation of concerns" means in reference to web browsers that doesn't really put it into relation to Tailwind CSS. Adam Wathan actually does note in his article that "separation of concerns" isn't the core issue:

Instead, think about dependency direction.

He goes on to rationalize why it's OK for HTML to depend on CSS:

  • CSS that depends on HTML: HTML is restyleable, but your CSS is not reusable.
  • HTML that depends on CSS: CSS is reusable, but your HTML is not restyleable.

By emphasizing "reusable CSS" he justifies HTML that depends on CSS.

This can be judged as either "clever" or "very wrong".

"Clever" because "HTML that depends on CSS" gives permission to drop the loose coupling that approaches like BEM invest in and replace it with HTML to CSS tight coupling. While typically loose coupling is highly valued it does tend to create extra work - so if you invest in loose coupling where it doesn't show a return it's a pure waste. This tight coupling manifests itself in the style-based class naming that is used in the HTML. Ditching the indirection of a loosely coupled (meta) naming system is going to save work - "reusing CSS" serves as an additional incentive to embrace the HTML to CSS tight coupling.

"Very Wrong" because of the fundamental notion of "Visual Design is an enhancement" (see previous comment). HTML and CSS are often described as being co-dependent - largely because it is sometimes necessary to add elements and class names to markup to expose additional binding sites for styling (though divitis and classitis describes an overuse of that practice).

In my view the reliance of CSS on selectors tightly couples CSS to HTML structure. CSS declarations with selectors that don't bind to any HTML are essentially dead code - this is why Tailwind CSS has to use PurgeCSS to eliminate dead CSS.

  • CSS is tightly coupled to HTML due to CSS selectors binding to the HTML markup structure
  • HTML is tightly coupled to CSS due to style-based class names

Typically bidirectional tight coupling is only a good thing if both ends are part of one cohesive whole - but:

  1. Content is the foundation
  2. Markup is an enhancement
  3. Visual Design is an enhancement

i.e. while visual design builds on markup there is a distinct separation between both which is why people keep bringing up "separation of concerns".

Approaches like BEM accept the inherent CSS to HTML tight coupling and invest in HTML to CSS loose coupling (via naming that isn't style specific).
Giving Tailwind CSS the benefit of the doubt, it tries to weaken the inherent CSS to HTML coupling by supplying a library of predefined selectors (lessening the need to work in style sheets) in order to exploit the perceived benefits of HTML to CSS tight coupling.

At the very least it should be acknowledged that Tailwind's approach goes against the grain of CSS.

In this context HTML, CSS, and Dependency Direction makes an interesting observation:

we don’t have any long-term data to tell what difference HTML ← CSS (HTML depending on CSS) and CSS ← HTML (CSS depending on HTML) make.

The Tailwind CSS community reports that editing HTML is more productive than CSS.

But I've also observed that individuals who like CSS often don't see the need for Tailwind CSS (e.g. Two cheers for Tailwind, Why I Haven't Jumped on the Tailwind CSS Bandwagon). This gives rise to the hypothesis that perhaps Tailwind CSS adopters feel more productive editing HTML because they are more comfortable editing HTML (i.e. they don't feel comfortable with the way CSS works).

In my view the preference to edit HTML can be problematic. In a comment to her talk "In Defense of Utility-First CSS"" Sarah Dayan states:

If you need to change black titles to red titles, you need a new utility class for red text, and use it in place of the former. Depending on your project, this may either require a find/replace in your codebase, or a single change in a template component (instead of in a CSS abstraction).

??? To me this sounds akin to endorsing changing a JS constant name from const TITLE_BLACK = '#000000'; to const TITLE_RED = '#FF0000'; rather than using const TITLE_COLOR = '#000000';to begin with. This is where the indirection of names that are not based on style values pays off. Furthermore the change from black to red may affect titles in more than one template component but not all black titles in all template components. It doesn't always make sense to capture every styling abstraction above the level of a utility as a template component - like capturing a particular style of title (for the sake of consistency). Also not every useful aggregation of styles warrants a separate template component - aggregate style boundaries can exist within template component boundaries. There is also an overemphasis on reuse and elimination of duplication. Abstractions sometimes simply identify meaningful boundaries even if they they only occur in one single place (while duplication isn't always a sign that there is an (or just one) abstraction waiting to be uncovered). I wouldn't classify the same title style in multiple components as a case of reuse but as a demarcation of a common aspect across various template components.

Back to Adam Wathan's 2017 article - he really zeros in on "CSS reuse" citing About HTML semantics and front-end architecture (2012) as the inspiration for coming to the conclusion:

The more a component does, or the more specific a component is, the harder it is to reuse.

Again "reuse" (rather than demarcation of meaningful boundaries) is being cited as the all important objective. This is the justification for using single property/value utilities as the basic building blocks (pre-built "lego blocks").

In my view that isn't the primary reuse mechanism that the design of CSS had in mind.

In 2016 Harry Roberts published his ITCSS architecture (for one current implementation see web.dev). ITCSS essentially lays out a strategy for wrangling CSS in a way that plays to the strengths of CSS. "Reuse" in the large is accomplished through global styles with a wide reach while narrow reach overrides are responsible for local styling; reuse in the small is largely left to mixins (see also mixin, BEMIT and CSS guide).

Aside: CSS Is Certainly Global And That’s Exactly The Point (2020)

There isn't anything that I can see in Tailwind CSS that encourages "reuse - the CSS way" (it's not actively discouraged either but exploiting it requires an understanding of how CSS works). Template components may repeatedly apply identical properties which really should be candidates for promotion to a "more global" reach via the cascade; leaving this type of duplication in place creates the opportunity for the "look and feel" of the components to "fall out of sync" when changes are only applied to some of them. Always maintaining a style guide could go a long way towards detecting these type of problems early.

In my judgement these type of problems result from the bottom-up approach to styling that is commonly found in the CSS-in-JS type approaches of component design styling. CSS itself is more of a top-down technology - set the overall global environment then override locally only when absolutely necessary. ITCSS coordinates between the top-down nature of CSS and the more local nature of components.

Recently Andy Bell introduced his CUBE CSS methodology which uses utilities but also incorporates some of the ITCSS insights. The first thing to note is that CUBE blends the top-down nature of CSS with the bottom-up approach of utilities - given that composition comes first, top-down gets the first pass. This mirrors "designing the system" before "implementing the components" in software development. The difference being that composition isn't just responsible for identifying the gross layout but also the global styles (i.e. establishing the overall "environment" of the page). And while a utility (generated by Gorko) can be just a rule with a single property/value, it isn't constrained to that. What is important is that it "does one job and does that job well" which can take multiple CSS properties
(aside: Anybody thinking "Single Responsibility Principle"? - that refers to: "Gather together those things that change for the same reason, and separate those things that change for different reasons." - "same reason to change" isn't the same as "single responsibility"; another case of bad naming).
Also "blocks" still have a role to play, whether or not they coincide with the boundaries of behavioural components doesn't matter.

So again I think that Tailwind CSS's definition of "reuse" deviates from the intent behind CSS.

Ran across this interesting tweet:

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.

... and further down:

I think buttons are still a good use case for custom classes in a lot of projects
I’m really more just bitter about all of the complexity and bugs apply leads to in Tailwind itself, wish we would have just offered the theme helper instead which is bullet proof.

My only conclusion here is "there is no getting away from knowing the fundamentals" - but that was an open secret even in the Bootstrap days; people just chose to ignore it.

Another observation:

Tailwind CSS users! Tell me what you like about Tailwind.

A point that keeps coming up:

easier to author by non css people

Now it's great to have such an empowering tool and Tailwind CSS operates at a lower level than Bootstrap - but from I can tell using Tailwind CSS doesn't contribute to understanding what makes CSS tick.

Frameworks have the potential to inhibit a deeper understanding of the things they abstract, which is the web platform.

radEventListener: a Tale of Client-side Framework Performance (2020)

This is a recurring theme with lots of popular front end tools - jQuery devalued JavaScript skills, React devalues Browser Web API skills, Bootstrap devalues CSS skills etc., etc., etc.

Aside: Tools don’t solve the web’s problems, they ARE the problem (2015)

From testimonials it's clear that Tailwind CSS:

  • is popular
  • has a number of short term benefits
  • is deemed useful over a wide range of use cases by those who have chosen to adopt it

As a result Tailwind CSS seems to be evangelized heavily but there seems to be a lack of clarity regarding applicability, deliberate tradeoffs, objective caveats, and potential long term (undesirable) consequences.

Mate. Create a post from this. Call it "just raw thoughts" or something. But it should not be lost in comments section here.
Well written stuff!

 

It's not a violation of SoC. Rather than do a bad job explaining it myself watch this talk which articulates it well.

youtu.be/R50q4NES6Iw

Code of Conduct Report abuse