11 ms·

Personally, I think there's an important lesson here, and its the same lesson that polymer is learning as it stumbles around trying to convince people to use it

Personally, I think there's an important lesson here, and its the same lesson that polymer is learning as it stumbles around trying to convince people to use it. Most people don't actually derive much benefit from writing custom UI widget primitives. Certainly, that's a useful thing for a UI toolkit builder to be able to do, but tangibly, for most people, it's not actually useful. I don't have time to invest hours implementing `ImageDropDownSpinner` as a custom element. <select> is good enough for me, and heck, maybe I'll use some 3rd party widget if I need something special. That's not why react, vue, angular, etc. are winning the mind share of 'how to build web apps'; building UI widget is far less interesting than the ability to decompose your UI into a custom hierarchy of re-usable self contained units of functionality, that only at the lowest level actually involve UI components, is extremely powerful. They might look like custom widgets, but <PageFoo> isn't a UI widget, it's your entire application; that's the difference. It's easy to say this was a revolutionary idea, before its time, and it would have flown today instead of vanished into obscurity... but I think it missed the mark; it didn't solve problems people were actually having. ...but to be fair, it's easy to look at 'Web Component' efforts (like Polymer...) and go... yeah, this seems very familiar...

Fifer82 9y ago
I really tried with Polymer (for the last few months) but it was particularly verbose. I remember implementing an "<iron-ajax>" tag, and thinking that this is so wild and "Out There" that I may simply never understand. Annoyingly, there is a whole "Hybrid" mode as well. So there is no distinction between V1 and V2. If you are confused,you go to the docs, they aren't giving you what you need, so you go to one of the sample elements, and it is written in V1. So you have to read the migration guide to translate what is actually happening.... Then Polymer Summit happens, and now it is all JS based which, is far better for me but now it seems pointless to stay on Polymer 2.0, and Polymer 3 is a preview with no docs... So I aborted this path, went to Angular and to be honest, it is beautiful. It is almost trivial compared to the bag of questions and confusion I had going on with Polymer. I do look forward to going back there though when 3.0 is available.
- chenster 9y ago
  Angular is a front-end framework for general purpose. Polymer is the library specifically to facilitate Web Component development only. So I think you are comparing apple and orange here.
  - mlsarecmg 9y ago
    Both are basic front end frameworks. Polymer just happens to use a minor spec to encapsulate and expose, the smallest part of what it actually does. Polymer of all the frameworks i've had to use has had the most breaking changes. That they're turning the ship for each and every major forcing you to rewrite the entire application is kind of ironic given that their motto is "use the platform" as if suggesting stability and standard behavior. Polymer is not the standard, just another arbitrary driver (as in: their own syntax, their own structures, their own api) for a pretty harmless spec that sets out to solve issues we haven't faced for at least 5 years.
    - chenster 9y ago
      Big corps like Google tend to over-engineer stuff. It's the very reason why Vue.js is so kicking ass due to its low learning curse and progressive approach. Why can't we do the same for WC standards?
      - wiredearp 9y ago
        It's not like Vue has been implemented in Angular. All the ass-kicking frameworks are built on W3C standards.
      - mlsarecmg 9y ago
        I think the problem is more or less that we're at a breaking point where it's getting quite obvious that we should move away from higher-up standards. The browser should worry about low-level interfaces only, high level abstractions should never be cast in any standard and that is exactly what the extensible web manifesto said. WC break this in half again and all of the sudden they're again trying to shovel more UI stuff into the dom. What they're trying to fix hasn't been a problem for years. Their entire spec was thought out in a meeting room maybe 10 years ago, but almost nothing of it has relevance today. It would simply make it harder again and block applications from leaving the browser behind.
