12,895 文字
JavaScriptは遅い。まあ、みんなが言うほど遅いわけではありません。JavaScriptを酷い言語だと馬鹿にするのはミームになっていますが、そんなに悪くはないんです。とはいえ、もっと良くできる点はたくさんあります。そのうちの一つがV8チームから発表されたばかりです。それはコメントです。
そう、コードを10倍速くするコメントです。一体何が起きているのでしょうか？この話を掘り下げる必要があります。なぜなら、明示的なコンパイルヒントがついにJavaScriptに導入されることに私はとても興奮しているからです。こんな日が来るとは思っていませんでした。これは非常に実装の詳細に関わることですが、V8の取り組みを見れば見るほど、彼らがこういった機能を有効にする理由が理解できます。それは個々の開発者がアプリケーションを構築する際に使うためではなく、ブラウザをより深く理解するフレームワークやツールが大きなメリットを得るためなのです。
V8チームとReactチームのようなフレームワーク作者との間には、これらのフレームワークやツールをより高性能で優れたものにするための機能を追加するために多くのコラボレーションがありました。これはそのひとつです。その可能性は絶対的に凄まじいものです。
とはいえ、ReactチームもV8チームも私にお金を払っているわけではないので、なんとか収益を上げる必要があります。今日のスポンサーから一言いただいて、それからすぐに本題に入りましょう。
最近はさまざまなAIアプリビルダーがありますが、問題があります。それらはすべてフロントエンド寄りに作られているように感じます。フロントエンドの人たちに対して何も悪意はありません。私がどういう立場かわかりますよね？でも私はバックエンドも大好きです。そしてこれらのAIアプリビルダーがバックエンドの扱い方を知らないことにずっとフラストレーションを感じていました。しかし、React界隈でバックエンドを本当によく知っている会社が一つあります。それがConvexです。
おそらく他の動画でも彼らがスポンサーになっているのを見たことがあるでしょう。今回もスポンサーですが、Convexについて話すためではありません。Chefについて話すためです。これは私が彼らに作らせたものです。その理由は彼らがバックエンドを知っていて、私は動作するバックエンドが欲しかったからです。あらゆる実用的なアプリに必要なバックエンドを持つAIアプリビルダーです。
これは、データストレージから同期、ファイルアップロード、認証、その他通常対処しなければならない面倒なことまですべてを処理する唯一のAIアプリビルダーです。話せばきりがないですが、むしろお見せした方がいいでしょう。これはChefを使って構築した実際のアプリです。パーティープランナーアプリです。すでにサインインしています。
匿名でサインインするか、メールパスワードでサインインすることができます。すべて期待通りに動作しますが、ここで新しいイベントを作成できます。新しいイベント、説明には適当なテキスト、場所はどこでもいいです。作成しました。さっき作成した新しいイベントがあります。Convexのデータベースレイヤーが高速なので即座に反映されます。また、スケーリングも素晴らしいです。
これについては以前聞いたことがあるでしょうが、これをご覧ください。データベース内のこのイベントに移動して、説明を変更します。保存をクリックして戻ると、それが変更されています。これはConvexのプラットフォームを使用してすべてがライブ同期されるため、データが非同期になることがない適切なフルスタック実装だからです。
バックエンドとフロントエンドがお互いをほとんど理解できない他のツールを使った経験との差は大きいです。現在、それらは完全に連携しています。なぜなら、Convexプラットフォームがこれを非常に得意としているからです。ここにある実際のコードファイルであるスキーマがあります。また、多くの意味を持つ実際のJavaScript関数であるミューテーションとしての招待状があります。
バックからフロントまでの型安全性もあります。ちなみに、このアプリ全体は1つのプロンプトで作成されました。これは一発でできました。他のアプリビルダーでは何時間試しても実現できなかったことを、一度のプロンプトで実現しました。信じられないほど素晴らしいです。彼らにこれを作らせると言った時、こんなに良いものになるとは思っていませんでした。そして私の想像以上に素晴らしいものでした。
soyb.link/fで無料でお試しください。
V8にヒントを与える。JavaScriptを高速に実行することは、レスポンシブなWebアプリにとって重要です。V8の高度な最適化があっても、起動時に重要なJSを解析してコンパイルすることでパフォーマンスのボトルネックが発生することがあります。初期スクリプトコンパイル中にどのJS関数をコンパイルするかを知ることで、Webページの読み込みを高速化できます。
ここがポイントです。V8にJavaScriptを与えると、それをすべて解析し、その中のすべての関数などをコンパイルして準備してから、コードの実行を開始する必要があります。そのJavaScriptファイルを通じてインポートされた関数の10分の1しか使用していなくても、関係ありません。
コードを実行する前に、それらすべてをコンパイルする必要があります。これが面白いところです。スクリプトを処理する際、V8は各関数について、すぐにコンパイルするか延期するかを選択する必要があります。コンパイルされていない関数が後で呼び出される場合、V8はオンデマンドでそれをコンパイルしなければなりません。
JSの関数がページロード中に呼び出される場合、初期スクリプト処理中にそれを積極的にコンパイルすることは有益です。なぜなら、関数の終わりを見つけるためには少なくとも軽量な解析が必要だからです。JSでは、関数の終わりを見つけるには完全な構文解析が必要です。中括弧のようなもので簡単なショートカットを使うことはできません。JavaScriptは複雑な言語だからです。
様々なことができます。関数が実際にどこで終わるかを把握する簡単な方法はありません。そのため、それを修正するには関数全体を解析する必要があり、また積極的にコンパイルするかどうかを決定した後、ネットワークからスクリプトを読み込む作業と交互に行われる部分があっても、バックグラウンドスレッドでそれを行う必要があります。
代わりに呼び出し時にのみ関数をコンパイルする場合、作業を並列化するにはもう遅すぎます。メインスレッドはその関数が存在するのを待っているためロックされています。コード内に関数があるからといって、まだその関数を呼び出せるわけではありません。JavaScriptは私たちの下手な構文を取り、それを私たちのマシン上で実行されるパフォーマントなものに変換するために多くのことを行っているからです。
呼び出そうとしている関数が最適化されていない場合、呼び出し時に並列化することはできません。最適化されるまでブロックする必要があります。多くのWebページは、積極的なコンパイルのために正しい関数を選択することで恩恵を受けるでしょう。例えば、人気のあるWebページでの実験では、20ページ中17ページが改善を示し、平均的なフォアグラウンド解析とコンパイル時間は半秒以上短縮されました。
630ミリ秒というのは驚異的です。この機能は明示的なコンパイルヒントと呼ばれています。これにより、開発者はどのJavaScriptファイルと関数を積極的にコンパイルするかを制御できます。Chrome 136では、個々のファイルを積極的なコンパイル用に選択できるバージョンが提供されています。このバージョンは、積極的なコンパイル用に選択できるコアファイルがある場合や、そのようなコアファイルを作成するためにソースファイル間でコードを移動できる場合に特に役立ちます。
ファイルの先頭にこの魔法のコメント「//all-functions-called-onload」を追加すると、スクリプトを読み込むときにそのファイルが優先されます。例を示します。スクリプト1、スクリプト2があります。スクリプト1にはこのコメントがなく、スクリプト2には「all-functions-called-onload」があります。テストページに移動した時のログを見ると、テストファンク2に移る前にテストファンク1に対して完全な解析が行われていることがわかります。
テストファンク1は遅延コンパイルされたため、最終的に呼び出されたときに関数イベントを解析しているのがわかります。興味深いですね。ここでの違いは、テストファンク2が完全な解析に直接スキップすることです。コンパイルがそれを解析してコンパイルすることを強制したため、対応するイベントは表示されません。なるほど、理解できました。
ここではテストファンク1はいくつかの異なるステップを経ています。事前解析、完全解析、関数の解析、そして解釈が必要です。テストファンク2では、そのコメントにより即座に完全解析され、その後インタプリタが実行できます。ここでは意味のあるステップをスキップしており、特定のものを優先したい場合には非常に便利です。
これは私がしばらく話していない特定のフレームワークを思い出させます。Quick（クイック）です。Quickがどのように機能するかご存知ない場合、これはAngularを作った人物が、ある意味でAngularで行ったことへの謝罪として作ったものです。Angularとは可能な限り対極にあります。
Quickが焦点を当てたかった主なことは再開可能性でした。ページロードについて考える必要があります。ユーザーがWebページにアクセスするとします。テスト.comにアクセスするとしましょう。実際には垂直の方が意味があります。なぜなら複数のレイヤーが必要だからです。ユーザー、ブラウザ、サーバーがあるとします。
ブラウザはtest.comに移動します。サーバーはそのページのHTMLで応答します。このHTMLには私たちが必要とするいくつかのものが含まれています。こちらで解析します。この矢印を描きましょう。HTMLを解析してスクリプトタグを見つけます。HTMLを解析してすべてのスクリプトタグを見つけ、それらをリクエストする必要があります。
script1.js、script2.jsなどをリクエストするとします。そして今、これらのスクリプトがすべて返ってきます。この間、HTMLファイルの内容がユーザーに表示されていることは注目に値します。このような見た目のWebページがあり、そのページにボタンがあるとします。カウンターで、クリックするとカウンターが上がるようにしたいです。
取得したHTMLにはこれらすべてが含まれています。問題は、HTMLにはこれをトリガーするJavaScriptが含まれていないことです。それは別のファイルにタグ付けされています。そこで、ユーザーがクリックしたとき、JSが読み込まれる前にクリックすると何も起こりません。なぜならこのボタンが何をするのか、それが発生したときにDOMをどのように更新するかを説明するJavaScriptがないからです。
クリックイベントはどこにも行きません。今、これらのスクリプトがかなり大きいと想像してください。JSファイルを送信し、ブラウザはそれらのファイルを解析して何かをする必要があります。私の素晴らしい矢印をここにコピー貼り付けします。JSを解析してコンパイルし、それからJSを実行してDOMにバインドします。これらのJSファイルが解析、コンパイル、実行されるまで、Webページはインタラクティブではありません。
HTMLファイルが読み込まれてから、それがすべて完了するまでの時間、この全体のウィンドウではインタラクションが機能しません。HTMLが読み込まれた後でも、正しいコンテンツが表示されていても、JSがHTMLから解析され、サーバーからフェッチされ、ダウンロードされ、再度解析され、コンパイルされ、実行され、DOMにバインドされるのを待つ必要があります。
その後、クリックアクションが機能し始めます。Quickの目標は、特に多数のスクリプトタグがある場合に、これを大幅に圧縮することでした。これらをすべて大きな個別のスクリプトとして送信するのではなく、基本的な対話を説明したり、少なくともイベントを予約したりするための少量のJSをHTMLにインライン化するとどうでしょうか？そうすれば、JSが読み込まれた後、イベントを発生させることができます。
それが現在のReactの動作方法です。サーバーからJSがフェッチされる前にReactページを読み込むと、イベントがキャッシュされ、完全なJSを取得した後、正しい結果を得るためにそれらのイベントが仮想DOMに対して再生されます。QuickはHTMLに状態を埋め込むことでこれを処理します。
Quickが以前に機能していた方法は、インラインJavaScriptや非常に短いJavaScriptが、UIのさまざまな要素とどのようにインターフェースするかをここにタグ付けされているように伝えるコメントのための奇妙なHTML構文でした。これは休止状態のようなもので、DOMを再作成するためにすべてのJavaScriptを再実行する代わりに、小さなJavaScriptのセットに、どの要素が何にアタッチされているかを説明し、この数字を更新できるようにします。それを囲むT8は基本的に、これはこの識別子であり、番号を更新したい場合は、これらのコメントの間のものを更新する必要があるとQuickフレームワークに伝える構文です。奇妙な構文です。
彼らはQuick 2.0でそれを圧縮しようとしました。代わりに要素内に何がどこにあるかの説明を入れ、これをより保守しやすくする方法としました。興味深い選択です。ここで言いたいのは、これらの決定はすべて、Quickがクライアント上の状態をインタラクティブ性とともにできるだけ素早く再開できるようにするために行われたということです。だからこそQuickと名付けられたのです。
フレームワークの全体的なポイントは、ページが読み込まれてからインタラクションが機能するまでをできるだけ早くすることです。これは特に、膨大な量のJavaScriptがあるWebサイトにとって重要でした。イベントをキューに入れるためのJavaScriptがあるが、他のJavaScriptがはるかに重い場合、それがすべて実行される前にすべてコンパイルする必要があるからです。
ページロード時に実質的に即座にコンパイルされて準備ができることを保証するコメントが付いたファイルが1つあれば、QuickのインタラクティブDIYを事実上どんなツールやフレームワークにも組み込むことができます。Reactチームから見てきたのは、彼らが今このような考え方に傾いていることです。つまり、いくつかの機能はフレームワークに組み込むことが非常に理にかなっているということです。
フックのようなものは明らかにReact内部に属します。サーバーコンポーネントのようなものは、主にフレームワーク内に属します。しかし、その他の例えばDOMから要素が削除されたときにどうアニメーションさせるかというような事柄は、フレームワークが行う必要のないものです。一部のフレームワークはこれを解決しようとしましたが、問題は、何かが削除された時のプリミティブがブラウザに存在しないということです。
追加に対するものはあります。要素が表示されるときにフェードインさせたり、アニメーションさせたりすることができます。何かがDOMから削除されると、そのためのイベントは実際には存在せず、要素はなくなります。もう存在しない要素にCSSやスタイルを適用することはできません。Reactチームはそれを回避するためにたくさんの時間をかけることもできましたが、代わりにビュートランジションが実現するのを待ちました。
ビュートランジションは、ナビゲーション中のページ間や、要素が追加および削除されるときに、ブラウザ内の特定のウィンドウ内で要素を移行しやすくすることに焦点を当てたブラウザ標準です。最近、Reactに搭載される新機能についての動画を作りましたが、その大部分はビュートランジション機能についてでした。なぜなら今、彼らは要素をラップするコンポーネントを構築でき、DOMから削除すると自動的にアニメーションが付くからです。ビュートランジションはブラウザの標準であり、その問題を解決したからです。問題はブラウザにあったのです。
これも同様です。ReactチームはQuickのような再開可能性に関する何か奇妙なことができたでしょうか？おそらくできたでしょう。大変なことだったでしょうが、できたでしょう。代わりに、彼らはV8とChromeチームに、インタラクティブな部分をできるだけ早く読み込み、残りを後で読み込めるように、スクリプトの優先順位付けをよりよい体験にするよう促したと私はほぼ確信しています。
これは非常に理にかなっており、これがブラウザに導入されるのを見ることができて本当に嬉しいです。これにより、潜在的にすべてが高速化され、Next.jsのようなフレームワークはこれを活用して、アプリがそのインタラクティブな瞬間により早く到達できるようになります。インタラクティブまでの時間は克服が難しい指標ですが、これはそれを大いに助けるでしょう。
コンパイラヒントは特に新しいものではありません。これについてもっと知りたい場合は、私が誇りに思っている動画があります。「ついにCPUの仕組みがわかった」というものです。これはゲーム開発の世界から来たCasey Morritoriと一緒に、マイクロアーキテクチャやCPUについての内容で、彼が私に徹底的に教えてくれました。
プロセッサがより速く実行するために行うことの一つは、どのパスが取られる可能性が最も高いかを推測することです。なぜなら、特定のCPUサイクルは一つのことだけをしているわけではなく、多くのことをしているからです。あなたがプロセッサで、この関数を取得するとします。ステップを踏むたびに、そのステップでできるだけ多くの作業を行います。
整数がfに渡され、このswitch文が何かを実行する必要があることがわかっています。そのステップ中にできるだけ多くの作業を行いたい場合、どのパスが最も可能性が高いと思うかを推測し、そのステップを通じて計算を続けることができます。それが間違っていることがわかった場合、そのツリーを終了し、次のサイクルで正しく行うことができます。
しかし、開発者として、これらのパスのどれが最も可能性が高いかを知っている場合、プロセッサに推測させる代わりに、コンパイラヒントを通じて教えることができます。「このケースが発生する可能性が高いので、これを優先してください」というわけです。他のケースも発生する可能性があるので、このパスを保証しないでください。これはケース2が常に発生するようにハードコーディングしているわけではありません。
これはアーキテクチャレベルでこれがケースになることを最適化しています。そうでない場合は、中断できます。これは非常に小さなマイクロ最適化です。しかし、CPUレベルでのこれらの最適化は非常に重要です。コンパイラヒントは、これらのものから得られるパフォーマンスを最大化するために、特に低レベルのものでは、アプリケーション開発に不可欠になっています。
実際に何をしているのかをよく理解していない限り、これらを使用しないようにとほぼ全員が言っていることは注目に値します。私も同意します。コンパイラは最適化されたコードを吐き出すのが非常に得意であり、これにはV8を使用したブラウザに組み込まれたコンパイラも含まれます。V8は驚異的なエンジンであり、理解しがたいことができます。
非常に高速です。これはアプリケーション開発者として私たちが使用するためのものではありません。私がその行を書くことはおそらくないでしょう。「all-functions-called-onload」を使用する必要があるものを書く可能性は非常に低いです。しかし、Next.js、React、Remix、Sveltなど、私たちが使用する他のツールは、コンパイラステップの一部として私たちのコードの適切な部分を優先するための良い方法を見つけるかもしれません。
これが非常に素晴らしいところです。これにより、フレームワーク作者は、最初のインタラクティブな瞬間にアプリをより早く到達させることができます。そしてこれはウェブにとって素晴らしい勝利です。Chromeのようなチームがこれからもこのような方向に進んでいくことが予想されます。なぜなら、エラーハンドリングのような新しい構文や配列とインターフェースする新しい方法など、新しいブラウザ機能はあまり意味をなさないからです。私たちのAIツールはそれらが存在することや、それらがどのように機能するかを知らないでしょう。
また、他のブラウザにそれらを採用させることも難しいです。そのため、他のブラウザがそれをサポートしていない限り、ポリフィルしない限り、その構文を使用することはできません。そして今、ポリフィルしていても重要ではありません。このようなものはAIが知る必要のない勝利です。私のAIコードツール、最近加わったJavaScript開発者チーム、これらの人々は誰も、フレームワークが高速になることを可能にするChromeに追加される新機能について知る必要はありません。
私たちがこのようなスタックを構築していると考えることができます。私はアプリ開発者です。アプリコードを書きます。アプリコードはフレームワーク内で動作します。フレームワークはコンパイルされ、コンパイルされたコードはランタイムに出力されます。歴史的に、私たちはこの世界にかなり焦点を当ててきました。フレームワークはアプリコードを書く私たちの経験をどのように改善できるか？どうすればより良いアプリケーションソフトウェアを作れるか？アプリコード部分を特に書きやすくする新しいフレームワークをどのように作れるか？その部分は簡単になりすぎています。
この範囲内の多くのものを生成できるAIがあるので、真下のものを変更したくはありません。使用するフレームワークを変更する場合、上のすべてを置き換える必要があります。アプリコードは破棄する必要があり、アプリ開発者は新しいコードを書くために新しいフレームワークに乗り換える必要があります。
そのため、ここから下のものに触れることに以前よりも躊躇しています。実質的に、これからは上のすべてを変更したくないラインを引きました。なぜなら変更すると、カーソルなどで使用しているツールがそれらの変更に追いつかないからです。そこで今の疑問は、アプリコードを考えると、特定のReactアプリケーションがあった場合、それを改善するために何ができるかということです。コードがより高速に出力されるようにフレームワークを改善するか、アプリコードをより良くするためにReact内で最適化を行うことができます。コンパイラを改善するか、このフレームワークコードを取得してより性能の良いものを出力する新しいコンパイラを構築することができます。出力されるコードがより高速に実行されるようにランタイムを改良することができます。おそらくフレームワークが使用できる新しいプリミティブをランタイムに追加します。しかし今まで以上に、この領域は変化が見られる場所だと思います。そしてGoogleのChromeチームやウェブ標準委員会は、アプリコードで開発者として書くものよりも、ここで何が起こるかに焦点を当てるでしょう。
これの素晴らしい例はscheduler.yieldです。scheduler.yieldは、Reactチームがそれを非常に欲しがったためにChromeが本質的に追加せざるを得なかった機能です。scheduler.yieldの役割は、アクション中に自分の作業を中断することです。ここにクリックのためのイベントリスナーがあり、スピナーを表示し、yieldし、その後このスローコンテンツスワップという他の部分を行うとします。スピナーをすぐに表示したいです。しかし、単にスピナーを表示してからコンテンツスワップを行うだけだと、特にこれが非同期でない場合、問題が発生します。それらは同じイベントの一部として同時に発生するからです。そのため、スピナーは表示されないでしょう。なぜなら後に起こるコンテンツスワップが同じイベントの一部として直後に発生するからです。
これは残念です。そのため、Reactのようなフレームワークがすぐに何かを表示し、その後完了したら残りを表示したい場合、あるいはキーボードでの入力中にレンダリングを中断できるようにしたい場合、多くのフレームワークは何か同期的なものを非同期にしたり、ランダムなnoopを待ったり、あるいはしばしばsetTimeoutを0に設定するような奇妙なことをする必要があります。その理由は、イベントキューをチャンク分けするためです。ブラウザにイベントがある場合、イベントループがあります。ユーザーがボタンをクリックしました。これはonclickがトリガーされたようなものです。onclickには多くのものが含まれています。ここで見たような部分があります。スピナーを表示するという高速な部分があります。スピナーの表示には1msかかるとしましょう。しかし、遅いペイントもあり、それには800msかかります。
理想的には、スピナーの表示はすぐに行われ、遅いペイントは別々にキューに入れられるようにしたいです。これらをキュー上の独立した別々のものに分割したいです。しかし、今度はonclickではなく、入力のonchangeだと想像してください。検索ボックスがあります。ユーザーが検索クエリを入力し、検索すると下のコンテンツが更新される古典的なWebページです。
そこで、Cで検索するというonchangeをトリガーしますが、まだ入力を終えていません。そして今、元々ブロッキングや他のことなしにこれら全てを1つのイベントに入れたと想像してください。次に、残りを追加します。その後、再度すべてを再描画する必要があります。次に、スペースで新しいイベントが入ってきます。
ここでの問題はスティッキーキーです。Webページの入力に入力していて、新しいキーを押すたびに遅くなり、最終的に多くのキーが一度に入力されるという問題を皆経験したことがあるでしょう。それは各キープレスが遅いものをトリガーし、中断の機会がないためです。
yieldを追加した理由は、以前は遅いペイントを呼び出すためにsetTimeoutを使用していたからですが、そのように呼び出すとそれは新しいイベントになり、すぐ後に来るイベントではなくなります。キューの終わりに追加されるでしょう。そのため、キューをフラッシュするために現在保留中のすべてを処理する必要があります。
Reactチームが望んだのは、2つのもの、つまり何か高速なものと遅いものがあるこのイベントの途中で、「ねえ、もっと重要なことはありませんか？」と尋ねてチェックする能力でした。そのため、高速部分を実行し、代わりに他にやるべきことがあるかどうかをチェックしてから、遅い部分を実行したかったのです。
そうすれば、より重要なことがある場合、遅い部分を完全に終了して実行せず、代わりにより重要なことを上に置くことができます。キュー内の位置を放棄せずにタスクを中断する能力がyieldの魔法です。ブラウザに「ここで止まって。もっと重要な作業があれば、代わりにそれをやってください。でも、なければ、中断しないで。私が行っていることを続けさせてください」と伝えているのです。
残念ながら、これは3年以上前のことですが、yieldはまだほとんどのブラウザに導入されていません。幸いにもChromeには入っています。setTimeoutの動作でポリフィルすることはできますが、Yieldで得られるのと同じ処理速度は得られません。
これにより、あなたや私ではなく、フレームワークの作者がブラウザで何が起こるかについて決定を下すことができます。そのため、もう一度検索クエリがある場合、入力するたびに常にすぐにその入力ボックスの内容を更新したいと思うでしょう。それをできるだけ最新の状態に保ちたいと常に思うでしょう。そして、古い結果が表示されていても、それは大丈夫です。
誰も気にしません。別のキープレスが入ってきた場合、毎回キープレスするたびに下の巨大なフィールドを再レンダリングしないでください。明らかに、Firefoxのnightlyバージョンには現在yieldがありますが、Safariにはまだありません。そこで、この例全体を持ち出した理由は、「ああ、みんながこれについて知って使うべきだ」というわけではなく、具体的にはあなたが気にする必要がないからです。なぜならそれはこのライン以下に存在するからです。
Reactのコアやあなたが自分で構築している他のフレームワークに取り組んでいない場合、これらの詳細はそれほど重要ではありません。知ることは非常に素晴らしいことです。だからこそあなたはこれを見ているのです。私は心からこれらのことを楽しんでいます。しかし、ここでのポイントは、ラインより上のイノベーションは終わったということです。
私たちのツールがそこにあるものをある程度固定してしまったため、上ではそれ以上のことが起こると期待できません。道路が大幅に改善されたり、道路の機能が変わったりしないのと似ています。なぜなら、特定の方法で動作することを期待する車がたくさんあるからです。私たちのツールの多くは、これが特定の方法で動作することを期待しています。
それは大丈夫です。つまり、より多くのイノベーションがここで発生する必要があります。そしてそれが私たちが見ているものです。JavaScriptへのコンパイラヒントの導入はそれに完全に適合します。フレームワークの作者やコンパイラなど、内部のものがブラウザのランタイムでより高速に実行されるコードを出力できるようになります。
このような奇妙なブラウザの話を深く掘り下げ続けたくはありません。私の言いたいことは理解していただけたと思います。うまくいけば、これはコンパイラヒントがなぜ起こっているのか、なぜあなたがそれらを使用すべきではないのか、そして時間の経過とともに私たちのブラウザとブラウザ内のコードがどのように改善され続けるかをより理解するのに役立つでしょう。みなさんはこれについてどう思うか気になります。
これはあなたにとって役立ったでしょうか、それとも完全にナンセンスだったでしょうか？教えてください。それでは、次回まで、ピースナーズ。
コメント