Scalable Vector Ember

Fresh from emberGarten in Toronto I bring you the latest on SVG in Ember.js, metal-views, and HTMLBars:

In Ember.js 1.8, we’ve added full support for SVG. This means you can author templates of SVG and make SVG-element components. Demo here, and code here. Zero graphic design skills were involved in the making of this demo, but you get the point!

SVG is slowly rising in usage as IE8 finally drops from the list of commonly supported browsers. To fully support SVG in Ember templates, 1.8 tackled a few tough challenges:

• Switching namespaces and element creation methods. Ember transparently swaps into the SVG namespace, and even swaps back out to HTML for foreignObject tags.
• Track contextual elements. In 1.8, each executed template is a string which must be converted into DOM with innerHTML. To properly support components and nested templates inside an SVG inline document, we’ve created a system to track the contextual (parent) element of a given template. This also helps us implement fixes for broken DOM APIs, and handle complex edge cases in the spec such as optionally omitted start tags (like tbody).

But the big story of metal views, and HTMLBars, is the slow migration of Ember from a string based rendering pipeline to a DOM based one.

• pre-1.8 Ember templates returned strings, and the rendering pipeline assembled strings. This is akin to how a server-side framework would generate HTML.
• In 1.8-1.9, Ember templates are strings individually converted to DOM, then folded into a DOM based rendering tree.
• In 1.10+, Ember will introduce the DOM based HTMLBars templating engine. This completes our migration from string composition to DOM.

The nominal goals of this transition are to introduce new syntaxes (<li class="{{someClass}}">) and improve performance (less strings means less GC pressure).

DOM based rendering opens up an additional and less discussed frontier- That of interoperability with other DOM based rendering engines such as those in Angular, React, Mithril, and Polymer. None of these tools output strings, all expect to be attached to a DOM node and yield to a DOM node. By kicking HTML strings to the curb and embracing the DOM, we’ve created the possibility of using the best rendering strategy for a given part of an app.

SVG support is nothing more than a proving ground for how this kind of integration can work. Our next steps are to ship HTMLBars, then work on making Ember’s conventional path a competitively performing one for all common cases.

My Ember.js consulting firm 201 Created has helped 15+ companies get up to speed. We’re eager to work on SVG projects, and available for hire in January.