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.

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:Visual Studio for ASP.NET

[Anonymous Coward]

No, the problem is that everything he said is off-topic

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?

Re:Visual Studio for ASP.NET

[Anonymous Coward]

To a small or medium business, setting up Linux is pointless. None of their software runs on it. You can complain to Intuit until they port Quickbooks and see how far that gets you. Or save your breath. Your choice.

Meanwhile, there are companies that will set up, administer, and maintain a Windows network for a reasonable monthly fee. $2k for full managed service is half the cost (or less) of a full-timer that can't do anywhere near that much work with that level of skill or expertise. Granted, that type of service isn't cheap enough for a start-up, but a small-to-medium enterprise (to clarify "SME" in the parent post) can afford it.

I happen to work for a company that does exactly this. We sell network management and maintenance contracts to businesses that don't want to have their own in-house IT department. A few of our clients have some Linux boxes on their networks, and we work with them with no problem. We also sell custom development work, mostly .Net. We could do Linux-based development, but, quite frankly, there's zero demand for it. I know this because I'm a developer, not a network guy. We've tried to sell development work to companies that already had Linux. All of them so far have opted to retire the Linux software they had been using in favor of custom .Net development.

YMMV.