Modern.js 前伝 - バイト現代ウェブ開発

振り返って補足：当事者は迷う、今振り返ると Modern.js の発展は、初期の宣伝と比較して氷山の一角を露呈している。常に新しい。最初は語雀に発表され、今はブログに移されている。

原文は GMTC2021 での講演現代のウェブ開発に入る（GMTC 2021 講演「バイトダンスの現代的なウェブ開発の実践」全文）

もう一つ対応する PDF は、今は公開しない。

技術的詳細#

三つの部分：

全体的に「伝統的な開発」を振り返り、ボトルネックを見つける
問題を解決するために起こった変化とトレンド
バイトダンスの技術的成果、これを「エンジンのアップグレード」と呼ぶ

バイトダンスのような大企業ではプロジェクトが多く、規模が大きいため、フロントエンドの問題がより明確に浮き彫りになる。

現代のウェブ開発の現状と未来：https://zhuanlan.zhihu.com/p/88616149

伝統的な開発と問題#

下の図は伝統的な開発技術スタックを示している。図を読んでください。

図の下から上にかけて、抽象レイヤーが下層から上層に向かっている。最右の三つのボックスは、最下層から最上層まで延びており、これらがエンドツーエンドのソリューションであることを示している。左側の体系や互いに切り離されており、大量の重複を含んでいる。このシェアは時間の関係でこの部分については話さない。

青いボックスはコードレベルのもので、緑のボックスはプラットフォームレベルのものである。

この技術は停滞に近づくと、多くの問題を示す。

スキャフォールド。構造と例がある
必ず変更しなければならないファイルがあり、変更後に実際のプロジェクト構造に合致する
複数のプロジェクトが同じスキャフォールドを使用し、それぞれ発展し、最終的に差異が大きくなり、再利用が難しい
スキャフォールドが進化しても、元のプロジェクトには利益をもたらさない
プロジェクトテンプレート
異なるプロジェクトでテンプレートが異なり、ますます増える
テンプレートはそれぞれ発展し、更新が停止するものもある
webpack のラッピング
誰もが webpack を設定する必要がないように、ラッピングや包装を行う、慣例
ラッピングの抽象度は限られており、設定の API は多様で、複雑になると変更が必要になる。規範が多すぎる
コンパイラツールの進化。webpack の他にも選択肢が多い。これを JS の第三紀元と呼ぶ。具体的な技術的詳細は省略
dev build だけでは不十分で、下の図は非常に神秘的で、一列一列に見ると、ここでは展開しないが、フロントエンドにはまだ多くの作業があり、dev と build だけでは不十分である。そして、プロジェクトの下層サービスには関与しない。

図中のこの文章は Redux の作者 Dan が書いた記事からのもので、JS ツールの設定 API の設計について語っている。この文章はこの分野の抽象と設計が巨大な影響をもたらし、高いハードルがあり、非常に真剣かつ専門的に扱う必要があることを述べている。このような作業は高度な集中を必要とし、「Webpack エンジニア」に様々な「規範」を扱わせるべきではない。

JavaScript のるつぼ: https://increment.com/development/the-melting-pot-of-javascript/

JavaScript の第三紀元: https://www.swyx.io/writing/js-third-age

続き

フロントエンドのエンジニアリング。コードレベルに限らず、プラットフォームレベルには至らない。（微妙に serverless？）
react の問題。
どの具体的な技術フレームワークを選ぶか。彼らは徐々に react に統一されていく、その理由はコミュニティのエコシステム、アプリケーションの規模、設計の進化、設計のトレンドである。この部分はあまり意味がなく、結論があれば良い。
react はフレームワークとしての機能が不完全
フレームワークレベルを見てみると、例えば nest はバックエンド中心の開発を提供し、普通の web プロジェクトのフロントエンドとの関係はあまりない。node の導入はハードルが高く、node から bff など、略する
核心は：層分け + 関心の分離（下には絶対に serverless がある）