DA vs Universal Editor Decision Guide

Content Objective

This chapter covers:

• The fundamental difference between DA and UE from first principles
• The authoring experience comparison for the same block in both systems
• The developer setup difference for DA vs UE
• Content storage: where content actually lives in each system
• The complete feature capability matrix
• When DA is the better choice and when UE is the better choice
• Whether you can use both in the same project
• The migration path if you start with one and need to switch
• A concrete decision framework for your specific project type

Two Authoring Systems, One Delivery Pipeline

DA (Document Authoring via da.live) and UE (Universal Editor) are two different interfaces for creating content that ultimately flows through the same EDS delivery pipeline.

Both systems produce content that EDS transforms into blocks. Both systems deliver through the same .aem.page / .aem.live URLs. The rendering pipeline, blocks, and CDN are identical.

What is different: where content is stored, how authors interact with it, and what developer setup is required.

DA Path:
  Author writes in da.live (Google Docs-like interface)
  → Content stored in DA's content store (separate from AEM)
  → Synced to Edge delivery on Preview/Publish
  → Same EDS rendering pipeline

UE Path:
  Author edits visually in Universal Editor (inside AEM)
  → Content stored in AEM JCR (same as classic AEM)
  → Delivered via AEM's bin/franklin.delivery servlet
  → Same EDS rendering pipeline

From a reader's perspective, a page authored in DA and a page authored in UE are visually identical. The authoring experience is completely different.

The Same Block in Both Systems

Let's author a simple hero block in both systems to make the difference concrete.

In Document Authoring (da.live)

The author opens a Google Docs-like interface. A hero block is authored as a table:

| Hero                                           |
|------------------------------------------------|
| Welcome to Abbott                              |
| Discover our life-changing healthcare products |
| [Image of doctor]                              |
| Get Started | /products                        |

The author:

1. Types text directly in the table cell
2. Inserts an image by pasting or dragging
3. Uses formatting toolbar (bold, italic, heading) for text cells
4. Cannot see the rendered result without clicking Preview

What the author experience feels like: Similar to editing a Google Doc or a Word document. Structured but text-first.

In Universal Editor (xwalk)

The author opens the live rendered page in a browser, with UE overlaid. The hero is visible exactly as it will appear on the live site. The author:

1. Clicks directly on the "Welcome to Abbott" heading
2. Properties panel opens on the right showing "Title" field
3. Edits the field in-place or in the panel
4. Sees the change reflected live in the page preview
5. Clicks on the image area to open the asset picker

What the author experience feels like: Clicking on things in a live web page. Visual and WYSIWYG.

Author Experience Comparison

Who adapts to each system better:

• Non-technical content authors who write long-form content → DA
• Marketers accustomed to CMS page builders → UE
• Authors coming from AEM Touch UI → UE (similar mental model)
• Authors who primarily work in Google Workspace / Microsoft 365 → DA

Developer Setup Comparison

DA Setup

No AEM Cloud instance required. DA stores content separately in Adobe's content storage.

Required setup:

# fstab.yaml — points to DA
mountpoints:
  /:
    url: https://content.da.live/{org}/{repo}

Developer setup:

1. Create site at da.live/{org}/{repo}
2. Set fstab.yaml to point at DA
3. Write blocks normally (no annotation required)
4. Deploy code to GitHub
5. DA renders the content automatically

No editor-support.js needed. No component-definition.json, component-models.json, or component-filters.json needed for basic usage.

Developer effort: Low

UE (xwalk) Setup

Requires AEM Cloud instance (Author tier).

Required setup:

# fstab.yaml — points to AEM Cloud
mountpoints:
  /:
    url: https://author-p{id}-e{id}.adobeaemcloud.com/bin/franklin.delivery/{org}/{repo}/main

Developer setup:

1. AEM Cloud instance configured and accessible
2. component-definition.json — register every block as a UE component
3. component-models.json — define every field for every block
4. component-filters.json — define which components are allowed in which containers
5. models/ — per-block JSON model files (merged into root JSON files via build)
6. data-aue-* annotations in every block's decorate() function
7. editor-support.js present in scripts/
8. xwalk.json for UE to discover the component registry

