Apple の WebKit オープンソース プロジェクト (OS X および iOS の Safari で使用され、さまざまな他のブラウザーを動かすために使用されています) の最近の変更には、効率的な新しい LLInt (低レベル インタープリター) の組み込みが含まれています。これは現在 JavaScriptCore (JSC) によって使用され、標準インタープリター (バイトコード仮想マシン、またはネイティブ マシン コードをオンザフライで構築する JIT (Just In Time コンパイラー)) にコードを渡す前にコードの実行を試みます。
新しいインタープリタの変更レポートには、「JSC は、LLInt でコードを実行して開始し、コードがホットであることが証明された後にのみ、古い JIT に階層化されます」と説明されています。
LLLintは、マクロアセンブリを修正した形式で記述されています。この新しいマクロアセンブリは、オフラインアセンブラ（offlineasmを参照）によってコンパイルされます。オフラインアセンブラは、チューリング完全なCPSベースのマクロ言語や、関連するC++型情報（基本的にはフィールドのオフセットと構造体/クラスのサイズ）への直接アクセスなど、多くの最新の便利な機能を実装しています。
新しいインタープリタは「SunSpider、V8、Kraken（ベンチマーク）において、従来のインタープリタよりも2～2.5倍高速です」とレポートには記されています。「トリプルティアリングを有効にすると（LLIntによるコード解釈が可能になるため）、SunSpider、V8、Krakenでは中立的な結果となりますが、JIT処理量が大幅に削減されたため、実際のウェブサイトでは2桁の改善が見られるようです。」
Web ブラウザーでの JavaScript パフォーマンスは、最適化の主な焦点です。これにより、コードの実行速度と効率が向上し、アニメーションの実行がよりスムーズになり、クロスプラットフォーム Web アプリケーションがより洗練され、応答性が高まります。
JavaScriptCoreのLLInt機能強化は、JavaScriptCore JITとガベージコレクタの改善に「主要な貢献者」として貢献した後、12月にWebKitのレビュアーに加わったFilip Pizlo氏によって実現されたようです。Pizlo氏は1月に「JSCは3層VMであるべき」と指摘したバグレポートを提出し、その後2月末までにこの問題を解決しました。
JavaScriptCoreへの新たな変更は、過去数年にわたるWebKitの同様の機能強化に続き、Safariのメインストリーム版に反映されるまでにはしばらく時間がかかるでしょう。Appleの次期Safari 5.2リリースにおける機能強化は、新しいユーザーインターフェースと共有機能の強化、新しいプライバシー設定、ウェブサイトアラート機能などについて報じられたレポートで紹介されています。
JavaScriptCore の Nitro の改善
2008年、WebKitはJavaScriptCoreをダイレクトディスパッチレジスタベースの高水準バイトコード仮想マシンとして書き直し、当初はSquirrelFishと名付けられました。これはJavaScriptをネイティブマシンコードにコンパイルするものでした。このプロジェクトは後に拡張され、SquirrelFish Extremeというコードネームが付けられました。
2009年、Appleは「Nitro」というブランド名でSafari 4に機能強化を適用し、新しい実装によりJavaScriptの実行速度が最大4.5倍になると述べた。
翌年、Safari 5 で新しい SquirrelFish Extreme 拡張機能がリリースされ、Mac での JavaScript パフォーマンスが以前の Safari 4 よりもさらに 30 パーセント向上しました。
昨年、AppleはiOS 4.3でモバイルSafariにNitroを追加し、AppleのモバイルデバイスにおけるJavaScriptのパフォーマンスを200%向上させました。しかし、iOSがNitroをSafariで実行されるWebアプリの高速化にのみ使用していたことが判明し、ちょっとした論争が巻き起こりました。その結果、フルスクリーンのWebアプリをホーム画面に保存すると、速度が大幅に低下しました。
iOS 5 では、Apple は以前のリリースで Nitro を使用してフルスクリーン Web アプリを実行できなかったセキュリティ問題を解決しましたが、セキュリティ対策により、UIWebView を使用して Web ビューを表示するアプリは Nitro を呼び出すことができません。
GoogleのJavaScriptの競合
他のWebKitブラウザは必ずしもJavaScript Coreを使用するわけではありません。例えば、Google Chromeは独自の競合するV8 JavaScriptエンジンを使用しています。
V8は、JavaScriptを実行前にネイティブコードにコンパイルすることでパフォーマンスを向上させることを目指しています。これは、SunのJava ME仮想マシンを開発したプログラマー、Lars Bak氏が率いるチームによって開発されました。OracleがSunを買収した後、OracleはGoogleに対し、仮想マシン関連の特許を侵害したとして訴訟を起こしました。この特許には、Bak氏がSun在籍中に出願した特許も含まれていました。
名前だけがJavaと関連しているJavaScriptは、もともとNetscape社でウェブページにプログラムによるインタラクティブ機能を追加する手段として開発されました（以前はLiveScriptという名称でした）。JavaScriptはその後、広く確立されたオープンスタンダードとなり、現在仕様として管理している標準化団体にちなんでECMAScriptと呼ばれることもあります。Microsoftはかつて独自のVBScriptをサポートしていましたが、その後、JavaScriptの共通利用を通じてウェブ上の相互運用性を支援してきました。
Googleは最近、JavaScriptを独自の新しいウェブプログラミング言語Dart（旧称Dash）に置き換えることを検討しています。DartはBak氏と共同開発されました。Apple、Mozilla、Microsoftはいずれも、JavaScriptを独自の新しい言語に置き換えるというGoogleの計画に反対し、JavaScriptを継続的に改良していくことを支持しています。
Netscape でオリジナルの JavaScript を開発した Mozilla の Brendan Eich 氏は最近、「Apple と Microsoft（Opera と Mozilla も、最初の 2 つだけでも十分ですが）が Dart VM を組み込むことは絶対にないと断言します」と記し、「Google の Dart に対するアプローチはほぼ完全に間違っており、Dart は優れた実装ではあるものの、標準化されておらず相互運用性もない状態のままになる運命にある」と付け加え、「10 年ほど前の Microsoft とは異なり、Google が勝利できるでしょうか？ それは、Web における新たな独占勢力になることによってのみ可能になります。その結末は周知の事実です」と考察しています。
12月に行われたDartに関する議論の中で、Appleのオリバー・ハント氏は次のように記しています。「非標準言語への直接的かつ公開されたサポートを追加することは、オープンウェブにとって敵対的です。なぜなら、将来起こりうる「コンセンサス」に基づく言語開発を一切無視し、代わりに私たちが望む言語をウェブに押し付けることになるからです。これは暗黙のうちに、独自の拡張機能をサポートするブラウザを、VBScriptのようなものをサポートするブラウザと同じ立場に置くことになり、同じ効果をもたらします。つまり、単一の製品でしか効果的に機能しないコンテンツを作成することで、オープンウェブを破壊することになるのです。」
Google は Chrome を活用してオープン スタンダードではなく自社の優先テクノロジーを推進しようとしており、この取り組みは独自の WebM ビデオ コーデック (H.264 ではなく) や、特に Android モバイル プラットフォームの差別化機能としてビデオとインタラクティブ機能を提供するための Adobe Flash (HTML5 よりも) の優先化にも反映されています。
