AEM Franklin vs AEM Sites

As you may have heard from #adobesummit2023, Adobe's "next-gen content management system" is none other than AEM Franklin. I wrote about Franklin in my previous article but something I didn't talk about was the distinction between when to use AEM Franklin vs AEM Sites. In this post, I'll give my opinion on just that.

For starters, let's revisit what AEM Franklin is:

1. A lightweight CMS architecture aiming for maximum content velocity and page performance
2. Uses Google Docs/Sheets or Microsoft Word/Excel for content authoring
3. Uses "blocks" instead of components, and these blocks are purely front-end and loosely related to the AEM Core Components

Let's now walk through what AEM Franklin is not:

1. A replacement for AEM Sites - not now and probably not ever.
2. A better or worse solution than AEM Sites
3. A silver bullet for your content velocity needs
4. The only way to get a 100 Lighthouse score (for page performance)

To that end, I'd like to demystify when you might want to consider AEM Franklin and when might want to go with AEM Sites. Let's get started.

Blocks vs Components

The intention of AEM Franklin's blocks are to be lightweight and very quick to create. This is largely because they are purely frontend: just some JavaScript and CSS. As we know from years of AEM Sites development, AEM Sites components are full-stack. The HTL is rendered server-side and often backed by a Sling model. Component dialog code is server-side too. All that said, you might then start to argue that customers with loads of frontend developers should lean Franklin while full-stack or back-end-leaning developer armies should lean AEM Sites but, with the introduction of Cloud Manager's frontend pipeline and the ability for pure frontend developers to build AEM Sites, uh, sites, I don't think this can be convincingly argued.

Verdict: it's a tossup

Authoring Experience

AEM Sites has long been known for its best-in-class authoring experience. Given that you have a robust component library built and teams who know what they're doing within AEM (more on this in a moment), the authoring experience is truly second to none. Contrast that with AEM Franklin and it's a no-brainer to me. Adobe has been casually arguing that AEM Franklin "meets authors where they are" in that they are letting authors use tools they "know and love" to author site content but who are we kidding here? Do we really enjoy authoring content in Microsoft Word? I sure don't. I'd take the AEM Sites drag and drop and dialog-based configuration over the disjointed, sidekick-based table/block authoring Franklin provides seven days a week and twice on Sunday. To be clear, I like Microsoft Word and Google Docs - for creating documents that I'm eventually going to PDF and attach to an email. Having played around with Franklin authoring for a while now, a couple problems are very evident to me:

1. The authoring experience feels "disconnected" from the actual site. Stated another way, context is lost between what you're seeing in Word/Docs/Sheets/Excel and what is going to actually appear on the page. This means we need to constantly preview our content to see what the effect of our changes is going to be to make sure it had the desired effect. With AEM Sites, you see the fruits of your labor instantly as soon as you save the dialog.
2. The "power" of the AEM Sites authoring experience completely dominates what's available while authoring in Franklin today. This should be obvious but I felt was worth stating. There is so much you can do from an authoring perspective directly in the AEM Sites UI from Targeting mode to direct AEM Assets usage from the side rail (as opposed to copying and pasting URLs or assets themselves out of the DAM as you'd have to do in Franklin), there's really no comparison here.

Verdict: If you need any of the powerful features AEM Sites' authoring experience provides, then lean AEM Sites. If you don't need any of those features and/or your primary objective is getting content out the door as fast as possible, consider Franklin.

Performance

This one might seem like a slam dunk for Franklin given that Franklin is literally built around performant pages as a baseline but when you actually think about it, you'll quickly realize that extremely performant pages is very doable with AEM Sites - it just takes a little more work to get there. Through the use of dispatcher caching and well-written front-end code, you can absolutely get that beautiful 100 Lighthouse score for performance from AEM Sites. The difference is that Franklin is essentially "writing" the HTML documents for you based on the marriage of what's in a github repository and what's been authored and is writing this code to ensure 99-100 scores.

Verdict: Franklin is much easier to squeeze performance out of for sure but you can do the same thing in Sites with a bit of effort. If performance and, particularly, ease of achieving performance is a top priority for you, consider AEM Franklin. If performance is important to you but you're fine to budget some additional time for your developers to accommodate it, then AEM Sites will be perfectly fine.

Integration to Adobe Cloud technologies

Most third-party integrations are going to be custom from either Franklin or Sites so we'll disregard those. However, while Adobe has promised many AEC, ADC and ACC integrations are present or coming to Franklin, we are likely a long ways off on this whereas AEM Sites' ability to easily integrate with other Adobe Cloud tools is a core strength. Set up a Cloud Service Config and you're on your way. Until I actually see something along the lines of enhancements to the Franklin browser extension for Adobe Target or AEM Assets integration, AEM Sites is the clear winner here.

Verdict: If you need to integrate with multiple, other Adobe Cloud tools, lean towards AEM Sites. If not, and just getting content out the door is your primary objective, lean Franklin.

Time to Market

I think there are two aspects of time to market to consider here:

1. Initial time to market or how long it takes you to get your first pages out the door.
2. Net new time to market or how long it takes you to get content out the door once you're already "live".

For the prior, Franklin is the clear winner. Because of the full-stack development time necessary for AEM Sites up front, Franklin is absolutely going to get your content out the door faster. For the latter, however, it really is a toss-up. Once your Sites component library is built, getting new content out the door can be just as fast with AEM Sites. It's simply all about how much process and governance you put over top of the publication process and this applies to both Franklin and Sites.

Verdict: Franklin is going to be significantly quicker on initial time to market but after the investment period of building your component and template library in AEM Sites, time to market becomes a tossup.

Final Verdict

Hopefully this gives you some insight as to how one might considering leaning given your specific priorities as a customer. Ultimately, I think there's plenty of room for both technologies for the foreseeable future and, given the sheer amount of investment in AEM as a Cloud Service by both Adobe and customers, combined with Adobe's own promises to their partners, I don't see Franklin really taking that much market share away from AEM Sites. I think small to mid-market customers that don't want to spend the initial investment dollars for AEM Sites will gravitate towards Franklin while those that are willing to invest and need a more powerful suite of tools will lean Sites. I can see Franklin being really useful for microsites, blog sites (or any very horizontally-structured site like a blog site). I can even see Franklin being part of a larger AEM Sites approach where some % of the site is Franklin-based while the rest is on AEM Sites. Think a massive, enterprise site where the main parts are on AEM Sites while the blog and case studies sections are built with Franklin. Regardless of which you choose, I think it should at least be clear that, with Adobe, you're dealing with a company that continually innovates.