Understanding the divide between AEM front-end and back-end developers

If you ask any front-end developer what they need to be successful, they'll likely tell you the three things:

1. A rapid prototyping tool.
2. A JSON end-point to grab data.
3. A template language that makes sense.
4. Don't tell me how to do my job.

If you ask any back-end developer what they need to be successful, they'll likely tell you they need three things:

1. Ability to leverage Java / whatever frameworks to make them highly efficient.
2. A good testing / CI / automation process.
3. Not too much business, front-end, or ops noise.
4. Don't tell me how to do my job.

AEM is built around experiences (FE) but powered through rich and deep integrations (BE) that keep businesses productive. How does a business consume CRM data? It's not through the front-end.

This is where we have to think about MVC at a macro level. FE might be asking for data in a concise JSON feed that can be consumed by a hot new template language (V), but BE is talking OSGi, separation of concerns, and scale-ability (C). Where the data is coming from is anyone's guess. If you live in the AEM world, you're hoping the JCR is building models the way you want (M). So whose domain is the model? I'd argue it's FE.

As an FE developer (FED), I build the dialogs that POST against SlingPostServlet and store my data exactly how I want. Do I want 45 properties outlining how this component should behave in responsive views or should I break them out as children? What does that mean for the back-end?

We're getting closer to a scenario where all parties can agree. FEDs just want a JSON end-point and a template language they're use to (JSX, HBS, whatever). BED's want to write productive Java classes (POJOs, Servlets, OSGi services). We just seem to be missing that final link. HTL is so incredibly powerful when rendered server-side, but doesn't satisfy the need of in-page updating. How do I sort a list without a query param and a page refresh? Angular? Handlebars? React? All of these solutions have felt like after thoughts or had down-sides when coupled with HTL.

At some point, the power of the back-end needs to be coupled with the front-end. Exposing the entire JCR tree to the front-end or writing servlets for every single view is not the answer.