Skip to content

Instantly share code, notes, and snippets.

@dungsaga
Created December 11, 2025 10:39
Show Gist options
  • Select an option

  • Save dungsaga/0fdf34501d30fb0ee82c5036be9849bc to your computer and use it in GitHub Desktop.

Select an option

Save dungsaga/0fdf34501d30fb0ee82c5036be9849bc to your computer and use it in GitHub Desktop.
Magento criticisms

Magento is infamous for being over-engineered and hard to customized for developers.

Here are some complains:

Magento 2 is complete trash, stay away at all costs

https://www.reddit.com/r/Magento/comments/egcb2g/magento_2_is_complete_trash_stay_away_at_all_costs/

Magento 2 was their chance to show they learned lessons from how Magento 1 development went. They proved instead that they learned all the wrong things, and doubled down on many of the architectural mistakes. I've moved on, and most of my clients have as well - not even at my prodding, simply from watching how Magento operates. The big dogs are going into SaaS ecommerce/custom, with the little ones taking advantage of the growing Shopify Pro ecosystem. The ones in the middle, I just feel sorry for, if they can't fit well into either of the previous camps and are stuck on this monstrosity while we look for proper alternatives.

I hate magento I hate magento "devs" I hate people who always cuts down HA vs short times performance

https://devrant.com/rants/244003/i-hate-magento-i-hate-magento-devs-i-hate-people-who-always-cuts-down-ha-vs-shor

Been developing with magento for about 6 years now or something...

Magento 1 is crap. Magento 2 is nice.

Nevertheless, always pick the right tool for the job.

If your client is a hobbyist that sells from his basement, magento is overkill. If your client is mid-range, and has the need to attach it's ecommerce logic with third parties, magento is a good fit. If your client is very B2B or very large, you might want to consider custom made software.

Nevertheless, each situation requires a unique approach. Magento in that opinion is like an almost fitting jacket. It does 80% very well, but it's that last 20% that well make you cry and weep.

I Hate Magento - The Cat's Whisker

https://catswhisker.xyz/log/2021/8/22/magento_sucks/

it has continually impressed me: I’ve never before used software that provides such a poor experience to administrators, developers, and users alike.

As far as I can tell, the only sane way to have a performant and maintainable Magento website would be to write a complete frontend using a modern framework and communicate with Magento solely through its REST API. In fact the general rule of successful Magento deployment seems to be to use as little of Magento as possible.

Where I’d expect a catalog management interface with an emphasis on importing and exporting product data, Magento provides a painfully slow product browser and editor for torturing copywriters and an anemic and convoluted product export tool unsuitable for any real reporting or feed generation. My solution lately has been to write programs which get data from the REST API to update reports in Google Sheets rather than trying to use or extend the Admin panel. (Magento’s product import tool is fine.)

Where I’d expect a “feature-rich eCommerce platform solution that offers merchants complete flexibility and control over the functionality of their online channel” to have an ergonomic and well-documented extension interfaces, Magento provides an over-engineered and convoluted plugin system wired together with XML files (with little reference documentation) and PHP code generated from classes you provide which interact with the core system’s classes (which have no reference documentation).

I think most of Magento’s issues — including its poor performance, poor security record, and high cost to customize and maintain — stem from two core defects: a lack of documentation and a fundamentally flawed software architecture.

Worse, the unnecessary complexity makes it more difficult both to understand code execution paths and to make changes to the code base: a recipe for security vulnerabilities.

What’s Wrong with Magento 2 an Adobe Commerce architecture?

https://yegorshytikov.medium.com/whats-wrong-with-magento-2-an-adobe-commerce-architecture-b6fc90e47546

I thought it was obvious that Magento 2 written in a modern like OOP style and uses Java-like approaches is unmaintainable and simply a mess. Magento 2 abuses all possible OOP principles and makes software complex and unmaintainable. Merchants have chosen Magento 2 to solve a few of your basic eCommerce problems. Now they are having 100,500 complex software problems.

“Magento 2 is supposed to make us feel like we’ve built a store on a solid, modern foundation, but from the very beginning it has left us feeling like we’ve built our store on a house of cards.

I feel like Magento 2 is so complex now that a point release can have as many regressions as a major upgrade on other platforms. Any single change can have a butterfly effect that ends up breaking something else in a totally unexpected way. That is the nature of this platform.”

Feedback from the community.

Magento: why complex doesn’t mean good

https://medium.com/@salvoadriano/magento-why-complex-doesn-t-mean-good-1f15992202de

Lack of unit testing

Magento doesn’t support unit testing out of the box. This could have been acceptable 5 or 10 years ago but it isn’t anymore. I found some libraries that add support for unit testing and I will try them anytime soon, but I guess it’s no picnic.

It’s built the old way

  • No Composer, it actually doesn’t have a package manager at all.
  • It has badly written Javascript using Prototype.js. It will eventually have a modern (sarcasm) Javascript framework such as JQuery in the new 2.0 version that it’s still in development from ages now.
  • It doesn’t have a modern templating engine like Twig, it uses PHTML instead.

It’s slow

Magento has several cache layers that can hide this issue, but caching is not meant to be a solution for not optimized code. Again, magento is extremely complex (remember the eight millions line of code?) so to serve a web page in a normal server it can take up to several seconds. This is due to the parsing of the configuration files and to the querying of the thatabase containing huge EAV tables, among the other things.

EAV means Entity-Attribute-Value, it is a way to store dinamically structured data in a database (e.i. the structure can change at runtime). In other words:

EAV gives you enough rope to hang yourself, and in this industry things should be designed to the lowest level of complexity, because the guy replacing you on the project will likely be an idiot.

