A dom-less version of Ember.js

Proposals
1

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.

2

Having dug through the code myself in an attempt to answer the same question. I think the simple answer is…you’re right, a “DOM” is still a requirement for Ember. However, if you look here in the HTML Bars source, you’ll see that all of the DOM operations are actually abstracted away from the DOM itself…so, I suppose there’s maybe some thought that this could be something possible in the future?

3

@Spencer_Price additionally I’ve found the following feature flag: https://github.com/emberjs/ember.js/blob/master/packages/ember-metal/lib/environment.js#L22

With the following comment:

  Ember can run in many different environments, including environments like
  Node.js where the DOM is unavailable. This object serves as an abstraction
  over the browser features that Ember relies on, so that code does not
  explode when trying to boot in an environment that doesn't have them.
  This is a private abstraction. In the future, we hope that other
  abstractions (like `Location`, `Renderer`, `dom-helper`) can fully abstract
  over the differences in environment.

(which was added in December 2014)

It looks like dom-less Ember is a thing and must be somewhere in the road-map. Anyone has more information?

1 Like
4

Re: FastBoot, this blog post explains how FastBook fakes the DOM server-side.

5

And I don’t know much about Glimmer 2, but Yehuda talks about it a bit around minute 47 of this video. Here’s another video I haven’t watched that discusses it.

1 Like