tl;dr: I was compelled to write this because I saw a lot of complaints which seem to come from the end of the Magento 1 era. Many of these complaints are reduced when considering the context, and they are all handled quite nicely in the Magento 2 era.<p>(Full disclosure: I'm Magento's chief evangelist, but I was an agency developer for a Magento shop from 2008-2014, so I'm not totally a shill. Also, I care that we are listening & getting things right.)<p>I spend a lot of time interacting with PHP developers around the world. Some have been / are Magento developers, some are not. By wearing Magento gear at conferences and usergroups I would hear quite a lot of opinions about Magento, both negative and positive. Here's the negative.<p>* No documentation
* Can't test it
* XML sucks
* EAV is the Devil's creation
* The view layer is impossible to understand
* Inconsistent implementation in core code
* Not true open source
* It's too complicated
* It's too slow
* etc.<p>Fact is, there's always more to the story. Take documentation: yes, it's tragic that there never was official developer documentation for M1, but it was an outcome of Magento's explosive origins leading to the company being totally constrained. (We did eventually produce some fantastic user docs though.) Magento 2 solves this by having several tech writers on staff, as well as a doc site to which the community can contribute via pull request.<p>In the case of testability, well, Magento 1 was born in 2007. Ideally, yes, it would have been built with test coverage, but that wasn't standard practice for PHP back then. (How many of you were writing tests for your PHP apps in 2007? Not too many aside from Sebastian Bergmann!) Eventually though some great tools came around, and there are many examples of fully covered installations as well as CI/CD implementations. Magento 2 solves this by covering much of the core with unit, integration, and functional tests.<p>Regarding XML, Magento 1 (and 2) largely favor configuration over convention, and the decision was made to use the most structurally descriptive markup possible. Of course, the implementation of it in M1 was full of Magentoism - building a DOM by combining DB data, merging multiple XPATHs, and filling out a bizarre hierarchy for scope. It's not intuitive without either experience or schema definitions. Magento 2 solves this by splitting up configuration into functionally-scoped files AND by providing XSD. The XSD help when editing files by hand in an IDE, and we are seeing the creation of tools to help developers avoid writing it altogether.<p>When questions about EAV come up, believe me, I understand. That's a tough storage pattern to get used to, but the ORM helps quite a lot. The implementation in M1 is imperfect though, as you do end up with domain objects which leak their storage pattern. EAV is invaluable for solving the complicated requirements of facilitating arbitrary entity attributes and scoping/translation of those values. We looked at removing it for M2, but could not find a better solution. And if you say "noSQL," sorry, you're wrong.<p>The view layer is the thing which trips most people up - even developers who grok Magento right away. Theme fallback and layout XML are the complicating factors here. Theme fallback/inheritance is not so hard to get, and it is fantastic at keeping custom themes DRY - especially when multiple sites are running off of one instance. If only one thing could have been documented from the beginning, it should have been layout XML. Layout XML - along with the view model approach which we took with M1, allowed for simplified, DRY controller actions and ultimately allowed frontend developers to build interfaces without having to need backend developers. In M2 we have refined layout XML as well as abstracted the entire rendering framework, allowing developers to adjust or replace framework details as they see fit.<p>For inconsistent implementation in core code (which is especially evident in adminhtml), this was the outcome of a small team producing a lot of code independently. It's unfortunate, and very confusing for developers new to the platform. I struggled with this when I was starting out. We've worked to eliminate this in M2, but there is work remaining to be done. Thankfully we have Issues and pull requests on GitHub, and at the very least we can evolve our test suite to help us (and others) to implement functionality in The One True Way®.<p>On the subject of GitHub, we are much more of an open source company than we were in the Magento 1 days. We did allow contributions, but the process for becoming a contributor was cumbersome, and development effort was only revealed through updates to an SVN endpoint with no discussion. That is very different from our approach with Magento 2. Starting with the beta in December of 2014, we allowed pull requests to the M2 codebase, eventually building in our contributor agreement into the CI process. Many of our core engineering team are regularly on GitHub interacting with a bevy of "how do I" requests along with legitimate issues and pull requests. We have improvements to make here which will help us to keep up with the volume of discussion, and you should see these soon.<p>When I hear that Magento is "too complicated," I have to ask, then why doesn't something similar take its place? Ultimately the problem of complexity rests with the domain of commerce, which is always custom and always complex. Consider just one area of a commerce application - say, price calculation - and look at the complexity: cost, retail price, adjustments at the catalog level, adjustments at the customer level, and then add in the multiple taxation schemes which exist in the world (tax on full price before discount vs after, tax on shipping, etc.). Complexity is everywhere, and if you want to make an app which works for most, there will be overhead. Ideally the app helps the user manage that complexity as best as possible.<p>When I hear that Magento is too slow, that is always a worthless discussion without details about traffic, order volume, amount of entity data, update frequency, etc. M2 is a much better application for performance than M1, largely because it was developed with a mind to commodity computing and reverse proxy (which were nascent in 2007). That allows us to build core architecture for performance as well as enterprise architecture for scalability. That said, performance for M2 is not a finished story; I imagine that we will continue to improve on it as time goes on.<p>Okay, if you made it this far, I owe you some coffee or beer or whatever when we happen to meet. I was compelled to write this because I saw a lot of complaints which seem to come from the end of the Magento 1 era. Many of these complaints are reduced when considering the context, and they are all handled quite nicely in the Magento 2 era. I'm always happy to see or hear feedback.<p>I can be reached at ben@magento.com.