Expressive syntax vs. view preprocessing: how to strike a balance? #163
Replies: 2 comments 7 replies
-
|
Having a go at this myself, let me order some existing and hypothetical features from most purist at the top to most pragmatist at the bottom. (I did not put this in the opening post, because any such ordering is imprecise and subjective.)
I would say that 1-9 are essential to not make Mustache harder to use than necessary, while 15-22 are unreasonable. I think the balance is between 12 and 13: dynamic partials are still acceptable, skip syntax is not. As a guiding principle, I would propose that every new feature added to the language should multiply the possibilities but only increment the syntactic complexity and the cost of implementation. In other words, new features that reduce the need for preprocessing are acceptable in principle, but only if high orthogonality is preserved. Given multiple possible solutions for a problem, the most orthogonal option should be chosen. Filters (8) do really well in this regard: they open a million possibilities that are currently only possible with preprocessing, but they require only one new grammar rule and it is just a function call on the implementation side. The list nonemptiness key modifier (17) does very poorly: it solves only one problem, but still adds a rule to the grammar and a special case to the implementation. Virtual keys (14) are only marginally better than that. A single change to the parser can recognize all virtual keys, but each virtual key (for example |
Beta Was this translation helpful? Give feedback.
-
|
Starting from #153 (reply in thread), a few comments went a little bit sideways and were rather about the current discussion (#163). Quoted here for reasier reference:
I have to say I lean more towards the position of @spullara in this case. I understand that having to register a filter may be considered a barrier by some users, but look at it from the other side: Mustache has been around for 14 years. All that time, there has been no standard solution for first/last, with many implementations having no solution whatsoever other than data preprocessing (mine included). Despite that, it is the most widely ported templating language and it has a large and faithful crowd of users. I think that proves that Mustache's notational minimalism is appreciated and that many users are willing to give up some bells and whistles in exchange for that. I know I do. On top of that:
|
Beta Was this translation helpful? Give feedback.
-
Right. I did not mean to claim that we will certainly do a better job. Just saying that exploring may be worth it.
It is absolutely fine to have a minority opinion. The discussions are not meant to be democratic as far as I'm concerned. I even specifically disabled to default poll category for that reason. If you are the only one with a particular opinion, you should still be heard, because you might be able to convince others. Even if you don't, you might still inspire people in other ways.
Nice nuance. You're basically positioning safety as a third dimension besides expressiveness and minimalism. (Not meaning that as a criticism. I make it explicit because I find it interesting.)
How does JStachio currently signal that to the user?
I feel this is a strawman. Helping users is done by writing good documentation. Documentation should be clear about what cannot be done and about how to do what can be done. Whatever ends up in the spec does not preclude good documentation.
Nice punch under the belt there. 😉 But no, I already conceded that one in #155 (reply in thread).
It is rather bold to claim that first/last detection is the most common problem. But for the sake of argument, let us agree that it is common. I would say that whether the current element is the first or last element of the list, is a statement about that element (as well as about the list). Another way to put it, is that the first/last boolean is a derived value. Hence, first/last detection is a subset of the more general problem of derived values. By extension, the derived values problem is more common than the first/last detection problem alone. I honestly think that filters are a very easy solution to the derived values problem. What is a more straightforward way to obtain a derived value than calling a function? The idea of using filters to derive values is not completely new or alien, either. There are other templating languages that do it as well. Jinja and Angular come to mind immediately, because I have used them. I'm not saying your argument is wrong, but I disagree it necessarily leads to virtual keys. I just demonstrated it can be used to argue for filters as well. |
Beta Was this translation helpful? Give feedback.
-
|
Mustache is like JSON to me. Very simple with very little to learn. Of course there are reasons for something insanely complex like XML, YAML, etc. but that doesn't mean we need to reach feature parity with them. Mustache, the JSON of template languages has a nice ring to it. |
Beta Was this translation helpful? Give feedback.
-
|
@spullara Thanks for that way of comparing Mustache to another domain. I find it inspiring. I find JSON, while minimal, not nearly as pleasant to write compared to Mustache. I also don't think that a JSON of template languages would have partials, lambdas or a way to change delimiters. I agree that the syntactic simplicity is similar, but on the semantic level, Mustache is much more powerful. I feel that Mustache is more efficient in squeezing as much expressivity out of as little syntax as possible. How about the Scheme of template languages? It has a simple, consistent, declarative and explicit syntax, too. It also has very powerful abstractions underlying that syntax. Mustache is perhaps not as expressive as Scheme yet, but I think that relatively minor tweaks to the syntax could lift it to that level (relative to the maximum attainable expressiveness for template languages, at least). |
Beta Was this translation helpful? Give feedback.
-
|
@jgonggrijp I agree that Mustache is better characterized as Scheme. I like Schema a lot. I used it in 1999 and had some minor impacts on it. I also used XSLT which I would characterize as the XML of templating. I don't think there is a JSON analog and I don't think Mustache is equivalent. I'm almost fully on board with filters. While I would like to keep Mustache as simple as possible and while I agree with @jgonggrijp that it has served people well for 15 years that doesn't mean the language can or should not grow. I know I pushed virtual keys hard and I'm probably the "bells and whistle guy" now (btw I meant the cherry pick of i18next as playful teasing... at least you are not the bells and whistles guy 😄 ). I did that because Scheme had a hard uptake because of missing features but I still think it was mostly successful. Anyway I think filters are needed to keep the language growing whether that is by new users or new problems. I think it should have been the original lambda. And I meant what I said about living in a vacuum. The same challenges and problems 15 years ago are not the same as today. If we do not evolve we die. Guy Steele - the creator of Scheme: https://youtu.be/lw6TaiXzHAE?t=762 BTW @jgonggrijp you will appreciate rewinding back a little on his thoughts on English language given our friend who is concerned with that. |
Beta Was this translation helpful? Give feedback.
-
No worries, I took no offense. Also, there is nothing wrong with being the bells and whistles guy!
"Growing a language". Awesome talk! Funny, inspiring and relevant. I recommend watching it to anyone who has not clicked that link yet. |
Beta Was this translation helpful? Give feedback.
-
Since the start of the spec's existence, this topic has come up in nearly every discussion. It touches on the soul of the Mustache language, or at least what various people think that soul should be. If we could form a consensus around some kind of explicit principle, I think that would help to guide future decisions.
We have a spectrum between two extremes, which I dub "purist" and "pragmatist". A purist prefers a minimalist grammar and preprocessing the data before feeding them to the template. A pragmatist prefers an expressive grammar and not needing to preprocess the data.
The killer argument for the purist side is that Mustache distinguishes itself from other template languages by having a minimalist and logic-free grammar. If users want bells and whistles, they have many other options to choose from. Mustache should not become like Handlebars, ERB or Jinja; that would defeat the point of the language.
The killer argument for the pragmatist side is that template authors are not always in control of the input data. @agentgt formulated it well in #147 (comment):
A radical purist might believe that lambdas should never have made it into the language. A radical pragmatist might believe that Mustache needs syntax for literal values, string operations and arithmetic expressions.
I would like to formulate the central question of this discussion as follows: where on this spectrum should Mustache try to be?
In our answers, let us appreciate that both killer arguments are true at the same time: minimalism is one of the main features that make Mustache unique and template authors are not always in control of the input data. We will be making a tradeoff, regardless of where we position ourselves on the spectrum.
Beta Was this translation helpful? Give feedback.
All reactions