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.
In my opinion the worst thing about WebForms were statefulness almost everywhere and very complicated page lifecycle including the refresh of nested components. For small applications it's great, but has problems when you're trying a large, dynamic product. Composability is much easier with MVC, where you can link to controller actions instead of always depending on the way nested controls process postback events and rebuild themselves.
Exactly. I actually kinda liked the ideas behind WebForms - the ViewState thing was a clever way to shoehorn statefulness into the Web. But the abstractions in it were so leaky and brittle as to be worse-than-useless. The page lifecycle was a nightmare, data-binding was frustratingly finicky about types and parameters (and it was always a roll of the dice whether a given component would use empty strings or nulls to indicate an empty value) and so on.
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.
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.
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.
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.
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.
The web is still for documents. It's for a resource that lives at a URL. It's markup, not programming, and that's the very reason it has lived to be twenty years old and the main way that information is communicated. It's how we're able to hold this conversation right now — people are comfortable stitching together words in XML-ish constructs.
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.
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.
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.
For better or worse, the way software delivery has evolved on the web is that documents contain applications.
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.
Of course it's sub-optimal, nobody is arguing against that. But from where we are today, there is no other way forward. There's not going to be another technology suddenly spring up that will replace the browser and allow websites as well as apps to run on any device in a matter of seconds, without installation simply by typing a short address and hitting enter. We're layering hacks upon hacks, but you'll just have to deal with it and stop complaining at some point, because no matter how much you'll complain it won't change.
There's never only one way forward. Besides, how does the old saying go:
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. :-)
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.
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.
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.