Back in the very early 2010s, when I started my programming journey, I used to do a lot of web development. More specifically it was PHP, Javascript, and CSS. Of course, HTML. Working with CSS was fun those days. I was building projects amaturely. Did you notice, that I said these are projects, not products? There is a clear difference between them.
The same story follows for 4 to 5 years. After that, I started working more on the backend in the current company I work in. Most of the time I would be doing python to be specific. It is completely a different world compared to the frontend.
Long story short, I used to be frontend developer a long time back, then moved to backend and beyond. I can confidently say that I understand the joy and pain of writing CSS at the same time I know how different frontend development is from the backend.
I can classify my experience with CSS in the following way
- Plain CSS era
- SCSS era
- Bootstrap era
All were best at their time and they come with pros and cons. I don’t talk about the pros here, because this story is not related to that. Today, looking behind, after widening my knowledge about building products that can scale, I can pick a few pain points about each of these eras. Here are few
CSS and SCSS
CSS is the low-level technology that supports styling in HTML. SCSS is a post-processor for CSS. So, they both are almost the same in the context of this topic. As these are low-level blocks, it is most powerful. It is both an advantage and disadvantage at the same time. As the saying
Power comes with responsibility
In the context of engineering, building products, responsibility means, drawing borders, being disciplined, maintaining them, etc. When we are a team of 10 people having this level of control is very hard. We end up having a skin for the app which is inconsistent. I will talk about the problems more in the following sections
Another pressing problem is, that when reviewing the code, it is hard to review so many lines of CSS code. The reviewer needs to be really careful of what colors are being used, pixel-level detail, responsiveness, and so on. I feel reviewing backend code is a lot easier than reviewing frontend code.
Bootstrap
To be frank, bootstrap was the savior of all the above problems. It provides grid structure, components like Button, Form, Input and gives beautiful styling for them. We had to write very few lines of CSS to bring up a bootstrap app. So, many people started porting their apps to Bootstrap those days.
If you see the above statistics from w3techs, even today, Bootstrap holds the majority of the usage share. It is well received and adopted. Well, this is where everything goes wrong. At least 5 out of 10 of the web apps you visit, you end up seeing a Bootstrap-based app. As I mentioned above, Bootstrap provides ready-made components that people can use. You can only customize them to some extent. It is not that you cannot override the skin of the components with custom CSS, but then, there is no point in using Bootstrap if that is the case.
People slowly understood that it is better to customize the Bootstrap as little as possible or just as well don’t use it in the first place to make sure that the app looks different than what a typical Bootstrap skin looks. First one is clearly not an option because you cannot make it look the way you want unless you override the styles. So what to do now?
Separately, apart from the CSS and styling, the control part of the web app, that is the Javascript also evolved with time. It evolved at a pace that no other technology could match. Initially, it was plain Javascript, then people adopted jQuery a lot, then Angular, and now React, Vue and Svelte are very popular and are holding a majority share.
Currently, we stand at this place where we need a better solution that works well with React/Vue/Svelte ecosystem which solves all problems with Bootstrap or similar kinds of frameworks. Here evolves, the Tailwind.
Tailwind
As of the time of writing this article, this is what the official website of Tailwind says -
Rapidly build modern websites without ever leaving your HTML.
So, their intention is clear, you write styles for the HTML in HTML. As simple as that. Before discussing more on it, let me show you how it looks when we use it.
<div class=”p-4 flex justify-center items-center text-slate-600 text-lg”>Hello world!</div>
Isn’t it funny that it is the same as passing the inline styles in the style attribute?
<div style=”padding: 4px; display: flex; justify-content: center; align-items: center; font-size: 18px; color: #eeeeee”>Hello world!</div>
What is the point of using Tailwind if this is the case?
Back from the CSS section, the major problem with CSS is, it gives more control and power that is hard to maintain when we work as a team at scale. This is where Tailwind shines. It takes away few controls like, defining pixel level styling, using any random colors, etc. Tailwind provides its own units and you just use them. These units get adjusted for different screens without any issues.
The second advantage is, that we write very few lines of code for styling stuff. We could achieve the same by using inline styling but we never did it. We always created a style.css file for each component/section/layer and keep CSS there. This brings down the code review times drastically. The reviewer need not worry much about styling now because Tailwind already takes care of it, the reviewer can just review the control part of the app. In my opinion and experience, this is the best advantage of using Tailwind.
If you compare Tailwind with Bootstrap, wait, this comparison does not make sense in the first place. Bootstrap is a UI framework whereas Tailwind is just a utility for writing CSS. To be clear, Tailwind does not provide you the components like Button or Card. All it provides is class names for styles. It does not compel you to follow any UI structure/layout. So, every app looks different from each other at the same time building the UI the way we want.
You might argue that if you add more and more class names, we will end up repeating the same class name, with long class name lines, etc. The reason I mentioned Javascript libraries above is, that currently almost all frontend frameworks like React support component-based UI. We should create a reusable component as much as possible. If there is some HTML element with so many class names, that means it deserves to be an independent component. In my opinion, this nature of Tailwind complements React philosophy of component-based UI. So, it is a win-win.
I am not saying Tailwind solves all the problems. You still need to have discipline, maintain the structure, CSS knowledge, and be consistent across the app. But for sure it is easier to maintain, build and scale compared to plain CSS/SCSS or Bootstrap kind of frameworks.
Summary
Plain CSS is powerful which means we need to be responsible for it that is maintaining it. On the other hand, Bootstrap kind of UI frameworks solve this problem but they enforce the UI structure/layout. Either we have to override its CSS or don’t use it all. As of now, in the current era of React kind of frameworks, Tailwind solves the above problems by providing an easy way of styling the HTML without enforcing the layout the same time not giving too much customization (power)
I hope this blog helps you in some way. Thanks for reading it. I tweet about engineering, product development, SaaS, and more. Follow me @pramodk73. Cheers!
Top comments (0)