AEM + Edge Delivery Services: What It Means for Traditional AEM Developers

If you've spent years building AEM Sites with Java, OSGi, Sling Models and HTL, Edge Delivery Services (EDS) can look like it comes from a different planet: no Java, no Maven build, no components in the repository, just JavaScript, CSS and a content source. This post explains what EDS is, how it fits with the AEM you know, and how to think about your skills and your project decisions.

What Is Edge Delivery Services?

Edge Delivery Services is Adobe's performance-first approach to delivering websites. It is part of the next generation of AEM's composable architecture: separate tiers for delivery, authoring and code, each of which can use tools you already have.

The core ideas:

• Delivery is separated from authoring. Visitors get pages served from the edge, built from content that was previewed and published
• No build step for the front end. You write standard HTML-friendly JavaScript and CSS, and it runs as written
• Performance by default. The architecture and the starter code are designed to produce very fast pages, with good Core Web Vitals as the norm rather than the exception
• Fast to start. Teams can often go live in days or weeks rather than months

The Three Pieces

Think of an EDS site as three independent sources that Adobe assembles:

Content, code and media have their own lifecycles. A new code branch immediately sees the current content, and changes to content are visible on both the preview and live URLs at the same time. This independence is a large part of why EDS is quick to work with.

Preview and Live

Every EDS site has two environments for each code branch:

• .aem.page: the preview environment, where authors check their work
• .aem.live: the published environment that visitors see, usually fronted by your own domain and CDN

Authors preview content to see it on .aem.page, then publish it to put it on .aem.live. Customers typically keep their existing CDN, DNS and certificates in front of the delivery tier.

Two Ways to Author

1. Document-Based Authoring

Authors write in familiar documents: Microsoft Word, Google Docs, or Adobe's own document editor (DA, often referred to as da.live). Documents follow a simple structure:

• Sections are separated by a horizontal line
• Blocks (the equivalent of components) are written as tables in the document, with the table's first cell naming the block
• Headers and footers are separate documents

This approach lets authors create pages without learning AEM at all, which is a major benefit for content-heavy marketing teams. Adobe's own guidance has increasingly favored its document editor over Word or Google Docs for new projects, so check the current recommendation when you plan.

2. AEM Authoring with the Universal Editor

Content stays in AEM (sometimes referred to by the project name "XWalk"), and authors use the Universal Editor, a modern WYSIWYG editor that edits content in context. This gives you AEM's strengths: workflows, governance, multi-site management, translation and DAM integration.

Be aware that the Universal Editor has not been at full feature parity with the classic Page Editor, so check the feature you depend on (for example, a particular MSM or Launch behavior) before committing.

What a Block Looks Like

A block is a folder in your code repository with a JavaScript and a CSS file named after the block:

blocks/
└── cards/
    ├── cards.js
    └── cards.css

The author writes a table in a document, and EDS delivers it as simple, semantic HTML. Your block's JavaScript decorates that HTML into the final markup. A typical block:

import { createOptimizedPicture } from '../../scripts/aem.js';

export default function decorate(block) {
  const ul = document.createElement('ul');

  [...block.children].forEach((row) => {
    const li = document.createElement('li');
    while (row.firstElementChild) li.append(row.firstElementChild);

    [...li.children].forEach((div) => {
      div.className = div.children.length === 1 && div.querySelector('picture')
        ? 'cards-card-image'
        : 'cards-card-body';
    });
    ul.append(li);
  });

  ul.querySelectorAll('picture > img').forEach((img) => {
    img.closest('picture').replaceWith(
      createOptimizedPicture(img.src, img.alt, false, [{ width: '750' }]),
    );
  });

  block.replaceChildren(ul);
}

Compare this with the AEM components you know:

Getting Started Locally

Adobe provides a template repository (the AEM boilerplate) and a code-sync app so the repository's code is picked up automatically. For local development you install the AEM command line tool and start a local server:

npm install -g @adobe/aem-cli
aem up

aem up serves your local code against the content from your preview environment, so you can iterate on blocks quickly with live reload. Check the current getting-started tutorial on aem.live for the up-to-date steps.

EDS vs Classic AEM Sites: How to Decide

It isn't always either/or. Some organizations run EDS for marketing pages and classic Sites for applications that need complex server-side behavior, and EDS can sit in front of AEM as a Cloud Service as its delivery layer. When you're advising a client, start with the content and experience requirements, then choose the authoring model, then pick the delivery architecture.

What It Means for Your Skills

For a traditional AEM developer, EDS shifts the center of gravity:

Skills that become less central (for EDS projects):

• Java, OSGi bundles and Sling Models for rendering
• Dialog XML and Granite UI
• Dispatcher configuration for the delivery tier
• Maven multi-module builds

Skills that become more important:

• Modern JavaScript and CSS, written without a build pipeline
• Web performance: Core Web Vitals, lazy loading, image optimization
• Information architecture for content authors: designing blocks that are easy to author
• Integration and API thinking: composing services rather than building everything inside AEM
• Git-based workflows and branch-based previews

Skills that carry over directly:

• Understanding of content modeling, governance and authoring workflows
• Knowledge of AEM Assets, translation, Cloud Service operations and CDN behavior
• Architecture and solution design experience

The practical advice for your career: you don't have to choose between the two worlds. The strongest AEM architects today understand both, and can explain to a client when each fits.

Common Pitfalls

• Treating EDS like a classic AEM project. Trying to recreate server-side components, or adding heavy frameworks, defeats its performance advantages
• Poorly designed blocks. If a block is hard to author, authors will work around it, so test blocks with real authors
• Ignoring content structure. Documents need consistent structure, or pages drift apart over time
• Assuming every AEM feature is available. Check specific needs against current documentation before you promise them
• No governance for code. Even with a light setup, use pull requests, reviews and performance checks

What's Next

Whichever architecture you work with, you'll eventually be asked to explain and defend your decisions in front of other people. The next post is about exactly that: preparing for AEM architect interviews, with the questions that come up and how to structure strong answers.

Next in this series: [AEM Architect Interview Prep]