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)?
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.
They also allow you to plug the inputs of one component into the outputs of another in a declarative way with model-driven views. So, if you have a menu that allows a user to choose a piece of data to work with, you can do something like this:
I haven't used the library yet, so I'm sure the syntax is wrong, but you can see how x-item-editor can know which item to edit by consuming the select's value property, without needing any glue in the JS.
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.
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.
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.
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.
randomfool|12 years ago
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|12 years ago
bsimpson|12 years ago
neilk|12 years ago
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|12 years ago
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.
tosh|12 years ago
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|12 years ago
http://www.dartlang.org/articles/web-ui/
It's like travelling to the future :)
just2n|12 years ago
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/shadowd...
ilaksh|12 years ago
dmragone|12 years ago