Magento 2, like any significant project, has a set of goals. These were publicly discussed at the recent Magento Imagine 2014 conference. I thought I would summarize them here for those interested and add a bit of a personal perspective on them.

Disclaimer: I work with the Magento team, but this post contains personal opinions and perspectives and does not necessarily reflect those of eBay Inc.  Or in other words, this post is not binding!

The new release of Magento 2 is upgrading the minimum versions for the tech stack. Magento 2 is designed to be a robust and stable platform, and so relatively mature technologies have been selected, not the bleeding edge. It is also a goal not to depend on too many different technologies, but instead endeavor to allow the community to use what technologies they prefer on top of the base platform. But I expect this is an area you just have to expect to not satisfy somebody.

Upgraded technologies include:

• PHP 5.4 is now the minimum version supported.
• jQuery is now being used. It is important to note that upgrading the tech stack is not a claim to be using the most leading edge technologies around.
• HTML 5 and CSS 3.
• RequireJS.
• PSR-0, PSR-1, and PSR-2 PHP coding standards.
• LESS for CSS preprocessing.

Improving performance (making requests faster) and scalability (making it possible to add hardware to support higher loads) is an important goal of Magento 2. Work is in progress on benchmarking, but a lot more work is planned here. Optimizing code that is going to be significantly reworked is not productive, so this area has not been the main focus of work on Magento 2 to date. This will change.

A lot of effort has been invested into streamlining customizations in Magento 2. One of the key benefits of Magento is that merchants can customize the site so extensively to meet their specific needs. Magento is not a one-size-fits-all system with a few templates. Radical new functionality can be included into a site to give a merchant that edge or support their online brand. Examples of work here includes:

• Addressing numerous pain points where adding a new module could not customize desired behavior (you had to hack the underlying code base), or when adding modules to your site would collide causing conflicts. Technology updates here include improved layout file inheritance, a new dependency injection framework, interception support, splitting of modules to make it easier to remove or replace modules, and more. Magento has a large code base, so phase 1 was to introduce the new technologies with phase 2 being to refactor code incrementally to take benefit of the new technologies.
• Restructuring the directory structure so everything specific to a module resides under a single directory for that module.
• Pulling business logic out of template files so it is easier to customize a template file without as much copy and paste.

It turns out many of the technologies to minimize extension conflict pain have a side benefit of having less lines of code required to build the customization. This may result in a higher initial learning curve for Magento 2 compared to Magento 1, but the end result is customization projects should be able to complete faster as there is less code to develop and maintain. Upgrading should also be easier and more reliable with the reduced conflicts and better encapsulation that has been achieved.

Added 5/18: Of course someone picks up on “may result in higher initial learning curve’, dropping the ‘may’! 😉  To expand, a part of reducing extension conflicts is to discourage practices that lead to such problems. Modern software engineering practices are being applied to Magento 2 to help here. There is also a greater emphasis being placed on product documentation to explain the concepts better. The end result is it may be easier to develop in Magento 2, but that is one area where community feedback will be the real measure, and the documentation is by no means complete at this stage so it is too early to tell. I certainly believe the overall story will be significantly better. There should be a much lower number of extension conflicts if people follow the new rules.

One of the cool bits of technology in Magento 2 is the new service layer work. While it is just good software design to have well defined interfaces to modules and so define a relatively small API that other modules can depend on (and the presentation tier of blocks and layouts), I think the cool bit is that with a simple XML configuration file, the PHP API is automatically made available as both a REST service and SOAP endpoint (with automatically generated WSDL file). No extra coding is required. So if you want to provide some new API for another system to access, you can create a new module with that client’s API, declare a short XML file, and you are up and going. I think this could have a big impact on integrations with the Magento backend, opening up a range of interesting new approaches that previously were too costly to embark on.

The fact that the business logic is being moved more and more out of templates and below the service layer is another bonus, making it easier to guarantee the APIs will behave the same as user interactions on the site. (This was a problem at times with Magento 1 where APIs could drift from web behavior.)

The Magento installation process is getting an overhaul. Much of the work to streamline customizations also makes upgrades easier. Automated testing (below) also helps increase the trust in upgrades. This is another area of work that is just starting to pick up. Composer is being investigated as one of the technologies to make it easier to spot supported combinations of modules before you install a new third party extension.

Magento 2 is being developed using modern automated test strategies. The goal is to minimize manual testing and publish the automated test suites so that all developers and merchants can see the test coverage achieved, and hopefully contribute to building even more test cases to ensure a quality project. Classes of tests include:

• Unit testing (testing small fragements of code independently)
• Integration testing (testing groups of code)
• JavaScript tests
• Performance tests (automated so any code committed that introduces a performance hit is identified immediately)
• Static code analysis (such as code style and XML validation)
• Integrity testing
• Functional testing (automated Selenium based testing using the Magento Test Framework (MTF), designed to minimize the effort of user interaction testing)

Conclusion

In some ways, many of the changes in Magento 2 are not that radical – they are just applying better software design principles to the code base. However I believe these platform level changes may have unexpected indirect benefits that are sometimes hard to explain. It is hard to explain to a merchant why dependency injection support (which also happens to simplify automated testing) is so exciting. Let’s be clear – to them, it’s not! What is exciting is the potential to reduce the effort (and hence cost) to develop new sites, customize them, and then upgrade them later. This has huge potential to accelerate the rate of innovation. Merchants may be willing to upgrade more frequently, with a greater sense of confidence. When did you think twice about upgrading apps on your smartphone? This can then give merchants an edge in terms of adopting current trends faster.

This to me is the real potential benefit of Magento 2. It’s acceleration effect. Only time will tell whether my predictions here come to pass!

Do you have a question on Magento 2 technology direction? Leave a comment and it might turn up in as a future blog post!