Since our company was founded in 1995, we have been building fully bespoke eCommerce websites for our clients. We now work a lot with Magento. For the past 6 years we have been building websites using the platform and we love it. Using Magento has helped us cut down on a lot of support requests and provides a consistent platform for us to build on top of.
Building our own eCommerce platforms in the past though has given us some valuable insight into how Magento is built, the things below the surface that make Magento tick. This encompasses all platform development from the back end code through to the front end css, js and template rendering.
We’ve noticed something of a bubble around the software, it feels like Magento finds it difficult to give us the complete control over the front end we desire.
— Magento Fox (@magentofox) November 12, 2016
The front end world is moving fast, faster than many platforms can keep up with. How will Magento deal with the rapidly changing technologies that developers want to use with the Magento platform? Will they layer on new technologies with each release or will they decouple the front end completely? Wait, decouple the front end? Sounds like a nice idea!
Magento 2 was released over a year ago now and so far we have built a grand total of 1 website on the platform. We’ve been holding off M2 for a variety of reasons.
Our clients though are accustomed to super lean, fast and scalable websites. While this and many other off-the-shelf themes are all well and good for some startup merchants, they fail to tick all the boxes of a custom built theme.
Performance has to be a top priority for any agency looking to build an eCommerce site. Front end performance can directly impact sales. There are a lot of boxes to tick these days when building a website. While a lot of off-the-shelf themes tick some of the boxes, to tick all of the boxes requires planning, regular maintenance and a custom built theme.
The front end team at iWeb identified several areas we would like to see change with M2, these are:
So why should we need to install a platform in order to create the HTML & CSS? Magento 1 also assumed that in order to develop a website you would want to have all your assets inside of the platform. This raises the barrier to entry, reduces the number of people who can do the job and does not marry up with the current way we develop and deploy our websites.
We are used to running gulp/grunt locally and not having to wait for our assets to compile. M2 has an asset build time of 3 – 8 seconds. This may not sound like much but for a front end developer it can feel like an eternity and this time soon adds up causing annoyance and lost development time.
There is no beating about the bush on this one. The Magento themes that come out of the box are bloated. This is because of a few reasons but the main ones being inconsistent HTML style hooks, this in turn impacts the structure of the SASS itself. In some places the SASS selectors are more than the ideal 3 levels deep. Nesting like this can cause the outputted CSS to balloon. The M2 developers are looking at implementing BEM throughout the theme HTML, this will drastically reduce the size of the outputted CSS and is a welcome move.
The Magento front end is currently not setup to deal well with design patterns. M2 has UI Components but they are insanely complicated to work with and require the platform to be installed.
At iWeb we deal with more than just Magento websites so we use our own solution to build front end patterns for these sites. Pain points still arise though when integrating these static patterns into the Platforms.
We have developed our own in house pattern library in order to circumvent the problems we have had battling with the out of the box Magento themes. The pattern library approach also enables us to develop rapid prototypes which can then be iterated and improved before the platform integration.
As we develop our pattern library I hope to be able to share more about the features and benefits on this blog so stay tuned.