Hacker News new | past | comments | ask | show | jobs | submit login

I might be missing something here, but this implicates a few things:

You won't be writing code in the browser anymore. Otherwise you'd have fragmentation where the user doesn't have the proper interpreter installed, and a never ending stream of "language downloads" which might be cool to devs but horribly impractical for end users.

Because we're not writing in the browser anymore, we'd be back to offline compilation and static code generation. I suppose it'd be possible to JIT the bytecode (assuming that current Javascript optimizers work on the IR; I don't know enough to qualify this any further). From my casual browsing of LtU, it seems that tracing JITs in particular may offer optimizations dificult to achieve with static bytecode compilation, particularly in identifying hot spots. But the more I think of it, that's a non-issue because you're still compiling to bytecode and JITing from there.

This feels very Java-ish to me. If you really want to script the browser in another language, compiling to Javascript (a'la GWT) would essentially do the same thing.




> You won't be writing code in the browser anymore

You could be. Impement a URL like http://mydomain/scripts/MyScript.bytecode. This is a page which compiles, say MyScript.rb into bytecode and delivers it back to the client. You get a new copy by saving a file on the server and hitting refresh, and there's only one interpreter to download.


That just moves the bytecode compilation to the server -- so you're back to my original point of generating the code statically. In fact it'd probably be worse, since there is no reason to compile MyScript.rb to bytecode more than once. It's like generating a dynamic page with Rails when all you really need is static, cacheable HTML.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: