この記事は、意図的に挑戦的で、二極化し、示唆に富むものです。それはあなたがおそらく知らなかった多くの新鮮なコンテンツとアイデアをカバーしています。
1はじめに
フロントエンド開発がどのように機能するかを理解するために従うことができる論理的な議論の首尾一貫したチェーンを作成するために最善を尽くします。
また、「非開発者」がほとんど追いつくことができるように、このブログ投稿をシンプルに保つようにします。
2.コンピューターまたはスマートフォンにはコアがいくつありますか？
このようなCPUの写真を見たことがあるでしょう。
たとえば、Macを使用している場合は、左上隅にあるAppleアイコンをクリックしてから、[このMacについて]をクリックすると、次のように表示されます。
プロセッサ3.2GHz8コアIntelXeonWプロセッサ
iPhoneには6つのコアがあります。
すべてのコンピューターまたはスマートフォンには、いくつかのコアがあります。
これは、複数のスレッドを並行して実行できることを意味します。
エンジンシリンダーが1つだけの車を走らせますか？
あなたの答えが「もちろん違います！」の場合。非常に遅くなります！」の場合は、この記事を注意深く読む必要があります。
3.ブラウザはいくつのコアを使用しますか？
その一部として、ブラウザはタブ/ウィンドウごとに1つのコアのみを使用します。
意味：AngularまたはReactアプリは次のようになります。
アプリケーションで実行されるJavaScriptタスクが多いほど、処理は遅くなります。最悪のシナリオは、UIが完全にフリーズし、コアの1つが100％になり、他のすべてのコアが完全にアイドル状態になることです。
これはまったくスケーラブルではありません。
[トピック外]シンプルで小さく、かなり静的なWebサイトまたはアプリケーションを作成している場合は、この設定で十分です。
4.WebワーカーAPI
WebワーカーAPI-WebAPI| MDN
Webワーカーを使用すると、実行のメインスレッドから独立したバックグラウンドスレッドでスクリプト操作を実行できます。
developer.mozilla.org
Webワーカーを使用すると、Webアプリケーションのメイン実行スレッドとは別のバックグラウンドスレッドでスクリプト操作を実行できます。これの利点は、面倒な処理を別のスレッドで実行できるため、メインスレッド（通常はUI）がブロック/スローダウンされないことです。
Webワーカー-ウィキペディア
zh.wikipedia.org
W3CとWHATWGは、Webワーカーを、クリックやその他のユーザー操作に応答するスクリプトによって中断されない長時間実行スクリプトとして想定しています。このようなワーカーがユーザーアクティビティによって中断されないようにすることで、バックグラウンドで長いタスクを実行している間、Webページの応答性を維持できるはずです。
ワーカーの最も簡単な使用法は、ユーザーインターフェイスを中断することなく、計算量の多いタスクを実行することです。
したがって、ワーカーを使用すると、実際に複数のコアを並行して使用して、このスケーラビリティの悪夢を終わらせることができます。
次の段落を本当に落ち着かせましょう。
ワーカーの最も簡単な使用法は、ユーザーインターフェイスを中断することなく、計算量の多いタスクを実行することです。
これは問題につながります。
「最も費用のかかる作業は何ですか？」
答えは簡単です。UIフレームワークまたはライブラリ自体と、それを使用して構築するアプリケーションです。
これはアイデアにつながります。メインスレッドから移動できるすべてのものを移動して、このスレッドが純粋に実行していることに集中できるようにします。つまり、DOMの操作です。
アプリケーションがメインシステムで実行されなくなった場合、UIの速度を低下させたり停止したり、メモリリークを発生させたりすることはありません。
この考え方が次のような考え方につながっています。
5.アプリケーションワーカーが主なアクターパラダイムです
このパフォーマンスのボトルネックに対処するために、メインスレッドを可能な限りアイドル状態に保ち、DOMのレンダリング/動的操作に完全に集中できるようにします。
現在発生する可能性のある最悪の事態は、このコアが100％で実行されている間、アプリワーカーの速度が低下することです。ただし、これはUIには影響しません（レンダリングスレッド→メインスレッド）。
おそらく、シングルページアプリケーション（SPA）に最適なソリューションは次のようになります。
アプリケーションワーカーが過度のロジックを処理するのを防ぐために、仮想DOMワーカーを使用することを選択できます。この場合、状態遷移間の遅延更新が計算されます。かなりアイドル状態のアプリケーションワーカーを使用するアプリケーションの場合、代わりに、アプリケーションワーカー内で仮想DOMエンジンを直接実行することを選択できます。
データワーカーを使用することもできます。リモートデータストアがあり、データをローカルで並べ替え/グループ化/フィルタリングしたい場合、これらの計算はそこで発生する可能性があります。
このブログ投稿では、同じAPIを維持しながらWorkersの使用を不要にする方法について説明しています。
JavaScriptの開発。代替のWebワーカーを作成する
これは、メインスレッドまたはWebワーカー内でJavaScript関連のロジックを多数実行している場合に意味があります。
6.ワーカーはDOMにアクセスできますか？
WorkerGlobalScope内では、windowとwindow.documentは未定義です。
意味：実際のDOMに直接アクセスすることはできません。
したがって、ここには基本的に2つのオプションがあります。
オプション1は、ワーカー内にDOMAPI全体を再作成することです。私の意見では、これは悪い考えです。労働者はある理由でDOMを理解しておらず、頻繁に変更されるロジックがたくさんあります。DOM OPは同期しなくなり、それらを順番に大量に起動すると、多くのワーカーpostMessageが発生します。唯一の利点は、以前と同じようにアプリケーションを作成し続けることができることです。これには疑問があります。後でそれをより良くする方法をお見せします。
実際、まさにそれを行うプロジェクトが1つあります。
GitHub-ampproject / worker-dom：あなたが知っているのと同じDOM APIとフレームワークですが、Webワーカーです。
よりスマートなアプローチはオプション2です。ワーカーは実際のDOMについて知らないようにする必要があるという概念に固執します。
これにより、仮想DOMの使用が絶対に必要になります。
ソーシャルメディアで読んでいると、「vdomが悪い！」のような投稿をよく目にします。
これは単に真実ではありません。それがどのように実装されるかに大きく依存します。
AngularとReactの主な障害は、xmlまたはJSXベースのテンプレートです。これらの人は、私たちが使用できるデータ構造に変換する必要があります。
JavaScriptは高速でも、文字列を解析するように構築されていません。
テンプレートの解析には費用がかかり、サーバーサイドレンダリング（SSR）でさえ人気が高まっています。私は20年前にそこに行き、html出力ファイルを生成するPHPベースのCMSを作成しました。
今日のクラウドでは、より多くのクライアント接続を処理できると言えますが、リッチ/ファット/シッククライアントの概念は依然として完全に理にかなっています。
7.ワーカーがDOMにアクセスできる例外はありますか？
実際に1つあります。
OffscreenCanvas-Web API | MDN
OffscreenCanvasインターフェースは、オフスクリーンでレンダリングできるキャンバスを提供します。ウィンドウとオフスクリーンの両方で機能します。
ワーカーはCanvasDOMノードの所有権を受け取ることができます。
これはすでにChromiumで正常に機能しており、Safari（Webkit）とFirefoxで積極的に実装されています。おそらくまだ6か月先なので、2022年の論点です。
8.スマートな方法で仮想DOMを作成するにはどうすればよいですか？
JavaScriptは文字列の解析には適していませんが、ネストされたオブジェクト/配列構造の処理には適しています。この形式には、よく知っている必要のある名前が付いています。JSON。
JSONベースのvdom構文に固執する場合、UIで高価なテンプレート解析を繰り返し実行したり、この部分をビルドステップに移動したりする必要はありません。
これは、JSX出力を直接操作するのと多少似ていることは間違いありません。
正しく行われると、仮想DOM内に変数、if / elseステートメント、バインディング、メソッド、ループ、またはあらゆる種類のロジックはありません。1000行以上のコードを含むテンプレートは表示されません（Angularを参照）。
プログラムによるアプローチでは、JavaScript内のロジックを使用します。たとえば、リストを作成するときは、最初にスケルトンのVdomを作成し、データストアが読み込まれると、レコードを反復処理して、その場で新しい仮想DOMノードを作成できます。
この概念により、実行時にコンポーネントのVdomを根本的に変更できます。はい、コンポーネントのvdomの変更は、インストールの前後でまったく同じように機能します。
無限スクロールやその他の高度な機能の実装が簡単になります。
あなたはここでより多くの入力を見つけることができます。
JSONベースの仮想DOMを使用する利点
JSONベースの仮想DOMの新しいフォーマットの概念
プログラムによるアプローチは低レベルのvdomOPには意味がありますが、アプリケーションの作成には宣言型のアプローチを使用することをお勧めします。
これらの2つのポイントを達成するために必要なのは、vdomの上に宣言型の抽象化レイヤーであるコンポーネントツリーを追加することだけです。
意味：コンポーネントクラスを作成するときにのみvdomを使用します。アプリケーションを作成するために、コンポーネントツリーに固執することができます。
9. UI開発はブラウザで直接実行できますか？
Reactが5〜8年前に普及したとき、ブラウザは最新のECMAScript機能をサポートするというひどい状態にありました。
たとえば、クラス（ES6）またはJSモジュールはサポートされていません。
この時点で、UI開発をノードに移動することは完全に理にかなっています。
意味：最新の言語機能を使用でき、1つのビルドステップを犠牲にして、ブラウザーが理解できるJavascriptにコードをコンパイル/翻訳します。
ブラウザベンダーは追いつくのに良い仕事をしています。現在、多くの優れた新機能がすぐに利用可能であり、フェーズ3の推奨事項のほとんどはすぐに実装する準備ができています。
ワーカースコープでは、JSモジュールはChromium内で正常に機能します。Webkit（Safari）も実装を完了しましたが、それでもSafariテクノロジープレビューに限定されています。Mozilla（Firefox）は積極的に宣伝しています。
完全なサポートは2022年に準備が整うと安全に想定できます。
ビルドステップは費用がかかるため、UIライブラリまたはフレームワーク開発モードでは不要になります。
その利点は明らかです。
- JavaScriptは、ブラウザエンジンが理解できる唯一のプログラミング言語であることが意図されています。
- ブラウザが理解できない方法でJSを書くのは間違っていると感じます。
- UI開発をブラウザーに戻すことで、ビルド/トランスパイルやソースマップを使用せずに実際のコードをデバッグできます。
- ホットモジュールの交換は必要ありません。
特に、外部要因によるエラーがないことを確認できるので、コードの作成とデバッグはまた楽しいものになります。
ローカル/本番出力を作成するには、webpackのようなツールが依然として必要です。ただし、これらはランタイム環境ではなく、ビルドツールになります。
ノードからデノへの移行により、これがさらに容易になります。CommonJSは遅かれ早かれ死ぬでしょう。denoにパッケージマネージャーが追加されると、ブラウザーで実行できる構文を使用するパッケージが増えます（たとえば、ベアモジュール指定子なし→無効なパスのインポートとファイル名拡張子なし）。
10. TypeScriptには未来がありますか？
これはおそらくこの記事の中で最も物議を醸す部分です。JSコミュニティは2つに分かれています。TSを使用するのが好きな人もいれば、触れることを拒否する人もいます。あなたの議論を楽しみにしています。
私の意見。
さて、ノードでUIを開発するとき、そして必要なビルド/変換ステップがあるとき、TSを使用することは問題ありません。
UI開発がブラウザに再び入ると、これは根本的に変わります。
TSを使用するための完全なビルドステップを設定しますか？
この時点で、それは高すぎるようになります。
問題はです。TSはWeb標準ではありません。現在、ブラウザに実装する予定はありません。
歴史は、Web標準に基づかないWebテクノロジーに何が起こるかを何度も教えてくれました。それらは、ある時点で消滅するでしょう。MSSilverlightは完璧な例です。
一般的に、型チェックは良いことです。主な問題は、AngularとReactがJSDocベースのコメントを使用しないことです。また、JSDocを使用すると、コードを記述しているときにIDEに警告が表示されます。
実際、JSDocベースのコメントを使用してTSを「偽造」することも可能です。
JSDocコメントでTypeScriptインターフェースを書く方法
それは間違いなく私たちが議論できるオプションです。
プログラミング言語で直接型チェックが必要で、ビルド手順を気にしない場合は、Dart2の方が適しているのではないでしょうか。
Dart2はワーカーを完全にサポートしているため、ワーカー設定をそこで実行することもできます。モバイルの利点には、AOTコンパイルが含まれます。
11. Reactの何が問題になっていますか？
公平を期すために、Reactの前にはJQueryがありました。Reactが普及したとき、それは大きな改善であり、Reactは仮想DOMを普及させた最初のライブラリでした。
では、なぜ2022年にReactを使用すべきではないのでしょうか。
- Reactはメインスレッド内で実行されます。
- ReactのコードベースはCommonJSに基づいています→ビルドステップがないと、ブラウザー内で実行されません。
- JSDocコメントはありません。
- JSXテンプレートの解析にはコストがかかります。サーバー側に移動するSvelteのようなコンパイラもあります。
- Reactはコアを公開しません。すべてがComponentを拡張しますが、これはまったく意味がありません。
- 状態管理は理由もなく難しすぎる。
- render（）メソッドは間違いなく問題があります。
問題をさらに詳しく説明しましょう。状態の変化がレンダリングをトリガーしないようにすることは、間違いなく複雑です。Reactコンポーネントに子コンポーネント（render（）内のカスタムタグ）が含まれている場合、キーを注意深く使用しないと、新しいインスタンスが作成されます。
コンポーネントインスタンスを再作成すると、関数型プログラミングが一般的になります。これは、クラスインスタンスを必要以上に頻繁に作成し、独自のコンポーネント実装でメモリリークが発生する可能性があるためです。
アイテムの位置に影響を与えるなど、状態の小道具がたくさんある場合は、JSXにかなりのロジックを追加する必要があります。
Reactは単なるライブラリであり、フレームワークではありません。この意味は。コンポーネントはほとんどすべてが内部にあります。論理的な階層チェーンはありません。
core.Base-> component.Base-> button.Base-> tab.header.Button
render（）の狂気が解決されたら、作成したいものに最も適切な基本クラスを選択できます。たとえば、コンテナには、その子のvdomオブジェクトへの参照を含むvdomオブジェクトがあります。次に、JSベースのインスタンスを再作成せずに、子コンポーネントのvdomを変更できます。
この時点で、状態管理は簡単になり、フックも必要ありません。特に、vdomエンジンへの呼び出しを1回だけ確保する場合は、多くの構成を並行して変更することが重要です。
12.マルチウィンドウアプリケーション
この概念は、SharedWorkersを使用するようにワーカー設定を変更することでオプションで拡張できます。
これにより、JSインスタンスの位置を維持しながら、コンポーネントツリー全体をさまざまなブラウザウィンドウ間で移動できます。
マルチウィンドウ状態管理、バックグラウンドは必要ありません。
ウィンドウ間でのドラッグアンドドロップが可能です。
詳細については、ブログにいくつかの記事があります。
13.ワーカー設定を自分で実装する必要がありますか？
上記のすべてのアイデアを単独で実装するには、単に何年もかかります。
あなたは幸運です、私はあなたのためにそれをしました。エコシステム内には12,000を超えるコミットがあり、MITによって完全にライセンスされています。
GitHub-neomjs / neo：アプリケーションワーカー主導のフロントエンドフレームワーク
これには、promise（メッセージパッシングの上にある抽象化レイヤー）を介してさまざまなワーカーまたはマスターのメソッドを直接呼び出すことができるリモートメソッドアクセスAPIが含まれます。
コントローラ、ビューモデル、アプリケーション、その他のユーティリティクラスとともに、多数のコンポーネントがすでに配置されています。
MVVM、Observableなどのアーキテクチャデザインパターンをサポートするために、サードパーティのライブラリは必要ありません。
特に、状態管理は非常に簡単です（ヒント：クラス構成システム）。
多くのデモアプリと例があなたの探索を待っています。40以上のブログ投稿：https：//neomjs.github.io/pages/
CLIは高度です。ワンライナーで新しいアプリケーション（ワークスペース）を作成できます：npxneo-app。アプリ間でブロックを分割することもできるため、1つのページに複数のアプリを配置する場合のオーバーヘッドはほとんどありません。
14.最終的な考え
2022年まで待つ必要はありません。これらのアイデアを今すぐ使用して、フロントエンド開発を次のレベルに引き上げることができます。一部の企業や開発者はすでにそれを行っており、新しいテクノロジーをビジネス上の利点に変えるために彼らの有利なスタートを利用しています。
neo.mjsは「最もエキサイティングなテクノロジーアプリケーション」にノミネートされました。
ほとんどの開発者は、イライラするneo.mjsプロジェクトの存在にまだ気づいていません。
誰かがこれらの概念について私が間違っていることを証明してくれるのを見たいです。
これを行うには、最初のネオベースのPoCアプリケーションを作成する必要があります。
この場合、コードを確認したいと思います。
実行時の動的DOM操作の場合、neoが最速のオプションです。特に、大規模で複雑なアプリケーションに関しては。
15.どのように始めますか？
この手法を使用して実際にアプリを作成する方法についてのチュートリアルを作成しました。
web4.0アプリケーションをマルチスレッドアプリケーションとして定義する
最後に、フロントエンドがすべての人に与えられ[Jiajun Yang：581286372]、すべての人がよりよく学ぶのを助けます！
