Polymer 3 - seriously get back to string jungle?

[Joern Turner]

Hi,

just read the blog article "

Hands-on with the Polymer 3.0 preview"

To start with: i'm a huge fan of Polymer and trying to push it whereever i can in our projects. I appreciate the hard work of all developers of that fantastic project.

In that light please allow me some criticism:

Seems that Polymer 3 is bringing another toolchain with it again (yarn). Polymer tools are fine and you want them for productivity. I'm not opposed to learn new things when they bring significant value. However having to learn a new way of doing things with every major release is also a burden for each Polymer user that doesn't eat every newest tool for breakfast. - would be great if you guys give it a thought next time.

But now for the important things:

i can live with the removal of link imports though i personally liked them but another syntax does equally well here.

But i'm kind of shocked by the prospect that Polymer 3 seems to drop declarative templates in favor of string jungle. Imagining to build complex templates as strings gives me a shiver and makes me doubt about all the work i put into Polymer 2 apps now. 

IMO HTML templates are one major selling point for me to work with Polymer (and to convince others of the innovation Polymer brings). I don't want to imagine bulding complex templates with strings.

Furthermore - turning the representation into a pure javascript one does harm the component metaphor IMHO. A compoment (of course my view of things) is built on-top of a custom HTML Element. As such it's natural that a web component is a html snippet. I always especially liked that about Polymer. And wasn't there something like "everything is an element" slogan? Is that deprecated? Sorry but representing an element as a ES6 module doesn't feel like the 'next generation' but more like 'yet another JS framework'.  Always speaking for myself - but this is a big step backward.

Sorry if my complaint directs in the wrong direction - i don't follow the W3C Web Component group, Apologies in that case.

As i doubt that my personal opinion will influence the flow of things here's my question: will there be any way to work with declarative templates in the longer term? Maybe as an option?

What about CSS and ES6 modules? No example of that in the blog post?

Lots of questions and complaints i know but i would really appreciate your opinions/comments.

Joern

[Joern Turner]

Really? Nobody?

Is this the wrong place to ask/discuss design questions or am i asking too much at once? Nobody else concerned about such questions? I would be really thankful if anybody could point me to the right location to ask such questions.

Again - i'm an enthusiastic user of Polymer 2 and do quite a lot of applications with it but i'd like to learn about where actually Polymer project is heading and to unserstand the choices. Otherwise it's getting very hard to commit to it and to see if it's still a fit to my needs.

Any comments welcome.

-Joern

[C Mcc]

Joern,

There are various 'slack' channels for polymer-related discussions.  Here is one related to polymer 3.0.  https://polymer.slack.com/messages/C6SLBGSHJ/details/ ... perhaps some of the core developers might be more responsive on there.

Good luck,

Colum

[Arthur Evans]

Hi Jeorn,

Sorry, I missed the original message over the weekend.

To answer your questions: yes, there's a lot of interest in a declarative templates (a.k.a., "writing HTML in HTML"). Many of the team members feel the same way you do. We'd love to see a solution—ideally a standards-based solution that doesn't require a build step. There is currently a standards discussion around "HTML modules", but it's somewhat unclear how that will play out. The minimal case would _only_ allow you to define HTML in an HTML module. A more elaborate version would allow script to be embedded in the module, as well, allowing single-file components like we have in Polymer 2.

But right now, we don't have a standard way to import HTML. What we have is a standard way to import JS, in the form ES6 modules. This is a case where our desire to have declarative elements is at odds with our desire to produce standards-based solutions—ideally ones that don't require a build step.

The Polymer 3 preview is a minimal viable version of Polymer in ES6 modules. In the short term, any HTML-in-HTML solution is going to require a polyfill or build step, since HTML modules aren't defined yet.

As far as the Bower => yarn transition, that's forced on us by the deprecation of Bower. We've had many, many requests to make Polymer available through the npm registry even before Bower was deprecated. It's also the dominant package registry and so it was the logical choice for us. The tools team has been thinking very long and hard about how to transition to the npm registry, and until yarn came along, they couldn't see a way clear to do it without building another, custom tool to manage webcomponents-via-npm. I realize that a new tool is always a pain, but just to be clear—this particular change wasn't made without a fair amount of thought. And we'll be continuing to work with the community to work out the details of this story. 

Hope that helps a little bit.

If you haven't read it, we also go into the rationale behind this change in a previous blog post: https://www.polymer-project.org/blog/2017-08-22-npm-modules.html

Finally, I'd encourage you to join the discussion on Slack.

Cheers,

