For the first time with Magento (then still "edinichkoy"), I encountered years ago, 6 months ago. Since then, so with her and work, with more or less density. Initially, the post wanted to be called "Quo vadis, Magento?" and until now this question remains relevant (since I even had a desire to use such a name). Therefore, the post is called as it is called.

Under the cut, I tried to formulate my own (that is to say, subjective) vision of the prospects of this platform - full of grunts and despondency. Without detailed calculations. Without detailed reflections. Without evidence. And most importantly -

yes, the main thing - without hope.

Le roi

In my practice, Magento, perhaps, is the most complex web application I have come across (once again I focus on the subjectivity of my calculations!). Colleague Jonathan Edwards once put it "programming is a hopelessly lost fight against the insurmountable complexity of the code and the treachery of the requirements ). So, Magento in this hopeless struggle advanced further than all the other web-applications I have seen.

The basis of Magento was originally laid down the principles of adaptability and extensibility: EAV, modules, rewrites, events - these are the mechanisms that allowed Magento to attract many users and, most importantly, developers and take a dominant place in e-commerce. The main "chips" Magento were and remain not only the wealth of functionality "out of the box", but also an impressive number of third-party modules (paid and free), allowing you to tune the store "by itself".

Magento became the center of attraction on the one hand of many developers - you could either get a good advertisement , make a small but necessary free module for everyone, or get good money by making a commercial module for specific customer needs not covered by basic functionality (or covered only by the Enterprise version ). Now Magento Connect has at least 966 pages of modules for Magento 1, 10 units per page are almost 10,000 extensions.

On the other hand, Magento also became a center of attraction for users - they immediately received not only a workable store, but they could also choose an attractive topic for it, expand functionality with the help of ready-made modules. Or order the creation of "their" modules. Or "his" theme. Extensibility has been one of Magento’s engaging marketing tricks. Of course, in reality, the addition / change of functionality was not an entirely trivial task , but nevertheless, such an opportunity was initially added to the platform when it was created and successfully used in evaluative comparison with competitors. As a result, the number of stores on Magento has reached, by some estimates of 2015, almost a quarter of a million.

This two-way attraction created a peculiar ecosystem in which various solutions in the field of e-commerce based on the Magento platform were created, tested, taken root or thrown out. In the first version there was no full-fledged testing, but its absence was compensated by the number of installations - if you use common functionality and do not build exotic configurations, then the probability of encountering errors in the store was quite low. A certain number of existing large stores also indicated quite good platform capabilities - at least from the point of view of medium and small businesses.

In general, more recently Magento was the undisputed leader in the e-commerce market.

... est mort

So why do I personally look at the future of Magento with pessimism? Probably for the same reason that they looked at the future with pessimism in the engine room of the Titanic. Perhaps even Captain Edward John Smith, to whom all information flowed, did not understand at first all the tragedy of the situation, not to mention the passengers, who were convinced by the analogues of the marketing services of the time that the Titanic was unsinkable. But in the engine room they saw bursting rivets and gaps between the steel sheets, which icy seawater burst into the air, bubbling and foaming, and the unsuccessful operation of the pumps. In the engine room they didn’t know exactly how long the Titanic would be able to hold out on the surface, but they knew for sure that he wouldn’t reach America.

Undoubtedly, Magento 2 is a development of the previous version - modularity has improved, compatibility with composer has been achieved, more modern solutions are used both on the front and on the server side, the code is publicly available and we are testing , the performance has been improved. At first glance, quite a wonderful perspective.

But what, nevertheless, darkens the picture?

Volume

Magento 2 has 1,357,121 lines of PHP code and 2,449,066 lines of total (WordPress - 423,759 ; WooCommerce - 131,549 ; osCommerce - 208,928 ; Drupal - 704,269 ).

