Status of templates and component representation in 3.x?

64 views
Skip to first unread message

Joern Turner

unread,
Mar 1, 2018, 5:05:31 AM3/1/18
to Polymer
Hi,

biggest noticable change in 3.x from 2.x is the complete loss of the declarative approach for templates.

I critizised that before and got the encouraging answer that there are many people behind me in seeing the declarative approach as important.

Looking at the latest blog article an the example template function the horror returned ;)

I keep on nagging on this - IMHO shifting from HTML to JavaScript for the representation of a Web Component is to state it mildly 'very unlucky'.

I know the Polymer team is following the current state of the discussion in the (upcoming) standard but nevertheless the point remains: if
Polymer and Web Components take this direction IMO Web Components loose a major selling point and are hardly better than many of the JS frameworks we've seen
over the years. While the representation change seems to be hard to resist (sometimes i hate democracy ;) there should be at least some way to keep the template declarative.

I know the work of standard comitees so i do not blame the Polymer team at all. However the decision - obviously triggered by the move to js module loaders - is a technological decision and
not a design or architecture-driven one. That's a poor approach especially considering the intended long-term relevance of a W3C standard.

So, first i'd like to know how the current debate is going and apologize if this is not the right place to ask.

Second - is there any more appropriate list at the W3C where i can throw in my 2 cents? The W3C page does not reveal much at first sight and i'm missing up-to-date minutes as well as latest drafts.

Thanks a lot.

Joern

Aaron Anderson

unread,
Mar 3, 2018, 12:04:19 PM3/3/18
to Polymer
I echo your sentiments. I use the Atom and it's linter to edit my Polymer HTML templates and I don't know if it will work with html template literals. 

I am using Polymer in a Java web application with no Javascript build framework. I simply update my Polymer components and refresh the page to immediately see the updates which is extremely productive for me. Adding in a preprocessor to convert HTML files into Javascript literals is unacceptable to me.

I hope Google keeps the html import functionality in both Polymer and Chrome until an official web standard can be worked out. I am using Polymer for an internal application and making it Chrome only is fine with me. 

It boggles my mind that after 26 years of the web and a decade after AJAX there is still no standard way of dynamically loading HTML files and JavaScript innerHTML is the only solution.

Kito Mann

unread,
Mar 5, 2018, 12:25:34 PM3/5/18
to Joern Turner, Polymer
+1

I think loosing support for templates is a big blow to productivity, although I certainly see the benefits of LitHTML. It's clear that people like templates -- that's why Angular, React, and even Stencil offer them.

I'd be happy with a preprocessor, though...

___

Kito D. Mann | @kito99 | Java Champion | LinkedIn
Expert training and consulting: PrimeFaces, PrimeNG, JSF, Java EE, Polymer, Web Components, Angular
Virtua, Inc. | virtua.tech 
JSFCentral.com | @jsfcentral 

* Listen to the Enterprise Java Newscast: http://enterprisejavanews.com



Follow Polymer on Google+: plus.google.com/107187849809354688692
---
You received this message because you are subscribed to the Google Groups "Polymer" group.
To unsubscribe from this group and stop receiving emails from it, send an email to polymer-dev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/c82033fc-73dd-47df-9f9e-be9e432ba22e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply all
Reply to author
Forward
0 new messages