Thoughts on Tailwind, CSS, and Vue

First, the real reason I'm writing this article is to test out the 'previous' and 'next' buttons I'm adding to each article page.

So while I'm here creating this place holder, I've got some thoughts about CSS and Tailwind and Vue.

CSS thoughts

I got an MS in information systems in 2003, so classes were hyper-focused on the web. Lots of talk about how to divide the information from the presentation, how to build web servers, user-driven design, and more. jQuery was still cutting edge.

So CSS was pretty amazing, even thought browser manufacturers made it really difficult to write a page that looked good everyplace.

CSS resets came from this (as you probably know) so that after you reset, you could write styles that were mostly portable across all browsers.

But as projects got larger, CSS got more and more confusing. A CSS file for a mid-sized site could easily have thousands of lines. Things got complicated, quickly, and maintaining the CSS next to the HTML & Javascript was frustrating as you needed lots of side-by-side windows, browsers open for preview, and so on.

SCSS, et al.

Next, folks decided to try to make CSS easier with things like variables and compiling files and (eventually) tree shaking out all the CSS dead wood that accumulates as files reach 1000s of lines and it's not easy to know what's needed and what's not.

Grunt and Gulp and Webpack and Babel all helped deal with this, running 'pre-processors' on the raw files (SCSS or CSS or whatever) to bring some efficiency to the setup.

Naming conventions like BEM were devised to make it easier to build large CSS files and (a) make them human readable and (b) help connect the selector to the benefit/result it delivered on the screen.

Component-based javascript frameworks, breaking the separation of concerns

React and crew came along and started to change things. (Well, to be honest, Backbone and Ember and things got the ball rolling but everybody knows React.) Breaking page content into components made things way easier for teams and followed the object-oriented paradigm that works so well in other coding situations.

On one hand, styling got a little easier as it was clear what each component 'owned'. Inline styling actually got a little more reasonable at that point as the problems on inlining were offset by having all the display logic bundled with the rest of the code. Inlining also was preferrable in some cases, such as where an if statement would determine if classes were appended or not. But, it was still lots of CSS and inlining gets ugly, fast.

Tailwind and the blending of concerns

Man. Nobody wants to go back to the web of 1999 where building a web page involved huge, complex tables to manage placement and nothing was responsive. There's a real benefit to having a way to express component logic and styling using tools focused on each problem domain.

But like anything, silos make it harder to build an end-to-end solution. Optimization for a specific problem (ex: unused CSS in a massive master file) leads to tools that bring fragility to the overall system (ex: who loves figuring out why your transpiler configuration files are breaking the build?).

Tailwind is a solution for a problem we have now: how do you write large, complex applications in a way that makes them easier to maintain. Separation of concerns is good until it isn't, when a massive CSS file makes it harder to manage an app.

Tailwind also helps navigate around problems that BEM et al. intend to solve. You don't need a naming convention when the Tailwind classes are the same between every component.

Building className strings or writing logic for display is also a little easier in the React world with Tailwind, as things are 'closer' to each other. If the presentation and content logic are all bundled into a single component, things like design systems get a little easier, too.

But, Tailwind and similar approaches aren't good everywhere you need to style things. It is a really good compliment to React, but maybe less so with Vue given the way Vue components are formatted. The <style> section of a Vue component makes CSS a easier and more reasonable to use than adding styling to a massive slush pile of selectors in some master file. Vue's scoping also is nice, preventing classes from 'leaking' and (again) solves the naming/scoping issue that things like BEM try to solve.

My guess is that Tailwind will be the new Bootstrap for a few years. It works well with React, which everybody uses or needs to know because something they use is based on React. Eventually, something new will replace React/Vue much like React/Vue replaced jQuery. And then, I'll write something about that.

WHO DO YOU THINK YOU ARE?

There are thousands of people out there who know CSS and can probably explain to me why Tailwind is ugly, a terrible idea, and when I use it I make babies cry.

This is an opinion piece. I like Tailwind because it makes writing React/Vue easier than having to write CSS rules from scratch and the styling is all bundled into a single component with the HTML and Javascript.

I've looked for facts-based analysis on what CSS approach is best and while there's tons of opinions (and hate!) about each option, there isn't a single write-up that "proves" why a person should pick one tool over another.