JSIL

Many languages use "inline method caching" - that is, a "call_dynamic x_named_method" bytecode is replaced with a "guard_and_call_static 0xfffffff" once the callsite is evaluated. In some languages invalidating this cache by calling a method with polymorphic arguments or altering the receiving class can be extremely expensive, so there are usually second-order optimizations applied. Objective-C: Takes one method pointer indirection / jmp trampoline forever, but caches "selectors" on the class so that they become a simple lookup rather than a full evaluation. See sibling comments for better write-ups than I could find. Most JS runtimes: Trace JITs mean many method invocations are compiled into traces and become either inline instructions or native function calls. Also uses "hidden classes" to implement inline method caching, where the call

Here's a page with some performance tips for both V8 and SpiderMonkey: https://github.com/sq/JSIL/wiki/JavaScript-Performance-For-M.... Unfortunately given the pace at which JS engines move it may be slightly out of date.

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

Also check out the demos at http://jsil.org/ The developer has implemented very basic functionality[1] of the XNA library (so there are games :D). Programming a complete game in .NET (super-powerful IDEs, with code-completion and integrated debuggers, profiles is nice), then deploying it to the Web is a pretty cool thing. Of course this project is not nearly as mature[2] as GWT. But I like the approach of compiling bytecode better, than GWTs Java compilations. Many cool .NET languages exist (like F#), which you can use that way. [1]: that's basically it https://github.com/kevingadd/JSIL/blob/master/Libraries/JSIL... [2]: page says "JSIL is still in development. You will hit bugs."

I like .NET/Mono stuff, and I totally understand the frustration of .NET developers. I would want to point out though that Javascript does have all the features you listed that .NET has, except the desktop stack - but of course that is precisely what Microsoft (and others, like GTK developers) may be developing. "what .NET is. It is a desktop stack, a server stack, a runtime for many languages, those many languages themselves, and countless libraries that are being actively developed" Javascript on the server: http://nodejs.org/ Javascript as a runtime for many languages (more than .NET even I believe at this point): https://github.com/jashkenas/coffee-script/wiki/List-of-lang... Countless javascript libraries: in the browser https://github.com/bebraw/jswiki/wiki and on the server: https://github.com/joyent/node/wiki/modules Even .NET cod