
Magento 2.1 released - alternize
https://magento.com/blog/magento-news/magento-enterprise-edition-21-unleashes-power-marketers-and-merchandisers
======
throwanem
From the release notes [1]:

> Upgrading the Magento system software no longer results in the loss of data.

Well, that's good. You're still working with Magento, though, so... (I've
built plugins for it. Don't. No money is worth that.)

[1] devdocs.magento.com/guides/v2.1/release-notes/ReleaseNotes2.1.0CE.html

~~~
sherjilozair
What's a better solution than Magento?

~~~
nachtigall
WooCommerce. I've used it for a (small) webshop for two years now, many
customization, no real problems at all so far.

~~~
kyriakos
I agree woocomerce is a much cleaner solution even though it's based on
WordPress.

~~~
nachtigall
> even though it's based on WordPress

I consider this to be an advantage actually. At least if you do not only want
a standalone shop, but an integrative website with a news/blog area, static
pages like faq to draw in customers.

------
DelaneyM
I spent two years trying to innovate on Magento, because it was the platform
before I got there and rebasing seemed like overkill, and it almost broke me
as an engineer.

My experience (and I'm not even going to complain about the XML!):

The code base is horrifying; we would often trace bugs through the stack,
realize they were in magento core files, then face really difficult decisions
about furthering our fork.

The code is deeply integrated from UI to DB. If you change it, upgrades won't
apply cleanly. But you need to change it (or the data structures/applications
therein) to implement any non-core features.

Speaking of upgrades, they are mostly done by opaque and undocumented upgrade
scripts, and tend to break plugins or addons...

Which are generally poorly written and untested, even highly rated ones in
their web store, but their quality isn't even the biggest problem. The absence
of a sane extensibility model means they virtually can't coexist consistently,
and when they do they break on (or need rigorous requesting due to)
upgrades...

The EAV table layout wouldn't be totally horrible if it weren't so badly
implementated. They put everything, even system data, in EAV tables; not only
did this make it hard to extend, but it put a huge load on the (outdated) ORM.

Performance was an exercise in caching like no system I've seen before,
entirely due to this design choice. The downside of that is that server
restarts under load could cause a full system panic as new web hosts put an
unbearable load on the DB, which could throw off other web hosts when their
ORMs blew up by timing out all their pooled DB threads, which started a
cascade through the rest of the system.

It was possible to deploy a single cache shared by all your Magento servers,
but even stock Magento would pepper that cache with dozens of _serialized_
queries to serve a single page, making the network overhead barely worth it.
Plus, this meant you couldn't clear the cache under load or you'd be down for
an hour, and clearing the cache was a daily necessity because their tagging
system to rebuild the cache incrementally was horribly broken. (Only barely
worked using Redis, which was both recommended by Magento _and_ provided by a
3rd party unmaintained driver and officially unsupported.)

We ended up reimplementing all our e-commerce properties on a custom node
platform by assembling high-quality atomic tools for the important bits. The
technical debt of the transition was paid off in 3-6 months on our feature
schedule and has paid dividends since, and we easily handle double the load on
~10% the infrastructure spend.

~~~
andy_ppp
Worth noting that Magento 2 is rewrite that actually uses some proper
engineering practices.

No idea how good it is but version 1 was horrifying.

The fact their github has 1274 open issues and 179 open pull request at the
time of writing suggest maybe nothing has changed:
[https://github.com/magento/magento2](https://github.com/magento/magento2)

~~~
billmalarky
But none of that matters because Magento 2 still can't serve a dynamic request
in less than a second in even the most optimal conditions.

[https://blog.amasty.com/magento-1-vs-
magento-2-performance-c...](https://blog.amasty.com/magento-1-vs-
magento-2-performance-comparison-speed-test-results/)

The Magento framework builds static sites with a (slow) dynamic CMS system.
It's garbage.

~~~
DelaneyM
We got it down to an average ~400ms under load with aggressive full page
caching (including our own hand-rolled component caching) and edge caching of
all static assets (freeing up the servers to be optimized for dynamic
content).

This should not be considered an endorsement; getting sub-second pages was a
downright herculean engineering effort requiring system-level optimizations
beyond what should ever be required of a pre-packaged system.

~~~
billmalarky
I've spent enough time in highly customized Magento in my day to both be
impressed, and deeply concerned for your well-being after such a task.

------
wysewun
I'm migrating to Magento 2 from a custom built solution in Laravel. It is very
complex, but there are some improvements from Magento 1, and it's been good
for the most part.

There are other alternatives we looked at, such as Spree (ruby) and other php
based carts, but Magento 2 has so many extensions available from third party
and the developers are actively listening to the community. The Chief
Architect, Alan Kent is available to communicate with and has pushed changes
that the community really wanted (i.e. moving to SASS from LESS).

It's been a steep learning curve, but there is also a lot of flexibility in
modifying the code to suite your needs (without needing to edit the core).

------
kyriakos
Magento was one of the biggest pains of my career.

I am obviously exaggerating but Magento might have an xml file to configure
another xml file.

~~~
DelaneyM
It does! (Or it used to.) The global configs defined the cache-specific
configs.

 _edit_ : Which defined the page-specific caching configs. It's XML all the
way down.

~~~
kyriakos
I said it as a joke but.. turns out its true. I am still not surprised,
Magento cannot surprise me anymore.

------
kyriakos
The only other large-scale PHP based system I've seen that has worse
architecture/coding standards than Magento is Moodle.

~~~
benmarks
Are you referring to Magento 1 or Magento 2?

------
mnkmnk
Why are all the popular ecommerce frameworks written in PHP? Magento,
prestashop, woocommerce etc

~~~
georgestephanis
Of websites using a discernable server-side programming language, over 80% of
them use PHP --
[https://w3techs.com/technologies/overview/programming_langua...](https://w3techs.com/technologies/overview/programming_language/all)
\-- The four biggest content-management systems on the web are all PHP --
[https://w3techs.com/technologies/overview/content_management...](https://w3techs.com/technologies/overview/content_management/all)

------
benmarks
tl;dr: I was compelled to write this because I saw a lot of complaints which
seem to come from the end of the Magento 1 era. Many of these complaints are
reduced when considering the context, and they are all handled quite nicely in
the Magento 2 era.

(Full disclosure: I'm Magento's chief evangelist, but I was an agency
developer for a Magento shop from 2008-2014, so I'm not totally a shill. Also,
I care that we are listening & getting things right.)

I spend a lot of time interacting with PHP developers around the world. Some
have been / are Magento developers, some are not. By wearing Magento gear at
conferences and usergroups I would hear quite a lot of opinions about Magento,
both negative and positive. Here's the negative.

* No documentation * Can't test it * XML sucks * EAV is the Devil's creation * The view layer is impossible to understand * Inconsistent implementation in core code * Not true open source * It's too complicated * It's too slow * etc.

Fact is, there's always more to the story. Take documentation: yes, it's
tragic that there never was official developer documentation for M1, but it
was an outcome of Magento's explosive origins leading to the company being
totally constrained. (We did eventually produce some fantastic user docs
though.) Magento 2 solves this by having several tech writers on staff, as
well as a doc site to which the community can contribute via pull request.

In the case of testability, well, Magento 1 was born in 2007. Ideally, yes, it
would have been built with test coverage, but that wasn't standard practice
for PHP back then. (How many of you were writing tests for your PHP apps in
2007? Not too many aside from Sebastian Bergmann!) Eventually though some
great tools came around, and there are many examples of fully covered
installations as well as CI/CD implementations. Magento 2 solves this by
covering much of the core with unit, integration, and functional tests.

Regarding XML, Magento 1 (and 2) largely favor configuration over convention,
and the decision was made to use the most structurally descriptive markup
possible. Of course, the implementation of it in M1 was full of Magentoism -
building a DOM by combining DB data, merging multiple XPATHs, and filling out
a bizarre hierarchy for scope. It's not intuitive without either experience or
schema definitions. Magento 2 solves this by splitting up configuration into
functionally-scoped files AND by providing XSD. The XSD help when editing
files by hand in an IDE, and we are seeing the creation of tools to help
developers avoid writing it altogether.

When questions about EAV come up, believe me, I understand. That's a tough
storage pattern to get used to, but the ORM helps quite a lot. The
implementation in M1 is imperfect though, as you do end up with domain objects
which leak their storage pattern. EAV is invaluable for solving the
complicated requirements of facilitating arbitrary entity attributes and
scoping/translation of those values. We looked at removing it for M2, but
could not find a better solution. And if you say "noSQL," sorry, you're wrong.

The view layer is the thing which trips most people up - even developers who
grok Magento right away. Theme fallback and layout XML are the complicating
factors here. Theme fallback/inheritance is not so hard to get, and it is
fantastic at keeping custom themes DRY - especially when multiple sites are
running off of one instance. If only one thing could have been documented from
the beginning, it should have been layout XML. Layout XML - along with the
view model approach which we took with M1, allowed for simplified, DRY
controller actions and ultimately allowed frontend developers to build
interfaces without having to need backend developers. In M2 we have refined
layout XML as well as abstracted the entire rendering framework, allowing
developers to adjust or replace framework details as they see fit.

For inconsistent implementation in core code (which is especially evident in
adminhtml), this was the outcome of a small team producing a lot of code
independently. It's unfortunate, and very confusing for developers new to the
platform. I struggled with this when I was starting out. We've worked to
eliminate this in M2, but there is work remaining to be done. Thankfully we
have Issues and pull requests on GitHub, and at the very least we can evolve
our test suite to help us (and others) to implement functionality in The One
True Way®.

On the subject of GitHub, we are much more of an open source company than we
were in the Magento 1 days. We did allow contributions, but the process for
becoming a contributor was cumbersome, and development effort was only
revealed through updates to an SVN endpoint with no discussion. That is very
different from our approach with Magento 2. Starting with the beta in December
of 2014, we allowed pull requests to the M2 codebase, eventually building in
our contributor agreement into the CI process. Many of our core engineering
team are regularly on GitHub interacting with a bevy of "how do I" requests
along with legitimate issues and pull requests. We have improvements to make
here which will help us to keep up with the volume of discussion, and you
should see these soon.

When I hear that Magento is "too complicated," I have to ask, then why doesn't
something similar take its place? Ultimately the problem of complexity rests
with the domain of commerce, which is always custom and always complex.
Consider just one area of a commerce application - say, price calculation -
and look at the complexity: cost, retail price, adjustments at the catalog
level, adjustments at the customer level, and then add in the multiple
taxation schemes which exist in the world (tax on full price before discount
vs after, tax on shipping, etc.). Complexity is everywhere, and if you want to
make an app which works for most, there will be overhead. Ideally the app
helps the user manage that complexity as best as possible.

When I hear that Magento is too slow, that is always a worthless discussion
without details about traffic, order volume, amount of entity data, update
frequency, etc. M2 is a much better application for performance than M1,
largely because it was developed with a mind to commodity computing and
reverse proxy (which were nascent in 2007). That allows us to build core
architecture for performance as well as enterprise architecture for
scalability. That said, performance for M2 is not a finished story; I imagine
that we will continue to improve on it as time goes on.

Okay, if you made it this far, I owe you some coffee or beer or whatever when
we happen to meet. I was compelled to write this because I saw a lot of
complaints which seem to come from the end of the Magento 1 era. Many of these
complaints are reduced when considering the context, and they are all handled
quite nicely in the Magento 2 era. I'm always happy to see or hear feedback.

I can be reached at ben@magento.com.

~~~
crimsonronin
Keen to hear about any discussions you had re postgres and document column
store instead of eav?

~~~
benmarks
Postgres is interesting and, well, super cool, but it wasn't a tenable option
for us. Not sure if it came up, I just know that we couldn't make a business
case for it. But man, Postgres has maybe the best vendor option for document
store IMO!

~~~
crimsonronin
Fair point. Would be a very difficult case to make; not only is the upgrade
path from v1 to v2 difficult already, but you would also have to change your
datastore!....that would be a tough sell. It's a shame really, because the
flexibility you would gain from utilizing a document store for product schema,
while retaining transactional support for all your vital commerce related data
(payments, inventory etc), is exactly what you need. I guess these are the
trade-offs we are often faced with as engineers.

