Slashdot Mirror

This is exactly the problem, browser sniffer should not sniff for products but for render engines.

*beep* Wrong. UA strings can be forged, so relying on them is not advisable. Instead one should detect browser features.

If even Google, a very reactive company when web security matters

Google are among the worst when it comes to being reactive. Example:

For over two years Google has had an script insertion flaw, I reported it two years ago, and again a couple of months ago, but still it's not been fixed.

There's a decentralised RDF-based "Semantic Web"-type version in the form of FOAF. You can already browse it with software like FOAFnaut etc, and generate your own FOAF file with FOAF-a-matic. There was a crawler called Plink, but that seems to be dead now.

Javascript Closures: has a nice tutorial. In this case specifically, you can follow the event-handler system he's created. You could also look at the prototype.js library, specifically the "bind" function (function extension).

foo.onclick = this.DoSomething.bind(this, arg1, agr2);

Now onclick executes "DoSomething" using the current "this" as the context, and stores the args. Not only is this very useful, but it avoids the memory leaks in IE caused by combining inline functions, DOM elements, and closures.

I still don't think I truly understand how RDF is supposed to work...

I don't think anyone does.

RDF's core idea is simple. Give everything a URI. Express relationships as a set of three URIs, (subject, property, value). So you might have (#me, #friend, #bob) expressing the idea that Bob is a friend of mine. Or you might have (#photo, #contains, #me), expressing the idea that I'm in a photo.

RDF is little more than a mechanism for expressing relationships. It doesn't give software the ability to understand those relationships, you need to build that on top. RDF just helps you solve the relationship problem in a generic way. So, for example, even if you have (#me, #friend, #bob), that's still meaningless until you write software that knows the #friend, #spouse, #employer, #whatever URIs are relationships between people. For instance, you could build a social network like Friendster, only decentralised - and people have, with FOAF, because they've agreed that particular URIs express particular relationships.

Javascript has a concept known as closures (basically function objects), which when created inherit the scope they were created in, in the form of the scope chain. This scope chain can keep pointing to variables long after a naive reading of the code would seem to conclude nothing is pointing to them (by all references to them having explicitly be set to null). This in turn causes memory leaks. This is not a bug, but is behavior that is mandated by the ECMAScript standards, which firefox tries to aspire to.

I've run into this problem myself in an actionscript (flash) application, where I initially blamed flash for my memory bloat, until I learned that it was my own weak understanding of closures that was the cause.

Since firefox extensions are written in javascript, I expect that a lot of them have memory leaks in the form of ill-designed closures, which would cause the firefox process to bloat, even though the firefox developers are not at fault.

Good suggestion! I would supplement it with the following as well:
1. Episodic Learner Model/An online Lisp tutorial
2. Common Lisp: A Gentle Introduction to Symbolic Computation
3. How to Design Programs
4. Practical Common Lisp
5a. The book - Structure and Interpretation of Computer Programs
5b. The movies - Structure and Interpretation of Computer Programs
6. Loving Lisp - the Savvy Programmer's Secret Weapon
7. Common Lisp the Language, 2nd Edition
8. On Lisp
9. common lisp: a web application tutorial for beginners
10. JavaScript: The World's Most Misunderstood Programming Language
11. Free JavaScript Learning Center
12. JavaScript for Scared People
13. JavaScript Closures
14. Why's (Poignant) Guide to Ruby

= 9J =

IBM's JavaScript articles are usually high quality. But this one is awful. It uses invalid code, it doesn't degrade gracefully, it mixes HTML, CSS and JavaScript into the same file instead of separating them, and it breaks when you try and do things as simple as open a link in a new tab.

Don't be fooled by the "senior software engineer with more than 20 years of experience" author, this guy doesn't know the most basic, newbie things. I can only imagine that his 20 years of experience was with something other than HTML, CSS and JavaScript. For example:

