3 ms·

Why not use html/XML style syntax rather than mixing two syntax styles? For example, "{/each}" already looks like "</each>".

benrutter 1y ago
I guess the argument against would be that <element> designates an HTML "thing", i.e. some content for rendering. </each> is about control flow, so it's a conceptually different thing. I can't tell how convincing that argument is to be honest, and how much I'm just rationalising familiarity.
- cubefox 1y ago
  I think there isn't too large a gap between "wrap this stuff in a box and add a line break afterwards" and "repeat this stuff for each item".
  - naasking 1y ago
    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.
    - cubefox 1y ago
      > 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.
      - naasking 1y ago
        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.
tannhaeuser 1y ago
The question is why developers even want to contaminate markup with programming constructs when they have already everything they could ask for, including an object literal syntax ("JSON") for arbitrary graphs that also can encode a DOM. SGML (XML, HTML) is for content (text) authors not developers, but webdevs just don't get it and look at it as a solution to developer problems.
- mananaysiempre 1y ago
  Because you need quasiquoting to construct trees decently, and JavaScript doesn’t have any worth a damn.

benrutter 1y ago

I guess the argument against would be that <element> designates an HTML "thing", i.e. some content for rendering. </each> is about control flow, so it's a conceptually different thing. I can't tell how convincing that argument is to be honest, and how much I'm just rationalising familiarity.

cubefox 1y ago
I think there isn't too large a gap between "wrap this stuff in a box and add a line break afterwards" and "repeat this stuff for each item".
- naasking 1y ago
  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.
  - cubefox 1y ago
    > 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.
    - naasking 1y ago
      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.

tannhaeuser 1y ago

The question is why developers even want to contaminate markup with programming constructs when they have already everything they could ask for, including an object literal syntax ("JSON") for arbitrary graphs that also can encode a DOM. SGML (XML, HTML) is for content (text) authors not developers, but webdevs just don't get it and look at it as a solution to developer problems.

mananaysiempre 1y ago
Because you need quasiquoting to construct trees decently, and JavaScript doesn’t have any worth a damn.