DEV Community

Discussion on: Say no to Tailwind, embrace plain CSS

Collapse
 
thethirdrace profile image
TheThirdRace • Edited

While I'm not a big fan of Tailwind, this article is all kind of wrongs...

Here's how I would have written the article instead.

Embrace the separation of concerns

Inline CSS, and the way tools like Tailwind are mainly used, may help you develop your project faster, but there are costs...

HTML shouldn't cross in CSS or JS territories

HTML should only contain content, hierarchy, structure and the necessary hooks to add interactivity and styling.

There's a huge advantage to separate the code from the hooks: reusability.

CSS example

CSS Zen Garden is an awesome example of this principle.

In CSS Zen Garden, you can completely transform the whole website by simply providing a new stylesheet. No code change whatsoever is needed beside including the new stylesheet.

JS example

With the modern "component first" approach, you already separate the structure from the actual interactivy code.

Let's say you have a Button component in React that goes like this:

export const Button = ({children, onClick}) => {
    return <button onClick={onClick}>{children}</button>
}
Enter fullscreen mode Exit fullscreen mode

As you'll immediately see, the onClick is passed as a prop.

But why? Well, because of reusability of course!

If you inline the code of the onClick directly in the Button component, that Button will only ever do that one trick. By passing the interactivity code through the prop, you can make the Button do pretty much anything. 1 vs infinite possibilities, the choice isn't hard to make...

Basically, you hooked the interactivity code in the Button structure, but you kept the actual code separated.

The advantages are obvious to proceed this way, I don't think I need to explain any longer than that...

Conclusion

The real choice here is: do you need the reusability?

If you want to reuse components between projects, you need them to be agnostic in styles and interactivity code. This could help you scale multiple projects much faster and keep bugs minimal since everything can be fixed at only 1 place. There are huge scaling advantage going this way.

If you don't need to reuse components between projects, then it's a matter of preference between inlining or not.

Inlining the styles will definitely speed up the project's development, less abstraction equals less code, less bugs, less maintenance, etc.

Personally, the reusability is the deal breaker for me. If I always need to start from scratch, then I feel I didn't do my job right. I understand it might be "right" for a project given the time tables and goals, but at that point I wouldn't be the "right" person for the job. But that's just me, different people have different goals, let's leave it at that... 😅