Context
A hands-on DX evaluation built the same mini-site (blog content type + list/detail views, React island, contact form with a zod-validated server action) twice: once as a JavaScript module (engine + tooling from the feature/js-server-extensions branch) against a local Jahia 8.2.3, once with Astro 7.1.3 in SSR mode. All features were verified working in the browser on both stacks.
Verdict: the authoring model is competitive — React SSR views, islands, typed content APIs, and .action.ts client-callable actions are at parity with Astro Actions (same zod validation, same devalue wire format), and the editor extension points (choicelists, validators) are a structural advantage Astro has no answer to. Where JSM loses is the feedback loop:
| Probe |
JSM |
Astro 7 |
| Edit → visible (3 runs) |
4.2s / 4.1s / 4.9s + manual refresh |
0.08s / 0.19s / 0.21s (HMR) |
| Server runtime error |
HTTP 200, component replaced by <!-- Module error -->, unmapped stack in server log |
HTTP 500 + overlay, source-mapped file:line:col |
Correction (2026-07-24). The JSM row was measured on a development-mode instance — the mode the Jahia Docker images boot into by default, and the one developers work in. Jahia does distinguish the modes in AbstractFilter#getContentForError: development puts the message in the comment, production replaces it with a timestamp pointing at the logs; and a failure higher in the render chain propagates as a 500 instead of being swallowed. This makes the gap sharper rather than smaller — the swallowing happens precisely in the mode used to develop. See #708 for the verified mechanics.
| Syntax error | terminal only, page silently serves last good build | overlay + terminal with exact source position |
| Cold build | 5.0s (tsc + vite dual build + pack) | 2.7s |
This epic groups the stories and bugs coming out of that evaluation. Individual issues carry the detailed findings and proposals.
Goal
Bring the JSM inner loop (edit, see, debug) to the standard set by modern frontend frameworks, so the platform advantages (structured content, editor integration, typed server extensions) are not paid for with a 20× slower feedback cycle.
Context
A hands-on DX evaluation built the same mini-site (blog content type + list/detail views, React island, contact form with a zod-validated server action) twice: once as a JavaScript module (engine + tooling from the
feature/js-server-extensionsbranch) against a local Jahia 8.2.3, once with Astro 7.1.3 in SSR mode. All features were verified working in the browser on both stacks.Verdict: the authoring model is competitive — React SSR views, islands, typed content APIs, and
.action.tsclient-callable actions are at parity with Astro Actions (same zod validation, same devalue wire format), and the editor extension points (choicelists, validators) are a structural advantage Astro has no answer to. Where JSM loses is the feedback loop:<!-- Module error -->, unmapped stack in server logfile:line:colThis epic groups the stories and bugs coming out of that evaluation. Individual issues carry the detailed findings and proposals.
Goal
Bring the JSM inner loop (edit, see, debug) to the standard set by modern frontend frameworks, so the platform advantages (structured content, editor integration, typed server extensions) are not paid for with a 20× slower feedback cycle.