# 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:

| Piece | What it is | Where it lives |
| --- | --- | --- |
| **Code** | JavaScript, CSS and block definitions | A GitHub repository you own |
| **Content** | Pages and text | AEM authoring, or document-based sources such as Word, Google Docs or Adobe's own document editor |
| **Media** | Images and video | Added through preview, and optionally managed in AEM Assets |

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:

```plaintext
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:

```javascript
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:

| Classic AEM component | EDS block |
| --- | --- |
| Component folder in `/apps` | Folder in `blocks/` in your Git repo |
| Dialog defines the author's fields | A table layout in the document (or a model definition for the Universal Editor) |
| HTL script renders markup on the server | JavaScript decorates HTML in the browser |
| Sling Model for logic | Plain JavaScript |
| Deployed through Cloud Manager | Pushed to Git, available on the branch's preview URL |

## 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:

```bash
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

| Question | Leans toward EDS | Leans toward classic AEM Sites (Cloud Service) |
| --- | --- | --- |
| Top priority | Page speed, quick launch | Complex enterprise requirements |
| Content shape | Editorial, marketing, landing pages | Deep personalization, intricate templates |
| Author skills | Comfortable with documents or a simple editor | Experienced AEM authors, needing every Page Editor feature |
| Developer skills | Strong web standards (JS, CSS) | Strong Java/OSGi/Sling |
| Governance needs | Moderate | Heavy: MSM, complex workflows, many locales |
| Integration needs | API-based, composable | Deep server-side logic in the AEM runtime |

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\]*