flomo 9y ago
"Third party widgets" was the use case. The idea was to build a marketplace for frontend components, much like existed for Visual Basic, eg. the average web developer would buy/download BobsTreeView.htc and bind an XML file and that would be it. The actual issue was that very few people was doing any serious frontend development back then. Netscape and IE had completely different DOMs and the environments were not super stable. But there was an attitude that frontend was for designers and "real programmers" were backend-only. So the real programmer found a backend component for ASP.NET or GWT and wasn't interested in the frontend sausage. (This article reminded me of the DHTML Dude column[1], and yeah some of us unreal programmers were doing this bleeding edge IE-specific front-end stuff for clients. Then we spent many years atoning for our sins. However, I think 90% of "IE-only" apps never used this stuff, they just had the wrong box model or some dopey ActiveX upload component or something.) [1] https://msdn.microsoft.com/en-us/library/bb263969(v=vs.85).aspx https://msdn.microsoft.com/en-us/library/bb263969(v=vs.85).a...
- chrisco255 9y ago
  That frontend vs backend attitude exists to this day, although somewhat less so. To be fair, apps were basically just forms in the early days of the web with very little dynamic activity.
hasenj 9y ago
I think the API actually does matter a lot. I think jQuery's massive success was precisely because it was a simple and concise API on top of the verbose and confusing DOM API.
pjmlp 9y ago
I think that people that disregard Polymer fail to understand that Web Components are already here. They are fully supported on Chrome and Safari, and hopefully Firefox and EDGE will eventually catch up with them. And they have to, because Chrome and Safari own the mobile web. Polymer is transitioning to being a thin layer on top of what the browsers support, which basically means a Polyfill for Firefox and Edge, and utility classes to make writing components easier. Web Components is what is making me finally get to love web development again. If it is to make an application platform out of browsers, then give me a platform, not an application for doing hypertext documents that we try to bend for something else. Chrome settings panel, the new You Tube, all new EA gaming portals are already using Web Components. I look forward to have something like Blend for Web Components. https://www.youtube.com/watch?v=otcmcNY-3pk&t=17s https://www.youtube.com/watch?v=otcmcNY-3pk&t=17s EDIT: fixed a few grammar issues
- dmitriid 9y ago
  > I think that people that disregard Polymer fail to understand that Web Components are already here. No. Polymer is here. As Rob Dodson said, "Polymer is the jQuery of WebComponents". No one in their right mind would even think about writing and using WebComponents in vanilla JS. Hence we're coming back to the problem with WebComponents: they are a solution in search of a problem.
  - chenster 9y ago
    > As Rob Dodson said, "Polymer is the jQuery of WebComponents". How about x-tag, a competing WP framework from Mozilla/Microsoft? I don't see any any mention of that.
    - dmitriid 9y ago
      Because for all intents and purposes it's absolutely irrelevant. If you go to webcomponents.org, you'll see that the overwhelming majority of components there are Polymer components.
      - 9y ago
Yaggo 9y ago
> <select> is good enough for me, [...] If it just was fully styleable. Browsers really should implement better selection of customizable standard widgets. Currently it requires too many hacks to re-style the built-in input elements. Web components feel a bit overkill for most cases.
- colejohnson66 9y ago
  Didn’t IE use to let you style random components such as even the scroll bar?
  - Yaggo 9y ago
    Most if not all major browsers let you style scrollbars, but the problem is that styling for built-in widgets is not standardized, i.e. it relies on vendor prefixes and worse, not all (sub) elements can be styled at all depending on browser. E.g. <select> has poor support for styling.
  - frou_dh 9y ago
    Yep - I remember on vBulletin forums, the native vertical scrollbar often got the same vibrant colouring as the forum's theme.
- noisem4ker 9y ago
  Or maybe designers should learn to respect the platform's widgets' look and feel, which the user is familiar with and has possibly customized according to their preferences and accessibility needs.
  - oblio 9y ago
    Hah! You're kidding, right? Custom styling or "skins" has been one of the main drivers of app development since the beginnings of time. I feel that we, puritans, should just give up and accept what the masses want.
  - Yaggo 9y ago
    Unfortunately the industry just doesn't work that way. Accessibility is one reason why css-themeable native widgets would be a win for everyone, their look will match with the branding (customer happy) and behaviour will be consistent (end user happy), and standardization would make developers happy.
