Component Model XBL HTC

From RuntimeWiki

Jump to: navigation, search



Component Model XBL HTC

Detailed write-up


The UI widget sets in existing Ajax toolkits generally require each toolkit to implement their own component model in JavaScript. This is because browsers have not implemented a common component model technology. Mozilla implements XBL1 and IE implements the not-yet-sufficient HTC technology. W3C is developing the XBL2 spec.

Note that if future browsers implemented a common component model capability, it would be highly difficult for existing Ajax toolkits to take advantage of such a feature. In many cases, the architectural approach used by existing Ajax toolkits is misaligned with XBL and HTC, and even if there were alignment, the migration costs would be very large, and Ajax toolkits would still need to support older browsers that do not yet support the industry standard component model.

Why Is This Important?

Longer-term, this would enable Ajax toolkits to deliver smaller, faster, more powerful capabilities to web developers.

What exists today?


In this section, the contributors should express their opinions about this feature request, such as providing particular technical analysis or describing in prose why this feature is important (or not). It is recommended that each contributor create his own level-3 sub-section (e.g., === Jon Ferraiolo Comments ===).

It is OK for others to insert comments within other people's sections, but as a courtesy please make sure that it is clear which part of the section is original and which section are annotative comments. For example, perhaps annotative comments would be colorized (e.g., enclosed by <span style="color:red">JON: Here is what I think about what you are saying.</span>).

Jon Ferraiolo's comments

Future browsers should implement a common flavor of XBL, but the primary reason is for long-term industry benefit. Most of the Ajax community will not be able to leverage XBL until old machines retire.

Brad Neuberg's comments

Browsers should just implement XBL 2. Its not perfect, but its based on alot of experience with Microsoft's behaviors and XBL 1 and is fully specified.

One thing: if browsers implement XBL 2, we should make sure that its actually performant. If we want to use XBL to create a new widget type, for example, and there are 100 instances of that widget on that page (possibly even thousands), will the browser fall over? What will startup time for the page look like? When I scroll the page will it take five years to scroll down? You can't make an extension mechanism like XBL and then ignore performance or you are dooming it to irrelevance.

BTW, I disagree with Jon that XBL 2 won't be usable by Ajax toolkits today. The Dojo project, for example, has been a leader in using (abusing ;) browser features like this as soon as we can get our hands on them.

Phase I Voting - Vote for Your Top 5 Features

NOTE: PHASE I VOTING IS NOW OPEN. (2008-04-01) We have now changed the voting procedure. Instead of putting votes on each separate wiki page, we are asking people to cast their Phase I Votes on the following wiki page:

Phase II Voting

More about this later.

Personal tools