10 Commandments of M2 Frontend Development

Having worked the last three years exclusively in Magento 2, I’ve had the pleasure of encountering Magento developers of all levels of skill and experience. Some have been working on M2 for years and others haven’t worked on the Magento platform at all. Regardless of experience level, with some exceptions, I find that most stick to what they know. What they know is a comfort level; a set of established habits that have worked for them in the past. Oftentimes, this consists of techniques learned on M1 or just general, platform-agnostic frontend development techniques. While having a functional toolbox is a great thing, being content with your current level of knowledge and skill can hinder development in Magento 2.

As you read on, you might notice a veiled concept in my advice. The concept I refer to is: code with Minimal Intrustion. Minimal intrusion refers to writing code that very narrowly targets a specific function or property without affecting anything else, without taking ownership of an entire file or class. Coding with little to no collateral effect should be your goal.

As I reflect on the most common mistakes I’ve seen from my position as a leader, I’ve put together a list of what I consider to be the top 10 “sins”.

10 Commandments of Magento 2 Frontend Development

Thou shalt Read the Dev Docs!

In my mind, this is the absolute most important commandment. I cannot stress this enough. Magento 2 dev docs are the pearly gates. On the other side awaits streets of gold – clean, efficient, extensible code that can survive platform upgrades.

The dev docs are a living, breathing document that just keeps growing. They are here to make all of our lives easier. We all love to dive right into the code, myself included. Taking just 10-20 minutes to read the relevant docs before beginning each task can have career-altering effects.

Thou shalt Not Use H Tags for Styling

SEO is a completely different topic than code development. However, basic knowledge as to the purpose of H tags are frontend development 101. On too many projects I have seen five H1 tags on a single page simply because they have the stylistic properties that the FED wanted to achieve. In these instances, the offending H1 tags are usually wrapped around worthless bits of text. The same can often be said of H2 and H3 tags.

To be clear, H tags are semantic markup, not styling shortcuts. They communicate a page’s content structure to the search engines. When used properly, they can be quite valuable. When used improperly, they are not neutral. Instead, they are negative. Improper heading tags can hurt a merchant for a significant period of time.

Intro to Heading Tags

Thou shalt Not Use Nested Media Queries

Spend ten minutes poking around Magento 2’s native .less files. You will notice that there are no nested media queries. If you do find any, they will be far and few between. Magento 2 uses LESS mixins to implement responsive breakpoints. These mixins are used to divide browser-width-specific styling into separate CSS files that load as needed. This is a performance enhancement that should be taken advantage of.

Responsive Breakpoints in Magento 2

Thou shalt Develop with a Mobile First Mentality

I learned this one the hard way. But I’ll never make this mistake again. This commandment is related to the previous one. When using Magento’s mixins to implement responsive breakpoints, you might notice that when @extremum = 'max' and @extremum = 'min' contain overlapping bits of code, the max usually wins. This is due to the order in which Magento loads the compiled CSS files: mobile first.


Thou shalt Style by Configuration

This is one of my absolute favorites. Style by Configuration refers to the fact that a huge portion of Magento can be styled with little to no code writing. Everything, well almost everything, in M2 can be styled by modifying LESS variables. Form elements, buttons, fonts, tables, breadcrumbs, etc. If you can name it, you can probably style it without writing much (or any) code at all. Spend some time exploring the files contained within lib/web/css/source/lib/variables. Make a day of it. Think about how you could have spent the countless hours wasted on unnecessary code. I have a feeling you might just refer to these files several times a day.

Thou shalt Implement FontAwesome Icons the Right Way

I really, truly love this one. At every turn, Magento surprises me in such a positive way with it’s built-in conveniences and easy configuration. FEDs love FontAwesome icons. I know I do. This is not limited to FontAwesome icons, it possibly applies any icon font library. So incredibly often when I review a pull request, I see something like:

&:before {
    display: block;
    content: "\f07a";
    font-family: FontAwesome;
    font-size: 18px;

Not only is this not the “Magento Way” of replacing native font icons with your own, it’s repetitive and unnecessary. Magento’s native font icons can easily and globally be replaced merely by overriding specific variables in your theme.

As shown in lib/web/css/source/lib/variables/_typography.less, we have the power to set our own icon font library for the entire site. All you have to do is override these two variables.


After telling Magento to use FontAwesome or your library of choice, all of Magento’s variables for specific icons can be found in lib/web/css/source/lib/variables/_icons.less. Override these in your theme.

@icon-up: '\f077';
@icon-down: '\f078';
@icon-down-thin: '\f107';
@icon-remove: '\f00d';
@icon-trash: '\f1f8';

Thou shalt Leverage Magento’s LESS Mixins Library

More often than not, I see developers writing tons of unnecessary code. There’s a mixin for that! The one that stands out to me the most, but most definitely not limited to, is the styling of buttons. I see site after site in which no two buttons are alike. I go from the product page to the cart page to the customer account tabs and I see five different buttons which should be identically styled but have different border radii, different padding, different font, you name it. Magento styling is not meant to be micro-managed. Have a look at lib/web/css/source/lib/variables/_buttons.less. Buttons that are meant to be identical CAN be identical. Just refer to commandment number five. If there actually is a button that requires unique treatment…great! Have a look at lib/web/css/source/lib/_buttons.less. There is a beautiful little mixin there called .lib-button().

Spend some time exploring the files within lib/web/css/source/lib. There is a treasure trove of mixins there for you to use in your theme.

Thou shalt Not Be Intimidated by Knockout JS

For quite some time, I was frustrated with Knockout JS. I didn’t understand why Magento decided to use it and I was content whenever I could simply get my task done, even if it wasn’t perfect. However, I suffer(and I make other people suffer 🙂 from an annoying level of perfectionism. I always preach “don’t settle for just enough to make it work”. I am very vocal about the importance of understanding how and why code works and the collateral effects it might have. When I finally took my own advice and studied Knockout JS, a whole new world opened up for me.

Knockout JS is remarkably simple to use, extremely convenient, and it makes the loading of dynamic content a piece of cake.

Easy to Understand Knockout JS Tutorial

Thou shalt Use Javascript Mixins

Javascript mixins are the cat’s pajamas! So many developers copy-paste-override entire javascript files just to modify two or three lines of code. It makes me crazy(er). What a fantastic way to miss out on core code upgrades which result in a mystery problem related to essential functionality. If there weren’t so many people in my office, I’d scream.

Magento’s concept of javascript mixins allows a frontend developer to easily modify or override a specific function or property. Using a mixin allows us to code write code that remains isolated and purpose-specific.

Thou shalt Not Hide Elements with CSS

Every element output to a page in Magento has a cost to it. That cost is usually in the form of server-side code execution. When an element is hidden with CSS instead of being removed through the layout system, the block still renders and the code still executes. An opportunity for performance gain is lost. Sure, the argument can be made that hiding one element with CSS will not cause a site to suffer. However, removing one single element is not usually the case. There are usually multiple elements that need to be removed from a Magento site for one reason or another. These add up to what could definitely become a noticeable performance improvement.

To be an effective Magento FED, knowledge of the layout system and light knowledge of backend functionality is crucial. I’ve found that most frontend developers consider the layout system to be of backend responsibility. I wholeheartedly disagree with that in every way. Knowledge of the layout system is the responsibility of EVERY Magento developer.

Leave a Reply

