Tuesday, July 15th, 2008

XBL 2: The component model is coming to WebKit and Gecko

Category: Apple, Standards

Wouldn’t it be nice if we actually had a decent component model? Instead of making JavaScript frameworks have to mess around and try to create one on top of the crud they have to deal with?

This is what XBL 2.0 is all about. I talked about XBL in one of my Web Archeology posts, and how Jonas Sicking of Mozilla was back working on the implementation for Firefox.

In WebKit land, we can now see that Julien Chaffraix is making it happen with very current commits.

This means that fairly shortly we will have Firefox and WebKit/Safari running with XBL 2 support. That in turn means that we will have an interesting component model for the first time, and who knows where that could lead us!

Posted by Dion Almaer at 7:23 am

4.2 rating from 24 votes


Comments feed TrackBack URI

Wow, great news – XBL is amazingly powerful. Of course, Gecko’s (Firefox) XBL implementation has a few differences from XBL 2.0 – good to know that’s being worked on too.

And I just happen to be messing around with XBL code at the moment, too.

Comment by Unfocused — July 15, 2008

Very nice catch, Dion! Looks like the XBL2 thing is in a WebKit branch, but hopefully soon that will make it to the regular nightlies.

Comment by codedread — July 15, 2008

“Wouldn’t it be nice” sure. But in my opinion it solves the mess with another mess.

As far as “ability to associate elements in a document with script, event handlers, CSS, and more complex content models”, sure but it introduces much more complexity and abstraction.

For me it gets an “interesting” note, more use cases and a better description of the problem and how XBL 2 solves that problem would help.

A start is here but I’m not convinced of the added value not to mention processing impact on browsers

Comment by jbondc — July 15, 2008

There is a cross-browser implementation of XBL 2.0 technology with all technological dependencies: http://code.google.com/p/xbl/
It works fine on all browsers (with a principal limitation of rendering shadow content into the hosting page, however you won’t run into the trouble caused by that in practice).
Check it out for your inspiration on the upcoming native support.

Comment by caston — July 15, 2008

>That in turn means that we will have an interesting component model for the first time, and who knows where that could lead us!

Component model has been present in “browsers” since ever – take HTC in IE, or XBL (1.0) in Gecko.

Comment by caston — July 15, 2008

A good component model is really a requirement before the open web technologies can assert themselves as a capable application platform. Many javascript frameworks have tried to fill the gap, and have taken us pretty far, but built in solution would not have the same limitations. Anyone who looks at this and asks “yeah, but what about performance” is missing two pretty obvious details.
1) We are already doing it with javascript. I really doubt this is going to be slower.
2) XBL (not XBL2) is used natively in firefox with XUL. It was built FOR XUL. That doesn’t necessarily mean blinding speeds, but if it works for them, its probably good enough (performance wise).

However, while I do think it would be great to have, because something is better than nothing, I don’t really find it the paragon of elegance. The syntax seems pretty kludgy, and while it does allow the use of javascript, it doesn’t integrate very well. I think this is a sore spot for open web technologies in general. Graceful degradation is very nice, but at some point, to reach the next level of application development, you need to be able to unify the parts. I want components that can really unite my html/css visuals to a javascript object with methods. I don’t think adobe got it perfect, but the Flex component model is actually pretty nice.

In the end, whatever happens, I think it’ll be a good thing, and if nothing else, existing js libs can wrap it with nicer syntax.

Comment by genericallyloud — July 15, 2008

Based on XML? No thanks.

Comment by spyke — July 15, 2008

Awesome. Finally a way to abstract interface from content.

Comment by Gordon — July 16, 2008

Leave a comment

You must be logged in to post a comment.