JSIL

You can absolutely do runtime code generation, you'll just be generating javascript. If you generate asm.js compatible javascript you'll be effectively JITting native code on the fly (you're just jumping through some absurd hoops to do it). There are some proof-of-concept projects out there that do runtime generation of JS on the fly for things like recompilation and such in the browser right now. I believe Shumway [1] does it (recompiling ActionScript VM bytecode to JS on the fly) and PyPy.js has an experimental JIT too [2]. The runtime library for my compiler JSIL also does a significant amount of runtime code generation to improve performance and reduce executable sizes [3]. [1] https://blog.mozilla.org/research/2012/11/12/introducing-the... [2] http://www.rfk.id.au/blog/entry/pypy-js-poc-jit/ [3] http://jsil.org/ ; https://github.com/

SpiderMonkey isn't a shining city on a hill in this case, certainly. In my experience though the docs that are there are easier to understand, the log messages are more verbose and understandable, and the developers are easier to get help from. I think this is all just a result of the fact that Mozilla relies more on community involvement to get stuff done, so they have to be a bit more dev-friendly. The same dislike of documenting performance details and internals exists on the SM team, though. Standalone binaries with debug options like d8 and spidermonkey js.exe are great for narrowly-scoped tuning and microbenchmarks, but in the real world your app runs in the browser and you end up having to debug and profile it there. That's where the whole picture falls apart (and where Spidermonkey's tools are dramatically better). Mozilla ships t

Not if you know anything about modern JS runtimes, it isn't. [1] https://github.com/sq/JSIL/wiki/JavaScript-Performance-For-M... [2] https://bugzilla.mozilla.org/show_bug.cgi?id=885526

If you're seeing miserable performance in everything other than Chrome, something is probably wrong with your Javascript, or you're doing something that is only optimized in Chrome. Given that you said web workers, are you transferring a lot of data between the worker and the document? Web worker transfers are pretty expensive, so it's possible you're seeing the effect of Chrome having a faster implementation. Does your JS generate a lot of garbage, and cause GC pressure? Chrome's collector handles garbage better than Firefox because it's generational, but getting rid of GC pressure can improve performance everywhere. I feel your pain about the difficulty of profiling web workers, though. Profiling browsers in general is a pain but it seems like none of the dev tools people on any browser actually bother to make tools work with web worker