Polymer 4 and beyond: what will be deprecated, and what will stay? #5240
Comments
|
@sorvell, @graynorton, @notwaldorf This one and #5231 are pretty close... Sorry about the duplication. |
|
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. |
|
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? |
|
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. |
|
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 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. |
|
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 ***@***.***> 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
<#5240 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ACB7XhZQ03oHl_Pk1sxYPtT5_0otFOueks5tzwFKgaJpZM4UEGlA>
.
|
|
Trying to wrap my head around it too. Correct me if I got it wrong.
🔁 swapped for something new from the Polymer team.
Edits (May 24): Added url references / clean up, spelling & naming fixes / v0 hybrid for Polymer2.x / LitElement with 2.x |
|
@mercmobily GitHub markdown for tables. As for the images or "emoji" just start by typing a colon : then the name of the emoji. |
|
@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 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. 🙏 |
|
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! |
|
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. |
|
Hi,
**thank you**!
One thing I would love to see addresses: apparently html`` by 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 ***@***.***> 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
<#5240 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ACB7XtMMrkACc244aAbHTfIr0AMJB44xks5t4I0kgaJpZM4UEGlA>
.
|
|
It has been stressed many times that it is crucial to have a smooth migration path from Polymer 2.x to 3.x.
IMO, 2 strongest points of Polymer 2.x are gone now. I am gonna cry now 😢 😢 PS: How is that blog post going, @graynorton ? Thx. |
|
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. |
|
@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 ? |
|
@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. |
|
@graynorton Holding my breath for that blog post, so that I can read it and close this issue :D |
|
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. 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 |
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. |
|
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. |
|
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.
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. |
|
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. |
|
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. |
|
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. |
|
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. |
|
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. |
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) |
|
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 |
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? |
|
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 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? |
@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 #5240 (comment) 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:
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. |
|
@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 |
|
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. 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. |
|
@jogibear9988 You can use iron-list just fine with polymer 3 https://www.npmjs.com/package/@polymer/iron-list. |
|
@arkihillel @jogibear9988 Thanks for responding. Some clarifications for your thoughts:
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.
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.
As @ergo pointed out, the Polymer 3 version of
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. |
|
@TimvdLippe: Thanks for the clarifications. |
|
@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? |
|
@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. |
|
@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? |
|
@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 |
|
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 |
|
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. |
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. |
|
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 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. |
|
The polyfill not only has a Performance, also a debugging implication, as I said before! I think this is the worse part of it |
|
@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? |
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. |
|
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 |
|
@jongmana webcomponents.org now supports elements on NPM - it is a bit undocumented, but you can publish from both locations. |
|
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 #5240 (comment) (and Arthur #5240 (comment), Gray in #5240 (comment), et al.) did so sufficiently. Also thanks to our various community members that chimed in with for example a great overview by @Tanbouz in #5240 (comment) 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. |
and others
It looks to me like Polymer 4 won't have/support:
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!
The text was updated successfully, but these errors were encountered: