Apple integrates LLVM compiler to boost WebKit JavaScript performance

This is a bit technical, but we’ll distill it down a bit. There’s essentially three levels of computer code that can be executed: machine code (written directly in assembler), compiled code and interpreted code. Machine code is the fastest, but very hard for normal humans to write at scale. Compiled code has the benefits of being easier to write, and then a compiler translates what you build into machine code before it’s deployed (I.e. What native apps use). Interpreted code is translated into instructions on the fly – more flexible and more quickly modified, but also slower when running. This is particularly why we are such heavy advocates of native mobile apps – the user experience is paramount and slow is always a detriment to experience.

JavaScript began as a purely interpreted language and browsers have been optimizing more and more the speed at which it can be run using ever more clever ways of processing as it runs to try and make it faster. Apple has taken a somewhat novel approach here: treat JavaScript more like a compiled language and do the low level translation before running it. The problem is that compilers take a while to run before they can do anything, so other trick they’re using is to run the normal interpreter first and ‘compile’ the code in the background.

This is especially useful when it comes to mobile, as the ARM systems we all use are vastly underpowered compared to desktop processors. However, because of security concerns, we will likely only see these optimization a in Safari itself, and not in the browser views inside of apps. This is how Apple’s Nitro optimization is now – only available on we pages when run in Safari. So for now, native apps will remain faster. It does make for an interesting speculation though: would Apple consider something like iOS 1.0’s original strategy of web-based apps if they were all precompiled before deployment? Certainly something to watch.