6 ms·

Can someone explain this to me like I'm a 5 year old and have no idea what any of it means? What will it help me do that I can't otherwise? What tech does it co

Can someone explain this to me like I'm a 5 year old and have no idea what any of it means? What will it help me do that I can't otherwise? What tech does it compare to, if any (direct competitors)?

ilaksh 13y ago
Similar to AngularJS also a Google project.
- dmragone 13y ago
  Yeah I got that feeling. I've used and like Angular, but can't figure out why I'd want to use this instead.
  - liamk 13y ago
    I have the exact same question. Polymere does databinding, and custom html elements, but I think Angular does it a little better.
    - ilaksh 13y ago
      I think AngularJS has more features but Polymer is more modular and designed to be more easily adoptable over time and also fit in with Web Components. I also think that a few things in Angular are hard to figure out, whereas this looks a little more straightforward. So if this Polymer thing could add some of the stuff that Angular has like routing with pushstate then I will definitely consider using it.
randomfool 13y ago
One difficulty with building large single-page web applications is having a decent component model. Right now, web pages are mostly composed of primitives (divs, etc) which are the building blocks for complex UIs, but there's not a first-class way of bundling these together into richer components such as a tab control, or a data bound listbox. The web components basically standardize a way to encapsulate more complex UI components, so you can do something like: <x-tab-view></x-tab-view>. Even beyond a rich community of pre-built components for you to consume, they make it easier for you to make your applications composable- <my-header></my-header> <my-paging-content> ... lots of content ... </my-paging-content> <my-footer></my-footer> Hopefully this all makes it much easier to build larger single-page apps.
- Pxtl 13y ago
  I realize it hasn't been like that in about a decade, but whenever I start seeing web-component tech I get bad flashbacks to ASP.net WebForms.
  - sgrove 13y ago
    What was wrong with it? I haven't used ASP at all (outside of some tutorial a decade or so ago), so I don't know. Curious to see if there are any pitfalls we're headed for, and if they're avoidable. In the meantime, I'm quite excited by the idea of web-components, though the implementation is staggeringly unpleasant to look at.
    - nzonbi 13y ago
      Adobe Flex was also completely based on this "components" model. I would say that it is a useful approach, but as you suggest, not without its pitfalls. Adobe mxml was pretty much the same as this is: xml based markup, with custom components, these in turn implemented in a combination of mxml markup, AS3 scripts and css styles. I was a flex early adopter, and used it for some years. Later I abandoned it, mostly because I got tired of writing excessive boilerplate code in java-styled AS3, and also because html started to evolve. I can remember some tips. Please excuse my diffuse language, I am talking straight from memory. - Avoid messy component structures. Keep component definitions simple. Use components hierarchies and keep nesting levels simple. - On complex UIs, "application intention" can get lost in a sea of anonymous data bindings. Use good documentations practices. Avoid data binding spaghetti. - On complex UIs, Use good planing for data binding. Because debugging it is "data binding hell". - Know your components well. Sometimes components capabilities may differ slightly from what you are trying to accomplish. Trying to go against the components quirks, can be very expensive. - Data binding is not the panacea. There are scenarios that are best served with other approaches.
    - WickyNilliams 13y ago
      WebForms, how I hate thee, let me count the ways. It perverts the web's statelessness. It imposes some half-assed, hacky state via "viewstate". You have to constantly prune the amount of viewstate which controls add to a page, or you end up with 50kb of viewstate in the markup! It is incredibly complex! The event model is difficult to understand, there are many steps - at a page level and later at a control level. I've never met anybody who truly understands it. You have a problem? Trial and error and sticky tape until you get it balancing just right that it works. Change with caution! Promotes highly coupled code. The "code behind" all but begs you to put your business logic in your view. Testing is basically impossible, unless you adopt a framework like WebFormsMVP. This eases things somewhat, giving a cleaner model to work with and forces you to move business logic out of the view. But that can be a challenge on occasions too, because you eventually have to deal with the complex event model underpinning the framework (as I described above). WebForms is basically demoware. Looks great when you drag a few controls on a page, click a few buttons, and have it pulling data into a sortable/filterable grid. As soon as you want to produce clean markup, styled as you want, performing some complex interactions, you'll end up wanting to pull your hair out. Disclosure: I've worked with webforms for around 4 years.
neilk 13y ago
The modern web app has gone way beyond the simple HTML page - now there are components in all but name, handling their own libraries, network connections, establishing model-view-controller separation, and communicating with other components via events. But it's all simulated out of the technologies originally made for web pages. One sign that things have gone very wrong: a lot of developers have to treat the web page as a kind of compilation target. We've lost the simplicity the original web had. The authors believe in a future where if you wanted a particular rich text editor in your web app, you could just put <my-rich-text-editor/> in there. Done. No web browser can do this stuff today, but libraries like Polymer are trying to bridge the gap between today's browsers and the way they may look in the future. As another poster mentioned, it's attacking the same problems as Angular.js, with a similar approach. Indirectly it's competing with pretty much every client side web app framework.
- mindcrime 13y ago
  No web browser can do this stuff today, but libraries like Polymer are trying to bridge the gap between today's browsers and the way they may look in the future. We should probably stop calling them "web browsers" at this point. We've basically re-implemented the idea of an Operating System in the browser, so we now have a full-fledged OS like Linux, BSD, Plan9, OS/2, Minix or whatever, being used to host a "poor man's OS" which is recreating most of what the base OS does! To say "things have gone very wrong" is a dramatic understatement in many ways. I still think we messed up by migrating away from the mobile-code approach for apps. But I largely blame Sun for that, as they screwed the pooch by shipping the Consumer JRE about 7 years too late, ignoring needed features for doing desktop and interactive apps (like modern audio and video codecs, etc.) and didn't stay on top of JRE security. Now, Java, which was probably the best "mobile code" platform that ever got mainstream traction, is basically dead as a client platform. :-( Browsers are great for doing what they were designed to do: Browsing hypermedia. But to shoehorn "remote application delivery" into the browser seems like a step sideways (at best) to me. We're layering hacks on top of hacks on top of hacks now, to try and recreate the "app" experience inside the browser. This strikes me as sub-optimal.
  - deleted 13y ago
tosh 13y ago
Like Angular.js from an end-user/developer's perspective but goes beyond that. Instead of being a framework it is an effort to polyfill the actual Web Components spec. This means that Polymer will eventually be supported natively by browsers which means that in the future we'll have something like Angular without needing to do the heavy-lifting at the framework-level. :)
- tosh 13y ago
  Also if you are interested in Polymer but want to actually use it in production right now (like we to at Blossom.io) check out Dart's Web UI: http://www.dartlang.org/articles/web-ui/ http://www.dartlang.org/articles/web-ui/ It's like travelling to the future :)
just2n 13y ago
A "web component" is some stand-alone combination of HTML/CSS/JS that does some thing. It should not conflict with the application that uses it in any way. It should, however, allow the application to communicate with it (to modify its state) and to potentially change its appearance in a way that will not break the component. A problem with HTML/JS/CSS pre-shadow DOM is that it was impossible to actually build a component as described above. There was no way to sandbox the HTML/JS/CSS that's used to build the component from the application. There was always the possibility for contamination. What the specs that Polymer is intended to polyfill permit is a combination of this sandboxing capability along with other means of permeating this sandbox with the functionality needed for such sandboxed components to be truly useful (how useful is something you embed in your page then can't access/talk to at all?). This includes data binding, events, allowing parent CSS to apply to certain things (in a very explicit, named way, which allows the parent application to style the component in a manner the component creator deems appropriate, and not in a way that will break the component), etc. These standards, in effect, define features that once implemented will permit true web components to be built. For more: http://www.html5rocks.com/en/tutorials/webcomponents/shadowdom/ http://www.html5rocks.com/en/tutorials/webcomponents/shadowd...

Can someone explain this to me like I'm a 5 year old and have no idea what any of it means? What will it help me do that I can't otherwise? What tech does it compare to, if any (direct competitors)?

ilaksh 13y ago

Similar to AngularJS also a Google project.

dmragone 13y ago
Yeah I got that feeling. I've used and like Angular, but can't figure out why I'd want to use this instead.
- liamk 13y ago
  I have the exact same question. Polymere does databinding, and custom html elements, but I think Angular does it a little better.
  - ilaksh 13y ago
    I think AngularJS has more features but Polymer is more modular and designed to be more easily adoptable over time and also fit in with Web Components. I also think that a few things in Angular are hard to figure out, whereas this looks a little more straightforward. So if this Polymer thing could add some of the stuff that Angular has like routing with pushstate then I will definitely consider using it.

randomfool 13y ago

One difficulty with building large single-page web applications is having a decent component model. Right now, web pages are mostly composed of primitives (divs, etc) which are the building blocks for complex UIs, but there's not a first-class way of bundling these together into richer components such as a tab control, or a data bound listbox. The web components basically standardize a way to encapsulate more complex UI components, so you can do something like: <x-tab-view></x-tab-view>. Even beyond a rich community of pre-built components for you to consume, they make it easier for you to make your applications composable- <my-header></my-header> <my-paging-content> ... lots of content ... </my-paging-content> <my-footer></my-footer> Hopefully this all makes it much easier to build larger single-page apps.

Pxtl 13y ago
I realize it hasn't been like that in about a decade, but whenever I start seeing web-component tech I get bad flashbacks to ASP.net WebForms.
- sgrove 13y ago
  What was wrong with it? I haven't used ASP at all (outside of some tutorial a decade or so ago), so I don't know. Curious to see if there are any pitfalls we're headed for, and if they're avoidable. In the meantime, I'm quite excited by the idea of web-components, though the implementation is staggeringly unpleasant to look at.
  - nzonbi 13y ago
    Adobe Flex was also completely based on this "components" model. I would say that it is a useful approach, but as you suggest, not without its pitfalls. Adobe mxml was pretty much the same as this is: xml based markup, with custom components, these in turn implemented in a combination of mxml markup, AS3 scripts and css styles. I was a flex early adopter, and used it for some years. Later I abandoned it, mostly because I got tired of writing excessive boilerplate code in java-styled AS3, and also because html started to evolve. I can remember some tips. Please excuse my diffuse language, I am talking straight from memory. - Avoid messy component structures. Keep component definitions simple. Use components hierarchies and keep nesting levels simple. - On complex UIs, "application intention" can get lost in a sea of anonymous data bindings. Use good documentations practices. Avoid data binding spaghetti. - On complex UIs, Use good planing for data binding. Because debugging it is "data binding hell". - Know your components well. Sometimes components capabilities may differ slightly from what you are trying to accomplish. Trying to go against the components quirks, can be very expensive. - Data binding is not the panacea. There are scenarios that are best served with other approaches.
  - WickyNilliams 13y ago
    WebForms, how I hate thee, let me count the ways. It perverts the web's statelessness. It imposes some half-assed, hacky state via "viewstate". You have to constantly prune the amount of viewstate which controls add to a page, or you end up with 50kb of viewstate in the markup! It is incredibly complex! The event model is difficult to understand, there are many steps - at a page level and later at a control level. I've never met anybody who truly understands it. You have a problem? Trial and error and sticky tape until you get it balancing just right that it works. Change with caution! Promotes highly coupled code. The "code behind" all but begs you to put your business logic in your view. Testing is basically impossible, unless you adopt a framework like WebFormsMVP. This eases things somewhat, giving a cleaner model to work with and forces you to move business logic out of the view. But that can be a challenge on occasions too, because you eventually have to deal with the complex event model underpinning the framework (as I described above). WebForms is basically demoware. Looks great when you drag a few controls on a page, click a few buttons, and have it pulling data into a sortable/filterable grid. As soon as you want to produce clean markup, styled as you want, performing some complex interactions, you'll end up wanting to pull your hair out. Disclosure: I've worked with webforms for around 4 years.