Arthur

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/3d64dcb3-b708-4bb3-82b3-104a0fba1b05%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Joern Turner]

Hi Arthur,

thanks a lot for your detailed answer.

Am Dienstag, 12. September 2017 22:41:40 UTC+2 schrieb arthure:

Hi Jeorn,

Sorry, I missed the original message over the weekend.

To answer your questions: yes, there's a lot of interest in a declarative templates (a.k.a., "writing HTML in HTML"). Many of the team members feel the same way you do. We'd love to see a solution—ideally a standards-based solution that doesn't require a build step. There is currently a standards discussion around "HTML modules", but it's somewhat unclear how that will play out. The minimal case would _only_ allow you to define HTML in an HTML module. A more elaborate version would allow script to be embedded in the module, as well, allowing single-file components like we have in Polymer 2.

 It's a relief to hear that i'm not alone with my point of view.  I've been waiting for such a solution to come along and it would be a nightmare if that gets dropped again. Btw, is there any resource where to follow the W3C discussions? I wasn't able to find anything like a community group or something.

But right now, we don't have a standard way to import HTML. What we have is a standard way to import JS, in the form ES6 modules. This is a case where our desire to have declarative elements is at odds with our desire to produce standards-based solutions—ideally ones that don't require a build step.

Means that HTML imports don't have a good standing? Heard rumors that some of the WG members don't want to follow that road though i personally find them very elegant. But i know how demanding and long-winding discussions about standards can be (been there before). At least it seems there's still hope that a standards-based, declarative approach will be possible sometime in the future.

The Polymer 3 preview is a minimal viable version of Polymer in ES6 modules. In the short term, any HTML-in-HTML solution is going to require a polyfill or build step, since HTML modules aren't defined yet.

As far as the Bower => yarn transition, that's forced on us by the deprecation of Bower. We've had many, many requests to make Polymer available through the npm registry even before Bower was deprecated. It's also the dominant package registry and so it was the logical choice for us. The tools team has been thinking very long and hard about how to transition to the npm registry, and until yarn came along, they couldn't see a way clear to do it without building another, custom tool to manage webcomponents-via-npm. I realize that a new tool is always a pain, but just to be clear—this particular change wasn't made without a fair amount of thought. And we'll be continuing to work with the community to work out the details of this story. 

Thanks for this insight into your discussions. Appreciate that. Also i'm very pleased to hear that you guys don't take the tools question easy. In the light of the bower deprecation the change makes absolutely sense.

Hope that helps a little bit.

If you haven't read it, we also go into the rationale behind this change in a previous blog post: https://www.polymer-project.org/blog/2017-08-22-npm-modules.html

Finally, I'd encourage you to join the discussion on Slack.

I've already joined Slack ;)

 Thanks again.

Best,

Joern

Cheers,

Arthur

To unsubscribe from this group and stop receiving emails from it, send an email to polymer-dev...@googlegroups.com.

[Arthur Evans]

Hi Joern,

Yes, HTML imports as a spec is essentially dead. No other browser is likely to implement it.

Here's a link to one of the ongoing discussions on HTML modules, a possible replacement for HTML imports.

https://github.com/w3c/webcomponents/issues/645

Thanks,

Arthur

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/cea24ec2-cab4-4376-95ad-7548ba890d78%40googlegroups.com.

[Douglas Hubler]

On Wednesday, September 13, 2017 at 4:39:49 AM UTC-4, Joern Turner wrote:.

Am Dienstag, 12. September 2017 22:41:40 UTC+2 schrieb arthure:

To answer your questions: yes, there's a lot of interest in a declarative templates (a.k.a., "writing HTML in HTML"). Many of the team members feel the same way you do. We'd love to see a solution—ideally a standards-based solution that doesn't require a build step. There is currently a standards discussion around "HTML modules", but it's somewhat unclear how that will play out. The minimal case would _only_ allow you to define HTML in an HTML module. A more elaborate version would allow script to be embedded in the module, as well, allowing single-file components like we have in Polymer 2.

 It's a relief to hear that i'm not alone with my point of view.  I've been waiting for such a solution to come along and it would be a nightmare if that gets dropped again. Btw, is there any resource where to follow the W3C discussions? I wasn't able to find anything like a community group or something.

I thought the blog post was example, I didn't think it was only way.   So for the record : Yes, very much against this.  This makes <template> pretty much useless. 

The rest of the items, prefer the way it was in P2, but totally understand greater good of the compromises.

[Joern Turner]

Hi Arthur,

thanks a lot for that. Wil study it. What a pitty that the simple solutions rarely make the race.

Thanks,

Joern