Holy Cow! Who knew that to develop a simple AEM project you needed 7 sub-modules!?!? I sure didn’t and frankly, nor do I think anyone does. Setting up the AEM project archetype requires first deleting 75% of the junk it creates.
There’s far too much going on in this project to be comprehensible and in my opinion, the whole idea of jamming all of the various components of an AEM project into a single Maven project is a bad practice. Yes, we want to produce a single deliverable, but why should the HTML code, Service integrations and Dispatcher code all be in the same repo? Crazyness!
To be fair the AEM Project Archetype finally has an option to support Node builds, but it’s not even enabled by default.
ClientLibs were a great idea in the time of jQuery and downloading JavaScript libraries manually, but it’s 2019. Can we please just have good documentation on how to integrate front end build processes into AEM and retire ClientLibs?
Seriously. Why?
The AEM Assets Metadata Schema editor is a great idea! But holy cow, the implementation is so bad!
The only explanation I can come up with is that the team which created it had never worked on AEM before they started. It’s so rigid, you can’t even define your own field types! There’s no real concept of extension so if it doesn’t have what you want… too bad.
Theres no reason for a number of things in the AEM ecosystem to exist since there are already better options in the market and they provide no tangible value. Some of the more egregious examples:
Conceptually, the Core Components are great, but they are a nightmare from an extensibility perspective. Here’s a clue: NO ONE WANTS TO ADAPT THEIR HTML TO YOUR CMS!!! Most projects are designed by people who have no reason to know or care about how the Core Components structure their HTML so why does making trivial changes to the Core Components HTML require completely overlaying the HTL for the component?
Then there’s the matter of the Sling Models backing the Core Components. I know that architecturally hiding the implementation details makes things easier for Adobe because they’re not responsible for changes implementors make, but wow it makes simple changes hard.
Touch UI does provide mobile support which is nice… for the 5 people who’ve ever authored a page on their phones, but it gives your index finger a workout. Most interactions which used to take 1-2 clicks now take at least 4-5. I was under the impression that the idea of mobile first was to create a great experience on mobile, not drag desktop down to a mediocre experience.
At least Adobe uses a relatively consistent UI framework, but holy cow, even within AEM parts of the application are implemented completely inconsistently. The UI and implementation details of Forms, Sites and Communities are radically different. These inconsistencies result in significant duplication and even security issues.
It gets even worse when you integrate the rest of the Adobe Experience Cloud. It’s painfully obvious that most people at Adobe only deal with one product and the products aren’t set up to integrate together without additional work.
AEM is full of old code and semi supported features which have long sense outlived their utility, but still hang on like barnacles on a speedboat. Im sure many of them have some customer somewhere who still uses the, but is there a reason to not make the add one instead of part of the base product?
Would you ever miss CRX Explorer or the legacy reports or the foundation components? Probably not! Just cut the fat!
Configurations in AEM are a hot mess. Different parts of the application use different configuration methods and most are poorly implemented. The sad thing is that there is a flexible, well implemented option already, Sling Context Aware Configurations (CA Configs).
Instead of the current mess of Cloud Configurations, AEM Configs and whatever mess Content Fragments use, if AEM converted entirely to Sling CA Configs would make configurations more flexible, cleaner and easier to use and understand.
Support sites don’t usually win design awards but Daycare has to be one of the most dated and poorly designed applications in use at Adobe. Digging a little deeper, why is AEM support provided differently than the rest of the Experience Cloud?
For a company that talks about experience driven business, Adobe’s customer experience at least as it relates to Daycare and support is very lacking.
Yes, AEM is based on OSGI which has the concept of modularization, but AEM itself has no well-defined system for creating plugins or modules. Adobe has not produced good documentation on how to extend the tool template third-party integrations so developers do it themselves and often run into upgrade issues.