[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.