tiglionabbit 9y ago
Why shouldn't your entire application be a widget? Sometimes it's nice to embed one application into another, multiple times. I find your reasoning here short-sighted, since there's often no clear point at which components should bottom out. You can always add another layer.
- Vinnl 9y ago
  That "sometimes" quickly breaks down when your application starts to grow beyond trivial. Some things that are rather application-specific like routing and dependency management don't quite compose well in the widget model. Or at least, Polymer at the moment doesn't have proper solutions to quite some edge cases that you'll be running into.
  - ergo14 9y ago
    I actually implemented React's UI Router in polymer, works the same as in Angular 1/2. The biggest issue with web components in general are problems with Shadow DOM support. Which means you need to do elements without shadow components up to top level - that is indeed annoying and reduces the pros of components.
- shadowmint 9y ago
  I think you've misunderstood my point; I don't think that at all. I'm specifically criticising the focus polymer has on creating user interaction elements. My point is that this sort of low level functionality isn't the right place to focus; most low level components you need already exist. What people is a way to build robust application UIs (and yeah, that includes having a root level <App/> component). For comparison, read: https://www.polymer-project.org/2.0/start/ https://www.polymer-project.org/2.0/start/ 'build custom ui widgets' <-- wrong, this isn't a problem most people have. vs. https://vuejs.org/v2/guide/#Composing-with-Components https://vuejs.org/v2/guide/#Composing-with-Components 'build your application from components' <-- right.
  - ergo14 9y ago
    Actually - the process of creating both is exactly the same, I created components in angular, react and polymer. No difference IMO (apart implementation details).
dheera 9y ago
The main problems I have with Polymer: * It's cumbersome to install. apt-get install npm && npm install bower && bower install ... this is about when I give up. Why not just include a 'polymer.js' file that just does all the work, no installs needed, no questions asked, CDN provided, batteries included, like every other client-side JavaScript library on the planet? Even the appropriate CSS can be loaded by the JavaScript itself, but it isn't. * Bloated. You end up downloading several hundred kilobytes of JavaScript if your webapp uses more than a few different types of UI elements. * Polymer components don't behave like native components. For example, you cannot swipe between tabs like a ViewPager does on Android. Implementing any kind of swipe-based feedback is hard, including pull-to-refresh. Back to native programming, I guess. * For having so much marketing and PR and a camel-cased name "WebComponents", you would think it would be productized enough that it employ the appropriate native Android elements at least in Google Chrome on Android, and use the HTML5 substitutes on iOS and desktop. For example, you should replace the Polymer button with an actual styled Android button instead of a nested div hell. Chrome should have worked with the Polymer team on this. Not doing this has serious performance implications when you display thousands of items (e.g. lists of results, contact lists) each with their own nested div hell. Back to native programming, I guess. * There is no framework to make apps look iOSish on iOS and Androidish on Android. Back to native programming, I guess.
- nilliams 9y ago
  Looks like they're working on moving away from bower: https://github.com/Polymer/polymer/issues/326#issuecomment-303148878 https://github.com/Polymer/polymer/issues/326#issuecomment-3... A quick CDN get-started would be convenient I agree. There is Polymer-CDN for demos/code-pens: https://github.com/download/polymer-cdn https://github.com/download/polymer-cdn The 'native' stuff in your comment I don't agree with. You want browsers to start implementing native Android ListViews/Buttons etc? Browsers have a hard enough time implementing web standards.
- Can_Not 9y ago
  > It's cumbersome to install. apt-get install npm && npm install bower && bower install ... this is about when I give up Half the things I've ever installed were far more complicated than that.
