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/d6d33ac7/attachment-0001.html>

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: