In 2013, a company called Facebook introduced a framework called "React," which allowed developers to blend their JavaScript logic with their HTML code without having to modify the document directly.
This, my friends, was JSX, or JavaScript Extended, where you could write HTML within your JavaScript! I was just 9 years old, and I didn't know anything about programming, but the rest of the community had strong opinions about it when it was released.
"The audience was skeptical. Most people thought React was a significant step backward." - at JS ConfUS 29/05/2013
React was innovative because it challenged many established best practices of its time.
Separating JavaScript from HTML? Discarded.
Direct DOM manipulation? Discarded.
Two-way data flow? Discarded.
However, its boldness was a double-edged sword. Just as there were people excited about this innovation, others thought it didn't make sense. "Mixing JS with HTML? It will create more complexity and reduced maintainability.".
Some had been mixing JS and HTML before, such as in the MVC design pattern, which had a Model to manage logic, a View to render the UI, and a Controller to mediate between them.
Creating code that resembles React:
In computer science, there is a concept called "Separation of Concerns," which involves separating sections into their own contexts. In other words, you write your HTML in an HTML file, your CSS in a CSS file, and so on. This was a significant reason many opposed React.
Fast forward to today, React is the dominant framework. It's quite remarkable. But how does all of this relate to Tailwind? What about today?
Similar to React's history, Tailwind challenges many of the best practices we used to preach. Some people appreciate the advantages it offers, while others believe that the benefits don't outweigh the drawbacks.
Some dislike it due to its verbosity, but that doesn't make much sense (example in the image):
Verbosity - the quality of being wordy, speaking excessively, or using too many words to express oneself.
The real problem is with the "separation of concerns" mentioned earlier, and in this respect, Tailwind falls short. It's okay for CSS to have 1,000 lines if it has its own file, but a class with 1,000 words pollutes our HTML/JSX.
There are third-party libraries like Tailwind Fold, but there's no native solution that resolves this 100% and is considered a good practice (im looking to you @apply).
With this article, I didn't intend to persuade you or provide a solution, but rather to tell a story and help you understand that this kind of debate has occurred in the past.
As George Santayana said, "Those who cannot remember the past are condemned to repeat it."
Who knows, maybe in 10 years, Tailwind will also become one of the most famous ways to write CSS? Only time and its evolution will tell.
Anyway, thank you for reading!
Have a good day 😄
Top comments (60)
Actually, Tailwind is the next evolution in styling. Before CSS, we used to style elements like this:
However, this approach was deprecated with the introduction of CSS. With Tailwind, we are revisiting the concept, but instead of using attributes, we now put all styles in a
className
with shortened classes. This madness pushed me to come up with a new idea: importing styled React components from a CSS file, where all style manipulation can be done through component properties:Where
style.scss
file looks like this:For more information, please check out the demo and repository:
✨ Online demo
✨ GitHub repo
That's a super interesting idea! Loved the concept!
That tell's me all I need to know about your position on tech choices 😂
You might want to take a look at PandaCSS for a similar but framework agnostic approach.
There's nothing particularly unique about Panda CSS in terms of its idea or approach. Many CSS-in-JS libraries offer similar ways of styling.
Tailwind isn't a new idea either.
Yeah, but Tailwind made this approach popular, just as styled-components popularized CSS-in-JS. Other CSS-in-JS libraries introduced additional features, such as build-time extraction and shortened CSS classes, but in general, it is the styled component approach.
What I know is that there are several ways to style components:
P.S.: If I had to choose between Tailwind and PandaCSS, I would pick PandaCSS.
I think we're already there, unfortunately. In my experience, Tailwind is overwhelmingly loved by front-end developers.
There are reasons for hate. Take a look at this article. I'd suggest read other articles from this author too. It's not a plain dislike or taste based hate. It's well grounded position. But, well, language might be somewhat offensive to some framework lovers.
The biggest / most fair critique against tailwind I heard against is
p-1 text-sm
Here is an Article with said critique in more detail
nuejs.org/blog/tailwind-vs-semanti...
I feel like the critique comes most often from designers, who translate figma design into html/css and have less knowledge on how to write idiomatic react code.
First 2 problems are solved if
My biggest grip with react + tailwind is, that I wish I could shorten
className
to justc
orclass
, because it is such a long word to type out and it takes to much screen / line space.That's a good linked article.
The set of designers that do HTML/CSS development is definitely non-empty, but it's not the norm IME. Figma has also a decent Tailwind plugin for the matter, so they wouldn't even sweat to translate their design into Tailwind mashups.
I fail to see how tailwind-merge could improve readability, while the others basically throw one of the main advantages of Tailwind out of the window: eliminating the necessity of naming things.
I personally never write
className
in full, because the IDE suggests it right away when I type justc
, but I'm amazed to see that you considerclassName
"too long" while the value could be something likebg-white border-slate-100 transition-all duration-500 demo-dark:bg-slate-800 transition-all duration-500 demo-dark:border-slate-500 border-b rounded-t-xl p-4 pb-6 sm:p-10 sm:pb-8 lg:p-6 xl:p-10 xl:pb-8 space-y-6 sm:space-y-8 lg:space-y-6 xl:space-y-8
.I group similar tailwind classes together
Example:
somewhere in ui / utils
In the long lines of tailwind classes you provide
Separating into function components like in the example
Because it's not straight from the source - it's the output, taken directly from Tailwind's homepage. If I have to debug a problem, that's something the dev tools presents me.
Common answer: because I don't want to name things.
Definitely harder that reading plain CSS, yes.
There's solidjs, lit or preact that uses just class attribute
I understand the reasons, but I don't like it. I know that evolution is necessary, but I also see front-end as an amusement park without supervisors, there are good ideas emerging wildly, and just because it seems cool to me doesn't mean I'll go into production and have to deal with it in 5 years.
Lots of new technologies wanting to solve problems that aren't even problems yet, that will probably cause problems.
interesting point of view 🤔
we usually think about the now and not about the distant future, but that is something we should keep in mind as well, so, fair judgement I would say
In the end, it is your responsibility to choose what works for you. It’s always a the matter of: “can I afford this abstraction/solution or should I choose battle tested tech?”
It’s the matter of what you think will be most stable and scalable for you software.
For instance, I regret choosing prisma as an ORM. It’s great for basic projects, but for larger projects that you need more control over prisma is awful outside of it’s schema and migration tool.
Is it bad on its own? No, just not perfect for what we’re building for multiple query related reasons.
Love its typings though.
Anyway, I’m all for new tech. Just make your judgment whether you should or shouldn’t use it. Don’t trust the hype.
But even with all the hype around tailwind, I found it useful. I don’t care about css much. Just want things to work, and tailwind provides me that out of the box without having to care about building my own set of standards. And 90% of the time it works 100% of the time.
Separation of concerns is just another opinion from what software could be and it's a lazy way to measure if a language can or cannot provide what your business needs in CSS architecture.
Tailwind provides an easy interface to CSS by dropping most of its funcionalities and abstracting it's units and APIs. This is not wrong, not good for everything and hard to measure in an industry that sees CSS architecture as a liability. When we talk about CSS we can be sentimental about it, we can talk about perceived performance in how fast we code or how we feel when coding, and care less about how it makes sense in a business model and if it truly provides an API that does not rely on template and are tightly copled to an ecosystem providing functionality.
Today tailwind future is bright and we can afford not to think about CSS at all, and abstracting even further regarding of its limitations, and it's ok, even if it does not makes sense > every time < business wise as the community makes it.
As you said the wheels always turns, it's good to see some fresheness, but I wish the discussion regarding CSS technology were deeper than the surrounding Tailwind are. Knowing it's limitations is also a power that makes you use it wisely.
I hope this is just an unfortunate way you expressed yourself, because that would be a terrible approach. Tailwind does not save you to learn and think of CSS.
Yes It does. Don't get me wrong, theorically I'm with you. In practice people could care less what Tailwind outputs as CSS as long as it works layout-wise - and the industry doesn't seem to care as well, CSS architecture is hard to grasp, to mantain and to enforce certain patterns.
So when I say
I'm saying that you can write the most verbose, repetitive, media-query full class based CSS and don't ever open the devTools again nor check the output code as long as layout works, relying only in template based reuse, JIT and compression in matters of performance, as if it were enough (it isn't).
And that's the point. Because almost nothing works on the first try, you'll eventually have to debug, and understand what's going on. And devtools presents you CSS, not Tailwind - which is not, and will arguably never be - a first class citizen.
I won't even mention that Tailwind's own documentation is full of references to the corresponding CSS properties and/or mechanics, so you have to know CSS to understand what Tailwind means.
What you're imaging - an abstraction layer that renders knowing what's under the hood completely optional - is a pipe dream that will eventually collide with reality (and in the case of Tailwind it fortunately happens very soon).
It's not something we haven't seen in the frontend community, mind you. Back in the day, there were jQuery developers who hardly knew anything about the DOM or even JavaScript. More recently, we have React developers who get lost outside of it. Accumulating knowledge debt isn't a route with a good outlook, although it seems sufficient in the short term.
I really hope you are right, because when there is an error with jQuery, it'll certainly break the application. CSS errors, verbosity or misconceptions are way more cheaper and overlooked, even if the layout breaks at some point. I had this problem working with CSS, SCSS and even Styled codebases, but with Tailwind is worse, not only because the thicker abstraction layer, but the community around it.
The same idea is repeated with ORMs which in my opinion comes from a very greedy point of view: we don't have time to understand something in depth, we want it immediately.
This is not a bad thing, on its own, when you work on prototypes and do market-research and you try to land what exact features bring value to people.
But then, eventually, successful companies need to scale; they start serving more people, the amount of data grows very large under them and so on.
You can't afford not understanding how SQL works, how the specific database you use work. You would do tons of ineffective queries with an ORM that can be into 1 query 1 round-trip with a mid-level SQL knowledge.
Same is true with CSS: you can design a set of rules that are easy to change, but if you don't understand it, and with the magic framework for hiding it for you, you won't be able to achieve certain effects, you will struggle a lot with a design change, your code will be brittle and ineffective, because there were much simpler ways that even a mid-level CSS developer would have created for you.
Why I am angry with bootstrap and tailwind and the rest, that they are no longer sold as a great tool for rapid prototype; we are told that it is "evolution", it is the logic next step.
It is not! Neither are ORMs. You can't skip learning your craft. You will need it eventually.
Maybe we should look at the topic a little more generally...
HTML is not the first language to build User interfaces. If you write an application for windows, linux or apple, things are very similar. If you need an input field, you will define it in a similar manner you do in HTML. But in traditional applications, you do not have so much control over the appearance, in fact, most visual components are styled by the OS, not the application. This may limit the developer, but gives a better user experience. Companies like Apple have their Human Interface Guidelines to ensure a uniform user experice - something we would whish we had for web developers today.
HTML / CSS was initially not designed as a UI toolkit, it was designed to apply better styling to static documents. The more the web is used to build applications, the more the conceptual issuses of CSS/HTML will be visible. The web is evolving from a presentation platform to an application platform. Any modern CSS toolkit should support this evolution, so future will show, if tailywind does the job.
The false dichotomy of the day is this:
vs.
For a more eloquent great case against using utility classes please read this: every-layout.dev/rudiments/global-...
Now my short opinion. Locally styling each and every component is bad CSS practice. You should have a lean vocabulary of well-defined bigger components and shapes. You see,
CSS
is an exception-based language: you create a set of general rules, and then only write further ones, when you have to differ from those.Tailwind on the other hand, went full in with local styling.
When you have globally set general rules, you will have less changes required to change the appearance of the page. If anyone here remember CSS Zen garden, it was possible only because the classes on the items were semantic. CSS Zen garden would have never been possible using the tailwind approach.
Generating another style would instead mean to rewrite each and every component. Let's say: screen sizes grew and we can afford thicker margins? With tailwind approach now you have to go into each items and change those values. Because you have eliminated general rules from the equation, now everything is an exception.
This line:
<div class="px-0 pt-1 text-sm" />
means that you want an average<div>
except that it has no horizontal padding, it has 1 amount of top padding and it also has a special small set of font.If you are lucky enough someone in the team will have a brain to move it into "presentational" React component, that does nothing just the same thing
class="something"
would do.Imho Tailwind greatest strength is eliminate the abstraction layer between layout of HTML and CSS. Before Tailwind I need to be use a verbose and class link between HTML DOM and CSS, with boring name giving process. With Tailwind mandatory layout information is stay here where it is belong.
In this example easy to understand which layut setup are we build. Does not need to futher explanation.
The JSX format MVC concept is really simple: The return object is the
View
, the props or useContext is theModel
, and the hooks is theController
.You're forced to name things only because of the limitations of your framework of choice. How about this:
If you have a truly encapsulated stylesheet - even emulated - you could do this.
You are right this is the CSS solution but the problem is the selector:
main
andarticle
which is to global and it is affect all main and article. But the tailwind does not need to create instance name, and recreacte DOM selector in CSS side.I mentioned style encapsulation for a reason: those selectors would have a local scope only.
This has been possible for a while, even natively.
My example does not framework dependent, that DOM part can be written in plain HTML too.
I never mentioned any framework either. I said it's possible to do that natively.
Sorry I missunderstand you, In my point of view simple:
Is much easier mental model than
Because In first case you can immediatly know everything about your layout conception, elements and layouts directive with a well .
Why should you know what's the layout from the markup? The markup is for the content.
What I suggest is something like this:
with a corresponding CSS:
10 years? I believe that as the technological evolution is exponential, tailwind will evolve in less than 2 years for this to become an interesting factor!
v1.tailwindcss.com/docs/upcoming-c...
On the official Tailwind CSS website, there is a section called Upcoming Changes, which shows the updates and deprecations coming in the future and how to prepare for them. For example, they plan to remove the deprecated gap classes, change the purge mode for layers by default, and add default line heights to the font size classes. These changes are intended to simplify and improve the use of Tailwind CSS.
Tailwind is at version 3.3, and the changes you mention has long been done.