Fog Creek Software
Discussion Board

Would compiled Javascript work?

I can see the reasoning behind a lot of today's suggestions, but some of them are confusing me.

How do you do compiled javascript without introducing a VM?  And if you've got a VM, how is it different from Java applets as they exist today?  I suppose this would mean that the compiled Javascript VM would have more direct access to the entire HTML layout, rather than being isolated in a little box.  But wouldn't the overhead of the VM leave you with the same (or similar) performance problems as a Java applet that uses its own window?

The idea of implementing a spellchecker / name lookup that requests from the database on every keystroke sounds like an overkill implementation, as well.  The javascript functionality would be nice, but the network latency and traffic issues sound like a nightmare.

Other than that, these are interesting suggestions.  It still strikes me as basically asking for a Java that is standardized by W3, faster, and included in all browsers.  But I'm no 'net coding guru so feel free to educate me.

Josh Giesbrecht
Friday, June 18, 2004

the javascript interpreter is already a VM in a sense, it's an interpreter.

in fact, microsoft has encoded jscript/vbscript. don't know if it's faster or slower than normal, though if it's smaller it might speed up download times.

i don't know if firefox/other browsers support this. never used it myself, though there are times where i'd like to.

Friday, June 18, 2004

"How do you do compiled javascript without introducing a VM?  And if you've got a VM, how is it different from Java applets as they exist today?"

Well as mentioned above, Javascript is really a form of VM.  The big difference is then the Java class library.  When you visit a page with Java you have to wait and wait for it load up; that's not because of the VM it's because it has to load an operating systems worth of class libraries!

Javascript is just the scripting language of your browser -- it doesn't have any dependencies.

Almost Anonymous
Friday, June 18, 2004

Of course compiled JScript would work -- it works today!

JScript "Classic" compiles to a proprietary bytecode format on a per-script-block basis.  The bytecode format is basically a linearization of the parse tree; it is quite high-level compared to Java bytecode or MSIL.  (No, there is no publically available tool that displays the bytecode, sorry.)

JScript .NET has two modes.  It can either compile to MSIL, or parse itself into a tree of nodes which can then interpret themselves.  (The latter is how "eval" is implemented in JScript .NET.  We cannot compile eval'd code to IL in JScript .NET because that would effectively leak memory.)

The "encoding" feature is a simple text substitution cipher.  It is not smaller and does not make anything faster.  It is easily broken.  It's about as effective as locking your car door -- a deterrent only to casual theft.

Eric Lippert
Friday, June 18, 2004

He said something like "compiled or compressed;" I think the intent was less to improve performance than to get large pieces of code over the connection quickly.  I suspect that tokenizing and compressing it would do just fine, and then unbundling it and using the existing interpreter on the client side.

Joe Ganley
Friday, June 18, 2004

Compiled byte code that only works for one profuct or platform is useless on the web.

Now, negociated compression is already there. I can setup Apache to server GZIP compressed files to all browsers that claim to support it. That means anything netscape and mozilla based. Anything KHTML based (or so it seems) and meybe even some IE versions.

Text easily achieve 80-95% compression, code with its extremely repetitive nature gets 95% or better compression. Decompression of a few hundred kilobytes on modern CPU takes at most 100ms of CPU time. More likely 20-30ms. Invisible to the user. Efficient use HTTP 1.1 cache management on the client means it's a one-time download for a web appplication that bundles all the JS in a few files shared throughout.

Web server can automatically re-generate the compressed file when thr original change for a one-time cost of maybe 5x decompression time. Why isn't all static uncompressed content compressed by default? I don't know. The technology is there.

Alexandre Carmel-Veilleux
Friday, June 18, 2004

*  Recent Topics

*  Fog Creek Home