Developer effort: High — significant upfront configuration per block

Content Storage Comparison

This is the most architecturally significant difference.

Where DA Content Lives

DA content is stored in Adobe's cloud content storage, separate from AEM JCR entirely.

Author edits at da.live
      ↓
Content stored in: Adobe DA Content Store
                   (Not JCR, not GitHub)
      ↓
On Sidekick "Preview": synced to .aem.page CDN
On Sidekick "Publish": promoted to .aem.live CDN
      ↓
Delivered by EDS

DA content versioning:

• DA maintains a document-level version history (similar to Google Docs)
• No JCR versioning, no CRX/DE access, no workflow API integration
• Access control at folder level (can share a folder, not individual nodes)

Where UE (xwalk) Content Lives

UE content is stored in AEM JCR — the same repository as classic AEM content.

Author edits in Universal Editor
      ↓
Content stored in: AEM JCR
                   /content/{site}/{path}/jcr:content/root/container/...
      ↓
On Sidekick "Preview": bin/franklin.delivery reads JCR,
                       converts to EDS HTML, syncs to .aem.page
On Sidekick "Publish": same servlet promotes to .aem.live
      ↓
Delivered by EDS

UE content versioning:

• Full AEM versioning (every edit creates a version)
• AEM workflow integration available
• JCR ACLs for node-level access control
• Full CRX/DE access for content inspection
• Can use MSM (Live Copy) for content inheritance

Feature Capability Matrix

When to Choose DA

Choose Document Authoring when:

1. You don't have an AEM Cloud instance DA has no AEM dependency. If your organization has EDS but not AEM Cloud, DA is the only option.

2. Authors primarily create editorial content Blog posts, articles, news stories, and long-form content are natural in DA's document-based editor. The author writes prose and tables, not visual layouts.

3. Non-technical content teams DA's interface is immediately familiar to anyone who has used Google Docs or Microsoft Word. No training on CMS concepts required.

4. High-volume content production Marketers who publish dozens of pages per week will work faster in DA's document-based model than learning UE interaction patterns.

5. Governance is folder-based, not node-based If your access control can be satisfied by "this team can edit this folder," DA is sufficient and simpler than configuring JCR ACLs.

6. Speed of project launch A DA project can go from zero to working in days. A UE project requires significant per-block configuration that takes weeks for a full site.

Real-world example: A healthcare company's marketing team publishes 50 news articles per week. Authors are not technical. Content is text-heavy with occasional images. DA is the right choice — authors are productive immediately with no CMS training.

When to Choose UE (xwalk)

Choose Universal Editor when:

1. Visual precision is required by authors When authors need to see exactly how the page looks while editing — hero layouts, card arrangements, page structure — UE's WYSIWYG model is essential.

2. Your organization already uses AEM Cloud If AEM is already deployed and licensed, UE lets you add EDS as a delivery layer without a separate content system. Content stays in JCR where your team already manages it.

3. You need AEM Workflow for content approval Multi-step approval, legal review, translation workflows — these all require AEM Workflow, which requires JCR storage, which requires UE.

4. Governance requires node-level access control Pharmaceutical, financial, and regulated industries often require that a specific user can edit one specific component on a page but not others. JCR ACLs provide this; DA folder-based access cannot.

5. You need MSM for multi-regional content If you manage 30 regional sites that inherit content from a master, MSM Live Copy requires JCR content, which requires UE.

6. Authors are coming from classic AEM Touch UI Authors who know AEM's authoring experience will adapt to UE more easily than to DA. The mental model is similar.

7. Integration with existing AEM content (Content Fragments, Assets) If your EDS pages need to reference or embed AEM Content Fragments or pull from the DAM asset picker, UE provides that integration natively.

Real-world example: A pharmaceutical company with 40 regional sites, strict regulatory approval workflows, and an existing AEM Cloud investment. Authors are accustomed to AEM authoring. UE is the right choice — workflow, MSM, governance, and existing author training all point to UE.

