AEM : Choosing a Front-end Approach in 2021

One of the questions that arise when starting a new AEM project, is what kind of front-end approach to choose. In Adobe we have internal guidance with a document of 15+ pages, and obviously I won't put that here because it's going to bore you out. Instead, I want to distill it down to a few considerations.

Customer First

Remember, the first priority is the customers needs, and that often includes not spending too much money and effort, on the short and long term. This might sound basic, but what I often saw in my consulting days, is that very passionate (Front-End) agencies push for the latest and greatest front-end tech. 

Why? 

• Because it's cool. 
• We like working with it. 
• Everybody else we know is doing it 
• It's a few milliseconds faster in rendering.

Now while these above are understandable, and I admire passion for the job, these reasons should be the lowest priority. Instead think this, I choose this front-end approach because:

• It fits the goals of my customer
• It's simple: low maintenance costs and developers can easily understand it
• If needed: It can work well with other developer teams on the platform
• It works well with Adobe Experience Managers' extensions (think edit-ability, Adobe Target) 
• It works well with the infrastructure of AEM, either on premise or in the cloud

After considering these, then you can consider the first 4 points. Think about it like this, a good salesman gives the customer what is appropriate for him. If a customer wants a very fast sports-car to do a race, then the car-salesman should sell him a Ferarri. But if a customer wants a car so he can make money with Uber, that would be an inappropriate: it would not never pay itself back. Instead he's better off with a new Mercedez. Unless, despite advising against it, he insists on blowing money on a fancy Ferrari, even though he doesn't need it, then fine, go ahead!

In general that means for most customers, simple vanilla javascript (like the Core Components are scripted) fits best for most scenario's. It's basic and covers most needs, and can live next to other solutions.

Advantages of vanilla JS:

• Simple
• Works with all Adobe solutions, AEM editing
• No technology lock-in

Some Disadvantages:

• Can get hard to maintain, discipline required
• Hard to get ready-to-go, reusable components 

But, what if you have a module, 1 or 2, for example a booking tool for Hotel Rooms? I would recommend an isolated web-components approach. You would have this one component as web component, and the rest of the page in normal HTL with normal javascript.

As framework choice, React is supported quite extensively at Adobe, so you have for example partial Target support. If you don't need Targets support etc, you can go along with other Framework's, using the web-component approach. Take a look at the react web-component library from Adobe.

Advantages of web-components

• No technology lock-in
• Works fine with AEM editor
• Works with Adobe Target VEC editor
• Self-contained components, work with multiple teams independently 

Disadvantages

• Harder to share state across page-requests
• Less framework control over page vs SPA editor

But what if you have lots of interactive components that heavily rely on a state, that needs to be transferred across pages seamlessly? Like for example, a flight carrier website with multiple modules such as book flight, check-in, login, view account etc? 

Then the SPA editor might be for you. 

Advantages of the spa-editor 1.0 

• Framework has very powerful control over page, routing, layout, state sharing
• Authors retain full editing capability of AEM, over the site
• Unified front-end code base, no duplicate front-end code
• Very performant, efficient 
• Server-Side Rendering available

Disadvantages

• Technology lock-in (Angular, Vue, React, take your pick!)
• Increased complexity (getting less due to updates)
• Not all core components available OOTB

Last but not least, SPA editor 2.0?  

The SPA editor 2.0 has been called into life to enable AEM headless editing for existing React applications, running on for example Express, Gatsby or NextJS. Using this you get a good portion of the core editing functionality of AEM, without too much refactoring in your JS app. This is useful if there is an already existing application.

In my personal opinion, if you are starting fresh, I'd rather to for SPA editor 1.0 instead, so you get the full capabilities of AEM. It does mean you have to deal with AEM more than with the 2.0 approach, but the customer get's much more value.  I will write a blog post later on how to do SPA editor 1.0 development, while avoiding having to code AEM as much as possible.

I hope this helps you choosing a front-end approach in these times!