Why you should try Tailwind CSS with Bricks Builder

In this article, we’re going to cover some of the reasons why we use tailwindCSS as our css framework of choice for nintu and why you should try it too. 

Before digging into what tailwind is and if it’s a good solution for you, let’s start with a couple of questions around how you’re building a project and its requirements. 

• Are you an agency, freelancer or part of a marketing team that is going to be working across multiple projects, funnels, pages etc.
• On each project, how many times are there going to be new pages and or components.
• How many different people will be using or working on this project (creating new pages, styles etc). 

If the answer to any of these questions is more than one, then you might start running into some problems when dealing with CSS/Styling in your workload. 

The problems with CSS on it’s own:

Problem #1: Naming

• How do you know which CSS stylesheet and class is actually being used to style your element?
  
• What will break if you change a property if you’re using the same classes with multiple attributes?

As a solution to these, we tend to keep adding new unique css classes or letting our page builder decide it for us. The downside to this is as we keep building out a site, our css file gets really big and it’s hard to know exactly what-does-what.

CSS on its own can also quickly become a mess. There is no direct relationship between your HTML and CSS, the relationship exists in your brain (only you know what classes have what styling when looking at your HTML)… 

This is how projects end up with 1MB CSS files.

Problem #2: Consistency

• How do you ensure consistent sizing, colors, styles, spacing etc?

Well, you could use CSS variables. But as your website grows and you have lots of pages and elements, you would have so many CSS variables making it difficult to maintain and update. .

• How to keep things consistent with multiple users editing a project (your team, your customer and even future you who has learnt more and changed the way you build)?

With vanilla CSS and/or leaving it up to the page builder,  there is too much room for every editor to get creative and use their own methods. Everyone has their own unique way of keeping their styles organized and manageable and this becomes difficult to maintain when you’re switching between different editors. Not to mention, once you throw in self made components, styles, functions etc, there becomes infinite ways of staying organized, which changes from editor to editor… Instead of using brain power to remember how a teammate has organized their styles, it would be better to have just one, consistent organized way.

Problem #3: Scalability

• Ever wondered why your site is really fast and snappy when you first install wordpress and set up your favorite plugins only to see performance degrade overtime as you’re building out the site?
• How do you keep your CSS file from growing indefinitely as you add more and more pages, components, templates etc each with their own unique elements.

As a beginner, you’re probably dropping in an element with your favorite page builder, and then using the builder panel to style this element. There’s nothing fundamentally wrong with this, but did you know that every time you drop in a new element it creates a new class or ID in your stylesheet (another line of code). And then every style you add to that element each adds another line of code. Just adding a heading to a new page might not seem like much, but in reality it’s actually adding a lot to your final CSS file. It might look something like 1 line for the headline class, one more for its size, another for the color, another for the font weight etc etc. Now imagine that across an entire project that has features much more complicated than just a heading.  

As someone more advanced, you’ve figured this out so you start standardizing, setting up global systems and templates, but with no real framework in place, as you grow your website, build in new pages, new components, new templates, with multiple users, different naming conventions, no consistency, the end CSS stylesheet still becomes huge and difficult to retroactively improve as you don’t know which global classes are styling which elements. You might then set out to start cleaning things up but then accidentally break other parts of your website, reverting back to adding additional unique classes so that you’re sure it’s not going to impact another page. 

The solution:

Well, before we look at tailwind, let’s have a look at other systems out there:

• Sass: This solves problem #2 (consistency), but does not solve problem #1 (naming) and doesn’t solve problem #3 (scale) as there are many ways different devs could try to organize their sass. Even if you use a naming methodology like bem it would only half way solve your first problem.
  
• Styled components (creating classes for components) like “Card”, “Avatar”, “h1” etc. These solve problem number #1 and #2 but not #3 without extra effort. Unless you’re creating your own standardized way of building that never changes, teaching everyone how to use this standard and hoping they don’t break your rules. I find myself being the biggest culprit of breaking my own rules because I’m always learning new things and wanting to create better, more complex designs. But my rules were set before I learnt all this cool new shit, and I constantly need to go back, update them, redo the site with the new rules, learn something new and the cycle repeats itself.
  
• Other WordPress frameworks (like ACSS, Oxymade etc.) These frameworks are great beginner frameworks and solve problem #1 (naming) and problem #2 (consistency). But still fall short with problem #3 (scale). The idea of either a utility only framework or some combination of utility and components is great on paper but falls short when you want more than what the framework has out of the box. You’ll typically run into one of two problems:
  • 1: The framework doesn’t cover everything, so you add your own extras to it, but, you’re pretty much back to ground zero when it comes to naming and consistency. 
  • 2: The framework creators continue to add to their framework, gradually covering everything you could possibly need but then you have to load that massive framework on your site and might not even need all the new functionality. Even if you could toggle off features you then restrict what you can use site-wide. What if you want that hover effect on just one page…
    

In short, you would have to make compromises one way or another. 

But it doesn’t have to be that way. For once you can have your cake and eat it too.

Ok, let’s get into the meat of why you’re really here. Tailwind.

How tailwind solves everything:

Tailwind solves all of these problems. It might not be the only tool that can solve all of these problems but it’s the only one that does it out of the box, without any extra effort on your part. 

Naming: It has one way of naming things, plain and simple.

Consistency: Everything is tied to its massive engine and can only be consistent. Every time you add a padding class (like p-2) it will always have the exact same size. You can customize everything within the framework but it all stays connected. So if I wanted to change my padding sizes globally, I would actually be adjusting the sizing scale globally, which then adjusts everything that uses a size on my site equally (margins, heights, paddings, etc).

Scalability: This is the #1 reason why we ended up choosing winden/tailwind. It addresses all of our scalability concerns:

• It’s mature. Not (yet) popular in the wordpress space but it’s the most popular CSS framework for web app and mobile app development in recent years. For building websites, just about every use case has already been explored. Every class you might need has been added. Every iteration of a young framework has been done. It’s tried and tested.
• It’s fast, like crazy fast. Let’s quickly jump back to the scaling problems I mentioned above with other wordpress frameworks. They are forced to find a middle ground between covering everything you need to build a site but not too much so they don’t become bloated and slow down your site. Tailwind solved this by implementing something they call a “JIT engine” (Just in time). Put simply, the engine scans your website, figures out which parts of the framework you’re using and strips out all the rest. This means they can keep building on their framework, giving you just about every possible option to style your website without ever impacting load times. Keeping your final CSS stylesheet lean and allowing you to keep building and building without having to ever worry about speed.
• Everything is connected. Tailwind is designed in a way that keeps everything centralized and connected. If you want to change your brand colors, you can add them and it will generate all the variations they could be used in. Everything from background colors through to your text and borders. This idea is applied framework wide. So maybe you just want to add brand colors, but maybe you want to add fluid typography or spacing or anything else. You add it in one place and it hooks itself up to the entire system. Again, never impacting load times thanks to JIT.
• It’s expandable. You can customize just about every aspect of the framework,  use one of the thousands existing community made plugins (yes tailwind has its own plugins just like WordPress) or create your own. For Nintu, we’ve already done some customizations to add brand colors, link them to bricks builder’s brand colors, make spacing & typography fluid and we’re only just scratching the surface of what is possible with the framework.
• It’s here to stay. The fact that the framework is platform agnostic and exists outside of the WordPress world means that it’s not going away with a page builder change or core WP update.
  All the skills you gain through learning tailwind can be transferred outside of WordPress and will follow you with your online career for years to come. Everything you do with tailwind on WordPress can be applied to any other platform using the framework.

So what is Tailwind and how do you start using it with WordPress and Bricks Builder? 

We went a little deep there, let’s get back to the fundamentals. What exactly is TailwindCSS and how to get started with it?

It’s all about utility classes. But not quite like bootstrap or some of the other conventional utility class tools.
With bootstrap, you could add one or two classes and an element would be completely styled; in tailwind, each utility class only controls a single css property. So for example, one tailwind class would set the padding, one class would set the font size, one would set the color and you have to define every class yourself.
In that regard, tailwind is quite difficult for users who don’t already have a base understanding of CSS. Just like a good video game, it’s easy to get into but hard to master.

• It’s not the same as just writing inline styles. TW comes with a whole suite of functionality that inline styles just can’t achieve. Stuff like hover effects, pseudo styles, variations between dark and light mode etc. There are just all sorts of things you can do with tailwind that you can’t do with inline styles. Not to mention the consistency of it all. Everything you style with tailwind remains part of a system that can be customized and displayed consistently site wide.
  
• Tailwind is indeed not the prettiest code when you look at a HTML document. It’s not pretty like with other frameworks but that’s also the whole point. When you’re working on a page, in a builder or just writing HTML, things don’t look so nice because everything is referenced on that page. Every element tells you how that element is being styled and shows its utility classes. If you’re thinking about how pretty your code is to stare at you might not be thinking about the right thing. You should be caring about how manageable your code is and how easy or difficult it is to read, hand-off, revisit or take over. In essence, can you efficiently build, update and maintain the styles of a large website that’s getting frequently updated by multiple people.
  
  So yes, your code might not look pretty, but tailwind is a beautiful solution to solve all problems we stated upfront. 

At this point, we’ve outlined how tailwind solves our CSS problems and we know it’s all about directly adding utility classes inside of our page builder or HTML file and not writing CSS to style each of your components. 

So how do you start using it?

Adding Tailwind to Bricks Builder: If you’re using bricks builder there’s a really easy way to get started. By using Winden. Winden takes all the complicated server side setup and does it for you.

Working with Tailwind: on Bricks Builder: Two great tools to get you started with your new web build are a cheatsheet and some basic copy/paste templates.

• The cheatsheet: I recommend using this one by nerdcave. It has a really simple search function and helps you get started when you don’t have all the utility classes memorized.
• Boilerplate templates: We have some great free resources to get you started with Typography, Layouts, and Buttons.

Templates for Bricks Builder and Tailwind: We also offer hundreds of pre-built, optimized templates for Bricks Builder and Tailwind. You can learn more about Nintu templates from here.