Comments on: Dealing with JavaScript scope issues; The tale of Alex kindly indulging me

By: haberler

haberler — Wed, 05 Aug 2009 09:22:03 +0000

useful article thank you. And i loved you secret question :)

By: toshiba

toshiba — Thu, 30 Apr 2009 01:46:02 +0000

JavaScript is about run-time. Run-time is great and all, but especially when dealing with the browser, and how your Web page has to bootstrap the entire world on every load, Ajax developers have to think about issues that other people don’t.

By: Alex Russell

Alex Russell — Tue, 31 Mar 2009 17:05:32 +0000

something I failed to mention in my original mail:

I have some hope that we’d be able to actually introspect (vai a Rhino AST or something) on the APIs that you’d be using from such a mapping and roll them back at build time.

As to Erik’s with(){} comment, it’s not really possible to turn off JIT in v8, but with(){} will cause polymorphic inline caching to become much less effective, hurting most kinds of lookups. It’ll still be happening in machine code (vs, say, IE which will need to look it up in the interpreter), but it will still be JIT’d.

Regards

By: Dion Almaer

Dion Almaer — Mon, 30 Mar 2009 20:06:09 +0000

Yes, yes, this isn’t meant to be a “do this in production” type thing, but rather an “experiment to see how JavaScript can be contorted in a way to make it both nice to work with, and sandboxed”

By: Eugene Lazutkin

Eugene Lazutkin — Mon, 30 Mar 2009 19:02:18 +0000

While JavaScript is not strictly a homoiconic language, it is fun to see what is possible. The biggest problem of this approach not with “with” but “func.toString()” — it doesn’t work on some mobile browsers as expected (does not return a function’s text sufficient to reconstruct the function).

If only the committee found a way to standardize AST making JavaScript homoiconic (http://en.wikipedia.org/wiki/Homoiconic), we would have an elegant way to do this stuff and a lot more including custom pre-processing, DSLs, code and data specializations, and so on.

By: henrah

henrah — Mon, 30 Mar 2009 17:38:24 +0000

If you’re going to use the `with` operator anyway, why bother using this runWith method? You’re incurring the considerable cost of decompiling and recompiling a function, plus the method setup and teardown process, on top of the existing penalty imposed by using `with` in the first place — and the API is not ultimately any simpler than a set of nested `with(object){}` blocks.

The API may look cleaner and more idiomatic because it looks like you’re passing a closure/callback function in the style of modern libraries, but really you’re not passing a closure at all. You’re just passing the textual representation of a block, since all its context is lost when it gets converted into text and recompiled by the Function() constructor. What benefit does this confer? It seems to me like a very flimsy decoration over a widely despised language feature.

By: Ray Cromwell

Ray Cromwell — Mon, 30 Mar 2009 17:16:25 +0000

I dunno, given the extra verbiage of dojo.runWith, the object array, and the function() {} closure, you’d have to type the dojo ‘prefix’ more than 6 times before you’d gain any less verbiage, and you pay a high cost.

By: Erik Arvidsson

Erik Arvidsson — Mon, 30 Mar 2009 16:33:47 +0000

Don’t do this on any production code. You have been warned :-)

I’m pretty sure that the with statement will turn off jitting for all major engines. The reason why all browser vendors wants to remove with is not only that it is error prone and confuses the hell out of most people. It also prevents optimizations.

The only solution to this problem that I’ve seen involves a compiler/preprocessor. While developing you can use eval (like base2) and then before you deploy you run a preprocessor that replaces those evals with inline code.