5 ms·
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. When
by AaronFriel 4y ago
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 4y agoI 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 4y agoIf 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.
- Existenceblinks 4y agoLogic-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 4y agoA 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 4y agoI 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.
- asddubs 4y agodisagree, 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.
- tuukkah 4y agoYes, 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.