• The code doesn't use a doctype line. Not only does that preclude basic QA in the form of validation, but it kicks browsers into "quirks mode", which screws up CSS rendering.
• The code uses href="javascript:...". This is stupid and wrong.
• He just dumps content out wherever he likes, hides it with CSS and then shows it with JavaScript. So much for backwards compatibility. When CSS is not available, you'll just get random bits of content scattered throughout the page.

That's just the tip of the iceberg. This is an exceptionally poor article.

That's probably not a leak. You probably grew the scope chain by inadventently creating nested closures. I wrote a web app which was sensitive to this, and managed to trim its runtime memory footprint up to 100 megs by being more careful about how I use closures.

Google have shown repeatedly that they don't understand how to deal with Javascript securely. Example.

Please don't promote that awful tutorial. It makes two classic newbie mistakes: javascript: hrefs and browser detection. These are stupid and wrong. Yes, I know Rasmus is a hot shot PHP developer, but his Javascript sucks.

No, it's not a nice platform. I can assume you've noticed this based on your "it's decent enough" comment. It's a horrible platform.

Decent enough for browser plugins. Decent enough if you are building an application that is very closely related to browsing. I wouldn't choose it for building general-purpose applications, no.

I recently discovered that JavaScript supports closures - which helped explain the horrible memory leaks I was experiencing with JavaScript. Stuff that was supposed to leave scope didn't because it wound up in a closure.

Well no, you might expect it to leave scope, if you assumed Javascript worked like some other language that doesn't support closures, but that's not the way Javascript works, so it's not supposed to leave scope.

Unfortunately for me, I've never figured out exactly WHAT the closure takes with it.

Richard Cornford wrote a decent explanation.

XUL is supposed to make cross-platform support easier. Instead it ensures that Firefox just feels wrong on all platforms.

I think that's an implementation detail rather than anything intrinsic to XUL itself. There was an experimental "KaXUL" to implement XUL within KDE and Konqueror a few years back, but I don't think anything came of it. As far as I know, there's nothing stopping a XUL implementation from rendering XUL applications with native widgets, it's just the people who built the only functional implementation chose not to.

Firstly, this is not news. This was posted on the IEBlog way back in September.

Secondly, this is one hell of a misleading headline. Internet Explorer has supported this interface since Internet Explorer 5.0, released in the year 2000. All that's different in Internet Explorer 7 is that it's implemented as a native object, rather than with ActiveX.

Finally, this matters to practically nobody. Any decently-written code will work just fine in Internet Explorer 7 with no modification whatsoever. Even code written to use browser detection instead of feature/object detection, (a bad idea) will work just fine, assuming that the ActiveX interface sticks around too.

The WebDeveloper Extension in Firefox even has "no XMLHttpRequest" coming as a feature to help testing in this area.

I find it's easiest just to put return false; at the top of the instantiation function or similar and then run through all the browser testing once more.

While I'm waiting I have the UserAgent Switcher telling my site which features to think I have.

That sounds like you are using browser detection instead of feature/object detection. Read more here.

They've had others in the past, but were quick to fix them.

Not true. Google ignored a security hole for two years and don't understand Javascript well enough to fix it properly.

They've had others in the past, but were quick to fix them.

Not true. Google ignored a security hole for two years and don't understand Javascript well enough to fix it properly.

That's not a problem unless you are using the old-fashioned style of Javascript where you have to manually assign handlers in the HTML. What's wrong with using closures?

function myClass()
{
    this.m_str = "poo";
 
    this.doAlert = function doAlert()
    {
        alert(this.m_str);
    }
 
    this.func1 = var function func1()
    {
        var obj = this;
        var fn = function doAlert()
        {
// Use a local variable from the closure. This
// restores the this point so that it can be used
// in the function that we call
            obj.doAlert()
        }
 
        setTime(fn, 10000);
    }
}
 
var myObj = new myClass;
myClass.func1();

