Polymer: Polymer 4 and beyond: what will be deprecated, and what will stay?

[mercmobily]

It looks to me like Polymer 4 won't have/support:

• 2-way bindings AND all elements that depend on it (iron-ajax, app-route, etc.)
• dom-template etc. (it's a lit-html world now)
• paper-element (with the new rewrite by the materialDesign team!)
• no HTML import

It looks to me like there isn't actually that much left of the "old" Polymer, even though V3 has just come out! However, the template-responsive-drawer-layout still uses the layout components (which, as explained in your blog post, will stay)

Hence my question: can you please make a "blacklist" of things to avoid when developing a new app? It's probably very obvious to you, but it's not so obvious to people out there who only tend to use a (more or less) limited subset of the tools you provide...

Something like "How to approach a Polymer project today, clearing the path to Polymer 4"...

Thank you!

[mercmobily]

@sorvell, @graynorton, @notwaldorf This one and #5231 are pretty close... Sorry about the duplication.

[merlinnot]

If you’re starting a new project, you might want to consider going with LitElement + Redux + @material-mwc* components.

I might be wrong, but as far as I see it the only thing that’s left is PropertiesMixin.

[mercmobily]

template-responsive-drawer-layout still uses app-layout ("@polymer/app-layout": "^3.0.0-pre.19") -- as far as I can see, that's the only bit left of the "old" Polymer. It would make sense to replace those layout elements with something that doesn't pull in the whole legacy libraries...

One of the requirements I have is that the app has that exact drawer requirement.

But oh my... there is really nothing left, is there?

[ergo]

I don't think there will be Polymer 4.x (no need really) - the thing you mentioned is called lit-element, thats the next step of evolution.
The 3.x branch will be maintained and updated as required, at least this is how I understand recent announcement and blog posts.

[arthurevans]

Hi @mercmobily,

If you haven't read it, you should check out the roadmap update: https://www.polymer-project.org/blog/2018-05-02-roadmap-update.html, which outlines the plans going forward.

Essentially, with Polymer 3, the Polymer library has reached a state of maturity. It does what it was originally intended to do, and it only relies on specs that we have good reason to believe will be implemented across browsers.

LitElement and lit-html are separate, next-generation projects. They aren't Polymer 4.

The common thread in LitElement and Polymer 3 is PropertiesMixin, which is _currently_ part of the Polymer library. That will be broken out into a separate (tiny!) library, which both LitElement and the Polymer library will depend on.

I'd argue that the question you should ask is, "What should I use if I'm starting a new project and I want to use web components?" In that case, it's clear that our answer is LitElement. The new PWA Starter Kit points the way here. Use Redux if you want. If you need the app-layout functionality, I'd recommend using the app-layout elements for now. Yes, it means adding a dependency on Polymer for the time being, but they work well. I can't make any promises, but since the PWA Starter Kit also uses them, I'd expect to see future versions based on LitElement.

So, to answer the question you actually asked... If you're starting a _Polymer_ project today, you need to use Polymer, because otherwise it's not a Polymer project :D

But Polymer is just a tool, and the goal of that tool was always to make web components easier to use.

[mercmobily]

I did read the post; however, this one Arthur is the clearest explanation
ever given on this matter.
So... basically, Polymer no more?

Justin's tweet confused me a little:
https://twitter.com/justinfagnani/status/994358200538349568 "LitElement
uses many Polymer mixins in it's implementation. Polymer's a transitive
dependency.". So... is it "many mixins" or is it just PropertiesMixin...?

The more pressing questions are: is Polymer likely to be obsoleted
soon-ish? There are tons of outstanding issues... and a lot of them are
structural (see the problems with app-route...). I am writing this thinking
that if I were Google, I would pull funding right out of Polymer since it's
effectively heading to obsolescence...

On Sat, 19 May 2018 at 01:13, Arthur Evans [e-mail] wrote:

Hi @mercmobily https://github.com/mercmobily,

If you haven't read it, you should check out the roadmap update:
https://www.polymer-project.org/blog/2018-05-02-roadmap-update.html,
which outlines the plans going forward.

Essentially, with Polymer 3, the Polymer library has reached a state of
maturity. It does what it was originally intended to do, and it only relies
on specs that we have good reason to believe will be implemented across
browsers.

LitElement and lit-html are separate, next-generation projects. They
aren't Polymer 4.

The common thread in LitElement and Polymer 3 is PropertiesMixin, which
is currently part of the Polymer library. That will be broken out into
a separate (tiny!) library, which both LitElement and the Polymer library
will depend on.

I'd argue that the question you should ask is, "What should I use if I'm
starting a new project and I want to use web components?" In that case,
it's clear that our answer is LitElement. The new PWA Starter Kit points
the way here. Use Redux if you want. If you need the app-layout
functionality, I'd recommend using the app-layout elements for now. Yes, it
means adding a dependency on Polymer for the time being, but they work
well. I can't make any promises, but since the PWA Starter Kit also uses
them, I'd expect to see future versions based on LitElement.

So, to answer the question you actually asked... If you're starting a
Polymer project today, you need to use Polymer, because otherwise it's
not a Polymer project :D

But Polymer is just a tool, and the goal of that tool was always to make
web components easier to use.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Polymer/polymer/issues/5240#issuecomment-390273095,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACB7XhZQ03oHl_Pk1sxYPtT5_0otFOueks5tzwFKgaJpZM4UEGlA
.

[Tanbouz]

Trying to wrap my head around it too. Correct me if I got it wrong.

| 1.x/2.x | 3.x | The :fire: future |
| ------------- | ------------- |------------- |
| Polymer library & data system | Polymer library & data system :coffin: :repeat: | "tiny new foundation library" + lit-html + 3rd party state manager |
| Polymer Element / LitElement with 2.x :warning: | Polymer Element :repeat: / LitElement | LitElement |
| Polymer Templates | Polymer Templates :repeat: | lit-html |
| HTML import :coffin: | ES Modules | ES Modules and :crystal_ball: HTML modules |
| bower :coffin: | npm / yarn | npm / yarn |
| polymer-cli | polymer-cli | :crystal_ball: 3rd party tools? pwa-cli? |
| polymer starter kit | polymer starter kit :repeat: | pwa-starter-kit |
| Paper Elements | Paper Elements :repeat: | Material Elements (LitElements) |
| Google Elements (v0/v0 hybrid)
| Google Elements (v0 hybrid) | :crystal_ball: Google Elements (LitElements) |
| Some Polymer Elements (v0/v0 hybrid)
| Some Polymer Elements (v0 hybrid) | :crystal_ball: Some Elements (LitElements) |
| Other Polymer Elements (v0/v0 hybrid) | Other Polymer Elements (v0 hybrid) :coffin: | Replaced with 3rd party (LitElements) |

:repeat: swapped for something new from the Polymer team.
:coffin: scrapped in favor of 3rd party replacement or native support
:crystal_ball: predictions or needs clarification

• Google Elements (YouTube, Google maps..etc)
• Some Polymer Elements responsive layout and infinite lists (iron-list? iron-flex-layout?)

* Other Polymer Elements: polymer elements not included in the above (app elements? iron ajax?..) "we'll scale back significantly on our own element lineup"

Edits (May 24): Added url references / clean up, spelling & naming fixes / v0 hybrid for Polymer2.x / LitElement with 2.x

[mercmobily]

@Tanbouz Thisi s a great summary. It would be great if somebody from "up there" at the polymer team could confirm/correct.

@Tanbouz Unrelated: how on earth did you make up a table this neat, and how did you shove images in it as well...?!? :D

[Tanbouz]

@mercmobily GitHub markdown for tables. As for the images or "emoji" just start by typing a colon : then the name of the emoji.

[atishpatel]

@Tanbouz Thanks for the summary. I was really confused with Polymer 3 being released but in the readme it saying use LitElement. LitElement seems like a competitor or alternative instead of Polymer 3 or 4. Anyway, your post was really helpful and I'd be nice if something like this was added to the readme.

I am still confused about certain features. For example, it seems like Polymer 3 supports two-way data binding - I assume - just like Polymer 2. But, LitElement doesn't. So, how would we implement forms and input fields now? There is no value="{{var}}" so is there a on-change="()=>{func}"? :\
https://github.com/material-components/material-components-web-components/blob/master/demos/formfield.html
This doesn't have examples on it, and the way i'm thinking of it really makes LitElement seem much more inconvenient than Polymer 3. Is there a migrating from Polymer 3 to LitElement guide?

Also, why should I? It seems I'm just losing features like two-way data binding, and Material Components Web Components doesn't have many of the elements that Polymer does. It sounds like the polymer team is in a way implying stop using Polymer because we are deprecating it in favor of LitElement. But, they are implying it while releasing Polymer 3 and LitElement's ecosystem being incomplete. This is all very confusing and concerning as a developer who's company relies on Polymer.

Sorry, I just ended up putting my concerns and thoughts here. 🙏

[graynorton]

Hi, all – I'll respond here within the next 24 hours or so. I started a reply last week but haven't had time yet to finish it up. Thanks for your patience!

[graynorton]

Another quick update: in the process of writing responses to the questions raised here, it became clear (as @mercmobily's original request suggested) that a new blog post and an update to our FAQs would be very helpful – in fact, I found that I couldn't resist trying to write that material, and I eventually stopped trying to resist.

I'm getting close to a coherent draft, which I'm thinking I'll share here before posting to the blog, but it will likely be another day or two. Thanks again for hanging in there while I finish up.

[mercmobily]

Hi,

thank you!
One thing I would love to see addresses: apparently htmlby a Polymer element and html from lit-html are different (?). How different? Why?
(I can't find the issue where this was mentioned... but I think addressing
the differences in actual usage, as well as way to integrate the two, would
be really welcome.

Thanks again!

Merc.

On Fri, 1 Jun 2018 at 08:39, graynorton [e-mail] wrote:

Another quick update: in the process of writing responses to the questions
raised here, it became clear (as @mercmobily
https://github.com/mercmobily's original request suggested) that a new
blog post and an update to our FAQs would be very helpful – in fact, I
found that I couldn't resist trying to write that material, and I
eventually stopped trying to resist.

I'm getting close to a coherent draft, which I'm thinking I'll share here
before posting to the blog, but it will likely be another day or two.
Thanks again for hanging in there while I finish up.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Polymer/polymer/issues/5240#issuecomment-393724472,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACB7XtMMrkACc244aAbHTfIr0AMJB44xks5t4I0kgaJpZM4UEGlA
.

[robrez]

@Tanbouz regarding iron-list: I think that this repo was mentioned during one of the I/O sessions. I recall mention of an actual spec proposal for virtualized lists and some how that repo is related.

[komasoftware]

It has been stressed many times that it is crucial to have a smooth migration path from Polymer 2.x to 3.x.
But even if the mechanical conversion does work for your project, upon arrival at 3.0 you are prompted with the message :

• two-way data binding is on its way out, think only downstream changes as of Polymer 3
  
  
  
  • the rich ecosystem of widgets in the paper-elements family gets deprecated
  
  

IMO, 2 strongest points of Polymer 2.x are gone now.
And where I could potentially change my code and approach to unidirectional, downstream data binding, a rich ecosystem of widgets is simply indispensable for adoption. There is reference made to material-components-web-components but that repository had hardly docs, no demos, very very early stage,

I am gonna cry now :cry: :cry:

PS: How is that blog post going, @graynorton ? Thx.

[arodic]

Personally, I feel like Polymer has served it's purpose and is no longer needed. Polymer 4.0, in my opinion, does not need to exist. We have everything we need in vanilla javascript.

On the other hand, I do miss two-way data binding and the ecosystem of reusable components.

To anyone considering to build a product on the web platform, I would suggest to make your own custom element base class and go from there. I decided to make mine following Polymer 3 hybrid syntax and I implemented a custom data-binding solution. If you do this, you will realize how small Polymer is... it is there just for slightly more convenient element definition and you don't really need it.

If you depend on someone else's elements library, be prepared for the pains of eventual migration.

[komasoftware]

@arodic are you still using the paper-elements and iron-elements ? do you start from scratch implementing iron-list for virtual scrolling e.g. or paper-input for feature rich inputs ?

[arodic]

@komasoftware I can still use polymer elements or any other custom elements for that matter. However I try not to rely on third party elements unless I have to. Another benefit of using your own base class is you can make the top-level app architecture any way you want it.

[mercmobily]

@graynorton Holding my breath for that blog post, so that I can read it and close this issue :D

[WooterTheTroubleshooter]

I am beginning to think that the reason (a lot) people fell in love with Polymer and the reason the developers are developing Polymer have become 2 different things. (Or have always been.)

For me the whole reason of using Polymer was the ease of use of 2 way bindings and re usability of components. I really do not care about the way this was solved and if this would be a native browser solution. (I really don't care that poly-fills have to be used to get the job done.) (I also really don't care how other frameworks work, switched to Polymer from Angular because of the ease of use.)

With Polymer 1 and still (although somewhat less) with Polymer 2, I am able to come up with working prototypes and solutions in hours instead of days.
Polymer took care of all of the glue (updating the views and communicating the changes to the models. I seldom have components that exceed 100 lines, because of the extreme 'practical-functionality' small components introduced.

I have no issues with using NPM over bower or using some hidden solution that concats my modules to js before deployment. But I would expect the Polymer ~framework~ solution to take care of that.

[web-padawan]

I would expect the Polymer framework to take care of that.

It was quite easy for backend devs with some php background to switch to Polymer 1 back in 2015 and early 2016, as it used ES5 - no babel or webpack knowledge was needed. And most of those devs did not really want to change their mindset for something like React. Personally, I had some prior PHP and jQuery background, and I was able to get Polymer 1 basic concepts in just 2 days, despite the fact that Starter Kit was not so good, the CLI did not yet exist, etc.

But nowadays the things have changed. Webpack is a standard de-facto, people use any ES features, as long as babel can transpile them, etc. The only thing is still valid: Polymer is not a framework (and has never been). Someone can try to build his own framework on top of it, as we do in Vaadin.

[WooterTheTroubleshooter]

Perhaps I used the wrong word to express my opinion., I have indeed always used it as 'solution' to take care of templates as client side self updating views. But while on the subject.
With PHP developers, the mantra has been for years to separate code from templates and now Polymer3 is back mixing code with html in the examples I have seen (Also in the pwa starter kit). Templates are back to their mixed content/string parsing form.

[ergo]

You can just use webpack or rollup to have templates in separate files, polymer doesn't care about that.

[WooterTheTroubleshooter]

You can just use webpack or rollup to have templates in separate files, polymer doesn't care about that.

I could, but that is exactly what I was trying to convey with my earlier argument. I think the Polymer development direction and (a part of) the community use case are completely different.

I could use additional tools to keep working with something that soon does not have anything left going for it, that I was using it for.
This is not solved with additional tools:

• two-way data binding is on its way out, think only downstream changes as of Polymer 3

Also, I am doing my best not to rant. Because I appreciate all the effort that has gone into a solution like this. I just think it is unfortunate there is such a gap between the awesomeness of the initial Polymer and the direction it has ended up in.

[ergo]

Yup, well you can continue to use P3 if you want to have two way binding. Maybe someone can build some new base class that does 2 way binding like vuejs.

[WooterTheTroubleshooter]

For the moment I think I'll stay behind with Polymer 2 with Polyfills to be honest. I have only used a small amount of third party web components to date. I'm not really interested in changing from the HTML centric solution just yet.

[ergo]

I think long term you will be better off with P3 + webpack for string loaded, in all my projects with 2.x I ended up with hacky solutions to add NPM packages. It obviously depends on your use cases, but IMO sticking with 2.x will be PITA in long run.

[WooterTheTroubleshooter]

Actually using Meteor as back-end (through NPM) and Polymer as front-end with Meteor handling the data synchronization. I never really had issues with NPM and Polymer(1.x and up) I really tend to try and keep advanced logic away from the view/web-components (Separation of concerns).

For the record, I am not trying to make people angry or anything. Was just hoping to add my 2cts to the discussion where I share @mercmobily's sentiment.

[askbeka]

Polymer promised to be a library that helps to create web-components easier and help standards evolve and then one day just vanish. Now web-components are ready to create reusable, isolated parts of web.

So it did its job in my opinion. Now you can go and use web components with your favorite framework, wrap it, compose it, extend it, follow practices you want, separate out html if you want(but if you find yourself jumping around the files too often, you know why), use two way data binding(or three way, I won't judge).

There are so much things to solve and so much ways to do it, and now you have webcomponents to help you out.

[robrez]

Polymer promised to be a library that helps to create web-components easier and help standards evolve and then one day just vanish. Now web-components are ready to create reusable, isolated parts of web.
... So it did its job in my opinion

this

[davidmaxwaterman]

and then one day just vanish

This bit I question. I think this more evolved as evidenced (is that a word?) by having features that were mostly just short-hand, and then switching back to the long-hand versions that were part of the platform.

I agree that it was essentially used to find out how best to develop/use WCs, and what parts of that can be standardised and baked into the browser(s). Personally, I never really thought it would disappear completely, though I suppose it actually won't, and instead most of it will melt away, leaving just a few parts that are self-contained enough to be their own entities. In name, it might well disappear.

However, I do don't care for this javascript centric approach, so perhaps there will be a resurgence with if/when that changes. Well, here's hoping.

[graynorton]

Sorry for the continued delay in communicating; I had to pause work on the blog post to focus on some important planning work.

For now, I'll go ahead and chime in here (borrowing liberally from the blog post draft). Thanks to all of you for the the good discussion, which gets to the heart of the transition we are going through now.

Let me start by reassuring you that the Polymer project isn't going anywhere: we remain committed to helping you make the most of web components (and other modern platform features). We also continue to take our responsibility as library and tool maintainers very seriously, so we've carefully planned this transition to ensure continued support for your existing projects.

That said, we're definitely at an inflection point: web components are most of the way to a successful cross-browser landing (Edge, I'm looking at you), and we're just completing the second of two major migrations (2.0: v0 specs => v1 specs, 3.0: Bower & HTML Imports => npm & ES Modules) necessitated by twists and turns on the way to standardization.

You can think of the Polymer 3.0 release as the destination end of a bridge to the future: it's a safe, stable place where you can stay if you like, but it's also the trailhead for a new path forward. Having reached this place, we're making some changes that we believe will position us better for the next era of the project.

The goal of these changes is to reshape our product lineup and brand to better reflect our vision. As you know, we believe developers should be able to build great experiences for the web using little more than what the web platform itself provides. Web components are a key piece of this vision, and we've worked hard for several years to land them successfully.

Along the way, though, we've ended up creating a body of work that (despite our intentions) is widely perceived as a full-blown framework, comprising the web components polyfills, the Polymer library, the Polymer Elements, the Polymer App Toolbox and the Polymer CLI. People commonly refer to all of the above as "Polymer" and talk about developing "Polymer apps".

This perception is at odds with our vision – we want developers to build web apps, not Polymer apps, and we aim to provide not an all-inclusive framework but a collection of lightweight, loosely coupled products that developers can use to build elements and apps that make the most of the platform.

To reduce this tension, we're both reducing the size of our future-facing offerings and changing the way we use the "Polymer" brand. To reiterate the product-line changes:

• Going forward, the simpler, lighter LitElement will become our recommended element base class, available in the standalone lit-element library. The polymer library is going into maintenance mode – meaning that it will continue to be supported with critical bug fixes and maintenance releases, but won't see active feature development – and will be renamed (most likely to polymer-classic) to reflect its status.

• Like polymer-classic, the existing Polymer Elements collections (paper-, iron-, etc.) will live on in maintenance mode after their official 3.0 releases (which are imminent). We announced at Google I/O that the new Material Web Components – a collaboration with the Material Design team – will replace the paper-elements collection. We'll have more to say soon about next-gen replacements for some of our other elements, but overall we'll offer fewer elements than we have in the past, relying more on the growing ecosystem of third-party components and recommending alternative (non-element) solutions for some use cases.

• PWA Starter Kit will replace the App Toolbox and Polymer Starter Kit as our solution for building apps out of web components. It uses LitElement out of the box, but the coupling is loose – if you wanted, you could build your app's view layer out of vanilla web components (or web components built with whatever library you like) and still benefit from PWA Starter Kit's patterns for state management, loading, testing, deploying, etc.

Rather than publishing a single website and a universal set of docs covering everything we offer, we're planning to publish a simple website and focused docs for each product. We'll use polymer-project.org for project-level information and news, providing a top-down view of the products, specs and other initiatives we're working on.

As these changes imply, we'll continue using the Polymer brand to refer to the project, but (as polymer-classic gradually recedes into the background) the Polymer name will no longer be attached directly to any specific product. Rather than "using Polymer", developers may choose from a range of products produced by the Polymer Project: lit-html, lit-element, PWA Starter Kit, Material Web Components, and so on.

While this transition will inevitably cause some near-term confusion, we believe that the changes we're making now will put us in a better position to fulfill our long-term mission and to continue evolving our offerings as the platform itself evolves.

I would still like to provide some additional detail on our plans for elements and some updated recommendations. I'd also like to address the concern and disappointment that some of you have expressed over the loss of specific features and virtues of Polymer 1.x and 2.x, but I'm out of time for now so am going to pause here and post now in the interest of incremental progress. I hope that what I've shared so far has at least shed some additional light on the overall direction of the project and the reasoning behind the changes underway.

[AndreasGalster]

@gray I hope you will touch on iron-elements and some roadmap for first alpha of all MWC components on npm.

Migrating a bigger polymer app right now is hard if you rely on several (really useful) iron-elements.

I believe those could be converted to lit?

[robrez]

@AndreasGalster you may be interested in this.

https://github.com/Polymer/polymer-modulizer/blob/master/docs/polymer-3-element-status.md

That link was shared the other day in the polymer slack polymer3 channel... The post there contains more detail

[AndreasGalster]

Ah sorry I'm referring to the fact that a lot of the iron-elements really wouldn't need to rely on the whole old-school Polymer library

[WooterTheTroubleshooter]

Along the way, though, we've ended up creating a body of work that (despite our intentions) is widely perceived as a full-blown framework, comprising the web components polyfills, the Polymer library, the Polymer Elements, the Polymer App Toolbox and the Polymer CLI. People commonly refer to all of the above as "Polymer" and talk about developing "Polymer apps".

This perception is at odds with our vision – we want developers to build web apps, not Polymer apps, and we aim to provide not an all-inclusive framework but a collection of lightweight, loosely coupled products that developers can use to build elements and apps that make the most of the platform.

Thank you for clarifying. I think this is exactly what has caused commotion in the community. Unfortunately, the 'solution' as a whole was a breath of fresh air when creating a web application for me. And I guess by the amount of commotion around this topic, for a lot of people.

However, as for me Polymer 3.x and up do not match the 'vision' I use Polymer as a solution for. (I am really really addicted to the obviousness of template repeats e.g.) Migrating to lit-element or lit-html seems like a step back now that I am used to the clear separation of view and view logic. Although "dom-if" or "dom-repeat" are more typing effort, I'd rather have them, than going back to writing view logic in code in my templates.

Again, I am trying not to rant. I am just expressing my sentiments about a 'solution' I loved. For me it was never about the web-components an sich. It has always been about creating clear, reusable models which allow almost seamless interaction by just including them in your templates.

[davidmaxwaterman]

For me, it was about being able to build apps using building blocks, rather than having to keep reinventing the wheel - to make things easier. I don't think I've ever written an element with the intention of it being used anywhere other than the app it was written for.
To me 'Polymer' was never an application framework - I considered it a 'web component framework'. There were many elements and element sets build using it, but they were never 'Polymer. Likewise the tools were never 'Polymer' (to me). It is a common mistake though.
However, I have used Polymer elements to implement the structure of my app, with a single top-level element in my index.html, and that is then decomposed according to the design of the app. I suppose that is where the 'framework' confusion comes in, but it seems obvious to me that the 'framework' is actually the browser (aka platform). IMO, it is really a new thing, and people who are unfamiliar with this sort of thing look at it from the view of whatever framework they are used to.
I also view this JS centric change as a backward step, but I also see it as a necessary one, and hope that the future will move back to an html centric approach. Time will tell.
Overall, I find @graynorton's post above to be encouraging, and I look forward to the full blog post.

[markcellus]

Migrating to lit-element or lit-html seems like a step back now that I am used to the clear separation of view and view logic. Although "dom-if" or "dom-repeat" are more typing effort, I'd rather have them, than going back to writing view logic in code in my templates.

@WooterTheTroubleshooter this is a common opinion--a lot of people seem to like the html (view) and JS (view logic) in separate files. But can't this still be done with lit-html? You can have your HTML in a separate file and import it into the lit-element JS file to keep HTML separate.

I think this speaks to the point that others have mentioned in this thread already: there is a belief among the community that the old Polymer is necessary to address these types of concerns, but it actually isn't. There are enough tools to do these things without Polymer today.

I firmly believe that the only need for Polymer elements is if it allows you to do something that can't be done using the native JS APIs like CustomElement, ShadowDOM, etc, which others have already pointed out.

[ergo]

a lot of people seem to like the html (view) and JS (view logic) in separate files. But can't this still be done with lit-html? You can have your HTML in a separate file and import it into the lit-element JS file to keep HTML separate.

Ofcourse it is.

[WooterTheTroubleshooter]

this is a common opinion--a lot of people seem to like the html (view) and JS (view logic) in separate files. But can't this still be done with lit-html? You can have your HTML in a separate file and import it into the lit-element JS file to keep HTML separate.

It's really not only about separating the content over different files. It's about the obvious separation of -style, view and view model. Using separate files is a way to work around the fact that JS literals lack syntax-highlighting, lit-element lacking 2 way binding and lit-html pushing string literals instead of using obviously toggled content.

Also, what I have seen from the PWA starterkit is the abolishment of the 'template repeat' and 'template if' tags in favor of using java-script to manipulate the template string. Which begs the question if those will remain being supported in the future.

Ofcourse it is.

Not without creating your own wrapper/build script at the moment as far as I know. And if you are going that route anyway. Consider @arodic`s comment:

To anyone considering to build a product on the web platform, I would suggest to make your own custom element base class and go from there. I decided to make mine following Polymer 3 hybrid syntax and I implemented a custom data-binding solution. If you do this, you will realize how small Polymer is... it is there just for slightly more convenient element definition and you don't really need it.

Anyway, the sentiment expressed is about the change in experience as a whole. Using wrappers or build processes will probably allow for some of the experience to be recreated. But it is very obvious with the direction towards lit-html that the HTML centric approach is disappearing in the long run.

Edit:
_Noticed a grammar error in a sum up of reasons why I do not feel I share the current vision._

Using separate files is a way to work around the fact that JS literals lack syntax-highlighting, lit-element lacking 2 way binding and lit-html pushing string literals instead of using obviously toggled content.

[ergo]

Not without creating your own wrapper/build script at the moment as far as I know

Yes, you need to build your app, or at least have some preprocessing, so yes, use webpack, rollup whatever you like to add that. Almost all real life applications are being bundled one way or another, so for me this is really bikeshedding.

HTML centric approach is disappearing in the long run.

There was no special "HTML centric" approach to polymer, it did support html imports, thats all - they won't be implemented by other browser vendors and thats all.

The library was about web components, and it was supposed to be minimal (and eventually go away for most parts). It moves towards the direction of the whole ecosystem and in the end this is a good thing.

'template repeat' and 'template if' tags in favor of using java-script to manipulate the template string. Which begs the question if those will remain being supported in the future.

It was mentioned multiple times that lit-html is the way forward and polymer will just be maintained and bugfixed, so I would not expect any active development, nor Polymer 4.x with new features.

[markcellus]

Using separate files is a way to work around the fact that JS literals lack syntax-highlighting, lit-element lacking 2 way binding and lit-html pushing string literals using obviously toggled content.

I'm confused. Separate files is separate files and I don't see how that has anything to do with the lack of feature support in lit packages.

As far as the lack of feature support: I don't think anyone here is saying that lit packages will solve all your problems. There will be things that you will need to code yourself or grab a package for in the wild or just wait for these things to be added to the lit package suite (or spec) someday -- who knows.

the sentiment expressed is about the change in experience as a whole.

Sure, but it seems like your bigger concern is that you think the new way forward lacks support of old Polymer features you once took advantage of. It would be good to be clear and specific about the features you think lit packages (and the future) lack, and open issues on the relevant packages. But complaining about the "change of experience" just seems unproductive imo.

[robrez]

Don't abandon hope folks!

html modules

https://github.com/PolymerLabs/html-modules-toolkit
https://youtu.be/7CUO7PyD5zA?t=32m38s

css templates

The material web components use a build step to create a style template via a (s)css file
https://github.com/material-components/material-components-web-components/tree/master/packages/card
https://github.com/material-components/material-components-web-components/blob/master/scripts/update-styling.sh

[ergo]

I think that bundling + splitting gave the best first load performance so I'm covered there if i want single file components or split ones.

[atishpatel]

@graynorton Thank you for the reply. It was helpful and I appreciate it.

There are still a couple of things that remain confusing so could you clarify.
It seems there are two efforts going on with the Polymer team:

1. Polymer 3 and PSK. There are still features like two-way data binding and there are all the components currently out there like iron-* and paper-*. This stuff will go into maintance and will not have new features.
   One could use this approch and still take advantage of LitHTML elements, like mwc-components. Thus, one would have a hybrid app that is flexible but requires more deps. The con to this is you would need to figure out offline support and other things that make an app a progressive web app. But, if you don't need a PWA, this is way simpler, feature rich, and less boiler plate.

For this approch, do we start with Polymer 3 and PSK? Is this is what Polymer 2 -> Polymer 3 app will be?

1. LitHTML and PWA. This approch drops some features like two-way data binding. And, it seems to impose learning and using Redux even though it uses Polymer 3 which has two-way data binding built in. The wiki writer had to explicetly say not to use Polymer 3 features.
   This approch would mean one would have to self limit the use of Polymer features, such as two-way data binding and this.set(...). Documentation of a 3rd party element might say use value="{{foo}}" but you would need to know and use value="[[foo]]" on-value-changed="(newFoo)=>{store.dispatch(updateFoo(newFoo))}"**
   The con is learning Redux and all the extra code that comes with it. But, maybe one doesn't need this. The pro of this is if you do all this, you get a PWA and this is what Polymer team thinks the future is.

Is this correct?

Side note: For me the PWA confused me until I understood one could use LitHTML without Redux. @graynorton I don't think the issue is so much the change. I think a big part of the issue is the Polymer team is telling developers what to do without the clarity of communication and rational on why to do it that way. Polymer 3, LitHTML, PWA with Redux, MWC. All of these things were "released" together and therefore i assumed they were all tied. But, they are all fairly unrelated other than the fact the Polymer team recommends using LitHTML and PWA for new apps.

** idk redux so this probably wrong

[WooterTheTroubleshooter]

@mkay581, @ergo I was adding to the conversation why there is a part of the community that feels that the reason we used Polymer is no longer there.
I was expressing sentiment and in no way do I wish to force my opinion onto anyone. It is obvious to me that a part of the community know a different use for Polymer and judging by the focus of the reactions it is clear that not everyone seems to understand why there is a part of the community that does not like this change.

Unfortunately I don't seem to be able to explain it correctly, because I see the same reactions as before. It has never been about technical solutions that could be made to 'fix' the experience.

The sentiments expressed(which I am adding to) in this topic are about a different vision of how to use Polymer and build web applications than what is the standard in the industry. That different vision is less and less practical with the current direction. It was already noticeably less with 2.x but since it was still workable, there was not really a reason to raise a question about it.

Again it's not about the technical solution. Also if you read my comments as merely complaining, you really did not read my comments with the message that was intended.

Edit:
Also those who merely use Polymer for the web components are not really affected by this topic as started by @mercmobily.
Personally I switched from Angular 0.x to Polymer 0.x and use Polymer as a replacement for Angular entirely.

[jhuesos]

For me, the biggest issue is that those of us who have decent size applications written with Polymer 1.x/2.x/Paper elements now we will have to migrate sooner or later. We are talking about applications that were started a year ago or less. And yes, it is expected that in the front-end world you will have to always eventually migrate, but for enterprise applications, migrating every year or two is not acceptable.

I understand that Polymer as a library might not be needed anymore but in previous Polymer summits and Google IOs, I don't remember any talk saying: build applications with Polymer but keep in mind that in a year or so whatever you are using will become deprecated and will only receive security fixes.

The last FAQ didn't even try to solve some of the doubts and concerns of those who have heavily invested in Polymer. I am wondering what the Youtube team must be thinking after they re-wrote the whole app to be in Polymer, which btw, they are still running on Polymer 1.x.

[ergo]

@jhuesos I did a mix of P2 and P3 elements in a single app using webpack, All the paper elements are also converted to 3.x, as far as I know they should be still working for the years to come. Deprecated does not mean something is broken or non-functional - we still use framework that is 10 year old on server side and it is only maintained for security problems. No issues here. People heavly invested into jQuery - it is still there, maybe not the hottest thing around but its still working fine. The 3.x migration is not a hard one and at least for me it solved some of the hacks I had to do for elements that depended on things from NPM.

[jhuesos]

@ergo I am aware of nothing will break but being a deprecated framework means that it will not receive significant updates apart from security and minor improvements and the community will definitely move away. One year ago I wouldn't have chosen AngularJS to start a new project because I knew it was deprecated even though it still works just fine and receiving minor updates. The main difference is that the community didn't know one year ago that Polymer and AngularJS were going to be both deprecated in one year time. In retrospective, knowing what you know today, would you have chosen Polymer/paper-elements to start a medium-big size application one year ago?

[ergo]

I would use polymer again, it is not like "we" as a community can't maintain the elements - there are two things at play here - polymer team is spread thin, they don't want additional burdens by expanding paper elements, but at same time nothing prevents us to maintain them, look at react or vue - they don't ship any elements on their own - community does that - we need to do the same instead of depend on google to do this for us. That is the endgame in my opinion, I think a lot of confusion comes from what Grey mentioned - people treated polymer as a turnkey solution, elements, library etc. It was mentioned few times on conferences that it is supposed to be jquery of webcomponents, and in this regard - it did not fail me. My biggest issues with polymer were with tooling and build process, but now with the move to NPM this problem is solved for me.

[markcellus]

Based on the sentiments throughout this thread, what I am hearing is:

1. it is a painful to migrate older polymer implementations to newer Polymer packages
2. there won't be any support for older Polymer implementations
3. Polymer's direction doesn't align with developer's expectations on previous Polymer versions 1.x and 2.x.

Regarding the first point, upgrading or migrating to new major versions of libraries or packages are all a part of building software and its inevitable as frontend development moves ahead. Major upgrades will sometimes be more tedious than we hope, that's why its good to plan for them and do them only when time permits. If time doesn't permit or you don't want to upgrade, you don't have to.

For No. 2 above, deprecated Polymer usages will still be supported. If not by the core members of the Polymer team, by the community. That's what open-source is all about. If an old Polymer package or component that you are using has bugs or lacks a feature, you can always open a PR or issue on the repo.

For the people who believe the last point above, can somebody tell me why exactly this a problem?

the community didn't know one year ago that Polymer and AngularJS were going to be both deprecated in one year time.

in previous Polymer summits and Google IOs, I don't remember any talk saying: build applications with Polymer but keep in mind that in a year or so whatever you are using will become deprecated and will only receive security fixes.

So the real issue is because the community wasn't notified enough time in advance of the deprecation? Isn't it expected that when a major version of libraries is introduced, deprecation of the previous major version is implicit?

Just so that we aren't repeating the same things throughout this thread and keep it productive, can we stick to identifying specific problems? If so, I'm sure other engineers here would be happy to address them. But if not, this all just comes off like you're saying "Polymer has changed and I don't want it to", which I'm not sure anyone can specifically address.

[arkihillel]

Polymer promised to be a library that helps to create web-components easier and help standards evolve and then one day just vanish. Now web-components are ready to create reusable, isolated parts of web.

This is the main issue in my opinion.

I use Polymer for the "easy" part meaning just the right balance between great readability, expressiveness and flexibility. The original issue Polymer brought up IIRC was that the front end world went completely crazy with all those tools and complex frameworks and that the web needed to be revolutionized to be made usable for the next generation. Or at least that's the message I heard. This is most probably what @WooterTheTroubleshooter and other people here appreciated in Polymer 1 & 2

Using bundlers still feels like a heresy to me. Compile compiled languages and run scripts, don't compile scripts it just isn't right (or at least doesn't feel like it is)

Now you do meet some point of inflection as @graynorton mentioned. And this point is where you have to chose between ease of use and standardization. When the end goal is to achieve two things, one of them will eventually get in the way of the other

I always advocate for readability and this is the weakest point of Polymer 3 whenever compared to Polymer 1/2. I would then definitely prefer to go the "easy" route instead of the "standard" route. I'm still thankful to Polymer for all it brought but I will probably leave front end development once again until somebody comes up with the next sane way of doing it (and hopefully gets it standardized)

[davidmaxwaterman]

I agree with the 'easy' part. IMO, there are too many computer scientists getting into web development, and they're forcing their methods into this world, which is why everything is turning into JavaScript and build tools. FWIW, I am also from that world (C, C++), but very much appreciated the way web development didn't need any of the faff for development, and this was something I valued from Polymer too, that it was html focused, not JavaScript focused. I also valued that it seemed that, when 'tools' were needed, they were largely hidden or automated - ie also 'made easy' (eg polymer serve just does it all for you).
In general, I see it as a spectrum of 'easy' - 'hard', where html is easy and JavaScript is hard. IMO, there is a huge barrier to entry, but there is also a barrier to existing developers. It's true that one has to continue learning in one's career, but it gets overwhelming and feels excessively demanding - sometimes it really feels like some of this really isn't web development at all any more.
However, I feel the point of inflection and hope the trend will reverse again (and Polymer is a force for good in this battle, imo).
To specify some problems, I feel like those of us who have had the luxury of being able to specify a browser for our apps, and specify chrome, do in fact face practical problems. Some of the features Polymer used were implemented natively into chrome, but they are surely going to be removed. /deep/ et al, shadow dom v0, and html imports, come to mind. It was clear that the polyfils/etc were needed to support other browsers, but it wasn't clear (to me, at least), that I might eventually need them for chrome too. In any case, I don't think it is necessarily accurate to say that "If time doesn't permit or you don't want to upgrade, you don't have to." - if you don't, then things break since chrome deprecates features. Of course, it is entirely reasonable for chrome to deprecate features that are abandoned experiments or however they should be described, but it is certainly a problem for some web app/site developers. You could say it isn't Polymer's fault, which has some truth, but it doesn't change much.

[atomikolex]

FWIW, I am also from that world (C, C++), but very much appreciated the way web development didn't need any of the faff for development, and this was something I valued from Polymer too, that it was html focused, not JavaScript focused. I also valued that is seemed that, when 'tools' were needs, they were largely hidden or automated - ie also 'made easy' (eg polymer serve just does it all for you).

Same goes for me, except that I am just a hobbyist developer and Polymer was really opening a new world to me. I loved Polymer for being opinionated, for guiding beginners on how to use Bower and Gulp, providing endless support on Github, mailing lists, Stackoverflow and then Slack, for teaching people every little twist and turn with Polycasts. There wasn't much missing for me, anymore, apart from it being client side only, until Firebase stepped in with functions to fill this final hole, and I thought that I might even make a living with web development some day.

Of course I had always heard what the team was saying from the beginning regarding Polymer not being a framework. But hey, we are humans and humans live in ecosystems!

So I guess I just didn't want to hear it. Not everybody is a seasoned developer who has a job in tech, works in a team and just already knows all the tools we are supposed to know now like Rollup and Redux and Webpack. So I was sad when seeing so many people leaving the team like Eric Bidelman, Addy Osmani, Rob Dodson, when Polycasts got wound down from being a biweekly series into a maybe sometimer, for lack of proper resources put in by Google.

On the other hand, I really like the effort put in by the whole tooling team, and I can see that it really comes into fruition. Everything is faster and cleaner now, the community is growing and ready and willing to take over stuff. I just fear that I can't keep up with it anymore. So I know it's a big ask, but I think it would keep many developers happier, if the team would consider committing time and resources for a new regular Litcasts series again?

[jondubois]

I started upgrading my Polymer 2 project to Polymer 3 yesterday and reading the migration guide was a huge disappointment. Polymer 2 was by far my favourite front end framework.

Polymer 3 makes me feel like I don't even know what WebComponents are anymore! I thought that the whole idea of WebComponents was to be a hierarchy of small separate HTML DOMs (each with their own scripts/controller logic) which could be embedded into each other in a neat hierarchy using html imports. Polymer 2 did that really well; it felt like the result of a full, cohesive vision. It was like a tree of mini-DOMs; it made sense, it was conceptually very simple. The DOM is the foundation of the entire page after it loads in the browser so it makes sense that it should also be the foundation for every sub-component within it.

Polymer 3 looks like a rip-off of VueJS and React; I don't get the vision anymore - I can't see what it has to do with WebComponents? Why are components .js files and why do they return a template as a string? My IDE doesn't recognise the string as HTML. Polymer is no longer about being just a composition of DOM components; now it's a bunch of JavaScript classes that return rendered HTML. Polymer 3 has become more opinionated than ever. I don't see how it can claim not to be a framework anymore.

I have a feeling that a big part of the decision to give up on .html components in favor of .js ones was to make it easier to implement server-side rendering. I think that server-side rendering is a mediocre idea to begin with. The client and the server are not the same; they're completely different environments; they need to account for different rules; for example the backend has to care about authentication and permissions and it doesn't deal with user interactions; that is a huge difference (it doesn't make sense to use the exact same code for both; it's just very limiting).

I hope that two-way binding is not dropped in the future because while it can be dangerous in the wrong hands, it's also very powerful in the right hands. The framework shouldn't force everyone to use a Redux-style architecture with a single global store; Redux is a good architecture but it's not the only correct architecture and two-way binding opens up a lot of good/simple alternatives.

The problem of Polymer 2.0 was not technology; it was bad marketing, bad luck, the big vision wasn't conveyed properly... I feel that Polymer 3 tried to fix something that was never broken.

Now I'm seriously considering rewriting my project in VueJS. I'm not sure that I can trust the Polymer team anymore. Are there any good forks of Polymer 2 I can use?

[TimvdLippe]

I have a feeling that a big part of the decision to give up on .html components in favor of .js ones was to make it easier to implement server-side rendering.

@jondubois I am not sure where you got this feeling, but it is not true. For more information, please see @graynorton's detailed response in https://github.com/Polymer/polymer/issues/5240#issuecomment-395922668 as well as watching our Google IO 2018 talk (https://www.youtube.com/watch?v=7CUO7PyD5zA). If you do not have the time to watch the full talk, I especially want to advise you to watch this specific section of our talk that goes into the whole HTML vs JS debate. I think especially this section acknowledges the points you make (as I quote Steve in this part of the video "A lot of our users, they really like using HTML to define components"). To give more context, please see the blogpost by Mozilla stating that:

Mozilla will not ship an implementation of HTML Imports.

All in all, the Polymer team has asked them to reconsider that statement, however sadly that did not happen. The decision to therefore not being able to importing HTML directly using HTML is therefore beyond our control.

I hope that this at least clarifies more. I acknowledge and share your sentiment, I would have preferred to use HTML imports as well. Sadly, that is not going to happen and in that future we had to reposition ourselves. ES modules have shipped and allow us to import pieces of code one-by-one, thus were the appropriate replacement.

P.S. Even though HTML imports did not make the cut, with the help of the Polymer team major browsers are now shipping implementations of custom elements and shadow dom. That is of course a huge success we had, which is based on our extensive experience we obtained by writing web components using the Polymer library.

[arkihillel]

@TimvdLippe I greatly appreciate the very best efforts the Polymer team put into moving the web forward. Going the standard way is an inevitable (and, in many ways, good) decision.

I wish the team would have gone completely standard though and hadn't used TypeScript unless there was some effort made to make it a web standard.

I also wish something else than NPM was used for dependency management – NPM is not made for flat dependency trees and if Bower is officially dead, this would have been a great opportunity to come up with a new dependency manager made for the web.

The lit starter kit is also based on Redux. While Redux is nice, why not promote Vanilla JS and show developers how to manage storage and state management issues without using an external library? To me, it tastes very much like the flavor of the month that will probably disappear sooner or later.

The move to lit-html is also a good step forward towards a leaner (more portable) code base. After almost a year though since last Polymer Summit, neither Polymer 3 component library nor lit-html nor material web components are ready yet which makes me a bit worried. I'm now seeing the number of "Polymer developers" shrink and the demand for it being only sustained by existing projects.

Besides, I don't know much about the internals of hyperHTML but it would've been nice to approach the project and attempt to merge it with hyperHTML or to explain why lit-html needs to exist on its own

Finally, I can only applaud the Polymer team dedication to push the standards even further

[jogibear9988]

For me it's not clear what to do atm.

I'd like to switch to polymer 3 (form polymer 2).

But, we also use "iron-list" extensively, and also two way bindings (with iron list). I know this will work with polymer3, but what will be replacement for iron-list?

And when can we expect a stable release of lit-element?

What I dislike most is that everything is so intransparent. No blog posts, nobody knows whats happening at or to polymer.
I found this issue yesterday, but why is many of the info inside not on any blog post?

This was discussed in this Thread also: https://github.com/Polymer/project/issues/36

I also don't know that 3 People left the Team (why?)

I really like what you do! Polymer is a great Library. But a little bit more commuination would be nice.

[ergo]

@jogibear9988 You can use iron-list just fine with polymer 3 https://www.npmjs.com/package/@polymer/iron-list.
Justin is working on lit-html 1.0 that will bring some changes, I guess lit-element will be updated then.

[TimvdLippe]

@arkihillel @jogibear9988 Thanks for responding. Some clarifications for your thoughts:

this would have been a great opportunity to come up with a new dependency manager made for the web.

The Polymer team does not have the capacity to maintain its own package manager. Rather than building our own, we reached out to the NPM/Yarn folks to resolve this issue in these respective managers.

I'm now seeing the number of "Polymer developers" shrink and the demand for it being only sustained by existing projects.

Personally, I think the phrase "Polymer developers" is wrong. Rather, there should be web developers that have extensive knowledge of custom elements, shadow dom and template (aka web components). Recruiting developers solely for 1 library is wrong in my opinion. Others probably disagree with this, just my 2 cents.

Besides, I don't know much about the internals of hyperHTML but it would've been nice to approach the project and attempt to merge it with hyperHTML or to explain why lit-html needs to exist on its own

lit-html was an experiment to tackle the "efficiently create and update DOM"-problem. The knowledge of developing and designing this tool is used in the standards process: https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Template-Instantiation.md More specifically, the implementation knowledge of lit-html was used in this concrete proposal by @cdata on the layering implementation of the standard. Again, as we have been doing with all our projects, is to eventually standardize those parts that we deem crucial to be implemented in the browser. We have web components now, but we continue to follow this path with new standards.

I know this will work with polymer3, but what will be replacement for iron-list?

As @ergo pointed out, the Polymer 3 version of iron-list published to NPM works just fine. Based on the knowledge of implementing iron-list (and analogous to my previous clarification), @valdrinkoshi experimented with a virtual list standard implementation. There is an intent to implement for Chrome which is all part of the larger layered APIs proposal.

I also don't know that 3 People left the Team (why?)

I am not sure where you got this information, but the number of Polymer team members has not decreased. Some people left, others joined. Moreover, I was specifically added/contracted to help out on GitHub with responding to issues and PRs.

Hopefully these clarifications provide more context on what we are working on right now.

[timeu]

@TimvdLippe: Thanks for the clarifications.
Is there a roadmap regarding the https://github.com/GoogleWebComponents components (i.e. google-map, etc).
Does Google plan to maintain and upgrade them (there are a lot of open PRs and issues) or is it up to the community to come up with proper custom elements around those services (maps, etc) ?

[AndreasGalster]

@TimvdLippe I'm actually getting worried here to some extent now. I realize now that lit-html is an attempt to experiment again with things to implement in the browser, just as Polymer was. Now the problem I see is, OK everything is implemented in browsers, no need for Polymer anymore to a large extent.

So won't that mean that let's say 1 1/2 years from now the Template Instantiation proposal gets implemented in browsers, lit-html again will be obsolete and now we'll migrate to the next implementation that you are prototyping to get into browsers? This is what worries me a bit. I'm all for using a library that works as the future will work (this is why I chose Polymer) but it's another thing if we have to abandon our code base every two years because of this.

The whole point why I chose Polymer in the first place was so I don't have to choose another implementation every two years. But now it seems this is where things might be headed. My assumption was that we get closer to the browser implementations and don't have to re-write everything all the time with framework x.

Thoughts?

[ergo]

@AndreasGalster I agree, my problem is less that Polymer itself stagnated, and got obsolete by lit-html, but is problematic that the elements are being abandoned, I don't want to reimplement everything every year for the next library.

[jogibear9988]

@TimvdLippe also thanks for the clarification!

Maybe it's possible that there will be a little bit mor communication on the Blog whats going on inside Polymer?

I also wanted to know, will anyone work on the Designer once again?

[moderndeveloperllc]

@AndreasGalster @ergo It's a bit of a philosophical discussion that's been rehashed on a thousand blogs and lampooned in just as many web comics: Another month, another JS platform and a new version every week. Angular has had versions 2, 4, 5, 6, and is in beta of 7 within the past 22 months for instance. React.js has 16 versions in 5 years. Change is the only constant.

There is nothing wrong with sticking with Polymer 2 or 3 for however long you want. The only reason to change to lit-html or any other flavor of the month is if there are new features you _need_ for a project. If you create your app today in Polymer 2, it should still work and be expandable 5 yrs from now. There are fewer worries about the lack of security fixes because this is all client-side, and you shouldn't be depending on JS "security" anyways. JM2C

[jogibear9988]

For polymer2 im not sure. As Chrome is planing to remove native html imports you will get a different debugging experience when this happens, because now you rely on a polyfill, and you cannot debug your html files directly

[cnbuff410]

So seems like the Polymer 3 is the way to go in the long term? I have no problem upgrading all my code to Polymer 3 if that's the case, but I am worries about Google's official attitude on Polymer 3. It just looks like to me that Google doesn't care about Polymer 3 any more. Oh yeah some parts of it is going to be supported. So we won't spend too much time on Polymer 3 development anymore.

It's not just about the bug fixing or code maintenance, it's about if people would flea away when they see even Google is not behind this library. One of the biggest reason for people to follow the trend and pick the most popular library is the "best practice" they can learn from others, that requires a big developer ecosystem behind the library. If Polymer 3 never gets the developer ecosystem, it makes very little sense for people to stick with it.

[davidmaxwaterman]

As Chrome is planing to remove native html imports you will get a different

Actually, it'll break my app(s) completely since I only target chrome and so have never bothered loading the polyfills. There are other such features too...but I forget exactly which.

[TimvdLippe]

We advise everyone to upgrade to Polymer 3 to remove their dependence on HTML imports and instead use the standardized loading mechanism ES modules. After the upgrade to Polymer 3, you can write your web components however you want in ES modules, whether that is based on the lit-element, your own library or none at all. That is possible, because we take advantage of the interoperability of all these custom elements, thus making sure all these elements can work together seamlessly.

You can of course not perform the upgrade to Polymer 2, but then you will need to rely on the HTML imports polyfill, as HTML imports will not be standardized. Chrome will be removing support in the feature, as it removes support for non-standard features. The polyfill of course has a performance implication, which you should investigate for your own websites. The impact might be minimal, or very large, that is hard to say in general of course.

[jogibear9988]

The polyfill not only has a Performance, also a debugging implication, as I said before! I think this is the worse part of it

[jongmana]

@ergo thanks for the npm link to the iron-list element.

But does anyone know if this means that Google also started to abandon the maintenance of their components on the webcomponents.org site?
The webcomponents.org site still refers to install PolymerElements using bower.
I too get the impression that since the latest polymer release a lot of things locks broken and unfinished for anyone starting with webcomponents using polymer.

[web-padawan]

The webcomponents.org site still refers to install PolymerElements using bower.

I believe once the stable versions of Polymer elements are released, they will update these. However, there is an important note: demos currently do not work for npm, and for official elements it is the only place to see them.

[nelsonsilva]

In case someone else wants to comment on the intent to remove HTML imports from Chrome: https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/h-JwMiPUnuU

[ergo]

@jongmana webcomponents.org now supports elements on NPM - it is a bit undocumented, but you can publish from both locations.

[TimvdLippe]

Thank you everyone for participating in this discussion. I acknowledge the changes that have happened/will happen can have an impact on your current web developer workflow. As elaborated upon in our various comments in this thread, we hope to have shed light on our reasoning and have provided more information on the expected future.

However, this thread has since then moved away from the original topic onto a wide variety of questions. Personally, I felt the obligation to answer or clarify any concerns that were raised in this ticket and I hope that I in https://github.com/Polymer/polymer/issues/5240#issuecomment-410456081 (and Arthur https://github.com/Polymer/polymer/issues/5240#issuecomment-390273095, Gray in https://github.com/Polymer/polymer/issues/5240#issuecomment-395922668, et al.) did so sufficiently. Also thanks to our various community members that chimed in with for example a great overview by @Tanbouz in https://github.com/Polymer/polymer/issues/5240#issuecomment-391337152

All in all, when looking at the original questions, these questions are answered in the above linked comments. As this issue then caught a lot of traction, we have since moved to various other topics. To streamline any potentially unanswered concerns, I will close this issue, as it's original concerns have been answered for. If you have any other concerns, feel free to look through the (closed) GitHub issues list to see if there is already a topic for. If not, feel free to open a new topic with that specific concern. I would therefore ask everyone to stay focused on that particular topic, such that I (and others) can listen and answer to the feedback in the most effective manner. In particular, this thread was hard to follow and thus it was tough for me to answer succinctly (yet sufficiently), as multiple topics were discussed at the same time.

Thank you everyone for your participation and your consideration, even though the initial reaction can understandably be heated. (I felt the same initially!) For any further comments/messages about this topic, feel free to post in a channel or sent a direct message to me on our Slack.