working on pulling out

proposed/sync-endpoints.md

@@ -28,4 +28,4 @@ A less opinionated API means more creative freedom for Extra Developers. For exa
 
 The MODX Advisory Board recommends that future major versions of MODX do not ship with JavaScript enhancements to the management experience in the core. This not only means refraining from including libraries or frameworks such as jQuery, React, or Angular in the core distribution but refraining from including an enhancement layer in "the core". While these enhancements are appealing, they may grow stale over the years and cause us to incur technical debt as our tooling grows stale while standards march forward.
 
-But how do we make the management experience state of the art without shipping any JavaScript in the core? Core packages. MODX 2.x ships with an efficient backend, an interface reliant on stale scripts, and no packages. The MODX Advisory Board recommends that future major versions of MODX ship with a lean backend, a semantic HTML interface, and optionally one or more core packages. It is within these core packages that the HTML interface is progressively enhanced with scripts. This would allow breaking changes within core package to be on their own release cycle and not necessarily tied to majorly releases of the MODX core itself. Improvements, updates, and refactoring of the manager scripts would no longer be bound to infrequent major releases of the MODX core. MODX Developers could update these core packages, which only affect the manager, independent of updating the MODX core itself, which affects how managed resources are served in production.
+But how do we make the management experience state of the art without shipping any JavaScript in the core? Core packages. MODX 2.x ships with an efficient backend, an interface reliant on stale scripts, and no packages. The MODX Advisory Board recommends that future major versions of MODX ship with a lean backend, a semantic HTML interface, and optionally one or more core packages (or maybe just a lean backend, and the HTML interface is pluggable as core packages as well?). It is within these core packages that the HTML interface is progressively enhanced with scripts. **This would separate the MODX backend from the manager** and allow breaking changes within core package to be on their own release cycle and not necessarily tied to majorly releases of the MODX core itself. Improvements, updates, and refactoring of the manager scripts would no longer be bound to infrequent major releases of the MODX core. MODX Developers could update these core packages, which only affect the manager experience, independent of updating the MODX core itself, which affects how managed resources are served in production. In other words, no more waiting for the next major version of the MODX backend core before front end contributors are able to make breaking changes to the interface used to interact with the MODX backend.