As for Google News, one reason it remains in beta is that it has no business model. If Google tries to put ads on Google News, the newspapers and magazines whose stories are listed on Google News would probably file lawsuits, alleging that Google is trying to profit from their content. Google's emergence is a threat to the major media outlets that represent much of the content on Google News, and some folks in the news business believe it will remain in beta untilthis problem is settled.

Google is incredibly slow.

Definitely. Google ignored a security hole for two years and don't understand Javascript well enough to fix it properly.

Google is incredibly slow.

Definitely. Google ignored a security hole for two years and don't understand Javascript well enough to fix it properly.

Not really. Some authors have explored other ways of submitting asynchronous requests to the server, involving iframes, images, stylesheets or other scripts. Basically, any sub request that does not involve reloading the main page should work.

And then, XMLHttpRequest itself is a kind of a misnomer. It doesn't necessarily involve XML, and there are actually non-XML data languages which are better suited for the purpose. It's actually a mystery why they didn't simply call it HttpRequest, maybe they needed to reach their monthly buzzword quota?

It's sad that Rasmus Leodorf, one of the main PHP developers, is so utterly clueless about Javascript.

Don't use href="javascript:"

Take Gmail. It's clear, concise, and uses Basic HTML to navigate.

The special version provided for older browsers does. But normal GMail certainly doesn't. It's really frustrating to try and open links in new windows only to find that they aren't links at all but some kind of pseudo-link created with spans and onclicks that doesn't work properly.

Google really don't have a clue when it comes to Javascript. Yeah, they come up with good features, but their implementation sucks. For example, it took them two years to fix a relatively simple Javascript security hole in their site, which could have allowed phishers to use Google to con people.

Frankly, DHTML is just the web-equivalent of "Feature Bloat".

Er, GMail uses what most people describe as "DHTML". You are saying GMail is better because it doesn't use something that it does, in fact, use.

I saw DHTML in practice when Barryworld still existed. The DHTML interface was so slow, and so horrible (Even on a 4MB Line, with Dell Optiplexes)

You know how GMail is so much faster than most other webmail services? That's because they use DHTML.

You've got some very odd ideas about DHTML. All it is is Javascript that alters the composition of a page. There's nothing inherently slow about DHTML; in fact in many cases, DHTML is used to speed up web applications.

javascript != functional programming? What does that mean? You can't do functional programming in javascript? Javascript functions are first class objects. Javascript supports closures. Now, javascript isn't a pure functional language, but neither is Lisp or ML (or any of their dialects), but nobody claims Lisp or ML are not functional languages.

Oh, I get it. Javascript isn't a functional language because Wikipedia doesn't mention it as a functional language. Yeah, that must be it.

Disclaimer: I don't program in javascript and I don't know javascript very well, but I do know that javascript supports the functional paradigm rather nicely.

The type of garbage collection Internet Explorer uses screws up when you use ActiveX objects (e.g. XMLHttpRequest) or the DOM. More information is available from the comp.lang.javascript FAQ notes.

Personally, unless I'm writing a web application, I say screw the users that use that substandard browser. Their browser will eat up more and more memory until they crash on some other website. This would have been fixed four years ago if Microsoft hadn't killed Internet Explorer development once they cornered the market.

This page indicates that XMLHttpRequest has been available in Mozilla since at least April 2002. I don't think Safari even existed outside of Apple at that time, and almost nobody cared about Opera- Opera 6 was pretty useless wrt JavaScript anyway, and Opera 7 wasn't released until 2003.

Also, there are several other ways to implement asynchronous JavaScript- Google Maps, one of the other widely hailed examples of AJAX, does not use XmlHttpRequest at all.

There's a nifty way to avoid having to maintain global references using JavaScript closures, which most people don't know about:

xmlhttp.open("GET", "test.txt",true);
var myObject = this;
xmlhttp.onreadystatechange = function() {
if (xmlhttp.readyState==4) {
myObject.doSomething(xmlhttp.responseText);
}
}
xmlhttp.send(null);

