Web Components - where are you heading (Polymer 3 blues)?

62 views
Skip to first unread message

Joern Turner

unread,
May 14, 2018, 11:04:16 AM5/14/18
to Polymer
First of all - congrats to the new release.

I'd like to thank for the marvelous work of the Polymer team during the last years.

I've complained here before and i know that's it's not the right address but i hope that somehow these words find the way into the discussions elsewhere:

when i consider Polymer 3 i mainly see a huge paradigm shift  - and - sorry to say that - for me personally i don' t like it. Maybe my understanding of a
Web Component was blurred by my personal wishes but i my view a Web Component is a custom-element with behavior and styling. This has been true before Polymer 3 -
we had a single file containing a component with all their parts in a natural representation - HTML being HTML, CSS being CSS and JS ... you got it.

Now JS has taken over and a lot of the initial charme has gone - what about 'there is an element...' idea? Instead this has been eaten by (i guess) performance and efficiency
considerations that push ES6 in front. Now we end up with the maybe more efficient but awful template literals that are a big productivity drawback - my IDE does not support syntax coloring,
pretty-printing and inspection inside of literals.

That much for the architectural view but IMHO this is a major stepback. I'm aware that the Polymer templating was an extra given on-top
but i heavily used (and will use) Polymer 2 for exactly that reason. It feels good and natural to work that way - defining an element as what it is: an element and using that as a container of all its aspects.

At this very moment i don't see much reason to switch to Polymer 3 - i have pure ES6-style Polymer 2 applications running and i guess i'll continue on that track until hopefully there'll come a better solution
that somehow allows for descriptive templates again. Sorry - LitElement doesn't look like a future friend of mine.

Again - i'm aware that the Polymer team is somehow bound to follow the development of the specs - i've been there myself before and in my experience not every decision of standards commitees are right.

Sorry for the somehow negative criticism but i'm a enthusiastic user of Web Components and Polymer and i have a position to defend inside of our small company.

Thanks for listening,

Joern

Mark

unread,
May 14, 2018, 9:40:38 PM5/14/18
to Joern Turner, Polymer
Hey Joern,

Although you have valid points, I'm afraid your message may not get much visibility on this thread. I believe your comments may be better served on the pull request that officially introduces Polymer 3 to the world here: https://github.com/Polymer/project/pull/46. There was also another discussion on that same polymer github repository, but I can't find it at the moment.

Good luck, and I'm sorry the Polymer future has disappointed you :(

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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/f757bc87-bad2-4ced-8f71-90d5dfe21913%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--

mark

Justin Fagnani

unread,
May 14, 2018, 10:43:30 PM5/14/18
to ma...@heyimmark.com, joern....@gmail.com, polymer-dev
Joern,

I'm sorry for your disappointment. You're not alone and we hear you. But I do think that a lot of the concerns you mentioned come from a slight misalignment of exactly what _has_ changed from Polymer 2.x to 3.0, and what has been _perceived_ to change from Polymer 2.x to 3.0.

First of all Web Components have not changed at all. They are an HTML standard and don't change when Polymer does. This means that all APIs for defining and consuming Web Components are 100% exactly the same as they were before. And the Web Components APIs have always been JavaScript centric for defining Custom Elements - from extending HTMLElement, to the lifecycle callbacks, to customElements.define(). And the APIs for consuming Custom Elements are the same, whether via markup, or script.

I understand that a lot of people were drawn to Polymer because of the HTML format, but Polymer has primarily been focused on enabling the easy authoring and consumption of Web Components and that remains the focus. HTML Imports were dead in the water and we had to move to a natively supported format so we didn't require polyfills indefinitely even on browsers that were natively implementing Web Components.

Second, Polymer has always been a nearly 100% JavaScript-based library. We've had people say they liked Polymer because it was HTML-based, but Polymer's HTML only contained <script> tags.

Third, Elements defined with Polymer have always been a combination of JavaScript and HTML. In Polymer 2.x, those languages were both put in an .html file, and in Polymer 3.0, they're put in a .js file. But the individual lines of code, and the division between HTML and JavaScript, are again nearly 100% identical - they're just in a different order. Even in Polymer 2.x you had to write plenty of script, including the critical script that defined and registered your elements. Only the templates were actually HTML.

Polymer 3.0 and all the 3.0 elements were automatically generated from their 2.x counterparts. They are that similar.

Lastly, we hope the situation where you have to define elements in .js files is only temporary. We're working on a successor to HTML Imports that integrates cleanly with JS modules called HTML Modules. You can follow the standards issue here: https://github.com/w3c/webcomponents/issues/645 and there will be more updates soon.

When that's in place you're be able to choose what file type you want to author components in, and consumers can in turn choose what file type they'll import your component into.

Again though, I want to emphasize that not much has changed besides the file extensions. I hope if you hang on there you'll get a fully native development target that supports authoring templates in "real" HTML like you want.

Hope that helps a bit. Cheers,
  Justin



Reply all
Reply to author
Forward
0 new messages