>Chyba miało być overview, a nie overwiev :P
Miało, miało.

>Mam poważne wątpliwości czy ktoś takiego systemu szablonów by używał, w poważnym projekcie.
Ale przecież to już jest używane ;) I to przez samych twórców HTML5 – https://github.com/ThePacielloGroup/html5-h

>Największą zaletą szablonów jest prosty podział obowiązków. Backend backendem, a frontend sobie, wystarczy tylko dostarczyć info o renderowanych do widoku zmiennych.
Obecnie słowo backend oznacza tylko i wyłącznie REST API dla większości aplikacji. Cały frontend Twittera opiera się na takiej zasadzie (Twitter.com jest klientem własnego API OAuth). To samo widać na FB (React.js i stworzenie abstrakcyjnego DOM). Co więcej, WebComponents przecież nie wprowadzają żadnego nowego pomysłu tutaj (aka mustache czy hogan) – serwer jedynie dostarcza danych a całe składanie odbywa się przecież na kliencie (Angular i Backbone działają identycznie). Jedyną różnicą między template a starodawnymi systemami szablonów jest fakt, że template operuje na DOM, reszta na stringach (lub abstrakcjach, jak React).

>Dodatkowe zapytanie o naszwypasionycustomelement.html, w praktyce daleko temu do $view->render(’naszwypasionycustomelement.html’) – a zawsze i argumenty będzie można podać, albo jakiś {include file=’naszwypasionycustomelement.html’} ze Smarty czy innego Twiga.
Twig jest przeportowany do JS i można go używać także po client side ;) Lekka rozbudowa tagu template (jak np ta, zaimplementowana w Polymer) pozwala także na taki binding w template. Jeśli serwer służy tylko do udostępniania danych dla aplikacji, to szablony leżą u klienta. W przypadku obecnej Sieci, gdzie coraz większy nacisk kładzie się na techniki offline first i no backend, jest to naturalne. I znów: mustache robi tak od wieków.

>Przyznacie sami, że dużo przyjemniejsze będzie np: data-ng-bind-html=”tplFactory(’tpl-name’, {arg1: 'foo’, arg2: 'bar’})”, które znamy z AngularJS.
Angular to akurat bardzo zły przykład, bo Angular 2.0 będzie opierał się na Polymer i wszystkie jego komponenty będą Web Componentami ;) http://www.2ality.com/2014/07/angularjs-vs-polymer.html (no bo po co wymyślać koło od nowa, skoro istnieje standard od tego?)
Zresztą to zależy od preferencji programisty. Mnie łatwiej się jednak pracuje z szablonami deklaratywnymi.

Mam wrażenie, że ograniczasz Web Components tylko i wyłącznie do systemu szablonów a to tylko wierzchołek góry lodowej. Prawdziwą potęgą jest ich modularność i reużywalność, połączona praktycznie z maksymalną hermetyzacją. To jest natywny mechanizm, implementujący eventowy model aplikacji, zaprezentowany przez Zakasa: http://www.slideshare.net/nzakas/scalable-javascript-application-architecture każdy element jest niezależnym modułem, który z resztą komunikuje się eventami/systemem pub-sub.

>Web Components to fajna idea, ale tak naprawdę nie wnosi specjalnie nic nowego dla użytkownika.
Super… ale od kiedy technologie internetowe związane z architekturą Sieci były przeznaczone dla użytkowników? ;) One są przeznaczone dla developerów, żeby mogli w łatwiejszy dla nich sposób dostarczać lepszy UX userom. I tylko to dla końcowego usera się liczy – a nie sposób przygotowania dania. Natomiast developerzy bardzo pozytywnie odbierają Web Components. Jedyne obawy z nimi związane to tak naprawdę semantyka i dostępność.

>Wszystko co można osiągnąć za pomocą Web Components można zrobić na dziś dzień używając HTMl5 i JS – mniej elegancko, ale nadal
Zapominasz o bardzo ważnych dwóch kwestiach: o natywności rozwiązania i jego standaryzacji. Mamy jeden, zunifikowany sposób robienia pewnych rzeczy. Na podstawie takiego standardu można zbudować rozwiązanie, które będzie działać wszędzie (a przy pomocy polyfillów de facto już działa). No i oczywiście, że można ;) Web Components powstały na bazie najpopularniejszych praktyk – to jeden z niewielu *realnych* standardów od W3C.

>Skutecznie Web Components będą blokować smartfony i tablety z Androidem, które często mają przeglądarkę na starszej o kilka wersji Chromium, a producent aktualizacji nie przewiduje.
Polyfill (wspomniane w artykule Polymer i X-Tags to najpopularniejsze) i już. Poza tym – na większości fonów z nowszym andkiem i tak raczej jest zainstalowany Google Chrome a on już aktualizacje dostaje ;) Cała reszta dostanie bardzo porządny polyfill, pozwalający używać tej funkcjonalności wszędzie (no hej, przecież cały czas tak robimy i działa!). Jedyną rzeczą, jaka od zawsze powstrzymywała HTML5 przed ogólną adaptacją, jest wciąż dychające IE9-. I tutaj upatrywałbym głównego zmartwienia.

Mam poważne wątpliwości czy ktoś takiego systemu szablonów by używał, w poważnym projekcie. Największą zaletą szablonów jest prosty podział obowiązków. Backend backendem, a frontend sobie, wystarczy tylko dostarczyć info o renderowanych do widoku zmiennych. IMO szablony frontendowe to trochę przerost formy nad treścią. Dodatkowe zapytanie o naszwypasionycustomelement.html, w praktyce daleko temu do $view->render(’naszwypasionycustomelement.html’) – a zawsze i argumenty będzie można podać, albo jakiś {include file=’naszwypasionycustomelement.html’} ze Smarty czy innego Twiga.

Przyznacie sami, że dużo przyjemniejsze będzie np: data-ng-bind-html=tplFactory(’tpl-name’, {arg1: 'foo’, arg2: 'bar’}), które znamy z AngularJS. (przykład wymyślony na potrzebę komentarza)

Co do przyszłości aplikacji sieciowych to raczej wypatrywał bym jej gdzieś w warstwie OSI, bo patrząc prawdzie w oczy użytkownik ma gdzieś jak ten element został wstawiony, tag video nigdy nie robił na nim żadnego wrażenia, bo użytkownik od dawna miał już konto na YT… Web Components to fajna idea, ale tak na prawdę nie wnosi specjalnie nic nowego dla użytkownika. Możemy się zachwycić Polymerem, pewnie, ale to raczej wisienka do tortu niż „przyszłość”. Wszystko co można osiągnąć za pomocą Web Components można zrobić na dziś dzień używając HTMl5 i JS. Skutecznie Web Components będą blokować smartfony i tablety z Androidem, które często mają przeglądarkę na starszej o kilka wersji Chromium, a producent aktualizacji nie przewiduje.

>Może kiedyś
Miałem to samo podejście… aż przez przypadek wsiąkłem ;) Na samym początku wydaje się to całkowicie bzdurną ideą, lecz po bliższym przyjrzeniu jednak to przekonuje.
No i najważniejsze: to działa. Istnieją już nawet bardzo sensowne projekty oparte na tym, np http://onsenui.io/