So make sure that you keep your cache in a good shape and that you throw a good amount of money on your hosting platform, or your store will be slow.

Community code is low quality code

I found myself refactoring a lot of code from third-party extensions. Often times there are antipatterns, lack of conventions, bad practices, even bad code formatting.

The Curse of Magento 2: A Nightmare for Developers and Merchants

https://www.reddit.com/r/college/comments/1ci9f94/the_curse_of_magento_2_a_nightmare_for_developers/

Complexity Overkill

One of the key selling points of Magento 2 is its flexibility and extensibility. However, this flexibility comes at a high price: complexity. Magento 2 is often criticized for being overly complex, with a steep learning curve that even experienced developers struggle to navigate. The architecture is intricate, with a multitude of components, modules, and dependencies that can turn simple tasks into monumental challenges. For merchants and developers alike, the time and effort required to understand and customize Magento 2 can be overwhelming.

Resource-Intensive and Slow

Magento 2's complexity also contributes to its notorious resource intensiveness. It requires substantial server resources to run efficiently, which translates into higher hosting costs and increased maintenance efforts. This makes it less accessible to smaller businesses and startups with limited budgets. Additionally, Magento 2's performance has been criticized for its sluggishness, leading to slow page load times and an overall subpar user experience. In the eCommerce world, where speed is critical, this is a major drawback.

Customization Nightmares

While Magento 2's flexibility is a selling point, it can quickly become a curse when it comes to customization. Custom modules and extensions often conflict with one another, leading to a tangled mess of code that's difficult to maintain and troubleshoot. This complexity can result in compatibility issues, bugs, and unexpected downtime, impacting both user experience and sales. Developers often find themselves spending excessive amounts of time resolving conflicts and debugging, diverting attention from core business needs.

High Cost of Ownership

Magento 2 is known for its high cost of ownership. Beyond the resource-intensive nature of the platform, businesses must invest in developers with specialized Magento expertise, which can be costly. Ongoing maintenance, updates, and security patches further contribute to the financial burden. For many small to mid-sized businesses, these costs can become prohibitive, leading them to question whether Magento 2 is the right choice for their eCommerce needs.

Security Concerns

As with any complex platform, security is a major concern. Magento 2 has faced its share of vulnerabilities and security breaches, requiring constant vigilance and timely patching. The platform's complex architecture can make it challenging to ensure security at all levels, leaving businesses at risk of data breaches and other cyber threats. This ongoing concern adds to the stress and anxiety of managing an eCommerce site on Magento 2.

A Better Way?

While Magento 2 has its merits, it's clear that the platform's complexity, resource requirements, customization challenges, and high cost of ownership can make it feel like a curse for many. Businesses seeking a simpler, more efficient, and cost-effective eCommerce solution may find that other platforms, such as Shopify or WooCommerce, offer a better balance of features and ease of use.

Conclusion:

Long story short, as a Developer, it is a curse. You should never use!

Magento 2 is often idea rich but vs the time spent function poor

magento/magento2#9554

This is constructive criticism of my experience as a Magento 2 developer coming from other ecommerce systems.

I expect a learning curve with any software change, however as a developer of 11 years Magento 2 has been an extremely frustrating experience and I will attempt to articulate why to you. I checked for a feedback forum in the forums but there wasn't one so seeing posts like this: #5906 I figured it could go here.

As a small business owner of a web development company my clients are very concerned with time spent to result obtained why I've stayed successful as a business owner for over 8 years is because I can deliver on that to them. They feel they get good value and good quality for the time I spent. CS Cart for example was messy but very easy to modify with any code I desired and it worked for over 6 years for one of my clients. Magento 2 comes extremely well recommended though so he pushed to go with that. And so we are but I want to give constructive feedback to you if I will be married to this software for years to come.

The biggest concern I have is it is very hard to be productive with Magento 2's framework. It is layered more densely than an onion and every layer has some ideology behind why it was designed that way. The problem is, it leads to architecture that is ideologically rich and functionally poor. It defies the oldest rule of programming which is KISS (Keep It Simple Stupid). Simplicity is beauty and harder to achieve, brevity is harder to achieve than this rant for example and would take me 10x longer to write and rewrite still convey what I wish to say.

When there is more ideology than functional purpose to code it obscures the function and purpose of the code to the point it becomes hard to work on it or achieve anything without hours of looking up examples. Object Oriented Programming in general has been on this trend for quite some time, becoming more and more about grand ideas and less and less about actual algorithms, procedures, or code that does the actual work. This shifts the focus from what matters to what I personally feel is things developers tell each other to feel good about themselves or come up with ideas to fulfill some personal need rather than solve a problem simply and beautifully. Complexity is expected but to be combated not fully embraced and then poorly documented in a way that mostly spouts ideology rather than useful information.

This iteration of programming is idea rich and function poor when I can achieve the same results in other frameworks and ecommerce systems in 1/6th the time even accounting for Magento 2 being new to me there's not something just a bit wrong but an entire foundational belief system that created it. Even reading guides on how to achieve certain tasks people will often comment at the end "wow that was a lot of work and really complicated but if you copy it exactly it should work for you". Like.. that isn't even close to the goal a framework should wish to achieve.

Magento 2 has a very good result as an end store in terms of features, it isn't functionally poor in it's delivery it is functionally poor in it's development because you are jumping through hoops constantly to appease the architects I'm half convinced wish me to either suffer or perhaps this was all designed to keep small devs out of the business entirely by making it extremely hard to break into. And really neither of those are feelings I should harbor when using a top end framework. I should marvel at the simplicity and how easy it is to get so much done so quickly not feel like I need to hire 5 more developers to do the same work I used to do as one person.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment