Over the past couple of months in between my day job of running WebShopApps/ShipperHQ (which keeps me more than busy) I’ve been writing Magento 2 extensions. For fun? No not exactly, we were asked to write them by Magento for the Merchant Beta, the rest of my team is maxed so I get the short straw.
I wanted to jot down some of my experiences so far, and my conclusions at this point in time. I realise you will not all agree, in fact far from it. But someone needs to raise these issues. Because many of them are valid I’m sure.
Magento 2 is a total rewrite of all our code
What I’ve found is that pretty much without exception we need to rewrite all our extension code. In the most part I have no issue with this. Its a chance to refresh, do things differently, regroup. But where I do have an issue is where I have code written in the last year and I’m finding that very little can be re-used due to the changes in Magento 2. And worse, if I do take the code and copy into Magento 2 extension I then have hours of painstakingly boring and meticulous work pulling out all the objects into the constructors, creating the factories, adding namespaces, switching around the way many many mechanisms work. The IDE is not helpful, coming from using IntelliJ on Java in the past 2 years I find PHPStorm is just utterly frustrating on every level. And its written by the same company, so clearly many of the isues are actually with the PHP language. Hopefully Magicento can help us!
Magento 2 is changing
It’s clear from looking at the Magento 2 codebase that not all of it has been fully refactored. In between Merchant Beta and a release just 3 weeks later my Magento 2 extn broke because of changes to the core code. The code is inconsistent, e.g. the use and non-use of underscores for variable names is frankly totally frustrating, as if you try to adhere to not using underscores (as seems to be recommended) you then find you are either repeating variable definitions in parent classes or have this rather odd mix of underscore and non-underscore in your own code (which looks awful). I get its in beta. We are being asked for code for ‘free’ against beta. Its frustrating.
There are many other examples around this area, for instance there was a full-on debate the other day raised by myself on whether Observers still are valid or are replaced by Plugins. TBH I felt like I was a leper even questioning the concept, and I was shouted down initially with a very firm argument against me saying that Observers were dead (which in my mind went against core computing principles around the use of interceptors). In fact they aren’t, as became apparent later. What if I hadn’t have questioned this (and if Alan Storm didn’t raise many of the very valid questions around Magento 2)?. In my mind these basic principles of the Magento framework should be fully decided, documented, and ideally adhered to throughout the codebase so we have examples (especially when there is a lack of clear documentation).
The biggest point here is that I don’t believe Magento really appreciate the knock-on effect of constant fiddling with the Magento 2 code. Agile is good, quicksand is not. They are asking us to write extensions on Magento 2. This is not a quick job, its tens of thousands of dollars worth of investment. And then if Magento go change everything we need to rewrite. This is why I personally stopped coding in Magento 2 between Feb and July, it just seemed that it was changing far too much to justify my investment of time.
Documentation is Sparse
There is an extreme lack of documentation to help us. The DevDocs area is non-searchable (yep I know the reasons why) and from my perspective its not adding value. Alan Kent and Alan Storm blogs are what I’m looking at most, apart from that I’m reading core code (hello 2008). I just hoped we would be further along by now, I don’t want to be investing my time in debugging the core or searching google, I just want to get a job done and fast.
Yes, I hear you say, write some docs for it. I have updated some docs. I’d do more but I have my own docs to deal with. I’d love to have hours to spend on writing Magento 2 docs but I have my own business to run. Magento is not my life, its a platform I integrate onto.
Design Pattern Overdose
It feels like some programmers swallowed some books on design patterns when I look at Magento 2. I get that architecture on such a large system needs to move towards standards and in an ideal world I’m sure we would all love to be using SOLID principles and never write an else statement, it seems to me that the resulting code is:
- Bulky, difficult to navigate and frankly overly verbose
- Written with unit testing as its primary goal
- Inconsistent in its use of computer science techniques
What Magento does is great, and I have the utmost respect for the Ukrainian development team that largely put this together.
I think whats bothering me is that as a company I’m being forced to write in this new way too. And actually whilst I think they have some great ideas I don’t agree with all of them (e.g. lets dependency inject the world even if we will never ever ever mock/change that), and they just added a ton of dev time to my projects.
I should say that I’m familiar with design patterns, have used them recently and in the past. I’ve read GoF many times, and variations of it. Do I live my life by it – no. I’m not trying to be the best programmer in the world, I’m not interested in winning the award for anything. I’m trying to deliver quality timely solutions to my customers within a reasonable budget such that I can pay staff wages and my mortgage. I have nothing to prove academically.
TDD
We all want to do test driven development (in theory). In reality few do. I’ve done pair programming, I’ve done TDD, in various languages, and its very hard to make that the way you function. There are many articles on TDD. Personally I think that unit tests are extremely useful, especially when it comes to refactoring and regression testing code, and I push all my staff to create.
But writing tests when you don’t understand the framework you are using is nigh on impossible, so following TDD when you start writing Magento 2 code IMO is very hard.
TDD is also time consuming. And unfortunately we don’t all have massive budgets or unlimited resources. Its a massive re-pivot to ask a company to follow a TDD approach, especially initially. I have no doubt it will happen, and it will be a good thing, but I’m just not sure automated unit tests will be there from day 1, and by enforcing it you are saying that companies need to have more funds (i.e. its becoming an enterprise product).
As a FYI we use automated unit testing very successfully in ShipperHQ, we also have automated unit tests on several of our Magento 1.x extensions. I’m not against unit testing at all (and I believe in the long run it will improve the quality of extension codebase massively).
Do we need Magento 2?
This is the biggest thing I’ve been struggling with. I know we need Magento 2 in theory, I totally get that we need higher quality, more testable code, and we need to bring the technologies upto date.
But – you know what we are all busy. And I have a team that is trained in Magento 1. Yes there are issues in 1, do I want to throw away a years worth of work at this time – frankly no. And it’s not just a years worth of work, because what I’ve found is that you end up just refreshing everything.
Add to this the fact that everyone is busy. We are all earning money right now and need to keep up with that. Do we have the time to invest in Magento 2? It is not 2008, there are many alternatives (including 1.x), maybe as businesses we decide not to invest in it.
Personally I do think we need Magento 2, well we need a replacement. I’m just not looking forward to the pain of what it is!
Integrating as a Technology Partner
From my experience thus far in Magento 1.x and 2.x our base investment in Magento is at least 100 times what we are investing to plugin into other eCommerce platforms. The ongoing investment for supporting an existing extn is massively more (though hopefully some of this will be alleviated with the introduction of service contracts and clear interfaces when they are completed).
Personally I think technology partners just want to worry about their own area of expertise, whether thats email, ERP, shipping, payment, or whatever. And they just want to plug in to Magento as easily and quickly as possible. With other platforms we don’t have our codebase under anywhere near the level of scrutiny as we are having to go thro with Magento. And it actually just works, nowhere near the level of site issues (in fact there are no site integration issues due to the way platforms such as Bigcommerce/Shopify define their apis).
Conclusion
I love Magento, and all its about. The merchants, the code, the community, the ecosystem. Magento 2 promises us many things, reduced conflicts between extensions, better performance, higher quality, to name but a few.
But I feel like no-one is flagging these very real concerns, and they should be flagged. Because it will affect us all directly or indirectly. If this blog makes one of the Magento developers sit down and write more developer documentation or helps push Magento publish a functional roadmap outside of github then my job here will be done.
If Magento 2 is hard to learn and does result in longer more expensive projects then I’m not actually sure companies will move to it. I think agencies might try one project, find out that it costs them a fortune and revert back to 1.x. I think extension companies will write basic extensions, see what the uptake is before investing significant money in building out more.
What I see is that Magento 2 today is destined to be an Enterprise solution. For definite anyone with a Magento site < 1million in revenue (and a decent profit) should really be looking at other solutions for their needs. You are going to see design agencies disappear, extn agencies disappear. And you will see new ones enter. But I’d be very surprised if the agency prices on Magento 2 implementations don’t rise dramatically. A big reason within this is that Magento developer salaries will rise further, because many will struggle with it.
What I’d like is for Magento to tell us where Magento 2 is pitched. And be clear about that. So that thousands of agencies/developers/merchants dont invest in this and then find that all their hard earned cash is sucked up in a money pit with no return.
And actually I’d love to be proved wrong on all of the above. Because personally the thought of this community become a small cliche of elite programmers and gold solution agencies just doesn’t appeal.
Great points. I can probably relate to most of them. I’ve been intensively working on a Mageto 2 development book for the last few months, and did a great deal of modules along the way, touching most of the aspects of platform. Personally I found it really easy to catch up with most of the parts of platform. But easy does not equal quick, as I always keep emphasising to clients and PMs. Doing even the simplest things the “right Magento way” takes time. I would guess that the junior developers would find it much more harder to master Magento 2.x than Magento 1.x, as it simply packs more patterns and technologies with it. With Magento v1.x I had a feeling that 80% of all code I write is just a boilerplate, with Magento 2 I have a feeling like 90% of all the code I write is just a massive boilerplate. While I honestly understand why this is the case, I still find it hilarious to see lets say the size of new Ui components XML grids for administration area. Platform simply is not built with speed of development in mind. On the other hand, its so robust and feature rich that I question all “simpler” solutions out there. Looking at Magento 2.x I am more than happy to build almost any web application with it, not just eCommerce. Because simply put, it packs (almost) everything you need from a platform(from admin area, ACL’s, roles, APIs, etc.). Fingers crossed for the next 4-6 years, may we all successfully continue to ride the Magento wave 🙂
Very good article, Karen!
We’re pretty much in the same boat as you – many years spent developing and learning Magento 1.x and now we’re starting on Magento 2 – is it worth it? I’d say yes if the performance benefits of Magento 2 are as good as we’re seeing so far.
Perhaps if Magento 2 was simply Magento 1 with the performance issues resolved the community would be happy enough sticking with it?
Then again, remember how bad OSCommerce got?
Not to detract from the main topic, but what performance issues in particular do you have with M1 that are solved in M2? I’ve never found M1 slow; the only things that make it slow are bad code and insufficient hosting.
A change of platform merely in the pursuit of speed is a huge leap to take; you’d save time, money and instability by spending a day profiling code and getting it on the right infrastructure.
Do we need magento 2? I say not at all, the current version is not perfect but it is close. With some custom performance improvements I could not imagine a better platform. The XML and fallback features combined with site/store/view is golden enough nothing else could make it shine any brighter in my eyes. What does not exist, I write myself. It’s php, its zend… What more could a dev ask for!? I love Magento the way she is and feel the community might consider a revolt before we lose what we have. Perhaps the aquiring company feels responsible to rewrite from scratch when in reality only a few changes need to be made, none which should affect the current modules functionality.
I found this article out of frustration when I received the work assignment to study Magento 2. From the existing documentation I could not understand much… I hardly understand the basics… It took me 3 days to build a module with a plugin class to intercept(I guess this is what I did) the addition of products in the cart… But I cannot understand the XML configuration of almost anything. Althrough I am familiar with Dependency Injection, I fail to understand it in Magento 2. Apart from scratching my eyes using some sparse module examples, I can’t understand how the f… you can add a simple form to be shown in the frontend somewhere… I can’t understand what’s the point of having so much differences in folder structure between frontend and.. Adminhtml. Also.. there is a lack of consistency in naming… You have all kind of naming… Oh you want to build a grid in the backend… F…YOU! Use a bulky XML file with a lot of tags nowere documented… Oh and the compiling “feature”… it’s the most annoying thing since Turbo Assembler… WTF people… it’s 2015 already…
How on earth can someone not mentally ill can understand this sick platform???
Thanks for writing this Karen. You’ve just scared the s**t out of me.
110% agree Karen. People likes me handling and maintaining severals customer’s magento dont ser the point to adoptó the Magento 2. IT is going to take more than a while to do that upgrade. Indeed more when you have mature online projects that are selling everyday. Who is going to take the risk of upgrading to something “new” when the “old” is selling and working (after a long time of tuning and solving problems)
I the technical side, I have had works with design patterns for more than a decade. First time I saw DI being adopted in Zend Framework the it tooks ages to be “explained” and “adopted” by the community. Indeed today still being quite controversial. This happened 6 maybe 7 years ago and the result was: a gap! A gap between projects and coders that don’t go forward and stay wit ZF 1.xx and new projects that were take the new way. The community become divided and believe me, ZF stop their strong evolution at that time. I love much of the design patterns I have known. But every pattern has its own reason to be used. I think as you that there are some decisions taken by purist programmers that force to the rest of us not to progamming but meta-programming.
Well you explained better than me. 110% agree. I hope to be wrong but this is going to be painfull. Don’t know if the clients at the other side are going to be happy to pay more just because our platform is heavier and more “time consuming” development environment.
thanks for sharing. This is also community!
PD.: Branko fhow is going your Magento 2 book? Finish it Asap .. It is going to be required!
I’m a Magento 1.x developper for 7 years now, and i’m diving into Magento 2 code, tutorials, for a week. What a relief to read this article. I’m not alone to feel that something is going wrong.
“Magento 1.x has bad performance” is really a sad “mass thinking”. It’s simply not true. And why it happpened ? Because bad developpers did very poor jobs in a lot of projects… Oh yeah do a load() in a foreach, oh yeah, 1500 sql requests on a 20 page list…
I installed sample data on the 2.0, out-of-the-box, and what i see ?
588 request on home page.
1117 on a 9 product list page o_o
Seriously ?
And i don’t even talk about all those XML, all those design paterns… I’m so used to (Magicento + UMC + PHPStorm) = WIN …
@Sennin
There are many performance improvements in magento and it’s clear you are not up to date with Magento 2 yet.
Do you really think they would send out 588 requests on a home page in production? Of course they optimize everything with bundling and mimification. Just put your installation in production mode instead of developer mode.
http://devdocs.magento.com/guides/v2.0/config-guide/bootstrap/magento-modes.html
Finally someone that doesn’t lick Magento 2 backend… Thank you Karen for this article!
You only have to have an “Install Magento 2” experience and you already know the hell in front of you. I understand the concept of splitting back-end from front-end and just let browser to do some front-side job instead of server-side, but even if you go completely front-end developer you would still have to scratch your JavaScript part of the brain to understand all flow (MVVM concept etc).
Biggest problem is the lack of clean documentation, and I’m not referring here on documentation about how we add products in back-end… It’s TECHNICAL documentation and samples that you just cannot find!
Short story, Magento 2 is a nice learning material, with lots of hours of study in order to get your extension working, so be prepared!
Andy
While I agree that the work required to ‘port’ (read completely rebuild) extensions to Magento 2 is massive and this is a big down side, I do really like the feel of the Magento 2 codebase. It really is leaps and bounds ahead of the Magento 1 codebase to the extent of (in my mind at least) almost making Magento 1 seem rather homebrew! But that just be because I’m so familiar with the Magento 1 codebase now, and only becoming so with Magento 2.
Personally I am excited to be working with the new codebase and didn’t really touch it too much until general release purely (outside of lack of time) because I could see so much transition taking place I anticipated a certain portion of work would simply be undone as the core code was further developed – it sounds like this very much proved to be the case for you! If I had started work earlier with the codebase I could imagine I would have been similarly frustrated.
So my general thoughts are that I am essentially enjoying the Magento 2 codebase and looking forward to working with it further, but certainly not enjoying the challenge of basically a complete rewrite of all of our extensions, particularly our flagship caching extension Evolved Caching which has seen 60+ releases over around 2 years. The time and money invested here is massive and a complete rewrite is not an attractive proposition.
Ultimately, I think that as long as Magento don’t get it into their heads to completely rebuild the platform again (or at least not for a *lot* of years) then the move to Magento 2, whilst troublesome during the transition has to be a good thing in my book as the codebase is just that much better and more structured.
You hit the spot with this one Karen: “Magento is not my life, its a platform I integrate onto.”
Seems like that in order to be at the top of the game you need to let Magento consume you instead of the other way around.
Agree with Branko here that with all of the drawbacks it is still the best option from the business perspective.
Looked at several other “new and shiny” API powered e-commerce solutions, yet they all pale in comparison with Magento, even with the obvious lack of proper documentation (Magento 1 all over again).
Glad we are not alone in our conclusions so far.
The over-design is purely ridiculous. Here are the inode counts for a clean install (without and with sample data):
find ./Magento-2.02 -type f | wc -l
41401
find ./Magento-2.02 -type d | wc -l
17085
find ./Magento-2.02s -type f | wc -l
43237
find ./Magento-2.02s -type d | wc -l
17295
Pushing 60,000 inodes.
It would be manageable if the design rules were followed throughout, but sometimes the code is found HERE, other times the code is found THERE.
I don’t understand how rational people can keep drinking the Magento KoolAid. How can someone say they like this new codebase. 60,000 inodes? That is pure insanity. Jonathan, do you work for Magento? http://ramblings.mshaffer.com/tech/74/magento-2-setup-inode-annoyances
When a private enterprise releases and controls the open-source CE edition, you are certain to understand it is far from an open-source solution.
Hi, I totally agree that M2 had lot of potential but unfortunately the developers made decisions that are very hard to understand. I was so excited before the release of M2 but the more I look into it, the more I feel like not only M2 solves none of M1 issues, not only M2 adds some new issues we really didn’t need, but M2 is NOT a new version of M1, it’s a different platform entirely! It’s like developers wanted to launch a new tool for e-commerce but were afraid that few people would be interested, so they put a well-known and respect to this new tool to drag a lot of people into it. Moreover, it doesn’t matter if M2 is good or not, we are forced to move to it because in a coulple of years support for M1 will be stopped.. I really would have appreciated more if the developers had taken all the good that there is in M1, fixed the few issues of M2, taken the result and released it, that would have been a new version of Magento!
But the way they did it, they created a totally different tool that it is not better of M1 is only totally different, so question isn’t really ‘do we need an improved new version of Magento?’ (because the answer of that is ‘yes, we do’), the question is more like ‘do we need another avarage prestashop-like tool for e-commerce?’ and to that question I can honestly answer ‘not at all’. And the fact that this mediocre tool we all are forced to use instead of a great tool like M1, well that really is depressing!
“I really would have appreciated more if the developers had taken all the good that there is in M1, fixed the few issues of M2”
of course I meant the few issues of Magento 1..
After Magento 2 was released I convinced myself that opencart was the best option for my customer with an online b2b sales website.
Boy, was I fucking wrong. I know that Magento needs to keep up-to-date but 1.9x to 2.0 was like a bullet in the fucking brain for me.
Sorry if that was dramatic but that’s the way I feel about it. I am now running a few customers sites on opencart and it is horrible. I just don’t like opencart, no offense. I think I’ll just go back to Magento 1.9 in the future.
Thanks for this article. While there are a few nice things to say about Magento 2, like the Plugin principle, no more hidden Flash integrations, no more Prototype… There is a real shitload of new problems.
In my view it is pretty clear what happened here. Varien decided to make it’s money on developers by selling …. sorry renting out educational material and making certifications harder. They are so focussed on that, that they put every effort into to making the software more complicated for no reason at at. New XML structures, Knockout, Magento UI, Generated PHP Classes, Bulky DI concepts, Static Content, Pre-Processed Static content, 1’000 cache variants… The whole system is a big FU. The chance that something goes wrong when you go live with this shop is above 300%, the chance that a customer doesn’t like a feature that cant be changed is just as high. The chance of getting a complex shop running smoothly is close to zero.
Seriously, caching should be there to handle heavy traffic, not to make the shop barely usable for a single developer that just wants to see if the checkout works.
Even tho there were some great brains behind the making of Magento2, the software itself is garbage. Sorry to say that, I wish it were different, but if don’t have millions asside for development, stay away from it.
I started working with Magento 2 yesterday. After years of M1 I was too enthuisiastic when I said to a customer to do a shop in 4 weeks.
Took me hours to change something in the header. So out of frustration i landed on this article.
But my question is. Are there any equal alternatives?
Hey John, Not sure there are equal alternatives, I think you have to go back and work out what you actually need here and where can you compromise. Magento is fully extensible and comes at a cost. If its a quick build then using a SAAS platform such as BigCommerce or Shopify is probably the way forwards.
NO NO NO – Do NOT use Magento 2 – it will waste days of your time, cost way too much (if you use a developer or firm) and become the worst mistake you ever made. Go with shopify or even woocommerce, if you need custom functionality, go with Drupal
Still sticking to M1 til now. M2 has a lot of mysterious bugs, even with the latest 2.2 version. And it’s very slow, I don’t know why. Maybe it’s my server setup or something. But it’s terribly, terribly slow and 2017 is almost over.
@Dave same here Dave, same here. Modifying just the product view page and moving one block to another div is like rocket science. It’s an obivous marketing stunt. So I tend to just move blocks using jQuery append and prepend, instead of the best practice method (via the new XML structure).
I really hope the community will continue to support M1 if Magento cease to support in by 2020.