sometimes you eat the bars, sometimes the bars eats you

[roadrunnertwice]

I'm brushing up on my Ember this weekend (for reasons), which is something like 50% re-learning syntax and standard library stuff, and 50% just stabilizing my mental models for how stuff fits together.

So since I'm thinking about the experiences I had when learning this stuff the first time around, here's the thing I most wish I'd been told basically before doing anything else:

Ember-style Handlebars isn't a text-processing language.

Every* other templating language I've met is content-agnostic and only does naïve text transformations, and if you go into Ember expecting that, shit like this looks absolutely, comprehensively haunted:

<button 
  {{on "click" this.saveProfile}}
>
  save
</button>

First time I encountered that I felt physically queasy, bc it looks like that on call will be replaced by some run of text that causes the element to get a click handler, and there's z e r o imaginable safe-and-sane way to implement that.

But in fact it's fine — that template directive doesn't get replaced by text at all, because .hbs fucking cheats! It's fully aware of the semantic, structural, and runtime rules of its HTML content, and it gets compiled into live JavaScript instead of a static HTML fragment string. So that "on" thing is a separate piece of syntax called a "modifier," and instead of inserting something into the HTML text, it waits 'til that <button> has a DOM element and then uses .addEventListener on it.

Anyway, tbh I'm not 100% sure what I would have told myself to save me the motion sickness. Maybe just: .hbs cheats and knows how browsers work, so some of its syntax acts on DOM APIs instead of on raw text.

---

* I guess the one exception is HAML, but HAML is also just generally deranged.