JavaScript doesn't run at the speed of native, but it certainly runs fast enough on things like Fx OS (or desktop browsers) to run 'native-like' apps. It really depends what you want to do with it.

For example, this is JavaScript: https://developer.mozilla.org/en-US/demos/detail/bananabread

So how come e.g. www.circuitlab.com which is a simulator written in pure JS is two orders of magnitude slower on Chrome or Firefox than native *SPICE implementations in C? It is actually even much slower than the already pretty slow Falstad's Java applet.

Two orders of magnitude? That can't be explained by the difference between C and JS. There must be some other difference, like which algorithms are used, or that the C one relies heavily on inline assembly or such.

The expected difference between C and JS should be more like one order of magnitude in the worst cases (and much better in the best).

Since azakai is too humble to mention his own qualifications, I want to point out that is the author of the Emscripten LLVM-to-JS compiler, and the BananaBread first-person-shooter demo linked above, so when he talks about the limits of JS performance compared to C, he really knows what he's talking about. :)

Well, I could agree if I saw any computational-heavy JS application (and not a microbenchmark) doing well compared to native counterpart, especially on multicore. So far, I found only the one I cited - and the fact is, it is damn slow.

While JIT is getting better over time, you are soon going to hit the law of diminishing returns - the JIT is already extremely sophisticated, but still being a few times slower on average even than JVM. And JVM has it much easier, because it has full explicit type information, while JS has to first figure it out. So I wouldn't expect miracles here.

> Well, I could agree if I saw any computational-heavy JS application (and not a microbenchmark) doing well compared to native counterpart, especially on multicore.

For example, BananaBread compiles 120,000 lines of code of a C++ 3D game engine, including AI and physics and so forth. It also uses 3 cores during startup processing

The difference between JavaScript and C++ is less than one order of magnitude, and note that this is a hard case to optimize for JS engines since LLVM inlining creates huge functions that JS engines just give up on optimizing currently. So that the game ends up still running as fast as it does in JS is a nice surprise.

There are also lots of other compiled examples of real-world code, like Box2D and Bullet. Typically the speed of JS compared to C is 5X-10X slower, again, much of it because of large functions not being fully optimized.

If you're working on Bananabread, can you check why it's not working on Chrome, the latest stable version? I get an Oops message. I use Windows 7 x64, Core i7 laptop with Nvidia 555m GT .Also just installed Nvidia's latest driver, though I haven't rebooted yet. Could that be it?

Have you enabled mouse-lock in chrome://flags ? It talks about this on the page, if you're curious.

I am aware of a bug in Chrome where the Chrome tab will crash after you play for a while or reload the tab. But in a new tab you should be able to play for a few seconds ok - is that what you are experiencing?

Just swap base e for base 10, and boom, twice the orders of magnitude.

In addition to the responses from the Mozilla guys, I'll also point out that the limiting factor in speed for most web applications is not javascript runtime speed but dom manipulation, reflow, and repaint. The tricks for optimizing these tend to be somewhat browser dependent and not generally known by the web development community.

Well-optimized C is likely to always be faster than well-optimized JavaScript.

It is also possible that circuitlab is not well-optimized JavaScript.

I will say that it also depends on the problem domain. You can make a fast 3D game in JavaScript because WebGL does hardware acceleration of the graphics. You can also make a fast todo list in JavaScript because, well, it's a todo list :)

I don't think C will always be faster. A JIT-compiled language can theoretically be optimized better than a precompiled binary, because the JIT engine can recompile hot code based on observed behavior on the actual system with the actual data.

Theoretically, a c-compiler could produce self modifying code.

Also, this theoretical c compiler could make use of implicit hints (like which variables to place together in memory), making it faster than JS (except asymptotically, when the JIT has run long enough to figure everything out).

But the original point is basically right - one day JITs will be faster.

JITs don't have so much time to optimize, as static compilers do. Therefore, they can't do e.g. whole program analysis, or expensive cache related optimizations. Despite 15 years of effort of speeding up JVM, it is still slower in general than optimized C. Not by much (usually good Java code runs within a 2x slower margin), but still - it can't beat static compilers.

The term "native-like" means "with a responsive interface" these days.

Oh yeah, by this definition interpreted Python is also native like. Just do all your UI rendering by native libs and use scripting to glue it together. But this is not what most of programmers call native speed.

I think you're misinterpreting the meaning of 'native' in this context; the tradeoff in question isn't one of interpreted/JIT'd v. ahead of time to the metal, but rather one of Web v. every platform's standard graphical application stack(s) (which may or may not be ahead of time compiled).

Hence the context of being magical. It is more of a sleight of hand trick than actual supernatural. The author of the post is misusing a development term to convey a different meaning.

And access to hardware, and with a common, system interface (native widgets) not custom or third-party UI widgets.

Seems like a completely accurate definition. As responsive as expected, similar looking and integrated as expected, and able to access the unique parts of my phone.

What is missing, other than having a different build/compile process?

Watch the video. That's not native performance. It will never be native performance, because there will always be the layer of the rendering engine between your application and device. The best they'll ever do is "close enough to native that you don't notice", and they're certainly not there yet. And the number of apps is already in the millions? Give me an example of one app out there that's in the same ballpark of quality as the stuff you can find on iOS or even Android.

The video does look a bit rough, but that's neither final code nor final hardware. For what it's worth, actually touching one of the Firefox OS dev phones is pretty impressive: it feels much smoother than it looks on that video.

It's not quite up to iOS or Android 4.1 performance, but it's running on far less powerful hardware. It definitely feels better than the initial releases of Android in terms of responsiveness.

> Give me an example of one app out there that's in the same ballpark of quality as the stuff you can find on iOS or even Android.

The HTML5 version of Cut the Rope works pretty great on Firefox OS; the experience is effectively identical to Android and iOS.

There is always a rendering engine unless you're writing pixels to the buffer directly. The thing is that Cocoa/CocoaTouch's rendering and compositing is much faster than Webkit's. Why that is, is left as an exercise for the reader.

Webkit uses iOS's rendering and compositing libraries to render information on screen. That's why it will never be faster than those libraries.

never say never.

Technology evolves and in time hardware improves to a point where the performance difference between native code and something that runs through an intermediate layer is not noticeable in a user interface (although there will always be a difference, it just wont be be relevant any more).

And at that point, native would still be faster....

At some point, native would still be faster in the same sense a curve approaches the x-axis but never quite touches it.

The mobile web rendering performance might never hit the 0-grade latency standard where we put native, but it will eventually get so close to it as to not make any difference whatsoever to anyone but cold-hearted scientists the likes of whom whish they could keep their science drinks at absolute zero chilly bins.

I wasn't speaking practically. The GP said "native will always be faster" and that's true. Relevance of that truth is a separate issue.

HTML hit practically 0 latency 10 years ago then we added DHTML, CSS, encryption, Ajax, 3D, multitasking, 2x DPI and 4x screen size, background syncing, ... When will we stop adding functionality to soak up the hardware power?

If we hadn't added those things, HTML&Cia. wouldn't even be a contender to replace native performance now. It would still be a simple technology meant for static information.

If your argument is more in the line of why do games keep getting bigger and meaner, needing more resources, when we could have stopped advancing 3D a decade ago and every computer would be able to play any game today; then that's a whole other discussion. But I like the path towards true virtual reality with photorealistic graphics.

The HTML5 version of Cut the Rope is one example:

http://www.cuttherope.ie/

Here are some other high quality HTML5 games:

http://worldsbiggestpacman.com/ http://www.wordsquared.com/ http://www.pirateslovedaisies.com/ http://browserquest.mozilla.org/