XUL, XBL, JS and DOM

JavaScript modules for web pages (think Yahoo UI widgets)?

3 Comments

This is just a wild idea I had, and I don’t have time to adequately explore it right now. So I’m throwing it out here to see what you think.

Mozilla Firefox 3.0 introduced several new ideas, including these two:

I love the concept of JavaScript modules (sharing common code) so much, I started thinking: wouldn’t it be nice to provide the same for web pages – a common location to load files that several websites might want available?

Of course, it’s a really bad idea to expose chrome JavaScript to content – scripts that won’t work, at least, and security holes at worst (if you’re considering passing objects from chrome to content, as I’ve been known to do). But that’s not what I have in mind.

Yahoo UI widgets are a library of fairly complex, JavaScript-driven user interface classes. They’re actually pretty useful. However, a site using them must provide bandwidth to download them for every page view that references them. That can add up quickly, which is one reason scripts like it are often minified. With a resource:// URI, you could take it further (no downloads at all, it’s already on the user’s machine!) – but how do you ensure that URI exists?

Build a Firefox add-on.

Imagine an extension’s chrome.manifest like this:

# Library for Yahoo UI widgets
resource library:yahoo-ui res/yahoo-ui

That’s all. Then you’d need a res/yahoo-ui folder in the extension which would hold the Yahoo UI widgets library.

A colleague last night correctly pointed out this doesn’t factor in versioning of Yahoo libraries. Plus, you’d probably need a generic loading library which would look for the resource://library:yahoo-ui/whatever.js file first, and go download the YUI files from the website if it isn’t there.

Another downside is that this really abuses the resource: URI protocol. I’d feel better implementing another protocol that would be more flexible and still web-safe.

On the plus side, the scripts in the library wouldn’t have to be minified anymore. From the perspective of debugging with Venkman, it is a royal pain in the butt to figure out why a YUI widget doesn’t work…

Personally, I’d rather not stop there. I’d rather make whole extensions that were restricted to content – specifying in their install.rdf manifest that they weren’t chrome extensions and that their packages lived in the browser’s sandbox for web pages. You could then specify global objects that would trigger exceptions if they tried to do anything outside what a webpage could do. (I keep thinking XPathGenerator could really have used that, just to assure everyone it was safe for 1.9.1.)
GreaseMonkey makes an attempt at this (a good one). I’m wondering if it’s worth promoting that capability into the main Firefox build.

Anyway, that’s enough white-boarding for the moment. I’m really sorry I don’t have time to delve any deeper, but work plus my own Verbosio project keep me too busy. Comments are open – feel free to tell me I’m crazy or that the Web doesn’t need this.

3 thoughts on “JavaScript modules for web pages (think Yahoo UI widgets)?”

  1. What you are essentially saying here is what drives me mad about the web. You are saying that a whole host of useful, and in some cases fundamental, UI components are simply not natively available to developers in the so-called web platform. Whilst desktop application developers merely have to click and drag fundamental components into their applications, web developers have to go through a whole process of deciding which library to use, trading off the weight of using more than one library or tolerating the often sub-par components available with their chosen library.
    A great example is jQuery UI. I love jQuery and I’m sure the jQuery UI guys work very hard but given that jQuery was one of the later libraries to hit the mainstream and jQuery UI was even later, they are really struggling to provide fundamental components that behave reliably. Do I include the core code of another JS library merely to get access to one component?
    It is realisations like this that make me laugh at the people who think the web is the future of applications. Native standardised UI components in browsers have not changed for a decade or more. Meanwhile Mozilla ‘progresses’ by constantly developing technology that will not ever be supported cross-browser such as canvas, SVG and so on. It’s one of the reasons I’ve abandoned the web as an application platform. People can talk about Web 2.0 and “cloud” computing as much as they like however when core components are not available web applications are still a compromised joke. For years we’ve heard about stuff like xForms and so on. For years I’ve been doing ‘the right thing’ by designing to web standards. However those standards are pathetic in that they do not form a framework within which a web application framework with basic UI components is possible.
    (From Alex: Profanities deleted. Keep your eye out for HTML 5, though. If I ever get back to working on it, you’ll see some small improvements.)

Comments are closed.