While crafting a response to this post on reddit, I soon realized my opinion was bigger than a reddit response and could be interesting to our blog followers.
What is the state of Magento 2?
The initial question was about the state of Magento 2 (which I argue is not bad, certainly better than other open source platforms but could be better – see below). The specific comment that got me thinking was the use of knockout.js.
I agree with the comment maker that knockout is a horrible framework that requires far too much specific knowledge to implement correctly. The criticism can be more generalized, though. Why have the stack and architecture of M2 made implementation and maintenance for most merchants more expensive with few important improvements to show for it?
The new design of the admin panel, while prettier, is less intuitive than the old one. The stack overall is dated for a relatively new product. Why is that?
Magento knows it has a problem
Magento has clearly acknowledged stack issues in some areas (decision to move to Sass from LESS, for example). Even the ‘headless’ movement (of which I am a supporter), while useful, is a bit of a hack. Other systems like React Commerce and even Shopify are more suited to headless implementations.
The Magento 2 tradeoff
Shopify, however, has the downside of the inflexibility of a SaaS platform (just try creating a custom API endpoint) and React Commerce has such a small ecosystem that most merchants would be crazy to launch on it given the meager potential for support resources (we wouldn’t support it — yet).
How did we get here?
I really think the time under the eBay banner turned out to be detrimental and threw the technical leadership into confusion, causing delays in release time as the finer points were debated in committee. In fact, Magento 2 didn’t get back on track until after it was spun off. These delays made for what appear to be bad choices and the datedness issues.
The framework problem and time-to-market
There is a great article by Ian Allen on Stack Overflow that elucidates the issue.
This graph shows that knockout.js was the bee’s knees in 2013 – probably when the decision was made to implement it. It was on the way up. In fact, the only real alternative the Magento 2 architects had at the time was backbone.js In 2017, both are all but dead. Magento 2 was announced around 2013, but, wasn’t released until 2017. This delay lead to sub-optimal architecture.
If you run the same comparison on less vs sass (two CSS compilers) you can see that in 2013 the decision would have been unclear. by 2014, it was clear. So, yeah, time-to-market does matter. A lot.
Giving up what is important for what is expedient
Other than the choice of frameworks issue, the Magento 2 team seems to have completely given up on the service layer which would have provided a system of contracts between modules (and extensions) and a common communication fabric (remember X.commerce, anyone?). This meant that Magento 2 would inherit the same conflict issues inherent in Magento 1.
Yes, we got RabbitMQ (in EE – thanks to Josh from Creatuity for fighting for that), full-page caching in CE, and the ability to run PHP 5.7+ (speed improvements), but, not much else. For a product that spent 3 to 4 years in development, we honestly would have expected more.
What should merchants do?
We could criticize Magento’s faults all day long, but that doesn’t help merchants with their platform decision. Other platforms have their issues, too, and there are clear advantages of using Magento 2, like the number of developers, size of the organization supporting it, ecosystem, extensions available, familiarity with how it works by merchant and admin users, and developers like Razoyo (shameless plug, I know).
While Magento 2 is not the right choice for all merchants, especially smaller ones who now have Big Commerce and Shopify to choose from, it’s still the right choice for many, many merchants.
I personally believe a lot in the current Magento team. I think they can and will solve most of the issues over time. However, I don’t have a crystal ball. Time will tell. If you are a merchant, you shouldn’t plan to stay on any platform over 3 years.
If you do, it’s a big win! Consider yourself lucky, but, don’t pat yourself on the back. You made the right choice in retrospect, but, at the time you didn’t know it would be.
Rather, plan to be flexible. Don’t over-invest in your platform. Refactor with external services (which tend to be portable) when you can. Ask us. We’ll be happy to help you with the decision.