Magento 2 has a lot of awesome new approaches to day-to-day issues, but also suites the classical Magento mantra “Let’s make standards the Magento Way™”
If you give it a chance and find your way around the quirks of it, it’s not so difficult at all.
They are using standard components
Magento 2 switched to very common standard components, which a lot of you already know: jQuery, requireJS, knockout.js – Some are not so common: Less
But unfortunately, they still follow their Mantra to implement these standards in a slightly Magento’s way. On one hand I can absolutely understand their reasons to do so, on the other hand: it makes it much more difficult to get started with Magento2.
Let’s talk about that “Less” thing
Yes: the bigger part of web-development-land uses SCSS. But to be honest: Less isn’t that different at all. Slight syntax differences but the concepts are identical.
Then why in lord’s name did they choose Less
Well, when this part of Magento 2 was built, there was no stable and maintained PHP-based SCSS parser. So they used Less for Magento 2.
But why not real Less?
Real Less, that you can directly parse with a native less compiler? Modularity doesn’t go well hand-in-hand with plain Less files. You can’t tell the processor, to include files from different directories based on patterns.
You only have two options now:
- Code some voodoo magic that runs ahead of the processing
- Have core files being changed by various people with merging conflicts and content duplication and what not …
I would have created something similar to Magento’s //@magento_import ‘hack’. Once you understand that concept it’s not just easy but also very flexible and saves resources if specific modules are turned off.
Speed of development
If you work with Magento’s native PHP-based Less workflow it’s very frustrating. Whenever you change a source file in your theme, you have to delete at least 3 different files in at least 2 different directories. There’s no built-in automation for that (var/view_preprocessed and pub/static)
If you complain about that at Magento, they go to reply that no one is using that. That’s not quite true, I would say, but what’s the preferred way then? Well … just use a local task runner like Grunt that does it for you. Magento 2 already ships default config files for NodeJS and grunt so you can start right away and take advantage of the file watcher benefit — change your less file, get rebuilt CSS files automatically.
Using that adds additional technology layers on top of your already quite high technology stack (Html, CSS, less, Php, Mysql, JavaScript + NodeJS, grunt).
Did you hear about these UI components?
Yeah … okay … that one particularly is a pain in the ass. It’s a freaking mashup of random configurating XML, knockout.js with Html templates, requireJS, and jQuery Widgets … It takes a good while to understand it if you really accomplish the “understanding”.
Magento thought about a way to load data asynchronously together with reusable generic elements in the backend and frontend. In order to not rewrite every component, there had to be a way to configure each component individually. That’s usually done with json injected into the component.
There’s one more thing …
But Magento wouldn’t be Magento if they’re not using XML for it! With Magento 2’s new layout XML capabilities you can create hierarchical structures containing arrays and data (like objects i.e.). So you can also create the configuration for UI components via layout XML …
That might look like some arbitrary XML that doesn’t follow any rules. Which … more or less …is exactly that: arbitrary XML 😶 but it’s flexible and interchangeable!
That’s one of the smaller parts of Magento 2 where no tool can help you and where no palliation is available.
But there are other crucial parts, where someone is to our rescue …
Caching
Magento’s Caching now supports a full page cache as well as a wide variety of other cache types. If you’re writing an extension that touches different parts of the app you got to clean the caches A LOT … So, the easiest workaround here would be: disable the caches.
No Cache … No Performance
If you disable the caches Magento becomes ridiculously slow on every request. Manually partial cache cleaning instead is a pain in the but again, because you always have to think about which caches you have to clear. And if config is one of them — get yourself a coffee :-) because you can’t kick out just the affected cache fragments but have to clear the full cache section.
Make sure you’re using redis to have a faster cache backend; that doesn’t solve the problem, but at least makes everything a tiny bit faster.
Plugins? I like them … not just in WordPress *cough*
Functional extensibility is always a tricky topic and not easy to handle. Most application chose to go along with publish/subscribe implementations. You can still create subscribers (called Observers) in Magento 2, but there’s a more powerful way: Plugins!
Before / after / around!
Magento 2 generates a lot of PHP classes automatically based on configuration options and source code. By simply creating 3 lines of XML together with a new class, you can hook into almost every public method call. That’s done by parsing your new class and look for method names of the original class, prefixed by either around, before, or after. Magento will then magically create a new class (called Interceptors) that (i.e. before) first calls your method and after its execution calls the original method.
1 … 2 … STEP
And the cool thing here is: you can have as many plugins chained in a specific order as you like. Even around, before or after. Magento takes care of it.
But why is this difficult?! That’s awesome, man!
It is! But in developer mode … oh hell … Magento will create those intercepting classes all the time for all the methods, no matter if you need them or not as long as there’s a plugin configured. And I dare you to go for it with xDebug … The stack traces are toilet paper long!
If you don’t care about these repetitive debug cycles with “autogenic training” like immersion … you’re fine! One note: Only use around Plugins if it’s unavoidable. Their impact on performance is much worse than before and after.
Conclusion
Magento 2 is more difficult than Magento 1, especially looking into frontend development. As always: the wonderful Magento community takes care of some of Magento’s events and tries to help with their expertise. Be it with tutorials or tools. Once you understand the ups and downs of Magento 2, how you probably did with Magento 1 year ago, you might have some real fun and some very tragic moments with it!
Read more in Magento DevDocs.
