4 ms·
Agreed on the syntax part. We’ve had good syntax for templates before: <ul> {% for user in users %} <li>{{ user.firstName }}</li> {% endfor %}
by notpushkin 1y ago
Agreed on the syntax part. We’ve had good syntax for templates before:
<ul>
{% for user in users %}
<li>{{ user.firstName }}</li>
{% endfor %}
</ul>
And we have good syntax for templates now:
<ul>
{#each users as user}
<li>{user.firstName}</li>
{/each}
</ul>
Why do we have to squish everything into HTML-like-but-not-quite blocks?
But no, JSX isn’t that great either:
<ul>
{users.map(user => (
<li>{user.firstName}</li>
))}
</ul>
- cubefox 1y agoWhy not use html/XML style syntax rather than mixing two syntax styles? For example, "{/each}" already looks like "</each>".
- benrutter 1y agoI 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 agoI 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 agoGenerally 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 agoLanguages 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 agoThe 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 agoBecause you need quasiquoting to construct trees decently, and JavaScript doesn’t have any worth a damn.
- Already__Taken 1y agoThese aren't good because for 0-lists you have an empty parent containers so often you have a wrapping if outside all of that. More generally, template logic indent doubles up inside the indent levels of the template markup and I just find it ugly. I like vue a lot more; <ul v-if={users}> <li v-for={some in users}>{some.name} </ul>
- notpushkin 1y agoAgree with sibling comments on control flow vs elements separation. For your specific case though, I think a middle ground can be found here: <ul #if={users}> {#each users as user} <li>{user.name}</li> {/each} </ul>