Friday, January 22nd, 2010

De-fusing JavaScript Natives with the Fusebox

Category: JavaScript, Library

John-David Dalton has released Fusebox, a library that allows you to sandbox natives:

Extending JavaScript natives gives you the power to customize the language to fit your needs. You can add convenience methods like “hello world”.capitalize() or implement missing functionality like [1,2,3].indexOf(2) in JScript. The problem is that frameworks / libraries / third-party scripts may overwrite native methods or each other’s custom methods resulting in unpredictable outcomes. Fusebox, a limited version of the sandboxing component found in FuseJS, avoids these issues by creating sandboxed natives which can be extended without affecting the document natives.

For example:


  1. var fb = Fusebox();
  2.   fb.Array.prototype.hai = function() {
  3.     return "Oh hai, we have " + this.length + " items.";
  4.   };
  6.   fb.Array(1,2,3).hai(); // "Oh hai, we have 3 items."
  7.   typeof window.Array.prototype.hai; // undefined

John has a series of short screencasts to introduce the topic of sandboxed natives, how to use them, and the techniques used to make it all happen:

  1. Sandboxed Natives 101: Screencast One
  2. How to create a sandbox: Screencast Two
  3. How to create a Fusebox: Screencast Three
  4. The Final Countdown: Screencast Four

Great to learn from. It is a shame that you have to remember to use a very different way to access the types of course and that you have to do all of this magic…. but with JavaScript, it is what it is!

Posted by Dion Almaer at 2:17 am

4.2 rating from 32 votes


Comments feed TrackBack URI

This seems similar to the standard I’m proposing.

Comment by KrisKowal — January 22, 2010

So, the “sandbox” only works if the third-party scripts make sure they only modify the fusebox instances (fb.Array, fb.String, etc) and not the real global object? Not much of a sandbox.

Comment by Stakka — January 22, 2010

Saw the 2008-2010 in the source, now that’s dedication. Great piece of work.

Comment by Jadet — January 22, 2010

@Stakka — as I understand it, only in IE will modifications to the normal natives actually creep into the sandbox’d natives. And even then, it shouldn’t “break” the sandboxes as modifying real natives does (foreach, etc).
The key is to start insisting on using the sandbox’d natives for all your extending needs and leave the real natives alone. If you do that, you should see an improvement in your code and functionality.

Comment by getify — January 22, 2010

@getify – If you’re the one modifying the built-in global objects. Then why use fusebox, when you can just stop modifying the objects in the first place?

Comment by Stakka — January 22, 2010

@Stakka – because there are valid use cases for extending natives… giving them features that arguably they should already have… makes code cleaner and in some cases more efficient. But the caveats of extending true natives have made most people shy away from them.
Fusebox kind of solves that as it gives you a safe way to extend them without the negative side effects, and still get all the improvements to the rest of the code that extended natives gives.

Comment by getify — January 22, 2010

There’s a framework named “Fusebox”, for ColdFusion, that’s been around for 10+ years.

Comment by WillPeavy — January 22, 2010

@Stakka – I released Fusebox as a standalone because it is unique & some may find it interesting. Its primary use is in FuseJS (fuse.Fusebox), which only modifies Fuseboxed natives and not ones on the global. It seems like what you expected was something to sandbox existing frameworks which is not the purpose/function of Fusebox.
@getify – The gotcha on things creeping into the sandbox is addressed in the README.markdown.
@getify – Your last comment is right on the mark. Ditto :D

Comment by jdalton — January 22, 2010

I experimented with Sandboxed natives too, but in different way.
But debuggers don’t like code from other scope. So I decided, if I would ever again want to use js code which modifies prototype, I would prefer invisible iframe rather. It’s clean a no hacky.

Comment by steida — January 23, 2010

Interested in a library that doesn’t work with “fusebox” types?

Sort of the same principle but not quite. But it allows working with the native types in the script. ;-)

– Karl

Comment by krukow — January 23, 2010

@willpeavy: I am a Fuseboxer (CF and PHP both) too, so the title of this article made me look twice too. An interesting read nonetheless…

Comment by starkraving — January 25, 2010

I am very impressed that the Fusebox approach was able to get the array notation [] to work with get/set. When I played around with extending the native data types, I had to rely on push/pop. Very slick!

Comment by BenNadel — February 25, 2010

Leave a comment

You must be logged in to post a comment.