If you build websites, you’re probably aware they tend to scale, or require the ability to in the future. New features are often requested by product owners, and building a site that conflicts with this nature is only going to give you (or your developers) a lot of headaches. This is why developing for scalability is almost a necessity in the current state of the web.

What does it mean to develop for scalability?

It means you need to build something that is capable of growing and expanding with ease (i.e. without requiring days, or even hours of development time). Developing with this mindset will also allow you to build components that can be reused throughout your User Interface (UI). This makes your code clean and modular which ultimately speeds up development time.

Ok, get to the point.

So how does this apply to your HTML and CSS? And how will it benefit you? Well, if you’ve only been segmenting your HTML and CSS as pages or templates instead of compartmentalizing them into components, then this approach will make your life really easy. It will also improve collaboration, as developers who jump into your work will have less trouble familiarizing themselves with the code base.

Explain components, please.

First of all, we’re not talking about web components (like Google’s Polymer Project), we’re talking about creating a framework where your HTML/CSS/Javascript is able to become modular by separating them as components.

Let’s say your UX/UI team builds a wireframe of your new client’s site, and they have a gallery that is used on multiple pages. You want to build it one time and use it on as many pages as necessary, so you build it as a component. A file, or a group of files (HTML, CSS, JS) that can be added anywhere throughout your site. This will allow you to build it once and use it everywhere. It will make your life easier. You’ll be able to code faster, which will allow you to deliver larger projects in less time.

Modular HTML with template engines.

So how does this apply to your HTML? That’s where template engines come in. Template engines are quite popular nowadays due to MVC frameworks. Mustache, Handlebars, Twig, etc. There’s a lot of them out there. Template engines are precompilers that allow developers to keep their HTML beautiful. No spaghetti code in between markup, just variables that are interpolated into HTML. You take care of your complex logic first and then render templates that pass values to your markup layout. Super clean and organized.

We’ve used some of these template engines at Zion & Zion and have currently stuck with Twig. If you code in PHP and haven’t heard of it, check it out. Twig has great features that facilitate a modular development mindset. You can build .twig files that can be included into other files, you can create files that can be embedded with their own variable objects, you can create files with dynamic blocks, and the list goes on. Again, if you haven’t checked out Twig, please take a look; even if you decide to use another template engine, this will give you an idea of how powerful they are. We also wrote an article that goes into more depth on what Twig offers and how it makes WordPress better; feel free to read it as well.

Twig HTML example.

So let’s dive into a component example with Twig. Below is a simple gallery component that works with an array variable called “images”.

gallery.twig


<div class="container component gallery">
   {% for image in images %}
       <div class="gallery-item">
           <img src="{{ image.url }}" alt="{{ image.title }}">
       </div>
   {% endfor %}
</div>

Every time we wish to embed this code into another page, we just need to create a Twig embed tag and pass the array that contains each gallery item. Let’s say we want to include this gallery in our home page.

[page-home.twig]


<!DOCTYPE html>
<html lang="en">
<head>
   <meta charset="UTF-8">
   <title>Home</title>
</head>
<body class="home">
   <div class="main-container">
       
       {% embed 'component-gallery.twig' with { images } %}
       {% endembed %}
       
   </div>
</body>
</html>

Super simple, right? The gallery.twig component can be used anywhere and it can have any number of images passed through.

Modular Less: sharing is caring.

Now that we know how to create HTML components with Twig, let’s go through how you can write component CSS. Twig makes HTML better as it adds features that make component development possible. The same applies to CSS; we’re going to use a preprocessor in order to give our CSS extra features that will make component development easier. We’re Less people at Zion & Zion; but If you’re more or a Sass person, no big deal, just incorporate these principles to that syntax. Also, if you’re not using a preprocessor by now, you might be living under a rock. So look into using Less or Sass as they make CSS everything it could never be.

We’ve been doing responsive web development at Zion & Zion for quite a few years now. We started by separating our .less files into device type, which made sense back then, as everything was either mobile, tablet or desktop. Then, as the spectrum of devices grew quickly, we switched to screen sizes: xs, sm, md, lg. This allowed us to hit every device screen size, from 1px to 1200px and beyond.

We’ve stuck with this approach but have pivoted parts of it. We used to separate our .less files into page and template files. This process was working fine, but we didn’t realize that by doing this, we were encapsulating styles to one view.As our projects became bigger and in need of constant scaling, we had to look for a solution that would allow us to speed up development. That’s when we switched to component based Less.

What does a Less component look like?

Instead of only separating our stylesheets as pages, we’ve also added a category of components. It doesn’t mean we have scrapped pages all together; there are instances in every project we create where pages are still in need of their own styles. But creating components in Twig and associating a stylesheet to them allows us to use them anywhere on the site and as many times as we want on the same page. Pretty darn cool!

Let’s take the gallery.twig component and create its own encapsulated CSS rules in the main stylesheet of the website (which is a .less file that eventually gets compiled into a .css file).

[styles.less]


 body &{
   @media only screen and (min-width: 1px){
   }

   @media only screen and (min-width: @screen-sm-min){
   }

   @media only screen and (min-width: @screen-md-min){
   }

   @media only screen and (min-width: @screen-lg-min){
   }
 }
 
 body.home &{
   @media only screen and (min-width: 1px){
   }

   @media only screen and (min-width: @screen-sm-min){
   }

   @media only screen and (min-width: @screen-md-min){
   }

   @media only screen and (min-width: @screen-lg-min){
   }
 }
}

By using this type of syntax, we are able to create a scope of the media queries (and the CSS rules in them) that affect the gallery component. The first group of media queries will apply CSS rules to any instance of the gallery component. The second group (under body.home) will only apply the rules to any gallery components that appear in the homepage. Quite simple and quite powerful!

So there you go, that’s how easy it is to convert your HTML and CSS to components.

Recap of component development

Let’s go through the benefits of building your website while using component based layouts one last time.

Maintenance

Your code will be easier to edit, not to mention any update you make to an existing component will ripple through every instance of it within the project. If other people in your team start developing this way, it will be easier to jump in and out their projects.

Scalability

Adding features is easy now. Build a component and start using it wherever you please. Your website now consists of a bunch of small building blocks. You can add, delete or replace as many as you want.

Develop faster

Separate your layouts into a bunch of different components. Build it once and forget about it. You’ll find yourself blasting through the pages of your site.

Javascript anyway you want

Choose whatever javascript style you want. Go vanilla or use jQuery to make your life easier. Make sure your code is scoped to instances of the component in order to have the ability to display many of them at the same time.