chenster 9y ago
> Most people don't actually derive much benefit from writing custom UI widget primitives. Bingo. Most won't and shouldn't. There's a different between building casual widgets for personal vs for business production use. jQuery UI got some widely popular components such as Select2 and jqGrid, Datatables etc. They will never be developed by non-developers or business users. The tool should be really reserved for code crafters. Imagining those crafters started creating tools with WP that are modular and self-cotained, work across whatever browsers threw at them.
rtpg 9y ago
It's really interesting to see these comments when I feel the struggle of not having this on a daily basis. I guess it's ultimately about how web development is actually two things: web pages (posters) and web apps ("software") Maybe when you're working on some one-off pages you don't feel much need for encapsulation, and in the end it's more trouble than it's worth. Let's say you are working on a social network though. You'll need to display a "person widget" a bunch, in different contexts. Of course you want to have it be consistent throughout your app. Of course you want it to look the same. Of course you want encapsulation! When you're writing a web app, your HTML isn't just layout but the entire interface. You're usually working with a huge team and need consistency. You want to be DRY. If you have a style guide, you probably could benefit some from this. The proof is that things like JQuery UI exist, even if it's activated more through JS. HTML is basically unreadable in so many cases because you can't encapsulate layout code into widgets. Having these tools lets you stay a bit sane when you need to build out a lot of workflows in a consistent manner.
- chenster 9y ago
  > I guess it's ultimately about how web development is actually two things: web pages (posters) and web apps ("software") This is what Progress Web Application tries[0](PWA https://en.wikipedia.org/wiki/Progressive_web_app https://en.wikipedia.org/wiki/Progressive_web_app), a fairly new spec, attempts to bridge the gap. Basically a normally web page will virtually be indistinguishable from a web app.
alwillis 9y ago
Sure, certain concepts have been around and keep getting reimplemented but it's far too easy to confuse the old with the new. One of the very real issues WebComponents solve is encapsulating the component functionality and styling away from everything else in a typical web page; you know, the basic separation of concerns stuff. Certainly nothing that Microsoft proposed then has today's comparability and flexibility of today's offerings. Microsoft didn't lack good ideas back then when they cared about the web; they were clueless about interoperability across devices and platforms. (IE for the Mac had a better but different rendering engine than IE for Windows did.) And because of their monopoly status then, they weren't to be trusted. I also want to correct something the article mentioned, that Netscape was irrelevant back then due to Microsoft's cool features--not true. In fact, on any big project, developers had to essentially make two sites--one for Netscape users and one for IE users. The "new" Microsoft it much better with getting their ideas out and working with other companies.
ehnto 9y ago
If you wanted to, with WebComponents you could easily use an x-PageFoo tag as a parent tag that orchestrates other child components. Your WebComponent is just a bunch of HTML, Javascript and CSS, it can really do what ever you want it to. It isn't a framework though, so to suggest that it doesn't provide as much as React is being a bit disingenuous, as it's not trying to. It's trying to formalise some of the foundations for things like react. Smaller scale but for fun, in vanilla WebComponents (as implemented in Chrome) I put together a Slider that can then accept and consume child elements that add behaviour, like this: <x-slider data-config="{autoplay:true}"> <img src="some.jpg" /> <img src="some.jpg" /> <x-slider-controls /> //Introduces left and right slider controls <x-slider-dots /> //Introduces slider dots </x-slider>
cageface 9y ago
I was a little bit disappointed to see that the plan for Polymer 3.0 is to leverage ES modules to handle all the asset loading. Maybe their hand has been forced here since browser vendors refused to implement http imports but if Polymer requires a fair bit of Javascript to do anything interesting then its advantage over something like React becomes a bit less clear-cut, IMO.
- hplustime 9y ago
  Yeah, its definitely been forced, you can see it in the team's faces (https://www.youtube.com/watch?v=0N-ldg1IPn4&t=1766s https://www.youtube.com/watch?v=0N-ldg1IPn4&t=1766s). Its possible that the HTML Modules spec will hit browsers in the next year or so (the fact that the ES Modules spec does nothing when the resource mimetype isn't JS means it'll be very easy to extend), in which case Polymer 3.0 will have just been a crash course in tagged template literals.