So, the onreadystatechange function can access the 'myObject' variable like its a local variable, so that it could call back to that object when things are ready. JavaScript has full closure support:

http://jibbering.com/faq/faq_notes/closures.html
http://www.forum4designers.com/archive22-2004-8-10 9835.html

Very powerful feature. Make sure to read a limitation of closures on IE:

http://jibbering.com/faq/faq_notes/closures.html#c lMem

Some boundry conditions of using them on IE can lead to memory leaks.

There's a nifty way to avoid having to maintain global references using JavaScript closures, which most people don't know about:

xmlhttp.open("GET", "test.txt",true);
var myObject = this;
xmlhttp.onreadystatechange = function() {
if (xmlhttp.readyState==4) {
myObject.doSomething(xmlhttp.responseText);
}
}
xmlhttp.send(null);

So, the onreadystatechange function can access the 'myObject' variable like its a local variable, so that it could call back to that object when things are ready. JavaScript has full closure support:

http://jibbering.com/faq/faq_notes/closures.html
http://www.forum4designers.com/archive22-2004-8-10 9835.html

Very powerful feature. Make sure to read a limitation of closures on IE:

http://jibbering.com/faq/faq_notes/closures.html#c lMem

Some boundry conditions of using them on IE can lead to memory leaks.

The idea behind Ajax *does* revolutionize the web paradigm.

Don't be silly. It's a nice optimisation. It's very useful, and I use it a lot, but it's not revolutionary.

For example, rather than load a form, and all the form formatting to make the text fields line up correctly, and all the validation code to validate that form, you load a series of XML tags that contain only the basic information needed to tell the client how to lay out the form.

Huh? An external stylesheet and generic script loaded from cache means the only thing you need in your HTML are the form controls and a couple of regexps to drive the script. You want to replace that with dynamically loading XML? That's over-engineering that reduces quality.

The client takes care of generating the HTML for the form

Sounds like you've just made your application dependent upon Javascript. That's not good practice, and law requires an accessible alternative in many places, so you either don't do this, or have to code the functionality twice, once with Javascript, once without.

Those who have used good Ajax sites (google maps, gmail) should understand the power behind it, and these sites only break the tip of the ice berg.

Have you actually looked at the gmail code? It's hideously bad.

For me, the crux of the usefulness and eventual adoption and finally complete embracing of AJAX lies in the article's paragraph:

Some of the buzz surrounding AJAX has been generated by Web designers as well as programmers. AJAX?s flexibility is invigorating for Web designers because JavaScript can control any aspect of any images or type on a page. Fonts can grow or shrink. Tables can add or lose lines. Colors can change. Although none of these capabilities are new to programmers accustomed to building client applications -- or, for that matter, Java applets -- they are novelties to Web designers who would otherwise be forced to rely on Macromedia (Profile, Products, Articles) Flash.

I've seen what Google has done with AJAX (e.g., Google suggest), and it's stuff I never imagined could be so repsonsive in a web context. For me it starts to make programming fun again, and web programming an acceptable form of application development.

When browsers and web first emerged I could see the writing on the wall, but I wasn't happy about it. Browser application writing from the programming perspective was probably the single most giant leap backwards in technology for me (not including technologies introduced by Microsoft)....: you mean, all the years I've spent honing skills writing applications no longer apply? You mean I no longer have "state" as a tool for maintaining sanity in my application???? Hwaahhh??? I have to do what to change the web page???

While there have been some technologies (ASP, JSP, etc) to help with these issues, none have addressed the responsiveness issue with the web page round trip message loop. AJAX comes close. Now all I have to do is learn it.

For a great example of the responsive nature of this (I've referenced this before), go to Google Personal Home, set up your own home page, and play... Configure your modules by dragging them around... open and close your g-mail previews. This all starts looking alot like programs actually running locally on your own machine. (I'm assuming all are familiar with and have played similarly with Google Maps.)

