This blog post is either spectacularly naive, or ridiculously over-hyped, or both.<p>"Consistent performance. (not like the V8 engine pausing the whole application for GC)"<p>Static complication doesn't get you out of having to worry about memory management. What's the alternative here? Reference counting? Leaking everything? Using a subset of JS that doesn't allocate anything? All of these things come with considerable costs.
This sounds like the first step in a vision I've had for how the web should evolve. We now have an LLVM frontend for Javascript, so Javascript code can be turned into LLVM bytecode.<p>The next step would be to swap out the existing Javascript runtimes with this frontend plus a sandboxed backend for the native platform so they can compile Javascript to LLVM bytecode, then to native code.<p>Finally, you add an extension to the <script> tag to allow loading arbitrary LLVM bytecode, something like <script src="<a href="http://some/url/code.llvm"" rel="nofollow">http://some/url/code.llvm"</a> type="text/llvm">.<p>Once that's in place then you'd be able to execute any language that has an LLVM front end inside the browser environment. Javascript is no longer the sole language of the web, and things like Emscripten and asm.js become obsolete.
Cool hack. Is the source code available somewhere?<p>> - Consistent performance.<p>> (not like the V8 engine pausing the whole application for GC)<p>But... you're still going to need garbage collection, unless you are only planning on supporting something like ASM.js. So there will still be application pauses for GC.<p>Also, you mention that you have support for JavaScript OO, but I notice the benchmarks don't exercise programmer-defined JavaScript objects/prototypes. Do you have numbers on its OO performance, or is that still something you're working on?<p>Finally, how do you handle type inference at the LLVM level? I assume you implemented some form of JIT compilation? I'd be interested to hear more!
> Javascript has always been considered as a scripting language with low performance compared to most low level languages. Thanks to V8 engine, it is now becoming a platform where developers can prepare a fully functional backend.<p>This is not accurate, and shows a lack of respect for the JS VM developers at other browser vendors.<p>Very close to the time v8 was launched, SquirrelFish Extreme from Apple and TraceMonkey from Mozilla were also launched, each far faster than previous JS VMs, beat v8 on various benchmarks while losing on others, etc.<p>Since then v8 has generally been in the lead, certainly, but not always, and it would depend on the benchmark and platform.<p>So it is not fair to say - and this is not the first time I see it, or else I would not write this comment - that v8 is single-handedly responsible for JS being fast today.
Does Node have an equivalent to the JVM's server and client modes? Node can probably assume that it will be hosting a long-running server process, skip the lazy JIT, and just AOT compile all JS code at maximum optimization.
My only concern is Apple's patent for this: <a href="http://www.google.com/patents/US20100153929" rel="nofollow">http://www.google.com/patents/US20100153929</a>
Found this via [1], would love to hear some opinions from knowledgable people here.<p>[1] <a href="http://www.echojs.com/news/8496" rel="nofollow">http://www.echojs.com/news/8496</a>