WIP Ember-CLI, Refactor to printing

[mixonic]

Emblem is languishing due to an inability to keep up with the Handlebars AST. In theory the Handlebars AST is stable- in practice it has been changing fairly rapidly.

To add Emblem support for Ember.js 1.9 (Handlebars 2.0), Ember.js 1.10+ (HTMLBars), and even the upcoming Handlebars 3.0, the library must de-couple from the AST and target a more stable output format.

In Ember, at the least, we've already taken massive pains to ensure template syntax is the same across versions regardless of the template engine. The template syntax itself is the stable target we should be compiling Emblem to. Emblem becomes a "Handlebars printer" instead of an AST-targeting compiler.

To achieve this transition, @bantic and I have leaned on a few lessons from tildeio/htmlbars internals.

The Emblem compilation pipeline used to work something like this:

• pre-process the template for indentation and whitespace data.
• process the template with a PEG.js parser. This parse is also passed the version of Handlebars being used.
• pass the returned AST (Handlebars compatible) to Handlebars for compilation into a template.
• you now have a compiled Handlebars template

The leaking of what AST version should be built into the parser couples Emblem to the details of that those ASTs, and makes the parser very complex.

Our refactor changes Emblem's compilation pipeline to be more traditional:

• pre-process the template for indentation and whitespace data.
• process the template with a PEG.js parser. This returns an Emblem AST.
• walk the Emblem AST and generate opcodes
• compile these opcodes to an uncompiled Handlebars template.

In practice the AST and template compiler are fairly simple. The parser, responsible for the grammar of Emblem, remains very complex.

A side benefit of compiling to a uncompiled Handlebars template is that with a small amount of effort into pretty-printing, Emblem users will have an escape path if they want to start using standard Ember templates. Removing the current threat of "lock in" only makes Emblem more attractive as a tool.

There are a few TODOs that likely need to land before this branch of Emblem can be considered a totally complete replacement for the current master. That said, we are soon to be using it in production and have tested it in a real app with ~180 templates.

TODO:

• [x] Further document and flesh out the https://github.com/201-created/ember-cli-emblem-hbs-printer ember addon
• [ ] Support the "vanilla handlebars" output format. Unlike the current implementation that leaks into the parser, this should simply be another template compiler against the current opcodes. Maybe a different walker, but regardless it will be much simpler and easy to maintain.
• [x] Support deep parsings of mustache contents. This was required to implement Emblem at all in the past. In our branch, it is only required to implement a few specific features. Personally, I think it would be better to drop those features than introduce the complexity of parsing mustaches in a Handlebars-esq way, but as things stand it is a blocker for merge.
• [x] Complete the porting of tests from tests/integration/general-test-legacy.coffee. We've been breaking these out into individual files and converting to JS as we go.
• [ ] Drop some now-unused code.
• [x] Ensure CI works
• [x] void elements (esp hr, see https://github.com/machty/emblem.js/pull/196#issuecomment-74819217)
• [x] bindings with _ in them (see https://github.com/machty/emblem.js/pull/196#issuecomment-74819217)
• [x] in-element hashstache with two bindings (see https://github.com/machty/emblem.js/pull/196#issuecomment-74819217)

Also worth noting are the https://github.com/bantic/emblem.js/blob/ember-cli/ROADMAP.md and https://github.com/bantic/emblem.js/blob/ember-cli/VANILLA_HANDLEBARS.md documents.

[thec0keman]

I've run into a few issues with compiling emblem templates:

• Static tags with no parameters fail: hr fails with Invalid end taghr(on line 1) (void elements cannot have end tags). likewise img src=item.url fails with Closing tag 'img' (on line 1) did not match last open tag 'div' (on line 1).
• Underscores in expression names fails = affiliate-token value=affiliate_id fails with Expected BeginStatement, DEDENT or end of input but "=" found.
• Mixing class expressions with variables. There are several tests related to mixing classes and variables (i.e. button.info class=active), but in addition the following expression does not work: button class={ enabled:active enabled:info }

Thanks so much for all of your hard work!

[mixonic]

@thec0keman you mean compiling them this with branch? Thanks for the check! We will add those to the list of things to confirm/fix.

[atsjj]

@mixonic @bantic thanks for killin' it with this work; it's totally awesome!

[mixonic]

@atsjj Thanks. We will put in some more time on this next week, hopefully close enough gaps to get it mergeable.

[mphasize]

This looks like an awesome piece of work and I really like the idea of offering a way to go back to Handlebars if necessary.

[drewcovi]

out of curiosity, is the escape path bi-directional?

as a front-end designer, having emblem has proven invaluable to quick changes in scaffolding and layout, but in-light of recent events we've had to abandon emblem temporarily.

it would be stellar if we could (at some point) quickly convert files back and forth.

[mixonic]

@drewcovi We have no plans to write an Emblem printer for Handlebars syntax.

[mmun]

It's not trivial to transpile Handlebars to Emblem because that requires an HTML parser. Seems in-scope for HTMLBars though.

[jimmay5469]

Does this PR include the work to get this to work outside of ember-cli as well? We are using emblem with ember-rails.

[bantic]

@jimmay5469 Yeah, when this lands it will be possible to use the updated emblem parser outside of ember-cli. The emblem gem will need to be updated to use the updated version of emblem.

[bantic]

@thec0keman thanks for testing this branch out last week. a0b9484 above should fix your issue with the underscores, and the others will be fixed soon.

[thec0keman]

Thanks guys for all of your hard work. Our 500+ templates are compiling great now!

Two things:

• This doesn't seem to be able to recognize components with a / in their name. Instead of compiling = navigation/button-list to {{navigation/button-list}} it compiles to {{navigation}}.
• What is the proper syntax for including escaped HTML? Prior versions of Emblem accepted p Put this text in your <head> tax, but now I believe it is trying to compile that.

[mixonic]

replaced by https://github.com/machty/emblem.js/pull/206, and tickets in https://github.com/machty/emblem.js/milestones/0.5.0