$ cloc vendor/magento/core/ 12915 text files. 12797 unique files. Complex regular subexpression recursion limit (32766) exceeded at /usr/bin/cloc line 7272. 1381 files ignored. github.com/AlDanial/cloc v 1.68 T=49.43 s (233.4 files/s, 49068.2 lines/s) ------------------------------------------------------------------------------- Language files blank comment code ------------------------------------------------------------------------------- XML 1682 2790 29878 697574 PHP 9203 129137 627973 690540 JavaScript 322 27167 22370 114274 CSS 167 5508 5038 49747 SASS 65 2265 1847 10702 HTML 76 597 423 5978 ActionScript 3 92 231 482 XSD 2 5 52 219 JSON 2 0 0 122 MXML 2 0 52 115 SQL 4 49 58 102 Bourne Shell 2 17 57 57 XSLT 1 15 2 53 DTD 1 3 0 16 DOS Batch 3 5 0 15 PowerShell 1 5 0 10 Ruby 1 1 1 8 INI 1 0 0 1 ------------------------------------------------------------------------------- SUM: 11538 167656 687982 1570015 ------------------------------------------------------------------------------- 

 $ cloc vendor/magento/ 27403 text files. 26893 unique files. 1806 files ignored. github.com/AlDanial/cloc v 1.68 T=102.50 s (250.2 files/s, 36028.6 lines/s) ------------------------------------------------------------------------------- Language files blank comment code ------------------------------------------------------------------------------- PHP 19356 240777 820913 1357121 XML 3754 1244 22948 714019 JavaScript 1163 49970 61526 234396 LESS 480 12370 25596 58090 HTML 367 1128 3373 30976 CSS 102 1298 559 27274 JSON 149 6 0 10963 Markdown 157 746 0 7895 XSD 85 494 591 7387 XSLT 9 43 93 408 Bourne Shell 7 67 50 227 YAML 4 16 0 103 SQL 4 49 58 102 XHTML 5 0 35 42 DOS Batch 4 13 20 31 Puppet 1 5 2 18 PowerShell 1 5 0 10 INI 1 0 0 4 ------------------------------------------------------------------------------- SUM: 25649 308231 935764 2449066 ------------------------------------------------------------------------------- 

In the very number of lines there is nothing terrible (the same SugarCRM contains 2,149,457 lines) - this is just an indicator of the “inertia” of the application, an analogue of mass in physics, the reason why the ship cannot change its course dramatically. What exactly are the problems?

Data structures

The developers of Magento 2 had a great chance to significantly rework the data structure - it was officially announced that the second version would be incompatible with the first. And the data structures made a significant shift - the tables and fields were renamed / added / deleted so that the database from the first version really could not be used in the second.

But it is clear that the main motivator in the processing was still “as little change as possible”. Otherwise, how can you explain the mismatch of store_id in the database and Store in the admin panel that migrated to the "two" (store_id in the database is the Store View attribute in the admin panel, but group_id in the database is just an attribute for the Store in the admin panel) and this cannot be understood remember)? Or ambiguous dependencies between data in the same store-tables or stock-tables ?

Or such a fundamental (or rhetorical?) Question - why for EAV there are only 8 types of entities (customer, customer_address, catalog_category, catalog_product, order, invoice, creditmemo, shipment) from which only product attributes (catalog_product) are available through the admin panel for EAV? Why are entities like admin, authorization, stock, sales_rule, cms, rating, report, review, ... ignored?

This, by the way, is awesome, especially at first - why produce support for EAV in data structures, if in fact the end user of the Community version can apply it only to one type of data, to products? And yes, it slows down the entire application (at least in developer-mode) and is the reason for the emergence of flat-tables. And yes, in the "two" part of the client's attributes was nevertheless transferred to the customer_entity (28 fields, versus 12 "ones").

Code

Magento 2 has significantly reworked the architecture - and this is a clear progress. I can only welcome the appearance of the DI and the layer of the repository classes, the integration of the API with Swagger, and the expansion of the CLI command set with my own commands. But ... try to programmatically store (Store View in terms of admin), guided by the best practices from Magento 2 - it will not work . This is despite the fact that the repo class for \ Magento \ Store \ Model \ Store exists , but without the save () method, and the standard save method for the "edinichka" inherited from \ Magento \ Framework \ Model \ AbstractModel is declared @ deprecated

