Generally for templating, you want a visual distinction between the control language and the target/rendered language, because they are two different things.
Where they aren't two different things, you have some kind of component configuration language, like WPF on .NET. There is no control language, the instantiated components have behaviours and are responsible for any control logic, like rendering a list of items. This isn't a template language though.
HTML now has web components and so you can think of it in the latter way. I'm not sure if anyone has take this approach though.
> Generally for templating, you want a visual distinction between the control language and the target/rendered language, because they are two different things.
But as I just said, in the end their function actually doesn't seem overly different (to me at least) so a visual distinction with curly brackets rather than angle brackets is perhaps not necessary.
Languages are intended to be read more than written. You'll often be manually reading both the original source and the generated source and comparing them to ensure the original source is being correctly interpreted. Having those visual markers is very useful for debugging this process.
Where they aren't two different things, you have some kind of component configuration language, like WPF on .NET. There is no control language, the instantiated components have behaviours and are responsible for any control logic, like rendering a list of items. This isn't a template language though.
HTML now has web components and so you can think of it in the latter way. I'm not sure if anyone has take this approach though.