[damienwebdev]

So, I happen to know this niche extremely well!

I'm one of the maintainers of MageOS (a fork of Magento) as well as a maintainer of Daffodil (a monolithic Angular PWA framework - not Microfrontends yet).

APIS are definitely the way to go but, while that's a great next step, what we're really facing is a standards issues.

Some have tried.

Schema.org as a standard is overly complex and each platform has their own API definition.

Microfrontends can be great as well, but ecommerce has a particularly special problem of requiring extremely performant SSR, so that's always a critical and complex piece to get correct.

However, this article is clearly an ad.

[calvinmorrison]

Former M1/M2 Dev here. The benefits of headless to me are that it's far easier to find javascript developers than to ruin someone with learning the Magento architecture.

I haven't seen Magento - under Ebay, under Adobe, under anyone address what I think is the biggest issue facing them - total cost of ownership in comparison to the competition.

Is mageOS mostly just a maintainence mode, keep this alive till everyone can switch off (like the M1 forks that exist) or do you actually envision trying to solve some of the challenges magento is facing as a community and platform?

[damienwebdev]

MageOS is not a maintenance mode, unfortunately we don't do a good job expressing that.

The goal is to migrate management of the codebase out of Adobe's hands back into the community's. Community PRs, triage, etc.

We're currently working on getting the entire CI pipeline setup in Github Actions (if you're interested in contributing, we could really use friendly faces, it's quite an undertaking). Once we're past that, we have goals that are in progress:

DevX:

1. Correct the dep graph of MageOS to be a legitimate DAG and then use nx/bazel/make, etc to compute the build graph. 2. Create codespaces/gitpods/devcontainers for easier day 1 devs. 3. Rip GraphQl out into a separate package space. 4. Create smaller more use-case specific metapackages so that you're not forced into all of Magento or nothing. 5. Maintain backwards compatibility with existing Magento packages.

UX: 1. Significantly improve overall performance.

MerchX: 1. Improve Merch documentation and make Merch docs easier to consume.

Generally to your question, we're not interested in maintenance, we're interested in taking on the burden of being a better development effort alongside a better merchant experience.

That said, this is not a sales pitch. The problem is hard, but we'd like to prove that we're harder.

[neon_electro]

Thank you for calling them "JavaScript developers" instead of "front-end developers"; it's accurate.