The subject of UIWebView not using JIT-enabled JavaScript engine becomes popular again, mainly due to the fresh release of Google Chrome for iOS. Unlike Chrome on other platform, Chrome on iOS is just an alternative user-interface on top of the UIWebView component hence making Chrome slightly inferior to Safari in pure JavaScript performance. This is usually not a problem since general web browsing does not involve heavy computation done in JavaScript. Update: Chrome under the hood packs some network awesomeness (SPDY, prefetching, etc).
A term which often shows up when discussing UIWebView is Nitro. What is exactly Nitro? First, let’s go back to the early moment when Apple mentioned Nitro. The press release Apple Announces Safari 4 says:
Safari 4 is built on the world’s most advanced browser technologies including the new Nitro JavaScript engine that executes JavaScript up to 30 times faster than IE 7 and more than three times faster than Firefox 3.
This was from February 2009. Later on, during WWDC in June, Safari 4 hit the final release. From the marketing material, there is hardly any mention of JIT, presumably because it is too technical for the general audience. However, if we look at the WebKit history, clearly this engine has that advanced JIT support. This is evidenced from the blog post Introducing SquirrelFish Extreme back in late 2008.
Note that technically speaking the JavaScript engine in WebKit is called JavaScriptCore. Its source code directory is called Source/JavaScriptCore. When it is installed in the system, the library JavaScriptCore.Framework is also using that name. If you are old enough to remember, JavaScriptCore was originally derived from KJS, KDE’s JavaScript engine. In fact, this was way before Safari time.
These days, there are apparently two schools of thoughts about what Nitro is.
Nitro = Booster via JIT
After Safari 4, a lot of people associate Nitro with JIT. This is emphasized again when iOS got updated to get JIT-powered Mobile Safari. When UIWebView did not get the JIT version of the engine, there was a lot of buzz, even Gruber wrote something like:
The Nitro JavaScript engine is only available within Mobile Safari.
In this interpretation, Nitro is identical to the some sort extra injection (Nitrous oxide) to boost the performance. This leaves a room for question: is there a name of the non-Nitro situation?
Update: For this camp, referring to the UIWebView situation would be:
- Mobile Safari uses Nitro
- UIWebView still uses who-can-remember-that-JavaScript-engine-without-JIT
Nitro = JavaScriptCore
Another group of people argue that Nitro is nothing but a marketing term for JavaScriptCore. It is the same thing, nothing more and nothing less. Two names for the same code. Apple’s press release did not insist that Nitro is JIT-only engine. The statement reads like “This fast engine is named JavaScriptCore by our engineers, but you can just call it Nitro”.
Whether it has JIT support or not, the name shall not change. It’s rather easy to refer both situations:
- Mobile Safari uses Nitro with JIT support
- UIWebView still uses Nitro without JIT support
To further reduce the ambiguity, we might even drop Nitro completely and stick with JavaScriptCore. Hence, Gruber should have written:
JavaScriptCore, the JavaScript engine, only supports JIT within Mobile Safari.
I believe calling it JIT vs no-JIT gives a clear meaning. It’s less confusing than Nitro vs whatever-engine-which-does-not-have-JIT. Why are we confusing ourselves?
Which school of thought are you subscribed to?