ergo14 9y ago
From index page "Polymer is a JavaScript library that helps you create custom reusable HTML elements". I'm using Polymer components same as as react's controller/view components. You don't need to reimplement custom select's or whatever. You can use exact patters as other frameworks use.
priolo 9y ago
"Web developers" do not know how to program, but they only know how to do "copyAndPaste". For this reason "the web" uses a shit technology. It's ONLY this: in other areas there are no such problems

Fifer82 9y ago

I really tried with Polymer (for the last few months) but it was particularly verbose. I remember implementing an "<iron-ajax>" tag, and thinking that this is so wild and "Out There" that I may simply never understand. Annoyingly, there is a whole "Hybrid" mode as well. So there is no distinction between V1 and V2. If you are confused,you go to the docs, they aren't giving you what you need, so you go to one of the sample elements, and it is written in V1. So you have to read the migration guide to translate what is actually happening.... Then Polymer Summit happens, and now it is all JS based which, is far better for me but now it seems pointless to stay on Polymer 2.0, and Polymer 3 is a preview with no docs... So I aborted this path, went to Angular and to be honest, it is beautiful. It is almost trivial compared to the bag of questions and confusion I had going on with Polymer. I do look forward to going back there though when 3.0 is available.

chenster 9y ago
Angular is a front-end framework for general purpose. Polymer is the library specifically to facilitate Web Component development only. So I think you are comparing apple and orange here.
- mlsarecmg 9y ago
  Both are basic front end frameworks. Polymer just happens to use a minor spec to encapsulate and expose, the smallest part of what it actually does. Polymer of all the frameworks i've had to use has had the most breaking changes. That they're turning the ship for each and every major forcing you to rewrite the entire application is kind of ironic given that their motto is "use the platform" as if suggesting stability and standard behavior. Polymer is not the standard, just another arbitrary driver (as in: their own syntax, their own structures, their own api) for a pretty harmless spec that sets out to solve issues we haven't faced for at least 5 years.
  - chenster 9y ago
    Big corps like Google tend to over-engineer stuff. It's the very reason why Vue.js is so kicking ass due to its low learning curse and progressive approach. Why can't we do the same for WC standards?
    - wiredearp 9y ago
      It's not like Vue has been implemented in Angular. All the ass-kicking frameworks are built on W3C standards.
    - mlsarecmg 9y ago
      I think the problem is more or less that we're at a breaking point where it's getting quite obvious that we should move away from higher-up standards. The browser should worry about low-level interfaces only, high level abstractions should never be cast in any standard and that is exactly what the extensible web manifesto said. WC break this in half again and all of the sudden they're again trying to shovel more UI stuff into the dom. What they're trying to fix hasn't been a problem for years. Their entire spec was thought out in a meeting room maybe 10 years ago, but almost nothing of it has relevance today. It would simply make it harder again and block applications from leaving the browser behind.

flomo 9y ago

"Third party widgets" was the use case. The idea was to build a marketplace for frontend components, much like existed for Visual Basic, eg. the average web developer would buy/download BobsTreeView.htc and bind an XML file and that would be it. The actual issue was that very few people was doing any serious frontend development back then. Netscape and IE had completely different DOMs and the environments were not super stable. But there was an attitude that frontend was for designers and "real programmers" were backend-only. So the real programmer found a backend component for ASP.NET or GWT and wasn't interested in the frontend sausage. (This article reminded me of the DHTML Dude column[1], and yeah some of us unreal programmers were doing this bleeding edge IE-specific front-end stuff for clients. Then we spent many years atoning for our sins. However, I think 90% of "IE-only" apps never used this stuff, they just had the wrong box model or some dopey ActiveX upload component or something.) [1] https://msdn.microsoft.com/en-us/library/bb263969(v=vs.85).aspx https://msdn.microsoft.com/en-us/library/bb263969(v=vs.85).a...

