For experimental purposes, I’ve been interested in running Ember in settings it wasn’t designed for. My main goal is to attempt to render an Ember app on top of a renderer other than the DOM (a canvas, a native mobile layer, server-side, as a scripting langage).
Ember as a framework offers a number of great conventions and core objects (containers, services, components, models, adapters, etc…) with strong re-usability potential. The downside is, because it’s first and fore-most a WEB framework, the Ember application as a strong dependency on the DOM. No DOM, no application. No application, no container. No container, no way of using core objects, add-ons, templates, and at first-glance it seems the whole Ember ecosystem starts to fall apart.
Not knowing how FastBoot internally worked I assumed the problem must have had been solved to enable a number of Ember features to run on the server side in a Node.js environment. To my understanding, however, the current version of FastBoot actually runs the ember-application in a sandboxed environment which replicates some of the DOM functionality (please correct me if I’m incorrect here) and doesn’t allow Ember to be dom-less.
While I know work is currently under-way on Glimmer 2 and hopefully a public API I wonder how much of this would actually contribute to achieve Ember to be fully dom independent. Please redirect me to early drafts of Glimmer 2 public API documentation if they do exist.
But if Glimmer 2 doesn’t allow that, what would one have to do to to enable this “major” feature? Is it just a matter of building Ember without certain dependencies or would one have to re-write a version of Ember conforming to Ember core objects public API but with a different private implementation?
This is in no mean a requirement, but more a though experiment. Any insights is welcome.