[AaronFriel]

I thought this was the most insightful part, though it would be the second most if the author did more than allude to conflict-free replicated data types.

Whenever you build a tiny language for the purpose of templating, it's worth asking yourself if it's really worth it to have to reinvent variables, loops, branches, scoping, expressions, and functions... Poorly.

> Many competing frameworks acted like this wasn't so, and stuck to the old practice of using templates. They missed the obvious lesson here: every templating language inevitably turns into a very poor programming language over time. It will grow to add conditionals, loops, scopes, macros, and other things that are much nicer in actual code. A templating language is mainly an inner platform effect. It targets a weird imagined archetype of someone who isn't allergic to code, but somehow isn't smart enough to work in a genuine programming language. In my experience, this archetype doesn't actually exist. Designers don't want to code at all, while coders want native expressiveness. It's just that simple.

[asddubs]

I always thought the point of the template language was more to enforce the boundary of presentation and code. and thus any template language that grows too powerful is a bad template language, because it's no longer doing the one job it has. So I think a template language should have loops, (non mutable) variables and basic conditions, that's it. So if there's something you can't do in your template that you want to do, the solution then isn't to write some sort of hideous thing in a bespoke templating language, but to add another variable/loop/whatever to the template.

Of course this requires coordination and the larger the organization, the more this is going to slow things down. I also don't think this separation is as important on frontend javascript code, since the lines get blurry there anyway.

[_0w8t]

If a template needs loops or even conditionals, it is already too complex for my taste as it leads to wrong design patterns blurring presentation/code boundary. Something that just allows to access variables and call functions will keep the boundary while allowing a non-programmer or even the end-user to edit it.

[asddubs]

disagree, because the alternative is having a million tiny templates, which is annoying and cumbersome. sometimes you just want a condition to check if a user has an avatar, or if there are replies to a post, or whatever else. same with loop, if something is specific to a template, there's no reason for repeating content to not be a loop (I don't think a template system should allow custom loops though, only looping over predefined content).

I prefer having one big template for a view, when doing SSR. Some layout components will have to be their own template if they repeat on different pages, depending on the template engine you can either pull other templates in directly (in which case using loops is also valid here IMO), or have a variable with a HTML blob generated from another template.

I don't really think either of those things count as code, because there's only logic that is relevant to how things are displayed. It's just, if the user has an avatar, show an image tag, otherwise, show a placeholder image/nothing. repeat this HTML once for each comment shown. That's not code in any meaningful way. I mean technically all of it is code, but you know what I mean.

[_0w8t]

If one wants a view for the whole page, then using a programming language with a good support for embedding strings will be a better solution as it avoids the need to learn one more language.

[pas]

DSLs have their place. arguably we have too few of them. we always use a general language. which is good, because it's general, sometimes great at a few things, but usually very awkwardly at most of the things.

Alan Kay (and his teammates during the STEPS project at VPRI) spent years and years thinking/experimenting with this, here's the final report from 2016: https://news.ycombinator.com/item?id=11686325

"The big breakthrough is making it easy to create new DSLs for any situation."

[asddubs]

a simple template language is composed in its entirety of like 3 separate pieces of syntax, it should be something you can learn in 5 minutes. Like I said in my original post, the point of it is to limit what you can do, so that templates stay templates, and code stays code. If there's a learning curve to your template language, you've already lost.

The template system is somewhat like the type system in that it provides you guarantees. The templates cannot mutate any data or pull anything in that you didn't provide to it. You can be 100% sure that no one did a cute little temporary hack modifying the data inside the template somewhere, pulled in some external data real quick on a friday afternoon or did anything else that doesn't belong in the template. That's the advantage over just using a regular programming language.

[Existenceblinks]

Logic-less template is ok despite some having loop because semantically, users also want to list things, add a thing to a list. I wouldn't add `if/else` but switch-case (this simulates category in user space, not complex condition). "Local variable" shouldn't be exposed to users. Collection name is ok. I think Shopify's Liquid is good, they just can't figure out decent UX on top of it.

[skydhash]

A logic-less template is easily done, by exposing a few methods to the programmer providing the data. I remember Android XMLs to be logic-less and while it refers to concrete classes, something like this could easily be adapted to generate text. A designer wouldn’t need conditionals or loops because he could mark something as a container, the goes on to design the content (for loop, each cell). Desktop and Mobile had this for ages.

I’d be more than happy if a more powerful version of figma existed (capable of handling UI states). Then the designer would then hand the design files annotated with IDs to me, and then I could go on to implement logic. If we agree on some sort of contract for the UI, he can go play to his heart’s content with the Look and Feel.

[Existenceblinks]

I have this idea in mind, how do think about 1 AST <-> 3 different UIs? Content editor, Developer, Designer. Each expose different things but shared AST. Because I think 1 UI with mixed bag contracts is not going to do it.

[tuukkah]

Yes, JSX (and React) is interesting in this way: it's not a (full) template language. Instead, it's a convenient way to write component fragments that include HTML/XML expressions and further components. Each component top-level is still JavaScript statements.

There's also an escape hatch to include arbitrary JS expressions inside your JSX expressions, although perhaps we should use it only to include variables and not more complex JS expressions.

In the end, templates are not important, components are. JSX provides just what's necessary to make it convenient to define components in JS.

[Rapzid]

JSX is a Javascript syntax extension.

[tuukkah]

Yes, and? Did I not differentiate appropriately between JS and JSX expressions?