- I'm trying to write pure and standard HTML, CSS and Javascript code.
- I'm trying to separate concerns: data, structure, style, behavior.
- When there are no standards and guidelines I do extensive research and pick up those technologies which are not breaking 1. and 2.
This is a short introduction to technologies I use for website development. During years and iterations finally I find this approach very productive, based on best-practices, and understandable by others.
It's based on semantic HTML5, SCSS, and pure Javascript to avoid external dependencies as much as possible. It uses a component architecture and runs Gulp tasks to assembly components into a website. My all thinking and approach is determined by Google Web Fundamentals, and sources like A List Apart, CSS Tricks and other leading knowledge bases.
Everything is standards compatible except the naming conventions where we have no standards yet.
Current mainstream approach is BEM, SMACSS, OOCSS and Atomic Design. I've tried all, even for years, and I've come up with a very simple solution based on BEM.
When BEM was created it was very simple. It was focusing only on naming conventions: how to name CSS classes and organize files into folders, in such way it is scalable even for large projects, and it is easily understandable by any front-end developer. They have come up with an elegant solution which can be learned in an afternoon and introduces no dependencies at all staying pure HTML, CSS and JS.
Now BEM went complicated following Facebook's React model, which is not compatible with plain HTML, CSS, and Javascript. So let's use it's first, fully compatible version.
Framework, Pages, Project.
Three main folders, nothing more.
- Framework holds the knowledge accumulated up until now and used to build the current site.
- Pages are holding the pages a website has. Home, Contact, Features, etc.
- Project holds everything specific for the current project.
For example, a grid component comes from Framework since it was used many times before. However the header component goes to Project since every header is specific to a project.
A better overview and live examples can be found here: http://metamn.io/styleguide/
Block, Element, Modifier
Three concepts, nothing more.
- Block is a standalone component. It's an entity which can live on her own and reused many times.
- Element is a component which is not standalone. It is the part of a
block, it can't exist alone. - Modifier is a component which is not standalone. It is the part of a
blockorelement, it can't exist alone.
Let's see an example, for a <button>.
<button class="button button--blue">
<span class="button__text">Create account</span>
</button>
button is a Block, button__text is an Element, button--blue is a Modifier.
And the naming conventions are:
- Blocks have no naming conventions at all
- Elements are using __ like
block__element - Modifiers are using -- like
block--modifierandelement--modifier
That's all. You've learned BEM.
Today every front-end developer, designer and client wants the same: to have a product which is built from re-usable modules in order to be extendable and maintainable on long term. To be future proof.
The solution is called components. Components are lego blocks. They can build and entire concept, and can be easily replaceable.
As naming conventions — components are not yet standardised. Everybody tries to come up with it's own: Google with Material Design and Polymer, Facebook with React, and so on.
If we want to stay compatible with basic CSS, HTML, JS then we can't use those proprietary technologies above. We should 'invent' our own.
Component technology is strongly related to styleguides. If you are really component based then a living styleguide is automagically associated to your website. Not generated by plugins and hacks, but automagically associated.
In this scene the leader is Lonely Planet's Rizzo. They have a pure HTML, CSS and JS living styleguide which powers their Rails applications.
What we can learn from them is that components must be standalone and self-contained. A component should contain it's own data (JSON), structure (HTML), style (CSS), behavior (JS), and assets (images, videos).
Now my framework is built on such components, you can see it live at https://github.com/metamn/metamn-v2/tree/master/code
Another important feature I found crucial during years is to write really semantic HTML.
As we saw above there are gray, non-standard areas of web development where you should make your own decision.
Semantic HTML5 is one of those things. Nobody knows exactly when to use <section> or <aside>. There are no strict rules.
However in this case we are lucky. We have the Semantic HTML5 Outliner which tells us how the browser / bots are seeing our HTML structure. If outlines well then it's really semantic. A good example is: https://gsnedders.html5.org/outliner/process.py?url=http%3A%2F%2Fmetamn.io
It turned out when an HTML does not outlines well then it has a design / structural flaw inside. For example, if you style an element and it's starting to be complicated, it smells, then you should check the Outliner and you'll probably see that element doesn't outlines well.
Gulp it's the local 'server' which produces a standalone static site. It is the glue engine combining the components into pages and finally into the website.
Moreover Gulp makes the website fast, cross-browser and cross-device compatible. It incorporates all best practices accumulated by all front-end developers during recent years.
For example it creates responsive images by resizing and compressing them to smallest sizes for all devices. It creates compressed HTML and CSS code. Adds prefixes and hacks to CSS to make cross-browser compatible. Adds documentation. And more.
A list of current Gulp tasks I use can be found here: https://github.com/metamn/metamn-v2/tree/master/tools/gulp/tasks
Recently I've started to use Webpack together with Gulp to make Javascript code component based using the CommonJS model. Since Webpack is novel technology and very complicated I use only that part which creates a single JS file from multiple components