How did we standardize Magento 2 frontend development?

Many Frontend developers in the Magento community felt a certain level of pain when they started working on their first Magento 2 project. So did we! “This is just a start. I will be faster on the next one“, was a common statement. However, new projects arrived and frontend development was still not as fast as it was with Magento 1.

To improve the speed, efficiency, joy of work and team synergy, our frontend team decided to refine our development processes. After a few completed projects, we got an idea of how to do things better and quicker. Modernizing the approach we’ve been using.

We weren’t very happy with the default tech stack and the level of complexity of Magento frontend architecture and we decided to tackle these issues. The first step was to create our custom compiler and introduce modern technology stack.

After this stack was created, we developed the Medellín theme. It serves us as a starting collection point for elements that need to be further customized (navigation, buttons, sliders, header, …) on any given project.

I sat down with Filip – our Lead frontend developer, Luka and Igor – frontend team members, and with Marko from our design team, to discuss the benefits of creating our own frontend solution.

Filip: Our goal was to create a standard starting point based on the latest technologies. Compiler and the theme include the most efficient choice of technology that provides our clients a faster way to meet their demands. In our world, faster also means cost-efficiency.

Igor: I was super excited that the whole team will be using the same starting point because it was not the case before. Jumping into an ongoing project is now much easier and stress free as we already know all the underlying tools and technologies.

Filip: Just to keep things straight; building a custom theme from scratch is faster and more efficient with a solution we use, even if we don’t use Medellin theme as a starting point.

What was the main reason for standardizing Frontend development in the first place?

Filip: I understand that Magento wanted to simplify frontend development with Magento 2. I could see the benefits of this approach if merchants needed simple tweaks like changing colors or small layout modifications. In reality, the average Magento merchant requires a unique user experience where more architectural changes are needed and current frontend architecture becomes a burden. The original idea just doesn’t work in most of the cases.

Luka: Before we had this starting point, we were frustrated with the outdated approaches we had to use. It felt natural to us that we need a different solution and all team members worked together to create it.

Marko: Relying on Blank or Luma theme in Magento was limiting our creative process. Providing unique user experience could significantly increase development time to a much higher level than merchants are used to. New solution enables us to be more flexible and this means that I can be more creative. As a designer, it makes me happy.

What are the benefits of this approach?

Filip: We chose to go with postCSS because it gives us more flexibility. What’s more important, it is a javascript. Tools that we use can be easily ported to any postCSS environment. We can set it up to work nicely with Gulp (Traditional) or Webpack (PWAs).

Igor: As I said earlier it’s easier for all of us to switch between projects. The codebase is cleaner, better tested, and more secure and adaptable in regards to ever-changing clients’ requirements and expectations. We believe we are 20-30% more productive thanks to our new toolbox.

Luka: I’m currently working on a project that requires a lot of customization. Comparing with the old way of working, I’m much faster and have a lot less frustration while working on some routine tasks.

How shall we improve the solution in the future?

Filip: We have two focus points. The first one is standard Magento stack, Gulp driven. Another one is progressive web applications, which is Webpack driven. Both solutions support postCSS loaders. This is great because we can reuse 90% of our frontend architecture (Mixins, Advanced Typography Sets (vertical Rhythm, Typographic Scales etc.)).

We will continue to maintain both solutions, even if there is some new technology update or mayor code change. Some parts of our solution are used in PWA development where we have the same technology as in Medellin, but at the same time, some of the things we developed in PWA are going to be imported as add-ons to Medellin. Our tendency is to have as much universal toolbox with the latest technologies as we can.

A lot of projects out there are not PWA ready (or is it that PWA is not ready for them?) and still gotta depend on known solutions.

Marko: We are regularly working with our front-end team on determining possible improvements and adding new elements and functionalities that will improve user experience in new projects.

Igor: Code is never finished. There is always some fixing, refactoring and tweaking going on, and we try our best to update our current stack with these new changes. Consequently, the documentation has to be updated as well.

Luka: We are working on three projects using the described solution and we will continue to use it. During the development, we got some nice feedback from our design team and other non-technical people and we will apply it in future versions.

Conclusion

Gained experience is of no use if you don’t put it into practice. While developing our solution, we learned a lot and we are quite happy with our current development environment. Also, we can see that connection and the bond inside the team are much better than it used to be because we all worked together and we supported each other along the way.