chrisco255 9y ago
That frontend vs backend attitude exists to this day, although somewhat less so. To be fair, apps were basically just forms in the early days of the web with very little dynamic activity.

hasenj 9y ago

I think the API actually does matter a lot. I think jQuery's massive success was precisely because it was a simple and concise API on top of the verbose and confusing DOM API.

pjmlp 9y ago

I think that people that disregard Polymer fail to understand that Web Components are already here. They are fully supported on Chrome and Safari, and hopefully Firefox and EDGE will eventually catch up with them. And they have to, because Chrome and Safari own the mobile web. Polymer is transitioning to being a thin layer on top of what the browsers support, which basically means a Polyfill for Firefox and Edge, and utility classes to make writing components easier. Web Components is what is making me finally get to love web development again. If it is to make an application platform out of browsers, then give me a platform, not an application for doing hypertext documents that we try to bend for something else. Chrome settings panel, the new You Tube, all new EA gaming portals are already using Web Components. I look forward to have something like Blend for Web Components. https://www.youtube.com/watch?v=otcmcNY-3pk&t=17s https://www.youtube.com/watch?v=otcmcNY-3pk&t=17s EDIT: fixed a few grammar issues

dmitriid 9y ago
> I think that people that disregard Polymer fail to understand that Web Components are already here. No. Polymer is here. As Rob Dodson said, "Polymer is the jQuery of WebComponents". No one in their right mind would even think about writing and using WebComponents in vanilla JS. Hence we're coming back to the problem with WebComponents: they are a solution in search of a problem.
- chenster 9y ago
  > As Rob Dodson said, "Polymer is the jQuery of WebComponents". How about x-tag, a competing WP framework from Mozilla/Microsoft? I don't see any any mention of that.
  - dmitriid 9y ago
    Because for all intents and purposes it's absolutely irrelevant. If you go to webcomponents.org, you'll see that the overwhelming majority of components there are Polymer components.
    - 9y ago

Yaggo 9y ago

> <select> is good enough for me, [...] If it just was fully styleable. Browsers really should implement better selection of customizable standard widgets. Currently it requires too many hacks to re-style the built-in input elements. Web components feel a bit overkill for most cases.

colejohnson66 9y ago
Didn’t IE use to let you style random components such as even the scroll bar?
- Yaggo 9y ago
  Most if not all major browsers let you style scrollbars, but the problem is that styling for built-in widgets is not standardized, i.e. it relies on vendor prefixes and worse, not all (sub) elements can be styled at all depending on browser. E.g. <select> has poor support for styling.
- frou_dh 9y ago
  Yep - I remember on vBulletin forums, the native vertical scrollbar often got the same vibrant colouring as the forum's theme.
noisem4ker 9y ago
Or maybe designers should learn to respect the platform's widgets' look and feel, which the user is familiar with and has possibly customized according to their preferences and accessibility needs.
- oblio 9y ago
  Hah! You're kidding, right? Custom styling or "skins" has been one of the main drivers of app development since the beginnings of time. I feel that we, puritans, should just give up and accept what the masses want.
- Yaggo 9y ago
  Unfortunately the industry just doesn't work that way. Accessibility is one reason why css-themeable native widgets would be a win for everyone, their look will match with the branding (customer happy) and behaviour will be consistent (end user happy), and standardization would make developers happy.

tiglionabbit 9y ago

Why shouldn't your entire application be a widget? Sometimes it's nice to embed one application into another, multiple times. I find your reasoning here short-sighted, since there's often no clear point at which components should bottom out. You can always add another layer.