Additionally, here are some very good resources to learn more about AJAX:

• Very Dynamic Web Interfaces
• XMLHttpRequest Introduction
• An example
• Using the XML HTTP Request object
• Dynamic HTML and XML
• XMLHttpRequest API madness
• Sarissa
• JavaScript: The World's Most Misunderstood Programming Language
• What kind of language is XSLT?

That's it, I'm done.

DHTML is still hard and mostly poorly documented.

Perhaps it's hard for an HTML monkey, but it's not for the average programmer who has been doing it for a few months. It's extremely well documented, the only real difficulty is in knowing which parts are supported by which browsers.

Try this though: Make an iframe window that simulates a regular window.

Define "regular window". When I'm running Firefox on Linux, my close button is on the top left. When I'm running Firefox on Windows, my close button is on the top right. When I'm running Opera, it's inside the main Opera window.

This has nothing to do with DHTML being difficult, and everything to do with a web developer trying to do something that is inappropriate for the web (since windows are operating system specific).

Some of the toughies are the event handlers for these browsers which are quite different. I've written code to make them both work with one code base but there is virtually no documentation on this.

Internet Explorer is documented on MSDN and Quirks Mode, and every other browser follows the DOM event model which is documented at the W3C's website.

Ironically, code re-use on JavaScript seems to be very low.

Look up the meaning of the word "ironic". You might have meant to use the word "surprisingly"?

Code re-use is very popular with Javascript, although it's of the form of searching for a script that does something, and copying it to your website - something that only newbie scripters do, or scripters with no intention of learning.

You don't generally build up giant libraries, simply because you have to be concerned about how long it will take to download them.

By the way, if you need evidence that cross-browser DHTML is hard, it even took Google a while to get Firefox compatible with GMail. Think how much cash they've got.

They may have lots of cash, but they haven't hired anybody who knows much about Javascript. They make loads of newbie errors. Even the maintainer of the comp.lang.javascript FAQ criticises them.

this was in my bookmarks. you can use the HTTP request to call a script (in turn accessing a database), or whatever else you want to do...

I'll be more impressed by something Opera says about compatibility when they fix their own issues--particularly their shoddy XMLHTTPRequest implementation.

data.open("GET",url,true);

The "true" as the third argument sets it to async according to this page.

B

somebody should tell this guy who wrote about this in 2002, or some of my old coworkers, who have been doing similar application development using frames instead of xmlhttprequest since about 1998.

It seems like ever since google released gmail, everyone has suddenly been preaching about the next wave of web applications. give me a break.... i don't mean to slam google- the interface on gmail is definitely amazing, and they should be proud of themselves. but revolutionary, it is not.

For the love of dog, please don't spread this brain damage any further!

Compare and contrast:

<a href="javascript:popupandgo( 'http://www.example.com/' );">text</a>

<a href="http://www.example.com/" onclick="return popup();">text</a>

One of them works with Javascript switched off. One of them is utterly broken with Javascript switched off.

One of them is readable by search engines. One of them is invisible to search engines.

One of them can be read by automated link checkers. One of them will make them bail out.

Stop spreading href="javascript:..." brain damage!

Err?

XMLHttpRequest is part of Javascript and is supported in mozilla and safari and Opera. You might be thinking of the Microsoft.XMLHTTP ActiveX object that has been repeatedly nerfed for exploitable bugs?

ECMA standardised javascript a good few years ago, there are 10 or more interopable implementations and are highly conformant to the specfication.

The crashing, you appear to be confusing the DOM and javascript, not surprising it always happens with muppets who flame something without actually bothering to check basics.

At least you're right not to trust scripts run on your computer, but you're free to have the scripts reviewed by people you trust. If you really want to look at the Script engines themselves, then Mozilla, Safari, IE etc. all have public access to the source code. Opera doesn't so best not to use Opera, but then what security minded person would be?

Google doesn't need to know much HTML. [...] The real Google innovations are ways of ranking pages

