Magento 2 vs Magento 1: A Comparison and Review (Part 1)

Magento is an open-source e-commerce platform written in PHP. The software was originally developed by Varien Inc., but after witnessing huge successes eBay started investing in Magento by buying shares and eventually acquired Varien.

In late 2015, Magento 2.0 was released, almost completely rewritten using modern programming concepts and technologies, we will be discussing the changes in Magento 2.0 and the new features through comparing it to Magento 1.

Extension & Theme Development

Magento 2 uses modern approaches in how it is built and how developers can build extensions and themes for it.

In Magento 1, themes and extensions’ files were distributed in many locations, we had to use a Module Manager “modman” which allows developers to place the files in 1 folder and then let modman create symlinks “shortcuts” to where Magento expects the files to be placed; this allows for better and easier development and also allows for using Code Version Control systems like “git”.

Magento 2 on the other hand uses modern approach; everything is a Composer package, which allows for better organization, updating, and code maintenance, along with automating some of the scripts and commands that need to be run after any updates.

In our current project with B.TECH, we made use of that fact and based all our work (both extensions and theme) on Composer packages, linked to our code repository to allow for instant code deployment (Continuous Deployment) for both staging and production servers.

This is definitely a step forward towards modern development cycle, and one that puts Magento 2 inline with modern PHP frameworks while opening new opportunities by enabling direct use of any of the thousands of packages available using Composer Packagist.

Frontend Development

Magento 1 uses Prototype JavaScript framework because -believe it or not- jQuery was not production-ready when Magento was in vitro, and it kept depending mainly on Prototype and the framework’s add-ons like Scriptaculous.

This made frontend development for Magento 1 a bit hard, although you can easily inject jQuery, sometimes you just need to stick with Prototype and work with it, which is not a pleasant experience usually.

Magento 2, on the other hand, uses modern approaches; it uses jQuery and Knockout, but more importantly, it uses RequireJS, which makes a webpage load only the required libraries instead of loading everything in all pages.

Magento 1 -and 2- has options for merging JS files, which, while reducing the number of HTTP requests, makes loading a huge JS file required with every page load, This was a valid recommendation in the early days;however, things have changed with HTTP 2.

HTTP 1.1 used to open a new connection for every HTTP request, so merging assets was a must; however, this has changed with HTTP 2 which allows for parallel requests on the same connection. This allows faster assets download and invalidates the recommendation for having less requests per page.

RequireJS is a good candidate for making better use of HTTP 2, as it makes use of HTTP 2 parallel requests per connection, while loading only required libraries per page, a win-win situation.

Our Senior Frontend Developer, Ahmed Alfy, wrote a nice introduction to RequireJS; make sure to check it out here.

Admin Dashboard

Magento 1 had a very clear dashboard; you can easily navigate and access everything; it loads fast and extensions can easily add functionalities to it.

Magento 2 revamped the dashboard completely. It is based on AngularJS, along with RequireJS for loading the assets, which, while sounds like a step towards utilizing modern technologies, raises many flags.

Magento 2’s dashboard is criticized due to the following.

  • It can easily fail to load if any of the assets didn’t load for any reason.
  • It is also much slower, due to having to wait for all the assets to load.
  • While using AngularJS sound promising, it is actually a disadvantage as it makes loading a large number of products or orders -or any relatively long list- very slow, and very CPU demanding, which can even cause the whole browser or computer to freeze for seconds or indefinitely sometimes.
  • It is built on AngularJS version 1, although version 2 is now out of beta.
  • While the overall look of the dashboard is modern and the use of icons and large menus should make it more usable and friendly, this is actually not the case as it is harder to navigate through all the menus and the different menu options and submenus.
  • While it is easy for extensions to add menu items, installing many extensions -which is normal- can easily make the dashboard’s menu much harder to use or not really usable at all.

Here is a quick example showing the steps required to reach the “Cache Management” page, which is a frequently visited page.

Magento 1

image02

 

  1. Hover over the “System” link in the horizontal menu.
  2. Click on “Cache Management” in the vertical submenu.

Magento 2

image03

image00

image01

  1. Look for the “System” menu item in the vertical (sidebar menu).FYI you won’t be able to see it as extensions add menu items that push Magento’s menu items downwards.
  2. Scroll down till the icon for “System” menu item is visible.
  3. Click on it.
  4. Inspect the submenu that slides, you won’t find the “Cache Management” link.
  5. Scroll up till you see the link for “Cache Management”.
  6. Click on it.

This is just an example of how the navigation, while might look seemingly better, is actually confusing and hard.

We have touched upon important aspects of the comparison and saw the advancements in Magento 2 in many areas. While it looks like Magento 2 is a real improvement upon Magento 1, in the second part of this blog post we will see comparison of performance and performance-related changes in Magento 2, we will also discuss the stability of Magento 2, so here is a sneak peak.

image04

Introduction to RequireJS (Part 1)

RequireJS defines itself as a file and module loader. The first part is easy to understand; it can be used to load files but what about loading a module? What are modules anyway? Modules are containers encapsulating a piece of code that performs a particular function. A module should also have an interface that lets you access its functionality in a uniform manner.

Why should you care about modules?

Splitting an application into a group of modules is similar to dividing a book into chapters and sections. It makes it easier to read and find the parts you need. Writing modules at the beginning might seem like a lot of work and sometimes developers get confused and ask themselves “Do I really need to do this?” When your application grows, you start to appreciate the time you invested in decoupling your code and writing reusable modules that interact with each other.

What are the benefits of using modules?

Perhaps the greatest benefit of using modules is code reusability. Modules can be imported anywhere in an application to perform its task whenever it is needed without having to worry about duplicating the code. It also becomes easier to export a module to be able to use it in a different project because it is encapsulated. Generally speaking, it facilitates maintenance and readability of the code as well as making it more manageable and easier to test.

How I entered the world of modules loading

From my experience, I used to include all my scripts each in a separate script tag. It doesn’t matter how many scripts I am loading; they will be executed in the same order they are written. There isn’t any abstraction or anything that will add complexity, so why would I need a library to do what I can already do? My build process was taken care of concatenating and uglifying my files so what’s the problem with loading a single nice file?

I wasn’t convinced until I read a couple of discussions and a few questions began to arise in my mind especially when projects I work grew larger as follows:

  • Most of the plugins and the codes I write aren’t required to run on every page. Why would I load something huge like a WYSIWYG editor on a dashboard while the user won’t really need it at the moment?
  • Most of the time, it was difficult to debug something without checking many files to find where exactly is that function defined.

I decided to give RequireJS a try. To be honest, I fell in love with the sense of power it gave me with the conditional loading of the scripts I define. Errors became much easier to debug. I no longer have to care about the loading order of my scripts–things just work out themselves magically. I got rid of the serving-one-fat-file anti-pattern with the rise of HTTP/2. What I do now is ship small files that can be transferred in parallel. Focusing on splitting my code into modules helped me improve the work.

I started to see things from another perspective and, after using it for a while, I really had a hard time imagining developing anything without it. We will explore how to start using RequireJS in the upcoming article. See you soon!