Template strings as a template language.

Andrea Giammarchi andrea.giammarchi at gmail.com
Tue Sep 15 07:27:22 UTC 2015


Bob, not sure why you think template means HTML, in my case the main
problem I have in JS is the absence of basic `printf` like syntax so that I
can build at runtime any kind of i18n string passing an object, without
needing to have the string evaluated in place, which is the strength of ES6
templates when it comes to server side and tooling tasks, but completely
overhead and non i18n friendly on the client side.

Since printf for some reason has never landed in JS but we have a
lightweight eval through `${this}` I've recycled the syntax and semantics
expected by ES6 templates and tags in order to be able to use any sort of
source of data for those values within curly brackets.

TL;DR it amuses me how much people still relate JS strictly with the Web
and the HTML in this era of Internet of Things, drones, nodejs nashorn,
espruino, kinomajs and all other JS engines that don't even necessarily
need to know what is HTML and wouldn't benefit a single bit from the good
old E4X or the current React thing

So if template should be, please let's think about an agnostic one and
de-couple JS from HTML as much as possible, thank you.

Regards





On Tue, Sep 15, 2015 at 7:16 AM, Bob Myers <rtm at gol.com> wrote:

> May be getting off-topic here, but I wonder why we need templating
> languages at all in this day and age. Originally templating systems were
> developed for server-centric applications such as PHP etc. which generate
> HTML and blast it down to the client, as a way to untangle program logic
> and display logic and get away from madness such as `<p><? $post.text
> ?></p>` or much, much worse.
>
> When people starting writing client-side frameworks such as Ember etc.,
> they brought over the notion of template languages without much thought, if
> I may say so. The client has perfectly good mechanisms for creating HTML
> with JS, that with bits of sugar are just as expressive as a template.
> Actually more expressive, because I can use arbitrary JS in my element
> creation, not just those constructs which the template language designer
> deigned to provide to me.
>
> Template languages bring in an entire new set of programming constructs,
> such as conditionals, loops, and computations, which duplicate those
> already present in JS. So if I want to loop in JS I use `forEach`, but if I
> want to loop in my template language I have to use `{{#each}}`. Some
> templating languages even provide the equivalent of function calls with
> their own weird syntax and some now support currying (!). For religious
> reasons, some templating languages limit the amount of computation that can
> be done within the template, so if I want to do something as simple as add
> one to a value, I have to precalculate that in my program logic and include
> the value in the scope passed to the template.
>
> It's weird when you think about it: We have a template which is for all
> practical purposes a big string, then we do what is essentially a kind of
> macro pre-processing of the string, then we feed the string into the DOM
> with `innerHTML` or whatever which requires parsing it again.
>
> And what happens if a value changes? In the worst case, we have to
> re-evaluate the entire template, and replace the entire result in the DOM.
> Now some templating implementations are developing ways to incrementally
> update the template and proclaiming loudly that they have invented an
> amazing new wheel. But if we dealt with the DOM directly via JS without the
> intermediation of templates, it would be trivial to update the DOM when
> something changed.
>
> What's more, a new language like templates brings with it an entire new
> toolchain. We now need ways to compile these templates, and lint these
> templates, and debug these templates, bringing yet another level of
> complexity into our build systems.
>
> In React.js, we see an interesting evolution of the entire notion of
> constructing the DOM. As I understand it, elements are created directly
> within JS, as in my opinion they should be. To avoid having to write `var
> foo =
> document.createElement('div').appendChild(document.createTextElement('bar'))`,
> it makes HTML syntax directly available from within JS, So you can say `var
> foo = <div>bar</div>;`. It may horrify some purists, and it does introduce
> another step in the build chain, but it's a great improvement over
> templates IMHO.
>
> One interesting client-side framework called Mithril does away with
> templates entirely and creates DOM nodes via JS via sugar routines such as
> `var foo = m("div", "bar");`. Works for me.
>
> So rather than attempting to figure out how the ES6 template string hammer
> can be used to pound in the templating system nail, I'd ask instead why we
> need to pound in that nail at all.
>
> Bob
>
>
>
> On Tue, Sep 15, 2015 at 10:54 AM, Thomas <thomasjamesfoster at bigpond.com>
> wrote:
>
>> With all due respect to your solution (it works, and it works well), it's
>> far from ideal to be relying upon `with` and Function. I guess what I'm
>> trying to get at is - wouldn't it be better to think about having a built
>> in version that didn't use with or eval (should be easy enough)? I sense
>> that you're not confident about it being successful in that sense, but a
>> built in function for this trumps with and Function any day of the week.
>>
>> Thomas
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150915/a73cc7c7/attachment.html>


More information about the es-discuss mailing list