[randomfool]

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]

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.

[polskibus]

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.

[Pxtl]

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.

[sgrove]

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]

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]

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.

[bsimpson]

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:

    <select id = 'menu'>
        <option />
        ...
    </select>
    <x-item-editor item_key = "{{ menu.value }}"/>

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.