In this article I describe envisaged strategies that site developers would use to customize the HTML, CSS, and JavaScript of a Magento store front, and then how Magento 2 is being reworked internally to support these strategies. I am not going to deep dive on any particular aspect of such development. I am also going to limit myself to HTML, CSS, and JavaScript changes on a site, leaving the Magento Layout Engine (which I think is pretty cool) to a later post.

Disclaimer: I work for eBay, these opinions are my own and do not necessarily reflect those of my employer.

More interesting disclaimer: I don’t call myself a web developer! So this is how I understand the workflows from talking with others. Feel free to educate me by leaving a comment!

Underpinning Magento 2 Goals

Different projects will have different goals. Some will be to minimize cost, some to create a new amazing experience. Here is the way I see some of the behind the scenes Magento 2 goals in the area of HTML, CSS, and JavaScript. (These are not the officially documented internal goals – these are my personal spin on things.)

• Reduce the cost of new store front development on Magento 2. To support this goal, simpler starting points are provided that are designed to be extended for simpler sites, or completely replaced for more advanced sites. But there is no point providing an overly fancy UI out of the box since its going to be changed.
• Reduce the upgrade cost on store front development. By providing finer granularity tools, more targeted changes can be made thus reducing any rework later as the result of upgrading the base platform. Separating concerns also helps – minor adjustments to HTML won’t invalidate enhanced CSS.
• Allow radical new ideas to be tried in web interface design without having to rework application business logic (too much!). For example, we don’t want to tie Magento 2 to any particular specialized web technology if it can be avoided. It is better to enable web developers more freedom without having to work out how to turn off what comes out-of-the-box.

Site Customization Strategies

The following are different strategies I can see being used to develop a new store front on Magento 2. Lots of variations are of course possible. Please leave a comment if you think I have missed a major use case.

Extending Magento 2 Provided CSS: Magento 2 supplies a default theme and a LESS based CSS set of styles. LESS is being used to make extensions easier. A store front can be changed to some degree purely using CSS.  This may be suitable for projects with a limited budget. It may also be of interest for developers who provide different look-and-feels for a site. A small business may be able to get up and going buying such a 3rd party developed theme from Magento Connect.

Replacing PHTML Template Files: Going beyond extending CSS, sometimes it is necessary to generate different HTML markup. For example, a CSS class name may be missing where needed, or an extra <div> tag is required to achieve some visual effect. Some JavaScript may also need adjusting to cope with different HTML markup. This goes a bit beyond the first strategy of extending Magento CSS, but again is useful for smaller projects.

Replacing Provided CSS: Rather than tweak the CSS provided, a project may decide to replace all of the store front CSS with their own. This avoids tying a project to the Magento 2 CSS, but puts a greater burden on the project. It also allows use of different CSS tools or technologies not provided with Magento 2. (Can anyone say “SAAS“?) This may be appropriate for partners who build their own set of CSS libraries to reuse on different customer projects. It may help differentiate that partner from others in the market. (Some minor replacement of HTML and JavaScript may also occur.)

Replacing provided CSS, HTML, and JavaScript: An more significant extreme may be for a site that wants to deliver a radically different site experience than what Magento supplies out of the box. A one-page Angular site would be an example site. There is some risk here in that if they want to pick up additional extensions in the future, they may be limited to the options they can pick and integrate easily. There has been a bit of noise on Angular store fronts for Magento 1, such as by Vinai Kopp and Arvind Bhardwaj. Doing some web searches quickly brings up more articles on this.

Magento supports more options than just the above using Magento layouts, themes, or additional modules. This article sticks to just what can be done at the HTML/CSS layer.

What is Magento 2 Doing to Help?

The following are some of the techniques being included into Magento 2 to help support the different use cases above. These are also (personal) recommended practices for extension developers building on Magento 2.

•  Move business logic out of PHTML files to behind services (or at least blocks). This makes it easier to replace and maintain PHTML files. Services can also be easily made accessible via REST which is useful for Angular based UI design.
• Create more, smaller, PHTML files. Rather than have mega-PHTML files, break up the files into multiple smaller files allowing one file to be replaced instead having to replace the complete set of HTML to change a single tag. (In production mode, files are merged where possible to avoid performance overheads of having more smaller files.)
• Move HTML generation code out of blocks and into PHTML files. Replacing HTML markup is harder when it is generated by a block. Use PHTML templates whenever possible to hold HTML to make it easier to replace without having to develop a new block in PHP.
• Remove all direct styling using ‘style’ attributes in HTML. Use classes and move all styling into CSS files. This makes it easier to adjust styles by changing CSS without having to replace PHTML templates.
• The default CSS library and theme provided with Magento 2 is called “blank” and is designed to be extended. This reduced the amount of styling that needs to be removed to bulid a customized site.
• The default CSS and theme are also Responsive out of the box, so they can be used across a range of display sizes (including mobile devices).
• LESS has been built in to make customization of CSS easier. Rather than replace complete CSS files (and incurring the maintenance overhead of keeping them up to date), LESS can be used to merge in the desired changes to the provided Magento 2 libraries with finer granularity.

Not all of the Magento 2 code base will be refactored by the Magento 2 release to follow the above rules. The most important areas (based on feedback) are being tackled first. But this is the direction Magento 2 is heading.

Conclusions

If I had to summarize the thrust in direction behind the Magento 2 HTML, CSS, and JavaScript it would be Separation of Concerns. Put HTML in PHTML files, put style instructions in CSS (with LESS to simplify extension and reuse), put JavaScript in JavaScript files (not in the HTML), put PHP presentation logic in blocks, put business logic behind services. This separation, combined with design decisions to allow the different technologies to be partly replaced (with finer granularity) or completely replaced (while keeping other parts of the UI stack), provides a flexible foundation to allow developers to build a wide range of user experiences. Rather than select the latest cool technology (such as Angular), the approach is to upgrade to somewhat modern technologies (such as jQuery) but simplify their replacement for those willing to go the extra mile to create a special and customized experience.