Wrote a Patreon post about recent Mustache milestones

[jgonggrijp]

I wrote this on my Patreon page:

https://www.patreon.com/posts/mustache-94544564

Most of what I wrote in there is likely not really new to regular visitors of the mustache/spec discussions, but I refer to it here because I mention several community members in the post.

FYI @determin1st @agentgt @locks @spullara @bobthecow

[determin1st]

he he, i see you referenced me first, so i have to write something.. well yeah, i found myself in imperative hell, trying to compose renderer functions that would render structured logs into console/terminal (those that are transferred/stored in JSON format) and recalling that i had my own small implementation of mustache template processor, a bit later finding out that power lambdas might be a great leap forward.

the manual of my mustache is quite fuzzy and unfinished, i also plan to rename the repo, but the webp image is nice :] those are alternative terms i talked about. though, it is more about a revision than a revival (sometimes you have to break few bones to make a sturdier base). now, with all the features listed there, implemented, i see no task the sm-mustache cant solve, that, for example, handlebars or smarty or another template engine can.

lambdas are great, lambda argument is greater. the first is out of syntax definition (as it is bound to underlying language). almost every imaginable/discussed feature may be done with their combo.

• a wrap:

Hello {{#wrap <em>,</em>}}world{{/}}!

• an even/odd alternation

<table>
{{@array}}
  <tr background-color="{{#isEven _index}}white{{|}}gray{{/}}"><td>dummy</td></tr>
{{/}}
</table>

• checking array is not empty

{{^isEmpty array}}
  array is not empty
{{/}}
{{#isNotEmpty array}}
    array is not empty
{{/}}

• formatting

{{user.name}} joined at {{timestampToISO8601 user.created}}

• etc..

so here i disagree with the filters approach. although i also changed mind about dedenting and re-indenting feature which will be very useful in experimenting / playground. it will not affect performance because there is no parsing step in performance mode - templates are kept in compiled form.

you asked about the (HTML) relevance of template processors earlier, i think it's a dead man walking:

but i also think that there is possibility to pull out of the HTML stalemate by oneself's hair like Baron Munchausen did and its definitely related to playground's data implementation.

[jgonggrijp]

Thanks for adding some background.

(...) it is more about a revision than a revival

True! The revival was just a side effect.

(...) now, with all the features listed there, implemented, i see no task the sm-mustache cant solve, that, for example, handlebars or smarty or another template engine can.

Congratulations.

lambdas are great, lambda argument is greater. (...)

I quoted this part of your post in #188. I intend to reply there, but I'll let you add anything you want to add first.

so here i disagree with the filters approach. although i also changed mind

Is this a "I might still change my mind" hint? 😉

about dedenting and re-indenting feature which will be very useful in experimenting / playground.

Do you mean #131? Or just the existing standalone reindentation for partials? Either way, good to hear that you find it useful.

you asked about the (HTML) relevance of template processors earlier,

Please remind me, where did I ask that?

i think it's a dead man walking: [image]

but i also think that there is possibility to pull out of the HTML stalemate by oneself's hair like Baron Munchausen did

I don't understand this part, could you elaborate?

and its definitely related to playground's data implementation.

Please clarify! Which playground, the Wontache one? In that case, what do you mean by the "data implementation"?

I find this image really confusing. The line with the three red dots, with the labels above it, looks to me like you are drawing a spectrum between server side "static" HTML and client side "dynamic" HTML.

You grouped names under each red dot, but by my understanding, they don't really match the corresponding positions in the spectrum. The left group includes programming languages and backend frameworks, which do match the server side, but also templating languages, which can be used at either side. The middle group consists entirely of client side frameworks, so I would expect those to be at the far right. The right group only contains "components", but that also happens to be the word championed by frameworks like Angular, React and Vue.

Then, there are the red and green arrows at the bottom, labeled "backfire!" and "a trick?". I have absolutely no idea what you mean by those.

[determin1st]

so here i disagree with the filters approach. although i also changed mind

Is this a "I might still change my mind" hint? 😉

cant see any advantage over lambda argument which has better/simplier syntax

about dedenting and re-indenting feature which will be very useful in experimenting / playground.

Do you mean #131? Or just the existing standalone reindentation for partials? Either way, good to hear that you find it useful.

standalone pairs, intrinsic indentation, etc, anything that could make swift result look "as expected". but the author shouldnt rely on it in a "production" variant.

you asked about the (HTML) relevance of template processors earlier,

Please remind me, where did I ask that?

here - #185 (reply in thread)
i assume its HTML because other applications arent mentioned/listed anywhere

I find this image really confusing. The line with the three red dots, with the labels above it, looks to me like you are drawing a spectrum between server side "static" HTML and client side "dynamic" HTML.

You grouped names under each red dot, but by my understanding, they don't really match the corresponding positions in the spectrum. The left group includes programming languages and backend frameworks, which do match the server side, but also templating languages, which can be used at either side. The middle group consists entirely of client side frameworks, so I would expect those to be at the far right. The right group only contains "components", but that also happens to be the word championed by frameworks like Angular, React and Vue.

both groups operate with templates that render to HTML/JS for the browser, the second/middle group also renders JS bindings with HTML that make it more to the right. pure components dont require HTML, only name and parameters, so no special renderer like React/Vue or mustache is needed. yes, those try to persuade they bear pure components, but their components come with some static burden.

Then, there are the red and green arrows at the bottom, labeled "backfire!" and "a trick?". I have absolutely no idea what you mean by those.

i think it's a dead man walking
but i also think that there is possibility to pull out of the HTML stalemate by oneself's hair like Baron Munchausen did

I don't understand this part, could you elaborate?

and its definitely related to playground's data implementation.

Please clarify! Which playground, the Wontache one? In that case, what do you mean by the "data implementation"?

mustache is smaller than the second group, its easier to understand mustache than Vue for example. so it can be used to render initial state of the component, like:

<html>
<tag-here>...</tag-here>

<!--{component dataGrid
  data-source: "users-table"
  infinite-scroll: true
  display-max: 100
}-->

<tag-there>...</tag-there>
</html>

here i put imaginary lambda with argument that includes the name and simplified JSON parameters.
that lambda and parameters can be also used in playground's data, actually it may be packed into a single textarea:

{{playground-data
  user:
    name: "Joe"
    age: 123
  flag: true
}}

{{#flag}}
  hello {{user.name}}, you are {{user.age}} years old!
{{/}}

should render to hello Joe, you are 123 years old!

[jgonggrijp]

you asked about the (HTML) relevance of template processors earlier,

Please remind me, where did I ask that?

here - #185 (reply in thread) i assume its HTML because other applications arent mentioned/listed anywhere

Ah, that is a misunderstanding. It started with me stating that I wanted to keep Wontache small. You dismissed that argument on the grounds that it is old. I countered that old age does not automatically make something less relevant. I mentioned Mustache as an example, but it was a rhetorical question. In my opinion, Mustache is still relevant, and I did not really expect an answer from you.

(...) pure components dont require HTML, only name and parameters, so no special renderer like React/Vue or mustache is needed. (...)

Do you mean the web components standard? Those still require a template containing HTML. Filling the <slot>s usually requires JavaScript as well. It is just replacing one template engine with another.

(...)

mustache is smaller than the second group, its easier to understand mustache than Vue for example. so it can be used to render initial state of the component, like:

<html>
<tag-here>...</tag-here>

<!--{component dataGrid
  data-source: "users-table"
  infinite-scroll: true
  display-max: 100
}-->

<tag-there>...</tag-there>
</html>

here i put imaginary lambda with argument that includes the name and simplified JSON parameters. that lambda and parameters can be also used in playground's data, actually it may be packed into a single textarea:

{{playground-data
  user:
    name: "Joe"
    age: 123
  flag: true
}}

{{#flag}}
  hello {{user.name}}, you are {{user.age}} years old!
{{/}}

should render to hello Joe, you are 123 years old!

I think I see what you mean, but I would not want to write the playground in this way. The mechanism you display does not help to separate concerns between model and view. The playground does use Mustache for the templates, but it uses Backbone for MVC.

Aside: you can already do something very similar to this with current standard Mustache and with the current playground.

{
    'playground-data': function(content) {
        var data = JSON.parse(content);
        for (key in data) this[key] = data[key];
        return '';
    }
}

{{#playground-data}}
{
  "user": {
    "name": "Joe",
    "age": 123
  },
  "flag": true
}
{{/playground-data}}

{{#flag}}
  hello {{user.name}}, you are {{user.age}} years old!
{{/flag}}

Savestate:

{"data":{"text":"{\n    'playground-data': function(content) {\n        var data = JSON.parse(content);\n        for (key in data) this[key] = data[key];\n        return '';\n    }\n}"},"templates":[{"name":"","text":"{{#playground-data}}\n{\n  \"user\": {\n    \"name\": \"Joe\",\n    \"age\": 123\n  },\n  \"flag\": true\n}\n{{/playground-data}}\n\n{{#flag}}\n  hello {{user.name}}, you are {{user.age}} years old!\n{{/flag}}"}]}

[agentgt]

@jgonggrijp You have been a fantastic steward of Mustache spec. I assume you still prefer Patreon for donations (I can't guarantee a lot as things have gotten a little tighter but I personally owe you greatly)?

As for the heated discussion mentioned in the post I think you did a great job on handling it and I am truly sorry that I lost my cool. My petty excuse is/was Covid brain. It pains me that I might have hurt the community. If there is anyway I can make up for it let me know.

Mustache is a critical component of my professional and personal software development. I use it for non HTML code generation frequently (the delimiter changing is super useful). I also use it for traditional HTML generation even if some thing that is a dead end I think there is still many that prefer server side rendering and using things like HTMX and Hotwired.

This coming year I plan on implementing filters in JMustache as branch first as it is easier since its runtime based and not compile time like JStachio which takes more work to do correct. I feel confident this is closer to the right direction (in spirit of Mustache).

Anyway I look forward to continued collaboration!

Cheers
-Adam

[jgonggrijp]

You have been a fantastic steward of Mustache spec.

Aww thanks! ❤️

I assume you still prefer Patreon for donations (...)?

Thanks for asking! I like Patreon, but you can also donate through GitHub if you prefer that. I also have Tidelift and StackAid, but both of those are restricted to Underscore and Backbone (for different reasons).

As for the heated discussion mentioned in the post I think you did a great job on handling it

I hope so. I welcome constructive feedback, so if at any point, you come up with a way I could have handled it better, please do not hesitate to let me know.

and I am truly sorry that I lost my cool. My petty excuse is/was Covid brain. It pains me that I might have hurt the community. If there is anyway I can make up for it let me know.

I think you already did; you have only made positive contributions otherwise.

Anyway I look forward to continued collaboration!

Likewise!

[determin1st]

Do you mean the web components standard? Those still require a template containing HTML. Filling the <slot>s usually requires JavaScript as well. It is just replacing one template engine with another.

's a really long out-of-standard out-of-mustache topic.. everybody want to represent components these days

I think I see what you mean, but I would not want to write the playground in this way. The mechanism you display does not help to separate concerns between model and view. The playground does use Mustache for the templates, but it uses Backbone for MVC.

Aside: you can already do something very similar to this with current standard Mustache and with the current playground.

imo, separation of concerns arent necessary for experimentation, the ease of use is more important.

{{#playground-data}}
{
  "user": {
    "name": "Joe",
    "age": 123
  },
  "flag": true
}
{{/playground-data}}

JSON is not enough, too hard to type by hand. yaml's better, coffescript object is even better

[jgonggrijp]

I meant implement the playground, as the creator. I now realize you didn't. I agree that you don't need MVC as a user of the playground. Then again, would typing everything into a single textbox really make things easier? How do you select which template to render in that case?

Entering the data in CoffeeScript notation is an interesting suggestion, though. I will consider that.