More compact notation for binding?

[bahrus]

I can live with this apparent shortcoming (in my view) of Polymer, because of its other nice features, but what is the reasoning behind the (increasingly) verbose syntax needed for binding?

<dom-repeat items="{{items}}">
  <template>...</template>
</dom-repeat>

I understand some of that verbosity is attributable to lack of support for the "is" attribute. Is there really no alternative?

I bring it up after reading this article, which reminds me of this one.

The verbosity of React is similar to the verbosity of Template literals, and Polymer 1, and xslt, so it's okay, I guess. Isn't this even worse?

Is the need for the template inside there just to gain a little more performance? Or to hide the unformatted content? Both? If just the latter, wouldn't it be sufficient to use the hidden attribute on the dom-repeat element?

Is there no way to support binding inside an actual built-in element, the way angular / vue.js do?

It would be great if Polymer 2 could provide pluggable binding engines (or none at all), so developers could chose the right one for the right job (possibly weighing factors between performance vs verbosity vs standards compliance vs code dependency size?)

[arthurevans]

This change is entirely due to the fact that we don't expect all browsers that implement custom elements to support is (a.k.a. "customized built-in elements"). Building dom-repeat and friends using is would force people to use a polyfill even on browsers that support native custom elements.

That is a possible alternative (for example, delivering a small, separate polyfill just for is elements).

Note that in 2.x preview, you don't need to use the more verbose format in most cases: inside an element's template or dom-bind template, you can use the old-style is format and Polymer makes it work.

You only need the more verbose format for top-level templates (dom-bind, for example).

Angular and Vue can do different things because they are (AFAIK) frameworks that control the entire page. Polymer isn't doing this. You inject Polymer functionality into each element you build with Polymer. (That's why you see apps built with either a top-level my-app type element or a top-level dom-bind template to wire things together.)

[bahrus]

Thanks for the explanation.

A little bit of extra verbosity at top level nodes, the first place Polymer gets invoked in the tree, probably isn't too bad. It seems to be consistent with other web components like amp. But at the risk of beating a dead horse: inside the top level nodes, where Polymer basically takes control within the Polymer based components, aren't you free to invent any syntax you want? Couldn't you then inject Polymer functionality into each element?:

<dom-if if="{{test}}">
         <template>
              <ul>
                 <li is="dom-repeat" repeat="item in items">{{item}}</li>
              </ul>
        </template>
  </dom-if>

Any further explanation would be appreciated. Feel free to close either way. Just my two cents.

[bahrus]

I raised another issue that is related to this... Assuming Polymer 2 has the equivalent of the

<template is="dom-bind">

helper element, it would be nice if a template tag is not required inside the

<dom-bind> 

(I asssume) tag. This would allow progressive enhancement to work well in many cases -- by requiring the template inner tag, browsers won't render anything inside until Polymer is fully loaded. I guess it would be nice if the template is not required for the dom-if or dom-repeat tags, though the use cases may be less in that case.

[sorvell]

The compact <template is="dom-repeat"> syntax is being retained in Polymer 2.x as explained here.