{{else}} should render a value rather than be a control-flow keyword.

[NullVoxPopuli]

One thing I noticed as I am both going through the Svelte tutorial again as well as writing a similar one for Ember / <template>, is that {{else}} is is syntactically incoherent.

Everywhere else, we use {{ identifier }} to render a value except for {{else}}.

For consistency, I think we should fix that. Svelte uses a "continuation" syntax to denote that a block is continuing.

So for us, that would look like this:

{{#if condition}}

{{:else if otherCondition}}

{{:else}}

{{/if}}

which has 0 ambiguity with value-rendering.

[chriskrycho]

This is a good thing to consider changing, though note that keywords and control structures in most languages are allowed to have their own syntactic forms. I would also suggest that the time to make that change would be in a broader syntactic reform, i.e. a switch to a single-curly-based form that is similar to Svelte's templates:

<template lang='sveltish'>
  {#if condition}
  {:else if otherCondition}
  {:else}
  {/if}
</template>

[runspired]

+1 for broader reform. Been thinking of proposing this since it actually wouldn't be hard to implement in the parser and could be done initially as an external optional offering. Double curlies don't feel necessary anymore to me.

[sandstrom]

I think this is something that Ember has inherited from Handlebars: https://handlebarsjs.com/guide/builtin-helpers.html#if

I don't know how far Ember templates has deviated from Handlebars, so maybe going further away isn't a problem.

But one thing to consider is that Handlebars tooling (linting, syntax highlighters, etc) mostly work with Ember, which is nice. With a custom template language, Ember would have to maintain that stuff themselves, which is more work.

[chriskrycho]

That's correct; technically Glimmer templates are still Handlebars templates. They've diverged substantially, but by addition rather than by change overall. The first pass of the parser is the JS Handlebars parser… but then we have to do more work to get to what we have today. That's a real and genuine concern, regardless, especially as regards syntax highlighting.

[chancancode]

I don't think there is anything intrinsically very wrong with this that requires rectification.

FWIW {{else}} isn't the only one, there are also {{debugger}}, {{yield}}, etc, which would not be "fixed" by the proposed syntax.

But as @chriskrycho said there isn't anything abnormal about this. In JavaScript you could say the same about many of the keywords that would otherwise be some other kind of statement/expression in the same position if spelled differently. return, debugger, break, continue, etc, all would have been an identifier if you change any one letter, or if you want to look at expression position, there are yield, arguments, null, false, etc, which would could totally use in places that would have been a variable reference. For example, console.log(yield) and console.log(foo) are syntactically indistinguishable, just that one happens to be a keyword. There are even import.meta, new.target... for some recent additions.

IMO if your syntax highlighting is working it shouldn't be particularly surprising or unexpected, especially since the <template> tag now shares the JS scope and you would never be able to use any of the JS keywords as template bindings anyway. I think there are many reasons to revisit the syntax, but this alone/by itself isn't a strong case.

As far single vs double curlies, there is a couple of tradeoffs, and personally I think on balance {{ is right. For instance if switching to single curlies would mean that anytime you use a { in the HTML content you would have to escape it, so stuff you copy and paste from HTML examples are now less likely to Just Work™ (which, historically has been a strong guiding principle for Ember in this space). Also, now that we are embedded in the JavaScript space, I personally find that highlighting/viewing {{ as a single special token has value, because it is very distinct from what { usually means in JS, especially if we ever want to embed some object literal-like syntax or subset of JavaScript syntax inside these positions.

Nothing that can't be overcome, but I don't see a strong reason to change them. Personally I probably would still have picked {{ if designing a new language from scratch today. Or maybe ${ ... } 🤷🏼‍♂️