Update Glimmer Template Truthiness Semantics

[bakerac4]

Rendered

Provide a path for Glimmer templates to switch away from classic Handlebars truthiness to JavaScript’s truthiness. This will align our templating language with users' expectations and make teaching easier. It will also allow TypeScript features like type narrowing to work as users would expect it to with keywords like {{and}} or {{or}}.

[boris-petrov]

I'm confused, is this connected to this issue? Isn't updating these semantics going to break billions of apps?

[chriskrycho]

1. No, because assuming we do this, we are going to have a migration plan that allows the community to migrate incrementally.
2. Billions of apps 🤣

[chriskrycho]

We talked a little bit about this at a high level at the Framework team meeting today (everyone is excited), and I'll review it early next week with the input from that!

[wagenet]

We should discuss what it takes for us to accept this at the next RFC Review.

[ef4]

Two main bits of feedback:

1. We need a more detailed migration plan. Does this use optional-features? Is the opt-in per-package or global? If it's global, how are people realistically supposed to upgrade without breaking their addons? What are addon authors supposed to do (they can't control when their consuming apps flip a global opt-in)? If it's per-package, how does that actually work at runtime (is there something visible in the actual compiled templates to say "this one uses the new boolean semantics"?).

2. An important "Alternatives" topics is the idea of adding Javascript expression syntax to templates, something that we've discussed at length and people generally like as an idea, though no written design exists yet. Since that would also introduce new replacements for truth helpers, ones that would necessarily have javascript semantics, it seems like an area of overlap and it could make doing this RFC easier if we also did that one.

I have to say, I've been working in Glint quite a lot already and I've yet to hit a realistic example where this semantic gap actually came up. I would be curious to see people's examples. That doesn't mean I don't care about closing it, but I do think it's relevant to how we teach this and how we prioritize the migration.

[chriskrycho]

The places it's likely to come up are exceptionally rare, but likely to be very annoying for people when they do happen, just insofar as they're a case where TS/Glint tells you they're safe and then you get a runtime error from it. Implicit in @ef4's comment is that Glint does let folks opt in (and our docs will better reflect that hopefully this week!).

That said, using a JS-expression-syntax would also solve this, and has the possibility a clear and straightforward opt-in at a template authoring level (e.g. a <template lang='something-good-here'> or some such along with an optional-feature to flip the default), and cleanly solves the problem from a Glint POV because there is no problem in that world: you just get TS semantics for free. Given the likely non-trivial work of migrating the truthiness semantics of existing Handlebars vs. switching to a JS expression syntax, my own personal preference would be extremely strongly toward the latter.

[wagenet]

We should hash through this at the next feature design meting.