Re: [webcomponents] HTML Parsing and the <template> element

On Tue, Apr 24, 2012 at 1:50 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> On Tue, Apr 24, 2012 at 10:14 AM, Brian Kardell <bkardell@gmail.com> wrote:
>> On Tue, Apr 24, 2012 at 12:45 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>>> On Tue, Apr 24, 2012 at 9:12 AM, Clint Hill <clint.hill@gmail.com> wrote:
>>>> Hmm. I have to say that I disagree that your example below shows a
>>>> template within a template. That is IMO 1 template wherein there is
>>>> iteration syntax.
>>>
>>> The "iteration syntax" is basically an element - the example that Arv
>>> gave even used element-like syntax, with open and close tags.  That
>>> iteration element is inside of a template.
>>
>> But in his example, and most of the ones people have been citing or
>> really want to use this for they are  no tags in the HTML sense...
>> Those are handlebars (or mustache or dust or haml or whatever)
> [snip further comments along similar lines]
>
> As long as it's handlebars that merely *look* like elements, we have
> to ship code down the wire that is simply a functional replacement for
> the DOM that the user already has.  This is suboptimal.  It's a
> cowpath that only curves this way because the straighter path was
> blocked by a boulder, and cows don't have dynamite.  We do.

I do not think it is an entirely accurate statement to say the path
only curves this way because the straighter path was blocked by a
boulder.  There is pretty much nothing preventing existing templating
languages (client or server) from looking (inside) just like has been
suggested, and yet the most popular ones generally don't do that...
Instead, we use things for instructions/controls/macros/etc that
purposely don't look like HTML specifically to call them out as
different because that increases readability and maintainability - and
it makes them not use-specific (I can use them to generate anything,
not just DOM).  Personally, I prefer it that way - but maybe that's
just me?  It does seem to be the case that many people are talking
about though -- using those libraries with the <template> tag... Maybe
they can chime in... I am very interested though in knowing whether
this would essentially be a case of "allowed/works, but discouraged".

I do agree that it is less optimal in the sense that you have to
lex/parse/etc but that also means there is a lot of room for
competition in variants which I think is a good thing in general.  If
things get so tight as to require that the <template> tag identifies
iterators, etc as well (by way of data-* attributes) - I think that
would limit the competition for templating languages to very close to
1.  At that point, might as well go ahead and define it.  At that
point - it also seems salty enough to my taste to want to trade a few
ms for something I like more... Does anyone have any kinds of metrics
illustrating just how much better optimized this would be by
comparison?  I've used templating a lot and honestly, I've never found
it to be the bottleneck or the problem.

All that said,  maybe with some time and experience I could learn to
love it as DOM too... I'm really not trying to be the only one arguing
endlessly about it, so unless someone backs me up on at least some
point here I will rest my case :)

-Brian

Received on Tuesday, 24 April 2012 18:41:12 UTC