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)?
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.
In the meantime, I'm quite excited by the idea of web-components, though the implementation is staggeringly unpleasant to look at.
- 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.
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.
Web forms was full of half-assed abstractions. Every postback it re-built your control tree and re-applied the viewstate, but any actual additions or removals of controls made in code-behind were not part of this rebuild and viewstate application, so it completely half-assed the control rebuild and thrashed its own abstraction. If you added a new control dynamically on one postback, you had to re-add it every postback, which demolishes the stateful model it presents with respect to the properties of controls.
<select id = 'menu'>
<option />
...
</select>
<x-item-editor item_key = "{{ menu.value }}"/>
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.
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.
I think that if we had known where we wanted to go, it may have been better to start the other direction, and make a web app API that basically allowed apps to contain documents. That would have avoided significant amounts of pain, and ended up looking more similar to what we have anyway -- web apps wanting or needing a larger and larger degree of extension-like autonomy and permission sharing with the browser.
The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man.
So who knows, maybe somebody reads one of my rants one day and goes "Hey, this mindcrime guy has a point... and furthermore, I see a better way to do this" and takes some initiative. Who knows what might happen?
Now, are the odds of that infinitesimal? Probably, but that's OK. I ran for public office (and lost) as a Libertarian, so that tells you what I think about odds. :-)
The people making games, applications, and lush webGL marketing demos are people who can throw lots of engineering resources at a problem until it does the thing they want it to do. Web dev has always been an insane mountain of hacks in order to get pages to render, but the attractive and democratic reasoning is that that extra effort is worth it if the maximum number of people can access the information. People on old computers, cheap smartphones, kindles, chumbys, whatever. The best computer is the one you have on you, that sort of thing. Access and ease-of-adoption are powerful things.
So that's why I see web components as something that enables people writing markup more than it empowers people writing giant javascript applications. This is so that people can add <twitter-tweet href="twitter.com/name">My Cool Tweet</twitter-tweet> tags to their wordpress blogs, and so that the people making that <twitter-tweet> tag can be confident that it will render and not look horrible on that person's blog. It's so that the complex, app-ish things can be abstracted away and added to documents with a declarative and logic-less syntax.
No amount of java applets would have ever made up for that.
Sure, and to the extent that Web Components do that, they are a good thing. Where I think we've gone a bit wonky is more on the "giant javascript applications" where we're using a great document delivery platform as a half-baked application runtime.
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.
:)
http://www.dartlang.org/articles/web-ui/
It's like travelling to the future :)
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...