For what's worth, my thought on Magento2
I have been working with Magento in general for over 3 years now. And with Magento2 in particular for 1 year or so.
So I thought it was time to make a small article about what I think about Magento2.
It brand new
Well Magento2 comes with plenty of new things,
- Zend2 & it's Dependency Injection System, which is enchanced in M2.
- The api layer for interacting with the DB.
- The native rest/soap api's.
- Magento 1 did have a few, but M2 make it much easier to create new API's sing the api layer.
- Composer out of the box (finally)
- Improved layout systemp with ui components.
- Require.js & Knockout.js with brand new jquery version in the front.
- ...
I won't dwell on all these new features in Magento2; there are dedicated articles that does this very well.
But, I must point out that behind all this shiny new code, there is a lot of old stuff. This is not something bad. The new stuff is built on solid bases that existed in Magento from before, but enchancing it and making it easier to overide the code.
Until here all is good, in this new version of Magento2. Now let's get look deeper into this old stuff and what it actually means.
Not that new
The tinymce case
Well among other things we find some ancient libraries, such as tinymce, from 2009. Tinymce is the javascript library used for handling the wysiwig. Why do we care if it's so old? Well among other there recently was a bug that affected Magento1 & Magento12 where neither in Chrome nor Firefox Wysiwig worked properly.
This affected all old version of Tinymce, and as Magento uses an ancient version they had to fix it themselves instead of using the official fix(the applied the official fix to the old version probably).
That is a problem by itself, you use libraries in order to diminish the code to maintain yourself. The issue is Magento did extensive codes for the wysiwig editor, more precisely for the widget part. Taking that code and making it work for the new version of Tinymce would be a challange.
I am hearing you say that the wysiwig editor in M1 was working flawlessly and rebuilding it with mean need of lot's of testing and such. Yep you are right, but for one thing. The Magento 1 Wysiwig had it's own issues that are still in M2; and there are parts of the code for the widgtes for exemple that habe been rebuild which introduced new issues in M2 anyway. For exemple at some point we found ourselves with an issue preventing special characters to be used in widgets #4232.
We still also have issues with widgets containing "rules", when those widgets open the rules are empty.
The grid
So this is much less of an issue, but the "new way" of creating grids and back office pages are throught the ui components. In many ways this is a xml layer ontop of what existed in Magento1.
The issue here is for both developers that starts doing Magento2 after Magento1 or without any history of Magento. Both those developers will at one point stumble across both methods. In which case
- He will need to understands 2 things instead of one,
- He won't know what is the best way,
The best wat is to use the ui components Just to be clear.
The conclusion about it
Well the issue is the layers, upon layers, upon layers of code. Magento2 on many ocassions simply added another layer, hiding the bad paint with a beautiful new coat.
The second issue is the standard, There is a lot of specific xml(thank god for the xsd).
There is also the performance issue. Every layer is a layer you need to process, more layers, less performance. This doesn't mean you need to make 1 layer only. No you need to find the good balance between performance and the number of layers. In M2 case there are a few instances where there are to many layers because of old code.
To conclude about this section, we need to take into account that Magento dev teams didn't have an infinite budget; so building ontop of existing to provide a better api for developers isn't such a bad idea. It allows them with time to clean-up the layers below without affecting the top layer we use (hopefully at least).
New is not always good
I just finished criticising everything that's not new in Magento2 now for what's new. Well just kidding. There are nevertheless some new things that were not thought through enough.
The checkout,
I believe no Magento2 developer that has at any point tried to change the behaviour of the one page checkout will disagree on how hard it can be.
- First of all, everything is done in javascript, which is not a bad thing in it's own but for :
- In may occasions magento rewrites logic that existed in PHP in javascript. This is basically the same code duplicated in front & back. (yes I know node.js better then php and blabla bla)
- The javascript template & widgets is stored in a huuuge array created from an xml. In reality this is quite interesing as you can move elements around but in reality it's such a messss.(lot's of "s").
- Debuging, you never know it's a Backend issue or a frontent issue.
- Strange things, Javascript & templates for disabled payment methods & shipping methods are loaded.
Globally as I said the idea is ok, but I think more of the processing should have neen done by the back in order to prevent logic duplication. And well I am not sure what should be done for that huge xml (you actually need to scroll horizontally to read it) but as it is it's impossible to use.
The product widgets
This is a new little feature, that basically allows you to display products based on some conditions on any CMS page or block. So nice, so powerful.
Well try it out with a 1 Million product catalog...
Some conditions, such as category is handled properly by modifying the sql query. But some others, (even through I had nothing to do with) ashamed to say simply loops over the product values (Product values not whole product objects).
I don't know what was thinking the guy that did this... But thanks god there is Smile-SA/elasticsuite, some custom code and we were able to redirect all the rules in the rule engine of this module; so using elasticsearch to search the products instead of mysql + php loops.
The staging
It has nice functionalities & works quite well but, for a back developer it's a nightmare.
First of all if you intend to have 10 stages a year and have a catalog of 1 Million product, well don't think about it. 10 stages per year means 19 product duplications. 1 for each stage + one for each intermediate stage. So if you have 1 Million product, after 1 year you will have a database load as if you had 19 Million product.
I don't really have a solution to propose. Beside some fundamental changes, which I will discuss later.
There is something else that really bothers me with the staging; It's timing. When the staging module arrived, over a year ago we still had a lot of critical bugs with Magento2. Not just for bug projects but even on small ones. This module arrived in the 2.1 version at while we had hoped for major fixes we were saved a new functionality. The bug situation has quite improved since.
Production mod
Magento2 comes with 3 different modes. I will simply talk about the switch from dev to prod.
Well what is my issue with production mode? It comes down to one thing, it works differently; to differently. For example for community modules you need to add a line in the composer.json for the system to load the module. If you fail to do so you won't detect it until production.
On bigger projects where you have a staging, a preproduction, and production you will detect it very early in the process. But on small projects(I mean very small) you might not detect it until it's to late.
And that's not all, the DI will also sometimes fail on production mode. I don't remember what was the error in one of the community modules we had downloaded but something prevented the generation of the static files.
These are just a few example, there is the way javascript and css are built differently(say hello to js translations).
Basically there is plenty of steps that only needs to be executed on production mode. In Symfony on the other hand all modes works the same way. Test mode, prod mode, dev mode, it's simply different config files loaded. But the same steps needs to be executed whatever the mode.
There is a few other points as well but these covers the majority of frustrations.
It's still Magento, it's still EAV
When magento was first made nosql solutions were scarce; therefore it was the logical solution to go for EAV structure for the product catalog(well half logical).
I will not discuss the advantages of EAV vs NOSql(they are a few). But the main issue with EAV is performance. I think it today's context having a mongodb for the catalog storage is a much more logical solution. When you see the complexity EAV brings in Magento...
Last point about this is the introduction of staging. Which increases number of data stored well not exponentially thanks god, but very quickly. This is something a flat structure can handle, and mangodb with ease. While a EAV structure will simply fail after a while.
There is one last point for a EAV structure; cost. It's harder to develop and so but for small & very small commerces it remains cheaper to install. According to the git history the next version of Akeneo will stop using a EAV storage. Instead, they seem to switch to a sql with json storage(something last version of MYSQL supports) with an elasticsearch as the search engine. This is a strange choice but I will wait for the next version of Akeneo to comment on it. I have my ideas why they chose it over a full mongodb storage.
Coding in Magento2
There are some critics on how much developments are longer in Magento2.
My first comment about this is true enough, but it's not the entire truth. The issue was that it was easy to do something in Magento1, you would do it fast, but that doesn't mean you would do it the proper way.
In Magento2 you can still do crappy code; but it's hard to do, once you go for it just do it the proper way from the start.
So when people say it's much longer to code in Magento2, no it's just a bit longer then coding properly in Magento1.
That doesn't meant I approve of all the complexity Magento2 brings. The database for example has to many layers.
Conclusion
I know my article is a lot about negative points; true enough. That does not mean Magento is a bad solution, not at the least.
The real struggle is to know where to draw a line of what you can actually do with Magento. This is a struggle whatever you try to do, the question should I use a CMS is an eternal one(http://www.commitstrip.com/fr/2015/04/03/cms-or-custom/)
The issue on this line will be price, a CMS can be cheaper to maintain because you can simply update as long as it's maintained(no worries with Magento there). But if you need a lot of community modules there will be that community module not support. This is actually even worse if you need to code alot of custom modules, as updating them for the new version might require lot's of devs.
The main choice remains the price, even with moderate custom developments making a website using Magento instead of a custom website will cost much less.
Before we enter a endless struggle which has no real answer.
I believe magento to be one of the best CMS out there. It offers lot's of customization a clean way to do it.