Divide & Conquer – An Overview About Modular Front-End Architectures

Consistency — especially when it comes to naming — is essential for readable and maintainable code. Unfortunately, achieving modularisation and consistency is not easy, since there are no standards, only a few guidelines and it is a very abstract topic to explain and educate. With this article I will try to explain the concept of modularity, list examples and techniques which you can use in your daily business.

Divide & Conquer

What does modularisation and conventions actually mean for your code? Instead of just giving random names to CSS or JavaScript classes, have large, unstructured files with tons of JavaScript functions, etc., you should use naming conventions and split your code into reusable or independent chunks. A popular approach is to divide code physically and semantically. Generally, this means to split code into separate files, use consistent naming for classes or attributes in HTML, scope CSS with prefixing and use classes and/or namespacing in JavaScript.

What	Technique	Example
HTML	Class
CSS	Class Prefix	.mod-example .rule { }
JavaScript	Class	App.Module.Example

Naming Conventions

But, which naming conventions should you use for your projects? Luckily, there is no right or wrong answer. On the other hand, it's important to make a decision and actually introduce them. One thing that might help, is to talk about the options you have. To find out more, it's worth to have a closer look at the two different types of parts we have in most web applications.

What	Attributes
Element	Global, Fundamental, Reusable
Component	Reusable or Independent, Based on elements or other components

First, there are basic, reusable elements like a link, a button or a form field, which directly represent a HTML element in your markup. I call them elements. These elements can be combined into something more meaningful, which is still reusable. I'm thinking of a navigation for example, a breadcrumb, pagination, etc. They are called components. Both of them together are called patterns. Working with patterns keeps the code simple, independent and maintainable. Good examples of pattern libraries can be found within Bootstrap or Foundation, but also in corporate pattern libraries like the one from Mailchimp or GitHub.

Semantics

There will be a lot of different elements and components in a project, so what can you do with your code to work as structured as possible? Looking at markup, the way to go is to introduce consistent naming for different elements & components. To help you with that, I've compiled a list of class names I personally prefer to use. For sure, you can use whatever names you want, the important thing is to keep it consistent and make them easily selectable via CSS and JS (e.g. with a class).

Layout Class Naming Examples

What	Use for
.row-*	Grid Row
.col-*	Grid Column
.span-*	Grid Column (Span)
.area-*	For header, footer, sidebar, content, etc.
.section-*	Alternative for .area
.block-*	Alternative for .area

Element Class Naming Examples

Similar to many popular pattern libraries & frameworks like Bootstrap, Foundation & Co.

What	Use for
.btn-*	Buttons
.fld-*	Form Fields
.lbl-*	Labels
.col-*	Table Columns

Component Class Naming Examples

What	Use for
.block-*	Modules, Components, Default for BEM
.mod-*	Modules, Components, Default for Terrific & OOCSS

Sidenote: There's also a pretty new technique available especially for HTML — Web Components. I'm not going to explain them in this post, but if you are interested in how they work, have a look at A Guide to Web Components from CSS Tricks. They will probably allow us to build even better architectures in the future.

Appearance

We talked about the semantics and meaning of our patterns, but what about their different appearances. The (semantically) same button can be used in green or blue for example — like we have colourful bricks in our lego world. This is where we have to define a modular CSS architecture. Why? Because you want be sure, that just the component you are currently working on is affected of your style change, it's necessary to ensure independence as much as you can, when it comes to styling elements & components. You can do that by adding scope to your CSS by prefixing every rule with the according element or component class. And — you should define as few generic CSS rules as possible to not mess things up. Here are a few examples of modular CSS naming concepts you can use.

Concept	Name	Examples
OOCSS	Block Skins	.mod, .mod .skin
SMACSS	Themes	.exm, .exm-caption
BEM	Block Styles	.block-name--element-name
Terrific	Module Skins	.mod-example, .skin-example-red

Just use whatever technique you and your team agree on, but be sure to educate everyone in your team about the rules you committed to.

Behaviour

Each of the mentioned building blocks can have a behaviour. For example, a simple list can be turned into a dropdown by adding a dropdown behaviour to it. In most cases, JavaScript is responsible for adding behaviour to our components. Since our JS code became more complex over time and probably continues to do so — it's essential to choose a modular architecture for JS as well. As with CSS, there are many different options out there, here is a short list of libraries, which help you with that.

Library	Name	Notes
JQuery	Plugin	Plugins are state-of-the-art for JQuery components
Angular.js	Module	Connects Service, Template and Controller
Ember.js	Component	Works with Templates
Terrific.js	Module	Modularisation based on conventions
Require.js	Module	File and module loader
Backbone.js	Views	Based on client-side templates

If you prefer a slim or more independent option, Terrific.js and Require.js are great. If you already use a library or framework, I'd suggest to stick with the matching component concept. For sure, you can also do it by hand and introduce your own naming and helper libraries, but the existing ones are fine. If you're interested in Terrific, you can use my tiny boilerplate to play around with.

Back-end Integration

The transition from front-end code into a back-end is one of the most challenging and time-consuming tasks. Similar to our modular front-end approach, every CMS provides extensibility through a component system. Here is a list of what components are called in a few of them.

System	Name	Language
WordPress	Widget	PHP
Drupal	Block	PHP
Adobe EM	Component	Java
Magnolia	Component	Java
Typo3	Extension	PHP
Squarespace	Block	Proprietary
Sitecore	Component	.NET
Django CMS	Plugin	Python

The back-end integration becomes much more simple and standardised, if you work component-based across front-end and back-end. But what's really interesting is, that this know-how allows us to prepare integration paths in a very structured or even automated way and save tons of time. I will cover this topic in a later post.

Conclusion

It doesn't really matter, if you are using one of the existing tools or concepts or build your own, but it's important to think about modularisation and a consistent naming when starting your front-end work. It not only helps you to work faster and more structured, it also helps new people to get familiar with a project in less time. You don't have to worry about affecting other parts of your site while changing the appearance or behaviour of a component. And generally, a consistent and modular structure also reduces the complexity of your whole project.

Getting Started

If you're at the beginning of a project and you want to start to divide a design into elements and modules, you might want to have a look at Frontify. It allows you to easily specify components visually and generate documentation and libraries for your team.

Further Reading

A New Front-End Methodology: BEM (Smashing Magazine) MindBEMding – getting your head ’round BEM syntax (Harry Roberts) Writing Modular JavaScript With AMD, CommonJS & ES Harmony (Addy Osmani) Atomic Design (Brad Frost) Brick (Web Components from Mozilla) Polymer (Web Components from Google) Writing modular frontend components in 2013 (CreativeBloq)

This article is based on my learnings from many web projects I worked on over the last years. The concept of Terrific was invented by Remo Brunschwiler at Namics, which influenced my view on this topic in a very positive way.