Wednesday, June 24th, 2009

MooTools: Saving the dollars, replacing document.write

Category: JavaScript

The religion behind a simple $ has been fierce in the Web world. MooTools has decided to make the Dollar Safe Mode which is similar to cousins such as jQuery.noConflict (in MooTools case it just looks for the $ function). Now you can just use if you want to play in the wild, or wrap up in a closure to be nice:


  1. (function(){
  2.     var $ =;
  4.     this.X = new Class({
  5.         initialize: function(element){
  6.             this.element = $(element);
  7.         }
  8.     });
  9. })();

Please note that MooTools will probably remain incompatible with other frameworks that modify native prototypes, as there will probably be more name clashes. This isn’t a cross-framework compatible MooTools version by any means, nor does it want to be. The whole point is not to “steal” the dollar function from other libraries.

In other MooTools news, MooTools Core Dev Thomas Aylott (subtleGradient) shows another example of overriding document.write():

I created a replacement for document.write that saves the arguments and then injects them into the page after the dom is ready. This is useful for embedding gists on your page since you can use the additional filter option to reject stuff from being written to your page. This would also be really handy for sites that include JavaFX or certain ads or anything that requires the use of document.write on your page. By deferring the injection of that stuff until after the dom is ready your visitors see the page content before any of the extras like Java applets or ads begin to load.

Posted by Dion Almaer at 6:28 am

3.6 rating from 38 votes


Comments feed TrackBack URI

We actually use “Ra.$” to avoid name-clashing in Ra. In fact everything we do is within the “Ra namespace”. Like “Ra.klass” (instead of Object.extend like prototype etc) and it really doesn’t add that much of overhead, so I don’t understand why not more Ajax Framework developers does this.
In fact part of the reason why we choice the “Ra-Ajax” name was because Ra was only two letters and would carry significantly less browser/JS/bandwidth overhead then e.g. “Supercalifragilistic Ajax Framework” would do … ;)

Comment by ThomasHansen — June 24, 2009

The big problem with replacing document.write the way Thomas Aylott describes is that it breaks expectations. document.write is not equivalent to innerHTML, it sends its argument to the currently running HTML parser, to be parsed as if it were actually in the page just after the <script>. With the regular document.write, one can write:


while this will obviously fail with the replaced version (leading to the options vanishing at parse time, and then an empty select box being added on DOM ready)

Comment by tbroyer — June 24, 2009

Why would you combine these two completely unrelated stories?

In other news…

Eah I know my document.write replacement has limited utility. But it works great for some pretty specific things.

Comment by SubtleGradient — June 24, 2009

@ThomasHansen, I think the point of overwriting the doc.write method is for AFTER the document has loaded. If a script (for example, a widget that you didn’t author) uses doc. write because it expects to be included at run time, and you append it to the DOM after page load, it would overwrite the whole page with its contents. Overwriting it this way allows you to prevent that.

Comment by anewton — June 24, 2009

@tbroyer while the case you presented holds true, there is no sensible reason to do something like that, specially considering that document.write should be gone in XHTML.

Comment by ricardobeat — June 25, 2009

Leave a comment

You must be logged in to post a comment.