Can You Use Both in the Same Project?

Yes. A single EDS project can have some pages in DA and others in UE — but NOT the same page in both.

How this works:

• fstab.yaml maps a URL path prefix to a content source
• You can map /news/* to DA and /products/* to AEM (UE)

# fstab.yaml — split content sources
mountpoints:
  /:
    url: https://content.da.live/acme/eds-site

  /products:
    url: https://author-p153710-e1614654.adobeaemcloud.com/bin/franklin.delivery/acme/eds-site/main/products

With this config:

• /news/article-1 → content from DA
• /products/paracetamol → content from AEM JCR (UE)

Blocks are the same for both. A hero block authored in DA as a table and a hero block authored in UE via the component panel both produce the same HTML after EDS rendering.

Developer overhead of using both:

• Block JS and CSS work identically for both (no extra work)
• You need component-definition.json, component-models.json, component-filters.json, and data-aue-* annotations only for the UE-managed pages
• DA pages require no block configuration files

When to split: When you have genuinely different content types with genuinely different requirements. Don't split just to use both technologies. Pick one per use case and stay consistent.

Migration Path: Can You Switch?

DA → UE

Difficulty: Moderate

Content in DA's store cannot be automatically migrated to AEM JCR. You would need to:

1. Use a content migration tool or custom script to read DA content via DA API and write to AEM JCR
2. Add component-definition.json, component-models.json, component-filters.json for all existing blocks
3. Add data-aue-* annotations to all existing block decorate() functions
4. Update fstab.yaml

The block JS and CSS remain unchanged.

UE → DA

Difficulty: Moderate

AEM JCR content exported to DA format requires conversion. The EDS block structure (component node hierarchy) maps to DA table format, but this conversion is not automatic.

Blocks lose their UE configuration (component definition, models, filters) since DA doesn't use them.

Recommendation: Choose your authoring system carefully at project start. Migration is possible but not trivial.

Decision Framework

Does your organization have AEM Cloud?
├── No → DA
└── Yes → Continue

Do authors need to see the rendered page while editing?
├── Yes, always → UE
└── No, document editing is sufficient → Continue

Is AEM Workflow required for content approval?
├── Yes → UE
└── No → Continue

Is node-level access control required?
├── Yes → UE
└── No → Continue

Is MSM / Live Copy required?
├── Yes → UE
└── No → Continue

Are the majority of authors familiar with Google Docs / Word?
├── Yes → DA
└── No (they know AEM Touch UI) → UE

Is speed of launch the top priority?
├── Yes → DA (no block configuration setup required)
└── No → UE

Is content primarily editorial (long text with occasional images)?
├── Yes → DA
└── No (visual layouts, marketing pages, structured fields) → UE

If you answer UE to any of the first five questions, choose UE. If you reach the bottom without a UE answer, DA will likely serve you better.

Summary Recommendation by Project Type

Key Takeaways

• Same delivery pipeline, different content origin — DA and UE produce identical rendered output
• DA is document-based — authors see structured tables, not the rendered page
• UE is WYSIWYG — authors click on the live page; properties panel opens for the field
• DA requires no AEM instance — content lives in Adobe's DA cloud storage
• UE requires AEM Cloud — content lives in JCR; significant per-block developer setup
• UE unlocks: workflow, MSM, node ACLs, DAM picker, Content Fragments — DA cannot do any of these
• DA is faster to launch — no component-definition.json, no models, no annotations
• Both systems can coexist — use fstab.yaml path mappings to split content sources per URL prefix
• Migration between systems is possible but non-trivial — decide early

Next Steps

In the next chapter, we cover Performance — Measuring and Validating Core Web Vitals in EDS. We have mentioned the performance guarantee in several chapters — now we measure it. Lighthouse, PageSpeed Insights, CrUX, the three CWV metrics, how to find what broke your score, and how to validate your blocks are not the LCP bottleneck.