And try to find the implementation of the \ Magento \ Sales \ Api \ OrderStatusHistoryRepositoryInterface interface . How would be "\ Magento \ Sales \ Api \ Data \ OrderStatusHistory \ Repository", according to di.xml . Well, try to find the class "\ Magento \ Sales \ Api \ Data \ OrderStatusHistory \ Repository". Maybe this interface is not used anywhere? No, it is used . Maybe autogenerate? No, Factory, Proxy and Interceptors are generated , and here we have a repository.

Wander through the code - there are very redesigned modules (customer, for example), but there is a wrapped code from the "one". I understand that the “two” was made on the basis of the “one”, that a “political” decision was made to use as much of the existing code as possible in order to be released to some significant date (for example, selling by ebay or ebay, attracting regular investments, etc.). Or " to reduce development costs ." The trouble is not that. If only this, then the situation could be corrected by systematic and methodical processing of the code. The trouble is that now in Magento they rule "effective" / "crisis" managers, not techies (guys, no offense - I don't know your names, I judge only by the results).

Releases

Well, what else can I think when 2 weeks after 2.1.4 comes out 2.1.5 the only purpose of which is:

This release updates the copyright date in every file. It does not contain any functional changes or security improvements. It is intended to simplify future updates and developer workflows.

Release! A whole release of non-essential changes in terms of techie !!! And now what, to explain to the owners of the stores that working for them 2.1.4 from the functional point of view is exactly the same as 2.1.5, except perhaps not the last one?

A release plan for mid-February:

For now 2.1.5 will be copyright, 2.1.6 security and 2.1.7 will have bugfixing.

Can we split the bugfixes into two groups - for the front and for the server side? And for each of your release will do? And if, on the next day after the release of 2.1.6, a hole in security is discovered, then we will "heal" it in 2.1.8 or 2.1.9?

bugfixes

And the saddest thing, IMHO, is that version 2.1.5 did not include this pull request. Here is the error code:

  public function getStockId() { return $this->getData(self::KEY_WEBSITE_ID); } 

here is the corrected:

  public function getStockId() { return $this->getData(self::KEY_STOCK_ID); } 

He was posted by a colleague Félix Delval on September 29, 2016. Before the release of version 2.1.2 (October 12, 2016), version 2.1.3 (December 14, 2016), version 2.1.4 (February 7, 2017) and to the notorious version 2.1.5 (February 21, 2017). Judging by the release plan, the error will be fixed in 2.1.7 - in 3-4 months.

But this is an obvious mistake, understandable even to novice programmers. How much time she has devoured by all 10 (!!!) participants of the discussion of this bug and has not yet been fixed!

Oh, no, I'm lying - fixed in developer-branch. But in releases - and continues to be.

I don’t ask the question “how many such fixed bugs are there in the developer branch and not in the release ones”, simply because I’m afraid to hear the answer.

Inertia

Magento has a good history, an impressive community, a decent “piece” in the e-commerce cake, but ... at the same time, I see a loss of controllability in the project. Magento 2 has ceased to respond to changes in a timely manner. She has become too big. Like Microsoft at one time.

Perhaps some laws come into force, according to which not only programming, but also the creation of complex systems in general - "a desperate losing battle". The structure comes close to some unknown complexity border, when each next step is like all previous steps taken together, and for building up functionality it is easier to create something new - another structure that implements similar functionality on different principles and at a lower level of complexity and allows to increase this functionality until it in turn comes close to the same border. In physics, there is a similar boundary - the speed of light, why should it not be in programming?

So, the inertia in Magento 2 due to its complexity has become so large that it becomes harder and harder to manage its development. The above problems in data structures, code, bugfixes, releases are consequences of approaching the "upper limit of complexity".

Disclaimer

Hey, that's my subjective opinion. I am not a lawyer and not an effective manager, I am a developer, a techie. I see a picture from my perspective and see it like this.

Vive le Roi?

As the saying goes, "holy place is never empty." And if not Magento, then - who?

Judging by this data - WooCommerce? Or, for the time being, who did not shoot OroCommerce - from the authors of the "one"? Or maybe even a little-known player, like Sylius ? Or will the new “king” not be in PHP at all? Where will the end users of e-commerce platforms go and who will become the new crystallization center?

I have no answer to all these questions.