2021ビッグフロントエンドこの分野に革新的なスタープロジェクトはありませんが、細分化されたさまざまな技術分野で一定の拡大と深耕が行われており、多くの新技術や新機能があります2022 年に到来すると予想されています。ブレイクしてください。
現在のインターネットの「寒い冬」において、フロントエンド技術者は、内部スキルを磨き、常に自分自身を強化することによってのみ、春の「東風」にうまく対応できます。 それでは、フロントエンド技術者はどの「筋肉」を練習すべきでしょうか? おそらく、「2021 JavaScript Star Project」でいくつかの答えが見つかるかもしれません:
zx ツールキットのみ それのみ年間を通じて Star で最も急成長しているプロジェクトになるまで 7 か月かかりました。これは、スタック全体におけるフロントエンド開発の継続的な浸透と影響を示しています。
Svelteは突破できるでしょうか?
ネイティブ ES モジュールの受け入れが続いており、vite の勢いは止まらない一方、パフォーマンス上の懸念から、次のことを考慮してください。ますます多くのフロントエンド ツールが他の言語 (Rust、Go) で構築され始めていること。
1. TypeScript の着実な成長 Github からの言語使用データ (長年にわたるトップ言語) によると、
2021 TypeScript は依然として 4 位にランクされています。
2021 年を振り返る公式ロードマップでは、TypeScript の目標は型システムの改善と実装を継続することであることが明確になっています。強力なツール 生産性の向上、ユーザー エクスペリエンスの向上、コミュニティへの参加の増加、インフラストラクチャとエンジニア システムの改善。目標を掲げてから、TypeScript チームは今年 4 つのバージョンを非常に効果的にリリースしてきました。最新バージョンは 4.5 です。新機能の多くは実際に使用するのが楽しくなります。たとえば:
続き タプル型のサポートが優れており、任意の型だけでなくどこでも残余型を使用できます。
Web フロントエンド
、Node.js プロジェクト、パブリック モジュールのいずれであっても、スキャフォールディング テンプレートはデフォルトで TypeScript をサポートします。パブリック モジュール システムは、TypeScript を使用してコードを記述し、型チェックを行うだけでなく、ESLint を使用してTS 言語標準 AST を実装し、公開モジュールの仕様を実装するために特定の検証が使用され、TypeDoc と組み合わせて使用法ドキュメントなどを生成します。Outlook
フラット宣言ファイル ( フラット化宣言)、モジュールごとの d.ts ファイルではなく、合計の d.ts ファイルのみを出力します。
アンビエント デコレータは、API が非推奨であるかどうかなど、一部の環境情報を宣言するために使用されます。出力に影響を与えないランタイム コードは、d.ts 宣言ファイルにのみ反映されます。
条件付きコンパイル (条件付きコンパイル) は、C の #if マクロ定義に似ています。コンパイル前にコードを前処理し、条件を満たすコード分岐を保持できます。
関数式/アロー関数のデコレータ。現在、TypeScript のデコレータはクラス内でのみ使用できます。将来的には、クラス外でもサポートされる可能性があります。関数式とアロー関数はデコレータを使用します。 ＃＃＃＃＃＃＃＃＃＃＃＃等。
ロードマップにあるように、TypeScript は正しい方向に進んでいます。生産性を向上させるために実行できる多くの型機能、パフォーマンスの最適化、エクスペリエンスの最適化、サポート ツールがあります。 JS 言語の標準型システムになることを目指しています。 TypeScript の開発と改善が進むにつれて、将来的に TypeScript はブラウザーと Node.js でネイティブにサポートされるようになるのでしょうか?一緒に楽しみにしましょう。
2. React が先導し、革新を続ける
React 18 は、2 番目にアルファ、ベータ、およびリリース候補バージョンのリリースを完了しました。正式版は 2022 年初頭にリリースされる予定です。 React 18 がリリースされると、すぐに使える機能強化 (自動バッチ処理など)、新しい API (startTransition など)、React のサポートが組み込まれた新しい SSR アーキテクチャが含まれます。 。怠け者。
これらの機能は、React 18 で新しく追加されたオプションの「同時レンダリング」メカニズムのおかげで可能になり、React の多くの新しい可能性が解き放たれ、アプリケーションの実際のパフォーマンスと知覚上のパフォーマンスを向上させることができます。
React 18 は段階的な戦略を採用しています。React 18 の同時実行性はオプションの機能であるため、コンポーネントの動作に明らかな破壊的な変更が直ちにもたらされるわけではありません。アプリケーションのコードをほとんど変更せずに React 18 に直接アップグレードでき、自分のペースやニーズに合わせて新機能を試すことができます。
一般に、React 18 では次の 3 つの側面で更新が行われます。 ➢ 自動バッチ処理
#➢ サスペンス向け SSR
##➢ アプリとアプリ向けの新しい APIライブラリ開発者#● 自動バッチ処理
React 18 では、デフォルトでさらに多くのバッチ処理を実行することで、すぐに使用できるパフォーマンスの向上が追加されています。アプリケーションまたはライブラリ コードで手動でバッチ更新を行う必要はありません。バッチ処理とは、React がコールバック関数内の複数の setState イベントを 1 つのレンダリングに結合できることを意味します。
React 17 はイベント コールバックでのみバッチ処理しますが、React 18 では、あらゆるソースから可能な限り多くの setState をバッチ処理します。setState が Promise、timeout、またはイベント コールバックで複数回呼び出された場合でも、それらは 1 つにマージされます。 。 これらの新機能を有効にするには、ReactDOM.render を ReactDOM.createRoot 呼び出しメソッドに置き換えます。# サスペンス用 SSR
#正式名称は、選択的水和を備えたストリーミング SSR です。つまり、水の流れのように、renderToString のような 1 回限りのレンダリング メカニズムではなく、サーバーからクライアントへの継続的なレンダリング パイプラインを作成します。選択的ハイドレーションとは、選択的なハイドレーションを意味します。ハイドレーションとは、バックエンド コンテンツがフロントエンドにヒットした後、ユーザー インタラクションまたは DOM 更新動作に応答するために、JS がそれにイベントをバインドする必要があることを意味します。React 18 より前では、この操作は次のようにする必要があります。また、水分補給プロセスは遅く、全体的な遅れを引き起こす可能性があるため、選択的水分補給により、必要に応じて水分補給を優先できます。
#アプリおよびライブラリ開発者向けの新しい API
同時 API:
同時レンダリング関連の変更は React 18 One 向けです。主な変更点を一言で言えば、React アプリケーションの応答性を向上できるようになった点です。これは、レンダリングを中断する可能性がある設計アーキテクチャです。レンダリングを中断するタイミングは?より優先度の高いレンダリングが到着すると、現在のレンダリングは破棄され、より高速な視覚的応答と引き換えに、より優先度の高いレンダリングが即座に実行されます。useTransition: コンポーネントが次のインターフェイスに切り替える前にコンテンツが読み込まれるのを待機できるようにすることで、不必要な読み込み状態を回避します。
useSyncExternalStore: useSyncExternalStore は、外部ソースをサブスクライブするための useMutableSource を置き換え、次のような原因で発生する可能性のあるデータの不整合の問題を解決します。同時レンダリング: ライブラリの作成者にも必要になる場合がありますが、通常の開発者が使用する可能性はほとんどありません。
React 18 は、新しい React Native アーキテクチャ (React 18 の機能が利用可能) を搭載して来年リリースされます。
3. Svelte はフロントエンド フレームワークの戦いのダークホースです
フロントエンド分野は急増しており、フレームワークが台頭しています3 つの主要なフロントエンド キャリッジである React、Vue、Angular は常にトップ 3 内に留まっています。同時に、私たちは、数多くのフロントエンド フレームワークの中で、Rich Harris (Ractive、Rollup、Bubble の著者) によって開発された Svelte がダークホースとなり、フロントエンド フレームワークの中で目立つと期待されていることにも気づきました。
Stack Overflow が 2021 年に作成した最新の調査では、回答者の 71.47% が最も人気のあるフレームワークとして Svelte を選択し、React.js の 69.28%、Vue の 64.41% を上回りました。 JS Status 2020 調査では、Svelte はユーザー満足度 89%、関心度 66% で第 1 位を獲得しました。 Svelte はその誕生以来、React/Vue などのフレームワークのベンチマークに使用されてきましたが、Svelte と React に関する議論や、2019 年に Youda が回答した「Svelte をフロントエンド フレームワークとして扱う方法」や、 vue-Svelte- サイズ分析評価は、Svelte の開発傾向を示します。
フロントエンドの戦いのダークホース
私たちの調査では、主に次の点から開発者が Svelte を愛していることがわかりました。
1. 開発効率の向上。 Svelte の構文は非常に簡潔で、インタラクティブなチュートリアルにより学習曲線と起動コストが低く、vue の構文に慣れている人は基本的にすぐに使い始めることができます。
2. サイズが小さくなります。 Svelte の中心的なアイデアは、静的コンパイルを通じてフレームワークの実行時のコードの量を削減することです。これは、小規模なアプリケーションでは明らかな利点があります。React の圧縮バージョンのサイズは 42.2 KB、Svelte の圧縮バージョンは 1.6 KB 。ただし、中規模および大規模なアプリケーションでは、この利点は徐々に減少し、欠点になることさえあります。
3. パフォーマンスの向上。 Svelte は一般的に使用される Virtual Dom を使用せず、代わりにテンプレート構文を使用して、コンパイラがコンパイル フェーズ中に更新する必要があるデータを記録できるようにします。これにより、Svelte は React だけでなく Angular や Vue よりも優れたパフォーマンスを発揮します。
4. Web コンポーネントの配布の改善。 Svelte は直接 JS にコンパイルされ、ブラウザで認識できる Web コンポーネントを生成するため、Svelte をベースに開発されたコンポーネントを React/Vue/Angular などの他のフレームワークで使用することができます。
時は経つのが早く、Svelte の開発スピードは私たちの想像を超えるかもしれません。 TypeScript をサポートしないフロントエンド フレームワークとして将来性がないとして批判されてきた Svelte も、2021 年には TypeScript をサポートします。UI ライブラリ Svelte Materials UI も徐々にイテレーションされており、開発者コミュニティも小規模なプロジェクトにどんどん参加しています。パートナー、Svelte のユニットのテスト、Web コンポーネント、SSR などの実践を強化します。
2021年を振り返って、Svelteで最も重要なことは次の2つです:
1. 2021年11月20日に秋のサミットが開催されました。サミットでは、リッチ・ハリスがスベルトの歴史について語り、ヴェルセルに加入し、その後はスベルトをフルタイムで維持することを発表した。コミュニティの多くの開発者もサミットに招待され、Svelte の実践の一部を共有し、Svelte のさらなる可能性を見ることができました。
2. SvelteKit はベータ版を正式にリリースします。 SvelteKit は、Vue.js に基づいて開発された Nuxt.js フレームワークと同様に、Svelte に基づいて開発された Web アプリケーション フレームワークです。サーバー側レンダリング SSR、ルーティングを継承し、TypeScript をサポートし、less/sass をサポートし、Vite パッケージ化およびその他の機能をサポートします。効率的に開発でき、高いパフォーマンスを発揮します。 SvelteKit にはまだ解決すべきバグがいくつかあり、不足している機能も早急に改善する必要があります。しかしそれでも、プロジェクトが実稼働環境でそれをあえて使用することを妨げるものではありません。
花が咲くのを待っています
Svelte は開発者の間で非常に人気があることがわかりますが、今のところ、大規模なアプリケーションを見るのはまだ困難です。 Svelte のパフォーマンス上の利点、ボリューム上の利点などは、大規模なアプリケーションでは検証されていません。特に大企業では React/Vue/Angular が最初に主流となっているため、すでに非常に完成度の高いシステム対応ソリューションが存在しますが、成熟したシステムは基本的に変更が難しく、新興企業が React やその他のフレームワークのような活発なコミュニティを持つことは困難です。 . スヴェルテは行かなければなりません 道はまだ長いです。しかし、Alibaba、Byte、Tencent などの大企業も Svelte 開発を新規ビジネスに活用しようとしているのを観察していますが、中小規模のアプリケーション、h5 アプリケーション、Web コンポーネントなどでは Svelte の利点があり、試してみる価値はあります。 Svelte には多くの利点がありますが、React/Vue/Angular の地位に自力で挑戦したい場合は、大規模アプリケーションのベンチマークを待ち、大手企業が Svelte ベースの UI ライブラリを立ち上げるのを待つ必要があります。偉大なる時が来るでしょう。
4. デスクトップ - フロントエンド開発の次の戦場
デスクトップ アプリケーションの影響力を拡大し続ける
Github が 2014 年に Electron オープンソース フレームワークを発表して以来、フロントエンドは Web クライアントの制限を飛び出し、デスクトップ アプリケーションを開発できるようになりました。近年では、Electron、React などのアプリケーション フレームワークに依存しています。ネイティブと Flutter によるデスクトップ アプリケーションのフロントエンド クロスエンド開発が可能になり、そのコンセプトは加熱し続けています。これらのソリューションは、QT や Xaramrin などの従来のテクノロジー スタックと比較して必ずしも最高のパフォーマンスを備えているわけではありませんが、コスト効率の高いオプションがいくつか登場し、デスクトップ アプリケーション開発の敷居を大幅に下げていることを意味します。
2021年は、フロントエンドのElectronやReact Native Desktopなどのアプリケーションフレームワークのアップデートが安定する傾向にあり、画期的なハイライト機能は登場していないものの、各フレームワークはパフォーマンスなどのペインポイントに重点を置いたものとなっています。徹底的な最適化が続き、近年人気のコンセプトとなっているFlutterも、2021年のベータ段階ではデスクトップ版も導入される予定で、急浮上したTauriはその優れた性能とパッケージで注目を集めているその規模とそのポテンシャルを過小評価することはできません。全体として、デスクトップ アプリケーション開発の分野では、フロントエンド テクノロジーの影響力が日に日に増大しており、フロントエンドが参加できるコンテンツの割合も増加しています。
Electron
Electron は、GitHub によって開発されたオープンソース フレームワークです。 Node.js (バックエンドとして) と Chromium のレンダリング エンジン (フロントエンドとして) を使用して、クロスプラットフォームのデスクトップ GUI アプリケーションの開発を実現します。 Slack、VSCode など、多数のよく知られたデスクトップ アプリケーションが Electron を使用して開発されています。 Electron に求められる開発能力は、フロントエンド開発能力の技術スタックと大きく重なるため、フロントエンド開発学生にとって、デスクトップ開発に Electron を利用する敷居は比較的低いと同時に、 Electron は 8 年間深く培われ、反復されてきたアプリケーション エコシステムを備えており、豊富なチェーンにより開始コストがさらに削減されます。
デスクトップ アプリケーション開発に Electron を使用すると、フロントエンドが自身の機能を向上できるようになります。一方で、テクノロジの幅が広がり、単一の Web からフロントエンドのビジネス機能の範囲を拡張できます。ページから PC アプリケーション開発への移行 現在 Electron でサポートされていない機能については、C で Node コンポーネントを記述してサポートを拡張することもできますが、その一方で、一部の従来の Web など、フロントエンド側の多くの制限が破られています。セキュリティ制限とシステムの基盤となるインターフェイスの呼び出しにより、開発能力が強化されます。
もちろん、Electron には欠陥がないわけではありません。よく批判される欠点には、次のようなものがあります。
依存関係が Chromium カーネルにバンドルされているため、Electron のパッケージング ボリュームは通常 100M になります。これを最適化するために、asar 圧縮、ダイナミック リンク ライブラリ、その他の方法を使用できます。
メモリ使用量が多い 同様に、Chromium カーネルにバンドルされているため、Electron のメモリ使用量も一般的に高くなります。
UI レイヤーのビジュアル レンダリング効率は低いです。これは、マルチプロセス処理タスクなどの最適化方法や、ユーザーの操作性を向上させるビジュアル アーティファクトの使用などによって最適化することもできます。経験。
Electron には既知の問題がいくつかありますが、その完全なエコロジカル チェーンとフロントエンド テクノロジとの高い重複は、依然としてデスクトップ アプリケーションの迅速な開発に推奨されるソリューションです。また、パフォーマンスの問題についても懸念があります。スコア 80 に達すると、いくつかの一般的な最適化手法を使用して解決する方が簡単です。 2021 年現在も、Electron は 8 週間に 1 つのメジャー バージョンという安定した更新頻度を維持しており、V12 から V15 までの複数のメジャー バージョンをリリースしています。更新内容は、主に API の削除と変更、システム機能の適応、および依存関係に焦点を当てています。 Chromium カーネルなどのバージョン、アップデートおよびその他の詳細。
React Native Desktop
React Native は、以前の React フロントエンド フレームワークに基づいて、2015 年 4 月に Facebook 技術チームによってオープンソース化されたモバイル クロスプラットフォーム開発フレームワークです。 。デスクトップ アプリケーションの構築に関しては、RN チームはまだ正式なデスクトップ バージョンをリリースしておらず、主にコミュニティ プロジェクトに依存して持続可能な開発のための能力を構築しています。その中でも、Microsoft が開発した React Native For Windows macOS 技術ソリューションは、最も蓄積された経験と最も安定した開発イテレーションを備えたソリューションであり、プロジェクトは 2015 年末にリリースされて以来、6 年間の安定したイテレーションを経ています。 2021 年に、RN チームは 3 つの重要なバージョン 0.64 ～ 0.66 をリリースしました。Microsoft は、React Native For Windows の反復で RN のメイン バージョンへの更新を常に保証し、多数の Windows 関連機能もサポートします。 Windows プラットフォームを主なターゲット ユーザーとするデスクトップ アプリケーションを構築している場合は、React Native For Windows を使用するのが良い選択です。
2021 年に、RN 技術チームは、リリースされた重要なバージョンで新しい Android 12 および iOS 15 システムのサポートを提供することに加えて、Microsoft チームとのデスクトップ アプリケーション構築テクノロジーにも焦点を当てたことは注目に値します。 RN チームは、React Native デスクトップ バージョンのユーザー エクスペリエンスを向上させるために、Facebook のメッセンジャー チームの導入を通じてデスクトップ アプリケーションに「独自の」技術機能を提供すると述べています。
Flutter Desktop
Flutter は、Google が発表したモバイル UI ハイブリッド開発フレームワークで、ユーザーが iOS 上で使用できるボトムアップの基本ライブラリの完全なセットを実装しています。 Android は高品質のネイティブ ユーザー インターフェイスを構築します。
現在、Flutter はデスクトップ側の開発機能をサポートするために、コードを Web に変換するクロスエンド レンダリング ソリューションを採用しています。しかしながら、Flutter to Web のパフォーマンスにはまだ多くの改善の余地があり、今年業界では多くの最適化計画がありますが、パフォーマンスを大幅に向上させたい場合は、多かれ少なかれ魔法のように修正することで達成できるでしょう。 Flutter ソース コード。これらの最適化方法は長期的には効果がありません。Flutter バージョンの反復プロセス中に、多大な最適化コストが発生します。それでも、Web に最適化された Flutter のパフォーマンスは、従来の Web プロジェクトと比較するとわずかに不十分です。したがって、互換性を考慮せずに、Web ソリューションを使用する開発者は Canvaskit レンダリング モードの使用を試みる必要があります。このモードは Skia の WebAssembly ソリューションに基づいており、レンダリング パフォーマンスが向上しますが、読み込みパフォーマンスは継続的に最適化する必要があります。
おそらくデスクトップ側のパフォーマンスの問題を完全に解決するために、Flutter Desktop は 2021 年半ばに Windows ネイティブ ソリューションをリリースしましたが、現在は 64 ビット システムのみをサポートしているため、32 ビット以下のシステムはサポートできません。 -Win7 などのビット システム Windows バージョンでは、開発者にとって互換性コストが大幅に増加します。ただし、2022 年 2 月に、Flutter Desktop は安定バージョンを正式にリリースし、カメラ、file_picker、shared_preferences など、多くの一般的なプラグインを Windows のサポートに組み込むように適応させました。さらに、コミュニティは他のさまざまなパッケージで Windows のサポートを追加し、Windows タスクバーの統合からシリアル ポート アクセスまであらゆるものをカバーしています。同時に、多くの Microsoft チームも積極的に協力し、正式版のリリースに多大な貢献をしてくれました。 2022 年には、Flutter Desktop を試してみる価値があります。
Tauri
最近 Rust を活用した Tauri は非常に注目を集めており、Electron と比較して主に次の 4 つの利点があります。
フロントエンド開発には、3つの致命的な欠点があります:
#5. Rust - 新しい言語をマスターする時が来ました
#Rust は JS インフラストラクチャの未来です
フロントエンドのエコロジー ツールが徐々に改善されるにつれ、フロントエンドの新しい領域を探索することに加えて、誰もがツールのパフォーマンスを向上させる方法についても考えています。 Rust は常に皆から批判されてきましたが、フロントエンド しかし、インフラストラクチャは構築などのパフォーマンスに非常に要求が厳しいため、フロントエンド ツールを他の言語で作成できないかどうかを誰もが検討し始めたため、Rust はみんなの注目を集めました。 Rust 言語は誕生以来、そのセキュリティ、パフォーマンス、最新の構文で多くの開発者を魅了しており、過去 6 年間、stackoverflow で最も人気のあるプログラミングおよび言語の中で常に 1 位にランクされ続けています。 Rustの書き換えプロジェクトは様々な分野で登場しており、Linuxプロジェクトでも一部の機能がRustで書き換えられているとされており、Rustのフロントエンド分野への参入も必然の流れと言えるでしょう。 Lee Robinson が 2021 年に書いた記事「Rust は JavaScript インフラストラクチャの未来」では、Rust で書かれた多くのフロントエンド ツール プロジェクトがリストされ、Rust が JavaScript エコシステムへの影響を増大し続けると述べられており、この記事は多くの公開アカウントによってリツイートされました。 、全員の間で白熱した議論を引き起こします。Rust ツールはフロントエンド エコシステムに統合されます
フロントエンド構築の分野では、2021-swc に非常に著名なプロジェクトが登場しました。 Rust によって書かれた構築ツールです。コンパイル、圧縮、パッケージ化に使用できます。Next.js、Parcel、Deno などのいくつかのよく知られたプロジェクトで使用されています。Next.js 12 は、代わりに swc を直接使用します。 babel では、公式サイトのブログに swc を使用していると記載されており、その後、ホットアップデート速度が 3 倍、ビルド速度が 5 倍に向上しており、Rust の性能の高さがわかります。
構築に加えて、Rust は他のフロントエンド分野でも使用されています。たとえば、Deno のランタイム エンジンも Rust で書かれた V8 エンジンであり、次世代のフロントエンド ツール Family Bucket Rome は Rust を使用して書き換えられると発表しました; Node.js は napi-rs を通じて Rust モジュールを呼び出して高パフォーマンスの拡張を実現できます; Rust で書かれた dprint 仕様コーダーは Prettier より 30 倍高速です; Rust はまた、WASM にコンパイルされることもあり、yew や percy のような WASM フロントエンド フレームワークも登場しています。
Rust ツールがフロントエンド エコシステムにさらに深く統合されることが予測されており、それがフロントエンド エコシステムの新たなアップデートを引き起こす可能性があります。
フロントエンドの人が新しい言語を学ぶ時が来ました
このような Twitter のスクリーンショットを見たことがある人は多いと思いますが、Redux 作者の Dan Abramov 氏は次の 3 つの質問をしました。年 「学ぶ価値のある言語は何ですか?」私は「Rust」と答えました。これはフロントエンド担当者にとってインスピレーションとなるかもしれません。フロントエンドのエコシステムを活性化するために新しい言語を学ぶ時期が来ていますが、多くの人はそうするでしょう。 Rust に混乱しています。学習の険しい道のりに落胆していますが、実際のところ、Rust は多くの点でフロントエンド開発に似ており、始めるのはそれほど険しいものではありません。
たとえば、ツールチェーンでは、Rust の Rustup は nvm に相当します。実行中のツールカーゴ (npm の Rust バージョン) のバージョンを切り替えることはできますが、また、nvm よりも強力です。rustup をインストールすると、clippy (eslint の Rust バージョン) と Rustfmt (prettier の Rust バージョン) もインストールされます。Rust サポート ツールを使用して新しく作成されたプロジェクトには、コードのフォーマットと分析のためのサポート ツールがすでに含まれています。
カーゴと npm の類似点を見てみましょう。この 2 つのツールは多くのコマンドで類似しており、プロジェクトで構成する必要がある npm の一部のコマンドは、cargo で構成する必要はありません。 Cargo にはモノレポ管理が付属しており、マルチパッケージ プロジェクトを直接設定できます。Cargo が npm に対応していると言うよりも、Cargo は npm と Yarn の組み合わせに似ています。これは、Rust チームが最新の言語ツール チェーンを参照した結果でもあります。
構文の面では、Rust は現代言語の特徴も備えており、関数型プログラミングと構造化言語の特徴を利用し、さらに多くの新しい言語をベースにして作成されています。高度な構文については、関数型プログラミングにはJavaScriptもたくさんあり、例えばJSのarrow関数はRustのclosed関数に相当しますし、Rustの配列にもmap、reduce、filterなどのメソッドがあり、Rustの関数も同様に使えます。変数に割り当てられます。
フロントエンドが以前学習できる 2 番目の言語が C だったとしたら、おそらく今は Rust でしょう。Rust には C よりも最新の依存関係管理、構文、ツール チェーンが備わっているため、たとえ説得されて辞めたとしても、フロントエンド分野での競争力が高まる可能性もあります。
6. ローコードは今後もホットなトピックになるでしょう
「ローコード」について話題になってから 1 年が経ちました。 2020 年のテクノロジー トレンド 2020 年の市場規模は、2020 年の 19 億から 2021 年の 28 億 5000 万までの範囲であり、この分野が依然として注目を集めており、急速に発展していることは間違いありません。 2020 年がローコード分野の継続的な加熱に対する期待を与えてくれたとしたら、2021 年はローコード分野の将来の発展についてのより多くのトレンドを見ることができるでしょう。
一方で、Tencent WeChat や Alibaba YiDa などのエンタープライズ レベルのローコード プラットフォームが業界で力を発揮し始めていることがわかります。また、社内にはビル管理に焦点を当てたプラットフォームもあります。 Wiji などのデスクも徐々に成熟してきています。多数のプラットフォームベースの製品は、今でも差別化された急速なペースで開発されており、依然として主流の開発アイデアです。 IMWebチーム内では、2019年のローコードプラットフォームVisionの運用から20年のローコード管理プラットフォームHulkの運用に至るまで、垂直型ローコードプラットフォームを通じたビジネスの研究開発を加速してきました。 2021 年には、サーバー側のシナリオをさらに試し、インターフェース構築に重点を置いて HulkData プラットフォームを磨きました。
HulkData は、Web ビジュアル コンポーネントを通じてパイプラインを構築し、データベースまたは少量のコードで既存の API に基づいて新しい API インターフェイスを生成します。 HulkData は、BPMN 2.0 プロトコルを利用してグラフィックスを使用してビジネス プロセスを表現し、複数のビジネス、複数のデータ リソース、ロー コード、プラグイン メカニズム、プロセス オーケストレーション、およびリクエストとレスポンスのパラメーター変更をサポートします。サーバーレスはますます成熟しており、サーバーレスの操作不要の機能は、HulkData にとって非常に良い機会です。HulkData 上で作成されたインターフェースは、SCF の形式で Tencent Cloud にデプロイされ、サーバーの操作に注意を払う必要はありません。そしてメンテナンス。 HulkData サーバー側インターフェイス オーケストレーションを使用すると、ビジネス ロジックを迅速に実装し、ビジネス アプリケーションを機敏に受信および配信でき、配信速度は従来の開発モデルより 80% 高速です。現在、合計 400 のインターフェイスが 3 つの主要な内部サービスへのアクセスに使用されており、正常に動作しています。
一方、急速に発展している差別化されたシナリオベースのプラットフォーム製品の間に共通点があるかどうかを考えてみる価値はありますか?結局のところ、どのようなシナリオを対象としても、ローコード プラットフォームをゼロから構築するコストは決して安くはなく、この種のリソースの無駄は特に大規模な工場で顕著です。
2020 年末に IMWeb チーム内で立ち上げられた Gems ローコード エンジン プロジェクトは、実際にはこの問題の調査です。ローコード エンジンの中核的な目標は、上位レベルのプラットフォームをより効果的に構築できるように、基本的な標準と機能のセットを提供することです。その考え方の鍵は、エンジンのモデルと機能の完全性、およびさまざまなシナリオでの拡張性にあります。 Gems はローコード エンジンとして、過去 21 年間にわたって基本機能と設計を継続的に改善し、フルボード プラグイン、コア編集オブジェクト API、その他の機能を提供してきました。チーム内の運用と管理のためのローコード プラットフォームを安定してサポートするだけでなく、徐々にチームを超えて拡張され、社内の複数のチームが独自のビジネス シナリオに合わせてローコード プラットフォームを効率的に構築できるようになりました。
同時に、今年末の GMTC カンファレンスで、アリババがグループのローコード エンジンを外部に宣伝したこともわかりました。テンセント社内のローコード Oteam の構築も 2021 年に組織され始め、その主な目標は基盤となるコアの共同構築でもあります。業界全体で見ると、ローコードエンジンが台頭し始めており、今後もその傾向は高まっていくことが予想されます。ただ、このセグメント化されたトラックには大手メーカーのみが関与する可能性があります。これは、小規模メーカーや独立系開発者にはできない多数のシーン サポートの検証が必要であるためです。
全体として、差別化されたプラットフォーム製品は今後もローコード分野にアクセスするための主な手段であり、ローコード エンジンの出現は業界全体にさらなる可能性をもたらすでしょう。
7. 今後も期待できるD2Cフロントエンドインテリジェンス
「フロントエンドインテリジェンス」は業界の新たなトレンド近年のフロントエンドAIの方向性を模索中。知性とは何ですか?これは、インテリジェントなアルゴリズムとフロントエンド エンジニアリングの実践を組み合わせ、機械が開発を支援できるようにすることを意味します。
D2Cの歴史と現状
これまで、フロントエンドインテリジェンス分野における最大の製品形態は、さまざまなDesign to Code（以下、D2C）でした。 D2C) ツール: 入力 UI デザイン ドラフトは、一連のアルゴリズムを通じて使用可能なコードを出力します。
2017 年の論文 pix2Code では、画像生成コードのアイデアが提案されました。
2018 年、Microsoft は Sketch2Code プロジェクトをオープンソース化し、この方向性の実現可能性をさらに検証しました。
2019 年に、アリババ タオバオは imgcook を立ち上げ、その後数年でダブル イレブンや 618 などの多数のビジネスをサポートしました。これは、D2C テクノロジーが徐々に成熟し、大規模なビジネス実装の必要性を示しています。
2021 年が近づくにつれ、国内外の主要企業がこの分野での同様の調査と実践を開始しました:
Tencent IMWeb チームが Project Auton を立ち上げ、内部でテストされました。サービスは今年 6 月に外部に提供されると予想されている; アリババの imgcook は急速に反復を続けている; Byte はローコード プラットフォームに基づいて「ALYX」プロジェクトを考案し、社内でも実装している; 58 チームはオープンソース化しているPicasso; Zhuanzhuan はオンライン「Magic Pen Ma Liang」プラットフォームです...
また、D2C 分野では多くのスタートアップ企業が出現しています。国内のCodeFun、Blue Lake、海外のFramer、Animaなど。
CodeFun は使いやすさと復元の点で比較的優れたパフォーマンスを備えており、オンラインで公開されてから高い評価を得ていることは言及する価値があります。
しかし、フロントエンドのオープンソース コミュニティ全体を見てみると、現在、D2C 分野で十分な影響力を持つオープンソース プロジェクトは存在しません。したがって、各社とも基本的には「密室で仕事をしている」状態にある。
コインの表裏: 欠陥、シナリオ、機会
純粋に視覚的なアルゴリズムに基づいた初期のソリューションと比較して、現在の大規模 D2C 製品は基本的にデザインドラフト 生の入力としてのソース ファイル (Sketch、Figma、XD など)。
純粋に視覚的なアルゴリズムでは 2 次元画像から UI レベルなどの情報を抽出することが難しいため、設計ドラフト ファイルは内部 DSL を解析することでより詳細な構造化された UI 記述を取得でき、これはユーザーにとってより便利です。その後の処理とコード生成。
従来のプロコード開発モデルでは、通常、「PRD 設計ドラフト」がビジネス コードを生成するための入力として使用されます。しかし、D2Cシステムではデザイン案のみが入力であり、デザイン案は単なるUIの記述に過ぎないため、デザインからは推測できない情報が多くなります。たとえば、アニメーション、インタラクション、ロジック、さらには応答性さえも、D2C のみに依存することによって実現することはできません。
これらの欠点のため、ほとんどの D2C シナリオは開発の補助ツールとしてのみ使用されます。真に完全にインテリジェントになるにはまだ時期尚早です（完全なロジックを備えたコードを生成し、人間の介入なしに実稼働環境で使用できる）。
上で述べた多くの欠点にもかかわらず、D2C は UI 開発の分野で大きな可能性を秘めています。
D2C 製品 (コンポーネント/ページ コードまたは UI を記述する DSL) には通常、次の消費パスがあります。
出力コードは、基本的な UI コンポーネントとして、次のもので構成されます。開発者は二次開発を行います。
出力コードは基本素材として提供され、二次編集やアレンジのためにローコード/ノーコード プラットフォームと組み合わせられます。
出力 DSL は、直接レンダリング用にカスタマイズされたレンダーと組み合わせられます。
特に第二の消費経路では、近年普及しているローコードプラットフォーム、データバインディング、論理配置、スタイル編集、D2C制作のUI素材などを活用しています。手動による介入とインタラクティブなオーケストレーションなどの二次編集は、D2C の機能の欠点を補い、高速で効率的で、デポジット可能で再利用可能な一連のコード生成 SOP を確立できます。
さらに、D2C は、その高い供給効率により、ローコード/ノーコードの素材生産のボトルネックを打破し、プロコードからプロコードへのフロントエンドの研究開発パラダイムの変革を促進します。ローコードのエージェント。
近年、SaaS、FaaS、BaaS などの人気のテクノロジー製品形式と組み合わせた D2C ローコード/ノーコードの助けにより、近い将来、ゼロコードが実際に達成できることが予測されます。エンジニアを必要とせずに、完全なデータ、インタラクション、ロジックを備えた製品を迅速に起動します。これにより、多くの革新的なビジネスの初期コストが大幅に削減され、インターネット起業家精神の次の波を後押しする可能性さえあります。
しかし、現時点では、上記の製品形態 (D2C ローコード/ノーコード SaaS/FaaS/BaaS) を完全に統合して、優れたユーザー エクスペリエンスを維持しながらクローズド ループを形成できるプラットフォームはありません。今後数年のうちに、この分野からスタースタートアップが誕生するかもしれない。
未来を見据えて: 深耕、統合、研究開発パラダイムの変化
2022 年を見据えると、フロントエンドのインテリジェンスと D2C がさらに進化すると予想されます全体的な状況は次のとおりです 2 つの大きなトレンド:
垂直方向: 取り組みを深化させ、プロセス、アルゴリズム、エクスペリエンスを最適化し、真の「インテリジェント」をさらに強化しますさらに「インテリジェント」に。
水平方向: 標準とプロセスを確立し、上流と下流の機能を統合し、ローコード、ノーコード、FaaS、BaaS、SaaS、設計システム、アルゴリズム システム、研究開発システム、データ システムなどは、まさに生産性を解放する工業化された高速発電システムを形成します。
長期的には、上記の体制が確立されれば、業界は確実に研究開発モデルの次の変革を開始することになるでしょう。現在のプロコードベースの研究開発モデルから、プロコード、ローコード、ノーコードが相互に補完し、供給し、力を与え合うモデルに変革する。同時に、標準化されたシステムの確立により、材料や製品の汎用化や再利用が容易になります。研究開発効率への影響は間違いなく非常に大きいです。
これらはすべて想像力に満ちています。知性への旅は疑問と障害に満ちていますが、未来を楽しみにする価値があります。私たちは新年も引き続き育成と開発を続け、2022 年には将来が期待できます...
8. DevOps、研究開発効率は引き続き焦点
研究開発の効率化は現在、インターネット企業と従来のソフトウェア企業の両方にとって大きな関心事の分野であり、インターネット大手企業は「研究開発の効率化」を通じて、ますます複雑化する製品開発に対応するために研究開発能力の継続的な向上を達成したいと考えています。ローエンドメーカーは「研究開発の効率化」によるブレークスルー達成を期待 路上で追い抜き、後発企業のアドバンテージを最大限に発揮、国内インターネット企業が一斉にこの分野に多額の投資を行っているのを多くの中小企業が見ており、パフォーマンス分野への取り組みも本格化している。
アジャイルの概念と同様、研究開発の有効性を正確に定義することは困難です。実際には、複雑な概念の多くは定義されていませんが、最初は現象として現れ、その後適切な表現を見つけて徐々に進化します。実際、効率と有効性はソフトウェア エンジニアリングの専用用語ではありませんでした。人類の発展の歴史を通じて、生産性と生産効率は継続的に改善されてきました。デジタル時代では、ソフトウェアの研究開発効率の重要性が強調されています。研究開発の効果を一文で要約するなら、「より効率的、より高品質、より信頼性が高く、より優れたビジネス価値を持続的に提供できる」となります。
私たちにできることは、研究開発効率の絶対値を向上させることではなく、研究開発効率が低下しすぎないように、その悪化をできる限り遅らせることです。速く、現状を維持するよう努力し、ただ成功するだけです。
IMWeb チームは、2021 年に DevOps において大きな進歩を遂げました。一方では、開発、テスト、導入、運用、保守などのさまざまな分野でテンセントクラウドコーディングと共同構築し、チームの自社開発パフォーマンスプラットフォームThanosとコーディングチームはアプリケーションワークフローソリューションを徹底的に作成しました。チームは、テスト環境用に Nohost ゲートウェイをオープンし、インターフェイス共同デバッグ契約プラットフォームである Tolstoy とコーディングは共同で API ホスティング、モック、テスト機能を構築しました。研究効率の面では、Tencent Cloudcoding を通じて統一パフォーマンス プラットフォームを実現し、全体的な研究開発効率が 30% 以上向上しました。
9. マイクロ フロントエンド、過小評価できないリンク
2016 年、ThoughtWorks はマイクロ フロントエンドのアイデアを提案しました。フロントエンド: 巨大なプロジェクトを複数のプロジェクトに分割する さまざまな小規模で柔軟なプロジェクトが互いに干渉せず、独立して開発、実行、デプロイできるため、マイクロ フロントエンドの幕が開きます。アリババが 2019 年にシングルスパに基づく qiankun マイクロ フロントエンド フレームワークを開発して以来、マイクロ フロントエンドの人気が高まっています。マイクロ フロントエンドの開発プロセスにおいて、開発者はマイクロ フロントエンドの現在のアプリケーション シナリオも徐々に理解してきました。
2021 年には、マイクロ フロントエンドのフレームワークは、数多くありますが、その中には古い Single-spa、Github スターの数が最も多いマイクロ フロントエンド フレームワーク qiankun、新興のマイクロ フロントエンド フレームワーク JD.com などがあります。マイクロアプリ。
single-spa v5.0 が 2020 年にリリースされて以来、昨年前半の主な作業は v5.0 のいくつかのバグ修正であり、7 月に v6 がリリースされました。今年の後半に.0 ベータ版。 v6.0 にも重大な変更がいくつかありますが、ほとんどのユーザーはこれらの変更に対してコードを更新する必要はありません。さらに重要なことは、ブラウザに関しては、v6.0 が IE11 をサポートする最後のバージョンとなり、将来のバージョン v7.0 では IE11 はサポートされなくなるということです。シングルスパ チームはブラウザの互換性により重点を置く予定です。単一スパのエコシステム全体を維持します。 v6.0 では、2 つの新機能も追加されています。
ページ ナビゲーションの非同期キャンセルをサポートします。
patchHistoryApi を公開すると、開発者は単一のスパでカプセル化された PushState/replaceState/popstate/hashchange を使用できます。
古いフレームワークが一生懸命働いているだけでなく、「おそらくこれまで見た中で最も完全なマイクロ フロントエンド ソリューション」であると主張する qiankun も常に更新されています。 。 qiankun は主に、さまざまなアプリケーション シナリオにおけるいくつかの問題を解決し、サンドボックスでの defineProperty の問題やサンドボックスのパフォーマンスの問題など、サンドボックスでの JavaScript 互換性の問題のいくつかを修正します。昨年の qiankun のアップデートはあまりないようですが、エキサイティングな V3.0 ロードマップもリリースされ、多くのアップデートについて言及されており、主なアップデートには、独立したアプリケーション ローディング モジュールと独立したサンドボックス モジュールが含まれます。
ただし、qiankun は強力な侵入の問題をまだ解決しておらず、iframe などのページに簡単に埋め込むことはできません。
今年下半期の良いニュースの 1 つは、JD.com が独自のマイクロ フロントエンド ソリューション MicroApp も立ち上げたことです。シングルスパやqiankunのコンポーネント化の考え方を採用せず、WebComponentの考え方を取り入れ、CustomElementとカスタマイズされたShadowDomを組み合わせてマイクロフロントエンドをクラスWebComponentコンポーネントにカプセル化し、コンポーネントレンダリングを実現します。マイクロフロントエンドの。これには次の特徴があります:
クラス Webコンポーネント HTML エントリ
ライフ サイクル
リソース アドレス補足完全
一般に、マイクロ フロントエンドの基礎は、「すべての大規模システムはエントロピー増大の法則から逃れることはできない」ということに由来しています。それが解決できる問題は、一部のモノリス アプリケーションの解体でもあるため、マイクロ フロントエンド多くの場合、エンジニアリングにおける「悲観主義」「エンジニア」の妥協です。マイクロフロントエンドを使用するかどうかについては、qiankun の著者 kuitos によるこの記事「マイクロフロントエンドは必要ないかもしれない」の分析を読むことができます。
IMWeb チームは、昨年マイクロ フロントエンドに関する徹底的な研究も実施し、qiankun x qiankun に基づく増分再構築というマイクロ フロントエンドの実践を非常に成功させ、古い Vue モノリスをプロジェクトは新しい React プロジェクトと有機的に統合され、並行開発とシームレスな再構築を実現し、フロントエンドの生産性を大幅に向上させます。具体的な実践的な詳細については、IMWeb チームの公開アカウントに関する以降の記事に注目してください。
2022 年のテクノロジー トレンドに期待セグメント化された分野に関しては、2022 年についていくつかの見通しを立てることができます。
フルスタックの徹底的な開発により、各主要な UI フレームワークは、フルスタック アプリケーションを構築するための独自の「メタフレームワーク」を備えています。百派が争うと言っても過言ではない新星Remix。
しかし、バックエンド開発の深海は、ある枠組みだけでは埋まりません。それよりもフロントエンド開発者の意識と経験の蓄積が必要です。来年にはフロントエンドが浸透すると信じています。より深く、より包括的に。TypeScript はすでにフロントエンド プロジェクトの標準となっています。
将来的には、生産性とユーザー エクスペリエンスを向上させるための、より強力なサポート ツールが登場すると予想されます。 。主要なクロスエンド フレームワークはすべてデスクトップをターゲットにしています。また、「クラウド ゲーム」の人気に伴い、「クラウド アプリケーション」にも大きな可能性があります。フロントエンド開発も捨てきれず、このポジションでは
ElectronのコミュニティとTauriのパフォーマンスが期待できます。さらに先に進みたい場合は、新しい言語 を学ぶ時期です。JS インフラストラクチャの未来 - Rust、フルスタック - Go、AI - - Python、Flutter -ダート、フロントエンドの人々はいつ自分たちの限界を破るのでしょうか? WASM は将来間違いなく大ヒットするでしょう。フロントエンドがなければそれはわかりません。
ToB の変革傾向は明らかです。ローコードには大きな可能性があります。嬉しいのは、 より多くの大手メーカーがローコードのオープンソース エンジンを統合する傾向にあることです。そしてローコードを終わらせる あらゆる場所で稼働するプラットフォームの混乱は、インターネット業界が工業化とインテリジェンスに向かう唯一の方法でもあります。
さらなるフロントエンド インテリジェント製品の発売を楽しみにしています。
研究と有効性のプラットフォームも統合の段階にあり、来年も引き続き実行される予定です。今後の研究開発のために 工業化と知能化は努力する価値あり！
ビジネスの発展、管理システムの継続的な成長、および大規模な統合の傾向に伴い、
Jushi アプリケーションは避けられず、ますます増えていくでしょう。この病気になるとマイクロフロントエンドは良薬になると考えられます マイクロフロントエンドの生態と構築、そしてWebComponentを借用したMicroAppのアイデアは非常に楽しみです!
![Meituan APPを模倣した実践的な開発 [フロントエンドプログラマー必須のJavaScriptプロジェクト]](https://img.php.cn/upload/course/000/000/068/6242bebc05ca9210.png)
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
