Re: [w3c/webcomponents] [templates] Ensure that template instantiation actually improves the platform (#704)

@rniwa 

The main problem with template instantiation proposal is that it attempts to solve a symptom, not provide the cure for the cause.

And there are two causes: 

- no declarative API for DOM APIs
- no data binding mechanism

As all compromises, template instantiation proposal solves both poorly.

> JS. For us, the main benefit of this proposal is that it paves a way to come up with a declarative syntax for custom elements. 
> It also provides a useful mechanism for template libraries to update different parts of DOM easily. 

This "syntax" already exists, and has been battle proven over several years on thousands of web sites. As is the ability to efficiently and easily update different parts of the DOM.

And it looks more or less like this:
    
```js
h('div', 
   { 
        attrs: { className: "x" }, 
        props: { duration: y }, 
        on: { click: () => z()  }
   }, 
   [ h(...), h(...) ]
);
```

Yes. It's virtual DOM, popularised by React, and which exists as [virtual-dom](https://github.com/Matt-Esch/virtual-dom), [hyperscript](https://github.com/hyperhype/hyperscript) etc. There are differences in the APIs between these libraries, but they are quite superficial, and they more or less converged on the same set of principles:

- declarative API that is pure JS, no external dependencies, no templates, just functions
- the API is essentially `f( tag, { props, attrs, events, lifecycle }, [children])` which is easy to reason about, easy to analyse, debug, optimise
- it solves about 100% of Web Component's data binding woes
- it solves the whole "we don't know how to provide a declarative API for WebComponents" because it also solves "we will provide a unified consistent API for all of HTML/DOM, not just WebComponents"
- it solves server-side rendering

Meanwhile templates... I don't know what actual issues do they solve? They introduce way more problems than it's worth:

- somehow only limited to template instantiation inside custom elements. Why not use them for the rest of the DOM?
- is a new templating language:
  - has no relation to the rest of the browser
  - needs a separate parser and execution model (not a small chunk of work in itself + an increased attack surface)
  - as all templating languages will be limited (so, limited control structures, limitations on what you can call from the host environment, poor and limited available standard library, if any)
  - only provides an imperative API to work with from JS that's no better and no easier than existing DOM APIs:
  ``` js
  // before
  var X = template.getElementById("#part");
  X.appendChild(document.createElement('span'));
  X.appendChild(document.createTextNode('hello'));

  // after
  var X = template.getRequiredTemplatePartSomehow();
  X.replace([document.createElement('span'), 'hello']);
  ```

  The vast majority of the web isn't even using DOM APIs with Web Components, and goes straight for  `.innerHtml` (even lit-html [does that with reckless abandon](https://github.com/Polymer/lit-html/blob/master/src/lib/template-result.ts#L77)). Given that the template proposal doesn't really add any new easy-to-use APIs, it will still be easier to drop to `.innerHTML` or reach for any of the virtual dom libraries out there than use the templates.

In my opinion, the templating proposal has its value to show some the problems that people experience with Web Components, but can never be a solution. The solution lies in better, easier-to-use declarative DOM APIs.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webcomponents/issues/704#issuecomment-474966905