These are two conflicting statements. HTML contains many pieces of information that Google could utilise to rank pages better. For example, keywords within strong, em and heading elements tend to be more important.

The sad thing is, Google really don't seem to employ expert web developers. The rudimentary HTML and CSS they use for most of their websites could be improved upon in myriad ways - often with the result of saving bandwidth and speeding things up. And as cute as their uses of XMLHttpRequest are, they've recieved a lot of criticism wherever they use Javascript.

Their data storage and parallel processing stuff might be innovative, but they can't even comply with the W3C specifications or implement best practices when it comes to anything visible to the public.

There's a server-side bug in Google search as well.

After looking at their rather obsfucated javascript code it seems that they (as I suspected) use XML HTTP Request

Google seem to use this alot (it's what makes their gmail interface so fast) but I haven't seen used much in other web applications which is a strange because it makes server interaction a lot faster.

That was mine, that one has since been fixed http://jibbering.com/2004/10/google.html -I know of a couple of others though which have yet to go public.

I agree it's googles responsibility, and some of the flaws that are th ere aren't the bugs of people who understand the issues - one of the google desktop bugs is because a search for <script>alert(1)</script> is written straight into the source of the document unencoded!

That's not a bug of developers who know what they're doing, or have good security procedures in place. I think they need a lot of publicity so like MS can start getting a real culture of security in.

That was mine, that one has since been fixed http://jibbering.com/2004/10/google.html-Iknowofac oupleofothersthoughwhichhaveyettogopublic.Iagreeit 'sgooglesresponsibility,andsomeoftheflawsthatareth erearen'tthebugsofpeoplewhounderstandtheissues-one ofthegoogledesktopbugsisbecauseasearchforalert(1) is written straight into the source of the document unencoded! That's not a bug of developers who know what they're doing, or have good security procedures in place. I think they need a lot of publicity so like MS can start getting a real culture of security in.

Isn't this like, a nasty "M$" exploit for "Windoze" twit? Paraphrasing you, I wonder why people keep using Linux cruft!?

What is with you people and thinking that Gmail is using ActiveX with IE??? IT DOES NOT USE ACTIVEX.

The GMail interface uses HTML, with Javascript doing the DOM manipulation (as you correctly state). It also uses XmlHttpRequest to get content (such as the full email) from the server via Javascript - that's why you see your email on screen without the page reloading.

Internet Explorer's implementation of XmlHttpRequest is done using an Active X component.

Gmail works with the new version of Safari mainly because that version also now supports XmlHttpRequest. Opera 7.6x is starting to support XmlHttpRequest too - its buggy at the moment.

There are simple technical reasons why readers will have noticed a discrepancy in the speed of Hotmail vs Gmail. Hotmail is built around a traditional client-server page model, i.e., the page reloads each time you do anything, along with all the unchanging 'boilerplate' page elements such as menu, ads, footer, etc.

Gmail, on the other hand, employs some beautiful client-side page loading techniques that mean that reading a message/switching to a different folder, etc., generally doesn't require a page refresh. The page simply queries the server for only the information that has changed (via XMLHTTP) and updates the page via DHTML. The result is a much snappier browser experience; the downside is increased min browser requirements (no chance of working in NS4, etc.).

XMLHTTP has been around since early 2002; it is primarily due to web developer laziness that has held-back more wide-spread use of this technique to improve the responsiveness of today's web applications.

For example, I have used javascript in an href to do the following:

Javascript in an href? Clueless developer alarm bells are ringing in my head. Let's see:

Open a new window

Presumably you'll be loading a resource into that new window. This means that the href attribute should be the URL of the resource or an adequate fallback, and the onclick attribute should be used to do your annoying Javascript stuff. That way it works with Javascript off or unavailable, rather than being a broken link.

Open a new window to a specific width and height

Ditto.

Change the location of the current page

Silly me, there I was thinking that a simple HTML link does that already.

Change the source of an image on the page

If you aren't linking to anything, why use a link in the first place?

This is basic stuff. Read the comp.lang.javascript FAQ.

It's not exactly sockets, but you can do an awful lot with the XmlHttpRequest object. Microsoft did it first, I think, and Mozilla has a complete clone. Check out the XulPlanet documentation, the Mozilla documentation, the Microsoft documentation or this tutorial called Using the XML HTTP Request Object

The XmlHttpRequest object is poorly named. Really you're just making an HTTP request, and if the response happens to be XML, there are convenience functions for getting a fully-parsed DOM view of the document. If the response is anything else (plain text, JavaScript, Perl, HTML, etc.) you can do what you want with it, including calling eval() on it from a JavaScript script. You can do synchronous (blocking) or asynchronous (non-blocking) calls to your web server, and either be notified of completion by a callback for non-blocking calls, or just treat it like a function call for blocking calls. It's quite handy, and we have a project at work that makes extensive use of this technique. We have a "thick" or "rich" client application that runs in the web browser. Our client looks like a native application--it has table widgets, with clickable headers that resort the columns, it has a tree widget that looks like the tree in Windows Explorer, it supports drag-and-drop and custom context-menus, and if you open our application in a chrome-free browser window, it's almost possible to forget it's not native (the speed is usually what gives it away, the GUI is a little sluggish...). It works equally well in Mozilla, Firefox, IE 5.5+, and Netscape 7.1+ on Windows 9x, 2000, XP, and many flavours of GNU/Linux (tested on Gentoo and Redhat 7.3, and 8.0 using GNOME, KDE, and some kind of *Box wm). Well, "equally well" is a bit of a stretch. IE's implementation of the DOM is dog slow, so some things run a bit faster in the Gecko-based browsers, but all functionality is equally available in all the configurations listed above. We've managed to stay standards-compliant for the most part, and have abstracted away the quirks in IE, so as soon as Konqueror, Opera and $YOUR_FAVOURITE_BROWSER fully support JavaScript 1.5, DOM 2.0, and CSS 2.0, our app will work in your browser, too. (I don't know which parts these browsers are missing, so maybe our app already works there.)

The only remaining hurdle is to convince management that it should be open-sourced so that other people can use it, too. If you can't wait, you might want to check out SourceForge. There are some other widget kits available for building browser-based apps. We chose not to go with them because, at the time, they were too Alpha-ish, and we disagreed with some design decisions. Our decision not to use those projects has not been revisited for a while though, now that we are rather comitted to our in-house implementation, so things may have improved significantly since the last time I had a look.

Also, if you're going to actually build any significant JavaScript apps (we have more than 40k loc that turns out to be more than 1 meg of JavaScript to download), I highly recommend JSDoc. The main developer, Gabriel, has been very responsive and helpful, and the documentation that his scripts produce is excellent. Especially considering he builds JSDoc in his spare time, I can't compliment his work enough. Now that our codebase is too large for me to keep it all in my head, the API has saved a lot of my time.

Ian

Slightly OT, I suppose, but you can already achieve the getURL() functionality with both Mozilla and IE in plain HTML + JavaScript pages (I don't know about Opera or Konqueror, or any other non-Gecko based browsers). IE exposed an ActiveX object to its script engine called XmlHttpRequest in about version 5.0 or so, and the Mozilla crew have cloned its functionality.

Some marketroids have called this 'inner browsing'.

Check out Microsoft's documentation on the XmlHttpRequest object, or Mozilla's version of the same thing.

Also see this document entitled Using the XML HTTP Request object.

You can also use the DOM-standard createDocument method that takes a URI as an argument if you don't want to or can't use the Microsoft-inspired XmlHttpRequest but this approach only allows GETs and not POSTs, and it forces the return to be XML, whereas the poorly named XmlHttpRequest gives you access to the entire HTTP response so you can read the plain text if you want to.

Ian