The Forgotten Macro Language of HTML: XBL 2.0

tvlinux writes "The web is becoming more than just a media display; there is more interaction and more special things that need to be done. Right now, jQuery is the preferred method of a very dynamic user interface. There is a W3 standard called XBL2.0. It is the macro language of HTML. To me it seems like a great idea — reusable HTML widgets, where each one is a separate object contained with in itself. You can define properties, methods, and events, each of which is self-contained. If the browsers supported XBL2, I can envision a whole ecosystem of new widgets, charts, grids and inputs that people could add to web pages just like any other HTML element. I see less experienced developers being able to create fancy websites by just using DOM and not having to learn jquery. My question: why is XBL dead? I think a macro-language for HTML is a good idea." XBL is alive and well, but only for XUL. Looks like another casualty of HTML5's rejection of XML.

Comments

Good thing it's dead

[MaxToTheMax]

HTML, XML, and really the whole SGML family kind of suck-- ugly syntax, annoying to hand-edit, lots of boilerplate, and the list of faults go on. The idea of writing actual programs in such a language is terrifying.

Re:Visual Studio for ASP.NET

[TheRaven64]

This is how you do decent shilling. Everything he said is true, his problem was his omission. The MS stack does provide a reasonable MVC programming model for web applications. So do a number of other competing frameworks, many of which are more scalable, free (to deploy and to get the dev tools), cross-platform (do you really want to be forced to run Windows on your server? Even if you like the platform, you'll pay more if you want to deploy it in something like EC2 because of the HVM overhead), and which have been around longer.

Re:Why is it dead:

[dkleinsc]

"Short != Better" (TM)

Short sometimes == Better:
- Programmers don't have to spend as much time reading to figure it out.
- In studies, the ratio of bugs to code size is basically constant until the code is thoroughly tested. Minimize the size of the code, reduce your bug count.
- For network services, including HTTP, fewer bytes = fewer packets = faster response.
- Short is often simpler.

Compare the XBL shown above to the equivalent JQuery:

$.("li#nav").on( "mouseover", doSomething );

Which one would you rather read and parse?

Re:Why is it dead:

[Cenan]

Simplicity is in the eye of the beholder.
Your code does not contain fewer bugs because you put it all in one line. Your code contains bugs because it was, for the most part, produced by humans. And even the best developers will have an error rate > 0. Shorter lines does not magically boost reader comprehension. The quality and clarity of the code produced will however help you, no matter how many lines you're maintaining.

You can scream and moan all you want, the OP is still comparing apples and oranges, and so are you. I don't lament the forgotten-ness of XBL, good riddance. But that little tid-bit of XBL code in the OP is actually very very clear with regards to it's intent; maybe it's just me being way too familiar with XML style syntax.

If every byte counts, don't pick a framework that serves plain XML as responses, that's just retarded. Choosing the right tool for the job, is, well, part of the job.

And yes I got fed the same statistics about code size leading to more bugs in school too, and I thought it was self-evident back then too. More lines -> possibly more features -> more bugs. It is a very simple, but apparently so hard to grasp that studies had to be performed.
If you minimize your code base, you're going to have to cut out features, which in turn leads to comparing oranges and apples again because you no longer have the same product. Or are you saying that jQuery-minified.js is less buggy than jQuery.js?