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 m

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.