Magento 2 has been around for a while and it’s fair to say that the frontend workflow differs somewhat from that of Magento 1. There are some similarities – PhpStorm is probably still the editor of choice and jQuery is very much alive and well (for now at least).
However, there are many new toys to play with such as RequireJS, KnockoutJS, Grunt and Less and the time has also come to say goodbye to some old ‘favourites’ like prototypeJS. In this blog, we cover a number of considerations when it comes to Magento 2’s frontend workflow along with some insightful snippets direct from the world of development.
Editors
Our frontend team here at Pinpoint is split roughly 50:50 on choice of editor or IDE (integrated development environment). We don’t force a particular editor on our team as it’s quite a personal choice. As long as formatting settings such as the size of the indents are universal, then the exact choice of editor is left to the individual developer.
PhpStorm
PhpStorm – the de facto choice for the backend team and the first choice for many frontend developers too. It’s an extremely powerful IDE built specifically for PHP development. When you combine that with the Magicento plugin it’s pretty unbeatable when it comes to Magento 2 development. Other popular plugins include:
- GitToolBox
- Material Theme UI
Top tip: To avoid lengthy and resource draining indexing operations that are regularly experienced with PhpStorm, exclude files and directories you never edit from the indexer. In Magento terms, this means everything except the `app` folder (and possibly the `pub` folder).
VSCode
Putting Magento aside for a moment, VSCode is probably the most popular choice for frontend developers. Super lightweight, yet powerful and adaptable – there are so many plugins available you can practically build your own editor.
For those frontend Magento developers that find PhpStorm a bit bloated with features they are never going to use, this is a fantastic choice. Top VSCode plugins among the team include:
- SCSS Intellisense
- PHP Intellisense
- XML Tools
- GraphQL
- ESLint
- Bracket Pair Colorizer 2
- Git History
- GitLens
- Night Owl
Both PhpStorm and VSCode connect with Git and allow you to use them as a GUI for your Git needs. Even if you are very comfortable with branching, committing and pushing on the command line, a GUI for conflict resolution is so much nicer.
Command line
The command line is your friend with Magento 2. Using Composer, a package manager for PHP libraries, a single command can install Magento 2 and all its dependencies, along with any third-party extensions and their dependencies too. We choose to make our own custom Pinpoint extensions installable via Composer for ease of set-up and deployment.
Thankfully, our editors of choice also come with a terminal built in so you can be sure you’re running the right command on the right project – you don’t even have to leave the comfort of your editor’s window to do it. From clearing caches to setting up admin users, the command line is a vital tool.
Version control
Git is the only sensible choice of version control tool these days – I remember SVN and I still have nightmares! We use Github to store and manage most of our repositories while a few of our clients use Bitbucket.
Most of the team use a combination of command line and GUI when it comes to Git. As mentioned above, it’s so beautifully integrated with our editors that it’s possible to seamlessly run a Git command in your terminal and visually see that file get staged in the GUI, all within the same window.
Pre-processors
Less is Magento’s choice of pre-processor for writing CSS. Sass (SCSS) is Pinpoint’s choice of pre-processor.
It sounds like we are making a rod for our own back by picking a competing pre-processor to the one chosen by Magento, but in fact it’s been a pretty good decision. We’re fairly confident in saying most frontend developers prefer Sass to Less – which is great for our current team and any future team members.
While we do have clients that have come to us with Less already implemented on their sites, we start every new build with Sass. In the past we’ve used Snowdog’s Sass port of Magento’s Blank Theme as a base, declaring it as the parent theme to our custom theme.
More recently we have developed our own ‘boilerplate’ theme to use as a starting point. This theme is a lot lighter, less opinionated and nowhere near as overengineered as the Magento blank theme. It provides us with a quick start to builds alongside removing the need to repeatedly build the same common components over and over. At the same time, we don’t have to battle against the overly specific styles generated by the blank theme. The result is a smaller CSS file for production and a more maintainable codebase for development.
We do have a few client’s sites where we have started completely from scratch with no parent theme whatsoever. Sounds scary, but we promise you it’s not. We actually prefer it to using blank as the parent theme for the reasons above, and we’ve not noticed any significant differences in development time between builds that use blank and those that start from scratch.
While our boilerplate is still in its infancy, early signs are showing that it will improve development time on builds, and we expect to use this for the majority of client site builds going forward.
Task runners
In a similar vein to pre-processors, our preference of task runner is different to Magento’s. We use Gulp to compile our Sass and minify it for production. Magento chose Grunt for the task of compiling Less.
For those client sites that already have Less and Grunt set up, we continue to use those technologies. We don’t rip them out for the sake of it. But our new builds always use Gulp and Sass. When we’ve used Snowdog’s Blank Theme in the past we have used their excellent, Gulp based Frontools.
However, now that we have our own boilerplate theme, we also have our own Gulp script. In fact, we are currently in the process of extending it to do more than lint and compile the CSS. We are enhancing it to also lint the JavaScript, optimise images and more. All the usual goodness is included – watch tasks, browser-sync and caching on the images so only new images trigger the minification – to make development as pain free as it can be on Magento.
Magento’s own bundler isn’t our first choice and we prefer to go with MagePack and have just started using MagePack for bundling of JavaScript. It’s early days, but it is looking very promising indeed with some quite dramatic improvements in page load times and other key metrics. JS Bundling has been a key thing that has been missing from the Magento 2 Frontend Workflow since it launched.
Looking to the future, with React PWA on the horizon, the choice of task runner is likely to change for any new sites built with a React theme. Webpack is our current preference for package management alongside Babel for transpilation of JSX to JS.
JavaScript frameworks
Magento 2 uses a variety of JavaScript frameworks and libraries. Roughly speaking, the majority of the JavaScript is written in jQuery, with the more interactive and dynamic parts written in KnockoutJS.
Magento 2 JavaScript is structured in a modular way. RequireJS is responsible for the loading and management of the individual JS components/modules, which it does in sync using the AMD specification. Understanding the basics of RequireJS is essential for making any progress with the JavaScript on Magento 2. However, the basics will only take you so far. It’s fair to say that the learning curve for JavaScript in Magento 2 is steeper than it was for Magento 1. But that shouldn’t put you off. There is much to gain from becoming familiar with importing and exporting JS modules and working with lifecycles and events in a dynamic JavaScript framework.
This, once again, brings us to look to the future. React is Magento’s choice of framework and this time we agree. Our in-house R&D team is busy identifying how we should best implement React on the frontend. Do we back Magento’s own PWA Studio, look to use a third-party React Theme (such as the very impressive offering from ScandiPWA), or go for a more platform-agnostic solution like React StoreFront? Only time will tell.
As you’d expect from a team of technical experts, we have an inner geek streak to satisfy. With a team of Magento certified specialists making up Team Pinpoint, we’re all about Magento and the capabilities it possesses to power online stores. However, it’s not all work and no play. Our culture encourages both hard work and fun along the way, making Pinpoint a perfect place to develop and thrive as a Magento Developer. If you want to talk more about Magento 2, find out what roles could be available for you at Pinpoint or require development guidance, please get in touch.
Share
