Comments on: De-fusing JavaScript Natives with the Fusebox

By: BenNadel

BenNadel — Thu, 25 Feb 2010 23:59:48 +0000

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!

By: starkraving

starkraving — Mon, 25 Jan 2010 06:40:27 +0000

@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…

By: krukow

krukow — Sat, 23 Jan 2010 12:32:45 +0000

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

http://blog.higher-order.net/2010/01/22/fuse-blows/

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

Cheers,
- Karl

By: steida

steida — Sat, 23 Jan 2010 09:49:58 +0000

I experimented with Sandboxed natives too, but in different way. http://github.com/Steida/PJ/blob/master/index.html
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.

By: jdalton

jdalton — Fri, 22 Jan 2010 16:15:07 +0000

@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

By: WillPeavy

WillPeavy — Fri, 22 Jan 2010 15:43:55 +0000

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

By: getify

getify — Fri, 22 Jan 2010 15:14:23 +0000

@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.

By: Stakka

Stakka — Fri, 22 Jan 2010 15:02:04 +0000

@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?

By: getify

getify — Fri, 22 Jan 2010 14:40:27 +0000

@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.

By: Jadet

Jadet — Fri, 22 Jan 2010 14:21:15 +0000

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

By: Stakka

Stakka — Fri, 22 Jan 2010 13:47:50 +0000

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.

By: KrisKowal

KrisKowal — Fri, 22 Jan 2010 08:29:11 +0000

This seems similar to the standard I’m proposing.
http://wiki.ecmascript.org/doku.php?id=strawman:modules_primordials