Why We're Breaking Up with Magento

 

At Third & Grove, we’ve worked with Magento since our inception. We built a Magento 1 eStore for Dwell, one of our first clients, more than six years ago. It lived alongside Dwell.com, which was built on Drupal 7 and shared theming with the main domain.

Magento 1 (M1) was in many ways the original open source PHP store platform. It wasn’t an outstanding CMS, but it never claimed to be one. It did everything that most eStores needed to do out of the box in a time when alternatives were scarce. Due to its practical utility, M1 got away with its limitations as a CMS. It was an almost universally-adopted practice to manage content in a separate platform, and this even led to a somewhat officially-endorsed Magento/Wordpress extension.

The PHP landscape was more of a wild west five years ago. There was no uniformity in PHP apps, Symfony and Composer didn’t yet have universal adoption, and a lot of the early 2000s PHP platforms had incrementally developed their own APIs out of basic PHP code over the last decade. At the time, M1 was impressive. It featured an intelligent XML-based DI architecture, and all you needed was a development team with a budget of five-to-six figures to take the out-of-the-box mold of Magento and make it into something truly custom.

In 2015, we helped Quicken with one of the earliest-ever Magento 2 (M2) builds and one of the largest ever. (You can read the case study here.)  We chose to place the commerce site alongside the Quicken.com site and use Magento’s web services to check out and place orders from the .com platform. We were excited to discover the introduction of a composer, mature CLI tools, and an updated feature baseline in M2. This “headless” estore ended up being one of the highest-revenue eStores driven by M2 in the world, and the first of many that TAG would create.

In the process of doing all these projects with Magento, we’ve gotten to know it quite well— maybe too well. We’ve gotten used to longer development cycles with M2 because basic features like address validation aren’t included in core, and are non-trivial to implement even with community extensions. We’ve gotten used to tacking on hours for performance optimizations that need to be made in core code. We’ve seen how M2 sites with very few customizations can devour PHP memory and lock up databases by hitting join limits. Developers on our team frequently say that M2 sites have a funny way of pushing the limits of their system to the point where their browsers lock up and laptop fans get loud.

What’s Wrong With Magento

At a high level, here are the pain points we’ve found developing for M2:

• It’s a resource hog: The official docs recommend a whopping 756M of memory be allocated for PHP to process each request. One byproduct of this is that it doesn’t handle concurrency well, nor lend itself to horizontal scaling of infrastructure. To put this number in perspective, Drupal 8 recommends 128M for production and Wordpress recommends 40M. The bottom line here is that making M2 scale requires considerable hardware, a varnish cache, and/or a CDN.

• It doesn’t use Symfony, which has been embraced by the PHP community as the de facto framework for dependency injection, routing etc. Instead, it uses a V2 of its legacy systems from M1. This is an odd choice, as it diverges from all of the progress being made elsewhere in the PHP open source community and diminishes Magento’s longer-term accessibility and portability.

• The admin experience is awkward, clunky, and slow. Page elements are configured using XML. Mobile editing is just not a thing. There is very little UI consistency:  In some places, to edit an item in a table, there is an edit/view toggle, whereas in others, you click anywhere in a row. Much of the admin hasn’t been thought through from a UX perspective—there are too many modals, spinners, and slow Ajax requests (which may be an attempt to distract/obscure the slow load times for data from the backend).

• Its CMS capabilities don’t have enough features for the majority of clients, meaning an additional platform (ie. Wordpress, Drupal et. al.) needs to be included in the development scope.

These are the big ones, but there are others.

The bottom line is that times have changed. The e-commerce landscape is entirely different than it was five or ten years ago. Businesses looking to start selling their products online are confronted with a bevy of platform options that never existed before. Shopify Plus, Bigcommerce, and Woocommerce have all captured big shares of the market with slick UIs and impressive out-of-the-box feature sets. They promise smaller development cycles, continually updated feature sets, and an impressive community of apps and integrations that expand exponentially each year. Next, to these new kids on the block, Magento 2 is starting to look monolithic, slow and—dare I say it—dated.

Paying five-to-six figures to develop a custom e-commerce software platform and then paying the equivalent annually to host it is no longer necessary nor appealing for companies that don’t have dev teams. One of our clients, the Boston Herald, sells the front pages of their paper as mementos. They had a dated Drupal Commerce application that was plagued with performance issues and they asked us whether they should move it to Magento 2.

We set up their entire eStore on Shopify in less than 25 hours and had them live with a fast and beautiful store within a week.

We recently did a pitch for the sub-brand of a billion-dollar food and beverage company. In what we took as a sign of the times, Shopify Plus was the leading contender—Magento 2 wasn’t even put on the table.

All of this is not to say that there aren’t compelling use cases for M2.  There will always be organizations that need a fully-customizable platform, but they are becoming more niche. In these cases, M2 still shines, since it gives full code control to the development team. That said, these cases are becoming fewer and farther between, and we predict the utility of solutions like M2 will continue to diminish as SaaS providers expand the customizability of their offerings. We still love Magento, but we can’t in good conscience recommend it to our clients as the go-to it once was.