neilk 13y ago

The modern web app has gone way beyond the simple HTML page - now there are components in all but name, handling their own libraries, network connections, establishing model-view-controller separation, and communicating with other components via events. But it's all simulated out of the technologies originally made for web pages. One sign that things have gone very wrong: a lot of developers have to treat the web page as a kind of compilation target. We've lost the simplicity the original web had. The authors believe in a future where if you wanted a particular rich text editor in your web app, you could just put <my-rich-text-editor/> in there. Done. No web browser can do this stuff today, but libraries like Polymer are trying to bridge the gap between today's browsers and the way they may look in the future. As another poster mentioned, it's attacking the same problems as Angular.js, with a similar approach. Indirectly it's competing with pretty much every client side web app framework.

mindcrime 13y ago
No web browser can do this stuff today, but libraries like Polymer are trying to bridge the gap between today's browsers and the way they may look in the future. We should probably stop calling them "web browsers" at this point. We've basically re-implemented the idea of an Operating System in the browser, so we now have a full-fledged OS like Linux, BSD, Plan9, OS/2, Minix or whatever, being used to host a "poor man's OS" which is recreating most of what the base OS does! To say "things have gone very wrong" is a dramatic understatement in many ways. I still think we messed up by migrating away from the mobile-code approach for apps. But I largely blame Sun for that, as they screwed the pooch by shipping the Consumer JRE about 7 years too late, ignoring needed features for doing desktop and interactive apps (like modern audio and video codecs, etc.) and didn't stay on top of JRE security. Now, Java, which was probably the best "mobile code" platform that ever got mainstream traction, is basically dead as a client platform. :-( Browsers are great for doing what they were designed to do: Browsing hypermedia. But to shoehorn "remote application delivery" into the browser seems like a step sideways (at best) to me. We're layering hacks on top of hacks on top of hacks now, to try and recreate the "app" experience inside the browser. This strikes me as sub-optimal.
- deleted 13y ago

tosh 13y ago

Like Angular.js from an end-user/developer's perspective but goes beyond that. Instead of being a framework it is an effort to polyfill the actual Web Components spec. This means that Polymer will eventually be supported natively by browsers which means that in the future we'll have something like Angular without needing to do the heavy-lifting at the framework-level. :)

tosh 13y ago
Also if you are interested in Polymer but want to actually use it in production right now (like we to at Blossom.io) check out Dart's Web UI: http://www.dartlang.org/articles/web-ui/ http://www.dartlang.org/articles/web-ui/ It's like travelling to the future :)

just2n 13y ago

A "web component" is some stand-alone combination of HTML/CSS/JS that does some thing. It should not conflict with the application that uses it in any way. It should, however, allow the application to communicate with it (to modify its state) and to potentially change its appearance in a way that will not break the component. A problem with HTML/JS/CSS pre-shadow DOM is that it was impossible to actually build a component as described above. There was no way to sandbox the HTML/JS/CSS that's used to build the component from the application. There was always the possibility for contamination. What the specs that Polymer is intended to polyfill permit is a combination of this sandboxing capability along with other means of permeating this sandbox with the functionality needed for such sandboxed components to be truly useful (how useful is something you embed in your page then can't access/talk to at all?). This includes data binding, events, allowing parent CSS to apply to certain things (in a very explicit, named way, which allows the parent application to style the component in a manner the component creator deems appropriate, and not in a way that will break the component), etc. These standards, in effect, define features that once implemented will permit true web components to be built. For more: http://www.html5rocks.com/en/tutorials/webcomponents/shadowdom/ http://www.html5rocks.com/en/tutorials/webcomponents/shadowd...