Vinnl 9y ago
That "sometimes" quickly breaks down when your application starts to grow beyond trivial. Some things that are rather application-specific like routing and dependency management don't quite compose well in the widget model. Or at least, Polymer at the moment doesn't have proper solutions to quite some edge cases that you'll be running into.
- ergo14 9y ago
  I actually implemented React's UI Router in polymer, works the same as in Angular 1/2. The biggest issue with web components in general are problems with Shadow DOM support. Which means you need to do elements without shadow components up to top level - that is indeed annoying and reduces the pros of components.
shadowmint 9y ago
I think you've misunderstood my point; I don't think that at all. I'm specifically criticising the focus polymer has on creating user interaction elements. My point is that this sort of low level functionality isn't the right place to focus; most low level components you need already exist. What people is a way to build robust application UIs (and yeah, that includes having a root level <App/> component). For comparison, read: https://www.polymer-project.org/2.0/start/ https://www.polymer-project.org/2.0/start/ 'build custom ui widgets' <-- wrong, this isn't a problem most people have. vs. https://vuejs.org/v2/guide/#Composing-with-Components https://vuejs.org/v2/guide/#Composing-with-Components 'build your application from components' <-- right.
- ergo14 9y ago
  Actually - the process of creating both is exactly the same, I created components in angular, react and polymer. No difference IMO (apart implementation details).

dheera 9y ago

The main problems I have with Polymer: * It's cumbersome to install. apt-get install npm && npm install bower && bower install ... this is about when I give up. Why not just include a 'polymer.js' file that just does all the work, no installs needed, no questions asked, CDN provided, batteries included, like every other client-side JavaScript library on the planet? Even the appropriate CSS can be loaded by the JavaScript itself, but it isn't. * Bloated. You end up downloading several hundred kilobytes of JavaScript if your webapp uses more than a few different types of UI elements. * Polymer components don't behave like native components. For example, you cannot swipe between tabs like a ViewPager does on Android. Implementing any kind of swipe-based feedback is hard, including pull-to-refresh. Back to native programming, I guess. * For having so much marketing and PR and a camel-cased name "WebComponents", you would think it would be productized enough that it employ the appropriate native Android elements at least in Google Chrome on Android, and use the HTML5 substitutes on iOS and desktop. For example, you should replace the Polymer button with an actual styled Android button instead of a nested div hell. Chrome should have worked with the Polymer team on this. Not doing this has serious performance implications when you display thousands of items (e.g. lists of results, contact lists) each with their own nested div hell. Back to native programming, I guess. * There is no framework to make apps look iOSish on iOS and Androidish on Android. Back to native programming, I guess.

nilliams 9y ago
Looks like they're working on moving away from bower: https://github.com/Polymer/polymer/issues/326#issuecomment-303148878 https://github.com/Polymer/polymer/issues/326#issuecomment-3... A quick CDN get-started would be convenient I agree. There is Polymer-CDN for demos/code-pens: https://github.com/download/polymer-cdn https://github.com/download/polymer-cdn The 'native' stuff in your comment I don't agree with. You want browsers to start implementing native Android ListViews/Buttons etc? Browsers have a hard enough time implementing web standards.
Can_Not 9y ago
> It's cumbersome to install. apt-get install npm && npm install bower && bower install ... this is about when I give up Half the things I've ever installed were far more complicated than that.

chenster 9y ago

> Most people don't actually derive much benefit from writing custom UI widget primitives. Bingo. Most won't and shouldn't. There's a different between building casual widgets for personal vs for business production use. jQuery UI got some widely popular components such as Select2 and jqGrid, Datatables etc. They will never be developed by non-developers or business users. The tool should be really reserved for code crafters. Imagining those crafters started creating tools with WP that are modular and self-cotained, work across whatever browsers threw at them.

rtpg 9y ago

