11 Must-Know FrontEnd Trends for 2020 の翻訳です 2020年 11 の知っておくべきフロントエンドトレンド - 昼食で、スマートにフロントエンドの会話をする方法
チームのランチトークでスマートに話すことは、最新のフロントエンドトレンドを常に最新の状態に保つ大きな理由です。 それはあなたがより良い開発者になり、より良い技術とより良い製品を構築するのに役立つかもしれません。 多分。
それで、いくつかの興味深い方向にあなたを向けることによって、この名誉あるクエストをより簡単にさせてください。 A 〜 Z のすべての概念を説明するわけではありませんが、その概念、それがどのように有用であり、さらなるリソースにつながるかを紹介します。
たとえば、 Micro Fontends 、 Atmoic Design 、 Web コンポーネント TS take-over 、ESM CDN、さらにはデザイントークンの概要を簡単に説明します。 自由にスクロールして、詳細を知りたいトピックをマークしてください。 ご質問やその他の提案については、コメントを下にドロップしてください。 楽しんで！
・・・・・・
1. Micro frontends
Micro frontendsは、昼食の会話で最も話題の多いフロントエンドトピックです。
皮肉なことに、フロントエンド開発はコンポーネントのモジュール式の利点を享受していますが、それでもバックエンドのマイクロサービスよりもはるかに monolithic です。
マイクロフロントエンドは、アプリのさまざまな部分で作業するさまざまなチームのために、フロントエンドアーキテクチャをさまざまなフロントエンドに分割することを約束します。 各チームは、マイクロフロントエンドのエンドツーエンドのライフサイクル全体にわたって自律性を獲得できます。これは、ビットなどのツールを使用して、個別に開発、バージョン管理、テスト、構築、レンダリング、更新、展開できます。
ここでコンセプト全体を説明する代わりに、 @martinfowler ブログで公開されている @thecamjackson によるこの素晴らしい投稿を読んでください。 これは本当に良いことであり、この概念を掘り下げるために必要なすべてを網羅しているはずです。
しかし、今日のエコシステムにはまだ一定の不足があります。 ほとんどの場合、人々は個別のフロントエンドの展開、バンドル、環境の違いなどの問題を心配しています。 Bit を使用すると、個々のフロントエンド/コンポーネントを分離、バージョン化、ビルド、テスト、更新できます。 現在のところ、これは主に複数のアプリケーションを使用する場合に便利です（ただし、コンポーネントを介して既存のアプリケーションの一部を徐々にリファクタリングするために既に一般的に使用されています）。
Bit が 2020 年に展開を導入すると、独立したチームは、スタンドアロンのフロントエンドを開発、構成、バージョン管理、展開、および更新することができます。 UIアプリを一緒に構成し、チームが独立した継続的な展開とインクリメンタルアップグレードを使用して単純な分離コードベースを作成できるようにします。 これらのフロントエンドの構成により、アプリケーションが作成されます。 Bit を使用して作成されたアプリは次のようになります。
もっと詳しく知る：
2. Atomic Design
Atomic Design は、ランチトークのもう1つの非常に興味深いトピックであり、純粋な方法論というよりも哲学として考えるのが好きです。
簡単に言うと、 Brad Frost によって導入された理論は、Webアプリケーションの構成を、 Atoms , Molecules , Organisms などの自然な構成と比較し、具体的なWebページで終わります。 Atoms は Molecules を構成します（例：テキスト入力+ボタン+ラベル Atoms =検索 Molecules ）。 Molecules は Organisms を構成します。 Organisms はレイアウト template に存在し、ユーザーに配信されるページに具体化できます。
30 秒間の詳細な説明と視覚的な例を示します。 素晴らしい芸術的才能で私が作成した非常に印象的な図面が含まれています。これをコピーしてオフィスボードに貼り付けることができます。😆
Atomic コンポーネントの利点は、モジュール式で再利用可能なコンポーネントを介したモジュール式 UI アプリケーションの構築にとどまりません。 このパラダイムにより、構成を考えるように強制されるため、すべてのコンポーネントの役割と API 、それらの階層、およびアプリケーションの構築プロセスを効果的かつ効率的な方法で抽象化する方法をよりよく理解できます。 ご覧ください。
3.カプセル化されたStyling と Shadow Dom
コンポーネントの重要な側面はカプセル化です。マークアップ構造、スタイル、および動作をページ上の他のコードから隠して分離できるため、異なる部分が衝突せず、コードをきれいに保つことができます。 Shadow DOM API はこの重要な部分であり、隠された分離された DOM を要素にアタッチする方法を提供します。
Shadow DOMは、実際には長い間ブラウザで実際に使用されています。 Shadow DOM は “DOM within a DOM” と考えることができます。 これは、独自の要素とスタイルを持つ独自の分離DOMツリーであり、元のDOMから完全に分離されています。
非表示の DOM ツリーを通常の DOM ツリーの要素にアタッチできます。この Shadow DOM ツリーは、通常の DOM と同様に、下にあるシャドウルートで始まり、必要な要素にアタッチできます。 これの主な意味は、名前の衝突やスタイルの流出のリスクがないため、クラスの名前空間が必要ないことです。 追加の利点もあります。 多くの場合、 Web コンポーネントのスタイルの真のカプセル化に対する長年の有望なソリューションと呼ばれています。 もっと詳しく知る：
4. TypeScript take over
したがって、最近のすべての会話は、 TS がフロントエンド開発を引き継いでいるように聞こえます。 開発者の 80 ％が次のプロジェクトで TypeScript を使用または学習したいと認めていることが報告されています。
欠点はありますが、 TS コードは理解しやすく、実装が速く、バグが少なく、定型文も少なくて済みます。 TS で動作するように React アプリをリファクタリングしたいですか？ 頑張れ。 徐々に始めたいですか？ Bit のようなツールを使用して、アプリ内のコンポーネントをTSに徐々にリファクタリングし、 React-Typescript コンパイラを使用してアプリから独立してビルドします。 この方法により、コードを一度に 1 コンポーネントずつ徐々にアップグレードできます。
もっと詳しく知る：
5. Web components
基本的に、これは未来です。 どうして？ これらの純粋な Web コンポーネントはフレームワークに依存せず、フレームワークなしで、またはフレームワークのスペルの標準化で動作できるためです。 JS の疲労から解放され、最新のブラウザーでサポートされているためです。 バンドルのサイズと消費量が最適であり、 VDOM レンダリングは驚くべきものだからです。
これらのコンポーネントは、新しい種類の html タグ、レイアウトを指定する HTML テンプレート、および当然コンポーネント固有の Shadow DOM を定義できる Javascript API であるカスタム要素を提供します。
この分野で有名な著名なツールは、 Lit-html （および Lit-element）、 StencilJS 、 SvelteJS 、そしてもちろん、どこでも直接共有、消費、開発できる再利用可能なモジュラーコンポーネント用の Bit です。
UI 開発の未来を考え、コンポーネントの時代にモジュール性、再利用性、カプセル化、標準化の原則がどのように見えるかを考えると、 Web コンポーネントが答えになります。 もっと詳しく知る：
- 7 Tools for Developing Web Components in 2019
- 9 Web Components UI Libraries You Should Know in 2019
- Prototyping with Web Components: Build an RSS Reader
6.コンポーネントライブラリからダイナミックコレクションまで
コンポーネント駆動型開発の出現により、さまざまなツールが誕生しました。 有名なツールの1つは、そのホストプラットフォームである Bit.dev と並んで Bit です。
面倒で高度に結合されたコンポーネントライブラリを構築するために一生懸命働く代わりに、Bitを使用して、既存のコンポーネントを動的に再利用可能な共有コレクションに継続的に分離およびエクスポートします。
Bit（GitHub） を使用すると、UI コンポーネントを個別に分離、バージョン化、ビルド、テスト、および更新できます。 既存のアプリのコンポーネントを分離し、リモートコレクションに収集し、どこでも使用するプロセスを合理化します。 すべてのコンポーネントは、プロジェクトの外部でビルド、テスト、およびレンダリングできます。 アプリ全体ではなく、単一のコンポーネント（および依存コンポーネント）を更新できます。
bit.dev プラットフォーム（または独自のサーバー）で、コンポーネントをリモートでホストし、さまざまなチーム向けに整理して、すべてのチームが独自のコンポーネントの開発を制御できるようにします。 すべてのチームはコンポーネントを共有および再利用できますが、その独立性と制御を維持します。
このプラットフォームは、すぐに使用できる共有コンポーネントのオールインワンエコシステムも提供します。UI コンポーネントの自動ドキュメント化、インタラクティブなプレイグラウンドでのコンポーネントのレンダリング、 npm / yarn を使用してコンポーネントをインストールするための組み込みレジストリも提供します。さらに、任意のリポジトリで変更のためにコンポーネントを bit import できます。
短期的には、これは、 Spotify / iTunes が静的 CD 音楽アルバムを介して以前に音楽を共有するプロセスを変更したのと同様の方法で、コンポーネントの共有および構成プロセスに革命をもたらします。 動的でモジュール式のソリューションであり、誰もがコンポーネントを共有して使用できます。
長い目で見れば、 Bit は micro-frontends への道を開くのに役立ちます。 どうして？ UI アプリケーションの一部を個別にバージョン管理、テスト、ビルド、および更新できるためです。 2020 年には独立した展開が導入され、最終的に異なるチームがアプリの一部をエンドツーエンドで所有できるようになります：分離されたシンプルなコードベースを維持し、チームが慎重かつ継続的に UI の増分アップグレードを構築して展開し、フロントエンドを一緒に構成できるようにします。
7.状態管理：Bye Bye Redux？ （ない…。）
Redux は辞めるのが難しい道具です。 フロントエンドのモジュール化が進むにつれて、アプリの状態をグローバルに管理することの苦痛はより明確になりますが、 Redux の非常に有用な機能により、多くのチームにとって重要なソリューションになります。
2020 年に Redux に別れを告げますか？ おそらく完全ではない 😄
ただし、状態（ React フック、 Context-API など）を処理するフレームワーク内の新機能の蜂起は、グローバルストアなしで未来への道を描いています。 Mobx のようなツールは、ほんの1年前にはあまり採用されていませんでしたが、コンポーネント指向でスケーラブルな性質のおかげで、毎日人気が高まっています。 他の選択肢についてはこちらをご覧ください。
読む：Making Sense of React Hooks— Dan Abramov 著
8. ESM CDN
ES モジュールは、ブラウザでモジュールを操作するための標準であり、 ECMAScript によって標準化されています。 ES モジュールを使用すると、機能を CDN などで使用できるモジュールに簡単にカプセル化できます。 Firefox60 のリリースにより、すべての主要なブラウザーが ES モジュールをサポートし、Node mteamは Node.js への ES モジュールサポートの追加に取り組んでいます。 また、 WebAssembly の ES モジュール統合は、今後数年間で行われます。 CDN を介してアプリで構成されるモジュラー Bit UI コンポーネントを想像してください…
9.プログレッシブ Web アプリ。 まだ成長しています。
プログレッシブ Web アプリケーションは、最新のテクノロジーを利用して、最高の Web アプリとモバイルアプリを組み合わせます。 Web テクノロジーを使用して構築された Web サイトであると考えてください。 ブラウザとサービスワーカーの可用性、およびキャッシュ API とプッシュ API の最近の進歩により、 Web 開発者はユーザーが Web アプリをホーム画面にインストールしたり、プッシュ通知を受信したり、オフラインで作業したりできるようになりました。
PWA は親密なユーザーエクスペリエンスを提供し、すべてのネットワーク要求はサービスワーカーを介してインターセプトできるため、中間者攻撃を防ぐためにHTTPSを介してアプリをホストすることが不可欠であり、これもセキュリティの向上につながります。 Facebook 開発者の Omer Goldberg による、PWAのベストプラクティスの概要を説明する素晴らしい講演です。
10.デザイナーと開発者の統合
製品やチーム全体で一貫した UI を実現するコンポーネント駆動設計システムの台頭により、デザイナーと開発者の間のギャップを埋めるための新しいツールが登場しました。 ただし、これは簡単な作業ではありません。 コード自体が本当に唯一の真実のソースである（これはユーザーが本当に得ているものです）が、ほとんどのツールはデザイナーの終わりからのギャップを埋めようとします。 このカテゴリには、Framer、Figma、Invision DSMなどがあります。
開発者の側から、次世代コンポーネントライブラリをホストし、共有コンポーネントの採用を支援する Bit.dev のようなプラットフォームを確認できます。 このプラットフォームは、実際のソースコードのレンダリングされた視覚化を提供するため、設計者は開発者と協力して、ソースコード自体を視覚的に議論することができます。
注目すべきもう1つの有望なアイデアは、design-tokens です。 コードにトークンを配置することで、外部のコラボレーションツールを介して、デザイナーが単純なスタイリングの側面（色など）を直接制御できるようにします。 Bit.devなどのプラットフォームと統合されているため、これまでにないほどタイトなワークフローを作成できます。
11. Web assembly — 未来へ？
Web assembly は言語の多様性を Web 開発にもたらし、 JavaScript によって生じたギャップをカバーします。 「スタックベースの仮想マシン用のバイナリ命令形式」として定義されています。 Wasm は、C / C++ / Rust のような高レベル言語のコンパイル用のポータブルターゲットとして設計されており、クライアントおよびサーバーアプリケーション用に Web 上に展開できます。
Eric Elliott は彼の投稿で、このコンセプトの利点を簡潔に説明しています。
- JavaScript の改善：パフォーマンスに重要な要素を wasm に実装し、標準の JavaScript モジュールのようにインポートします。
- 新しい言語：Web Assembly コードは、バイナリ形式で表される AST（ Abstract Syntax Tree ）を定義します。 読みやすいようにテキスト形式で作成およびデバッグできます。
- ブラウザーの改善：ブラウザーはバイナリ形式を理解するため、現在使用しているテキスト JavaScript よりも小さいサイズで圧縮するバイナリバンドルをコンパイルできるようになります。 ペイロードが小さいほど配信が高速になります。 コンパイル時の最適化の機会によっては、 Web Assembly バンドルも JavaScript よりも高速に実行される場合があります！
- コンパイルターゲット：他の言語が Web プラットフォームスタック全体で一流のバイナリサポートを取得する方法
このコンセプト、それがなぜ役に立つのか、どこで使われるのか、なぜまだここにないのかについては、この素晴らしい投稿とこの素晴らしいビデオをお勧めします。