It's really interesting to see these comments when I feel the struggle of not having this on a daily basis. I guess it's ultimately about how web development is actually two things: web pages (posters) and web apps ("software") Maybe when you're working on some one-off pages you don't feel much need for encapsulation, and in the end it's more trouble than it's worth. Let's say you are working on a social network though. You'll need to display a "person widget" a bunch, in different contexts. Of course you want to have it be consistent throughout your app. Of course you want it to look the same. Of course you want encapsulation! When you're writing a web app, your HTML isn't just layout but the entire interface. You're usually working with a huge team and need consistency. You want to be DRY. If you have a style guide, you probably could benefit some from this. The proof is that things like JQuery UI exist, even if it's activated more through JS. HTML is basically unreadable in so many cases because you can't encapsulate layout code into widgets. Having these tools lets you stay a bit sane when you need to build out a lot of workflows in a consistent manner.

chenster 9y ago
> I guess it's ultimately about how web development is actually two things: web pages (posters) and web apps ("software") This is what Progress Web Application tries[0](PWA https://en.wikipedia.org/wiki/Progressive_web_app https://en.wikipedia.org/wiki/Progressive_web_app), a fairly new spec, attempts to bridge the gap. Basically a normally web page will virtually be indistinguishable from a web app.

alwillis 9y ago

Sure, certain concepts have been around and keep getting reimplemented but it's far too easy to confuse the old with the new. One of the very real issues WebComponents solve is encapsulating the component functionality and styling away from everything else in a typical web page; you know, the basic separation of concerns stuff. Certainly nothing that Microsoft proposed then has today's comparability and flexibility of today's offerings. Microsoft didn't lack good ideas back then when they cared about the web; they were clueless about interoperability across devices and platforms. (IE for the Mac had a better but different rendering engine than IE for Windows did.) And because of their monopoly status then, they weren't to be trusted. I also want to correct something the article mentioned, that Netscape was irrelevant back then due to Microsoft's cool features--not true. In fact, on any big project, developers had to essentially make two sites--one for Netscape users and one for IE users. The "new" Microsoft it much better with getting their ideas out and working with other companies.

ehnto 9y ago

If you wanted to, with WebComponents you could easily use an x-PageFoo tag as a parent tag that orchestrates other child components. Your WebComponent is just a bunch of HTML, Javascript and CSS, it can really do what ever you want it to. It isn't a framework though, so to suggest that it doesn't provide as much as React is being a bit disingenuous, as it's not trying to. It's trying to formalise some of the foundations for things like react. Smaller scale but for fun, in vanilla WebComponents (as implemented in Chrome) I put together a Slider that can then accept and consume child elements that add behaviour, like this: <x-slider data-config="{autoplay:true}"> <img src="some.jpg" /> <img src="some.jpg" /> <x-slider-controls /> //Introduces left and right slider controls <x-slider-dots /> //Introduces slider dots </x-slider>

cageface 9y ago

I was a little bit disappointed to see that the plan for Polymer 3.0 is to leverage ES modules to handle all the asset loading. Maybe their hand has been forced here since browser vendors refused to implement http imports but if Polymer requires a fair bit of Javascript to do anything interesting then its advantage over something like React becomes a bit less clear-cut, IMO.

hplustime 9y ago
Yeah, its definitely been forced, you can see it in the team's faces (https://www.youtube.com/watch?v=0N-ldg1IPn4&t=1766s https://www.youtube.com/watch?v=0N-ldg1IPn4&t=1766s). Its possible that the HTML Modules spec will hit browsers in the next year or so (the fact that the ES Modules spec does nothing when the resource mimetype isn't JS means it'll be very easy to extend), in which case Polymer 3.0 will have just been a crash course in tagged template literals.

ergo14 9y ago

From index page "Polymer is a JavaScript library that helps you create custom reusable HTML elements". I'm using Polymer components same as as react's controller/view components. You don't need to reimplement custom select's or whatever. You can use exact patters as other frameworks use.

priolo 9y ago

"Web developers" do not know how to program, but they only know how to do "copyAndPaste". For this reason "the web" uses a shit technology. It's ONLY this: in other areas there are no such problems