2020年の11の必見のフロントエンドトレンド

> こちらの記事は、Jonathan Saring 氏により2019年12月に公開された『 11 Must-Know FrontEnd Trends for 2020 』の和訳です。
本記事は原著者から許可を得た上で記事を公開しています。

# 2020年の11の必見のフロントエンドトレンド
ランチ中のフロントエンドトークでスマートに見られる方法！

![](https://miro.medium.com/max/2400/1*4o8a1yvlifG4zGw9AvSSrQ.png)

チームのランチトークでスマートに見られることは、最新のフロントエンドのトレンドを常に把握しておくための大きな理由であることは言うまでもない。 それは、あなたがより良い開発者になり、より良い技術とより良い製品を作るのに役にたつかもしれない。 たぶんね。

だから、いくつかの興味深い方向を示すことで、この名誉あるクエストを君が簡単に達成できるように少し時間をもらいたい。 すべてのコンセプトについて1から10まで説明するのではなく、そのコンセプトとそれがどのように有用であるか紹介しよう。最後にはさらなるリソースを書き記した。

例えば、マイクロフロントエンド、アトミックデザイン、Webコンポーネント、TypeScriptの台頭、ESM CDN、さらにはデザイントークンの概要についても簡単に説明している。 スクロールして、詳細を知りたいトピックをチェックしてみてほしい。 質問や提案がある場合は、下部にコメントを残してもらえればと思う。 それではごゆっくり！

---

## 1. マイクロフロントエンド

マイクロフロントエンドは、ランチの会話で最も話題になるフロントエンドトピックだ。

皮肉なことに、フロントエンド開発はコンポーネントのモジュール化された利点を享受しているが、それでもバックエンドマイクロサービスよりもはるかにモノリシックだ。

[![](https://miro.medium.com/max/1180/1*SdrrxeKfuAyDEAKATFNUNg.png)](https://micro-frontends.org/)

マイクロフロントエンドは、アプリの異なる部分で作業する異なるチームのために、フロントエンドアーキテクチャを異なるフロントエンドに分割するという約束をもたらしてくれる。 各チームは、マイクロフロントエンドのエンドツーエンドのライフサイクル全体で自律性を獲得できる。これらは（例えば**Bit**などのツール</a>を使用することで）開発、バージョン管理、テスト、ビルド、レンダリング、アップデート、デプロイが独立して可能だ。

ここでコンセプト全体を説明する代わりに、@martinfowlerのブログで公開された@thecamjacksonによる[**この素晴らしい投稿を読んでみてほしい**](https://martinfowler.com/articles/micro-frontends.html#InANutshell) 。 この記事は本当にすばらしく、この概念を掘り下げるために必要なすべてをカバーしているはずだ。

[![](https://miro.medium.com/max/1702/1*fxACkCp1y_fDwnF-N7bVMQ.png)](https://martinfowler.com/articles/micro-frontends.html)

しかしながら、今日のエコシステムにはそれでもまだ足りないものがある。 多くの場合、分離されたフロントエンドの展開、バンドル、環境の違いなどの問題に悩まされる。しかし、[**Bit**](https://bit.dev)を使うことで個々のフロントエンド/コンポーネントの分離、バージョン管理、ビルド、テスト、アップデートができるようになる。 現時点では、これは主に複数のアプリケーションを操作するときに役立つ（コンポーネントを介して既存のアプリの一部を徐々にリファクタリングするためにすでに広く使用されているが）。

**Bit**が2020年にデプロイメントを開始すれば、独立したチームがスタンドアロンのフロントエンドを開発、構成、バージョン管理、デプロイ、アップデートできるようになる。 これにより、UIアプリを一緒に構成し、チームが独立した継続的なデプロイと増分アップグレードを使用して、シンプルな分離されたコードベースを作成できるようになる。 これらのフロントエンドを組み合わせることにより、最終的にアプリケーションができあがる。 Bitを使用して構成されたアプリは次のようになる。

[![](https://miro.medium.com/max/2400/1*pHH9k186BYju30BC9OxXTg.png)](https://bit.dev)

Bitで構成されたUIアプリ

### もっと詳しく:

> [マイクロフロントエンド](https://martinfowler.com/articles/micro-frontends.html)

## 2. アトミックデザイン

[![](https://miro.medium.com/max/6528/1*q5IW7xZF8AYFj8NZEVi17Q.jpeg)](https://blog.bitsrc.io/atomic-design-and-ui-components-theory-to-practice-f200db337c24?)

参考：アトミックデザインを30秒で理解する！

[アトミックデザイン](https://bradfrost.com/blog/post/atomic-web-design/)はランチトークのもう1つの非常に興味深いトピックで、私はこれを純粋な方法論というよりも原理として考えるようにしている。

簡単に言えば、[Brad Frost](https://medium.com/u/52f676b44c62?source=post_page-----cea8a629b08----------------------) によって導入されたこの理論は、Webアプリケーションの構成 － 突き詰めると具体的なWebページと、原子（Atom）・分子（Molecule）・有機体（Organism）といった自然界の構成とを比較するものだ。 原子は分子を構成する。（例：テキスト入力「原子」 + ボタン「原子」 + ラベル「原子」=検索「分子」）。 分子は有機体を構成する。 有機体は１つのレイアウトテンプレートに存在しており、これはユーザーに配信される１つのWebページとして具現化される。

これは[視覚的な例を用いた30秒でわかる説明](https://blog.bitsrc.io/atomic-design-and-ui-components-theory-to-practice-f200db337c24)だ。そこには、私が素晴らしい芸術的才能で描いたとても印象的な説明図があるから、どうぞオフィスのホワイトボードに書き写して使ってほしい😆


アトミックコンポーネントの利点は、モジュール式の再利用可能なコンポーネントを介したモジュール式のUIアプリケーションを構築できるというだけではない。 このパラダイムに従うと、すべてのコンポーネントの役割とAPI、それらの階層、アプリケーションのビルドプロセスを効果的かつ効率的な方法で抽象化できる方法についてよりよく理解できるように構成を考える必要が出てくる。 次の記事を読んでほしい。

###
> [アトミックデザイン](https://bradfrost.com/blog/post/atomic-web-design/)

> [アトミックデザイン：実践のための理論](https://blog.bitsrc.io/atomic-design-and-ui-components-theory-to-practice-f200db337c24)


## 3. カプセル化されたスタイリングとShadow DOM

[![](https://miro.medium.com/max/2276/1*TSOpITlAqbyYC_UYYW7zMg.png)](https://developer.mozilla.org/en-US/docs/Web/Web_Components/Using_shadow_DOM)

出典：developer.mozilla.org

コンポーネントの重要な側面はカプセル化だ。これにより、マークアップ構造、スタイル、および動作をページ上の他のコードから分離して、異なる部分が衝突しないようにできる。また、コードをきれいに保つことができる。 [Shadow DOM API](https://developer.mozilla.org/en-US/docs/Web/Web_Components/Using_shadow_DOM)はこれの重要な部分であり、非表示の分離されたDOMを要素にアタッチする方法を提供してくれる。

今日、_Shadow_ DOMは実際にブラウザーで長い間使用されている。 [Shadow DOMを次のように考えることができる。](https://bitsofco.de/what-is-the-shadow-dom/) 「DOMの中にあるDOM」 これは、元のDOMから完全に分離された、独自の要素とスタイルを持つ独自の分離DOMツリーだ。

これにより、非表示のDOMツリーが通常のDOMツリーの要素に接続することができるようになる。このShadow DOMツリーは、通常のDOMと同じ方法で、あなたが必要とする要素に接続できるシャドウルートから始まる。 これが[主に意味すること](https://dev.to/maxart2501/css-for-an-encapsulated-web-7fo)は、クラスに与える_名前空間が必要ない_ということだ。 つまり名前の衝突やスタイルの流出のリスクがないということだ。 また、他にも利点がある。 これはWebコンポーネントのスタイルの真のカプセル化に対する当分約束されたソリューションであるとしばしば言われている。 もっと詳しく:

> [shadow DOMを使う](https://developer.mozilla.org/en-US/docs/Web/Web_Components/Using_shadow_DOM)

## 4. TypeScriptの台頭

最近、どんな会話でも[TypeScriptがフロントエンド開発を支配する](https://medium.com/@jtomaszewski/why-typescript-is-the-best-way-to-write-front-end-in-2019-feb855f9b164)かのように言われている。 [**80％の開発者が次のプロジェクトでTypeScriptを使用または学習したいと認めている**](https://2018.stateofjs.com/javascript-flavors/typescript/)という報告がある 。

TypeScriptには欠点もあるが、コードは理解しやすく、実装が高速で、バグが少なく、必要なボイラープレートが少なくて済む。 TSで動作するようにReactアプリをリファクタリングしてみたい？ やってみよう。 徐々に始めたい？ [Bit](https://github.com/teambit/bit)などのツールを使って、アプリのコンポーネントを徐々にTSにリファクタリングしてみよう。そしてそれらを[React-Typescriptコンパイラ](https://bit.dev/bit/envs/compilers/react-typescript)を使用してアプリとは独立にビルドしよう。 この方法では、コードを1コンポーネントずつ徐々にアップグレードできる。

### もっと詳しく:

> [TypeScriptが2019年にフロントエンドを作成する最良の方法である理由](https://medium.com/@jtomaszewski/why-typescript-is-the-best-way-to-write-front-end-in-2019-feb855f9b164)

> [LyftでのTypeScript](https://eng.lyft.com/typescript-at-lyft-64f0702346ea)

> [SlackでのTypeScript](https://slack.engineering/typescript-at-slack-a81307fa288d)


## 5. Webコンポーネント

![](https://miro.medium.com/max/3200/1*-zkpV1IfOv-1dux6ZqWBCQ.png)

基本的に、これは未来だ。 なぜかって？ これらの純粋なWebコンポーネントはフレームワークにとらわれず、フレームワークなしでも、どんなフレームワークの**標準的な構文**でも機能するからだ 。 JS疲労から解放され、最新のブラウザでサポートされているからだ。 バンドルサイズと消費量が最適化されていて、VDOMレンダリングは驚くほど素晴らしいからだ。

これらのコンポーネントは、新しい種類のhtmlタグを定義できるJavascript API、レイアウトを指定するHTMLテンプレート、そしてもちろんコンポーネント固有のShadow DOMを提供するカスタム要素を提供する。

この分野でよく知られているツールは、[**Lit-html**](https://github.com/Polymer/lit-html)（[Lit-element](https://lit-element.polymer-project.org/)も）だ。[**StencilJS**](https://github.com/ionic-team/stencil) 、[**SvelteJS**](https://github.com/sveltejs/svelte)そしてもちろん[**Bit**](https://bit.dev/)だ。どこでも直接共有できて、使うことができて、開発もできる再利用可能なモジュール式コンポーネントを提供してくれる。

私たちのUI開発の将来と、モジュール化、再利用性、カプセル化、および標準化の原則がコンポーネントの時代にどのように見えるかを考えるとき、Webコンポーネントががその答えだ。 もっと詳しく:

- [2019年にWebコンポーネントを開発するための7つのツール](https://blog.bitsrc.io/7-tools-for-developing-web-components-in-2019-1d5b7360654d)
- [2019年に知っておくべき9つのWebコンポーネントUIライブラリ](https://blog.bitsrc.io/9-web-component-ui-libraries-you-should-know-in-2019-9d4476c3f103)
- [Webコンポーネントを使用したプロトタイピング：RSSリーダーを作る](https://blog.bitsrc.io/prototyping-with-web-components-build-an-rss-reader-5bb753508d48)

## 6. コンポーネントライブラリから動的コレクションへ

[![](https://miro.medium.com/max/1838/1*VmerRS_ufSltgSGYiNHinQ.png)](https://bit.dev)

コンポーネントを動的コレクションとして編成しよう。再利用し、構成し、独立性を保つのだ。


[コンポーネント駆動開発](https://blog.bitsrc.io/a-guide-to-component-driven-development-cdd-69dbd3d07bf0)の登場はさまざまなツールを生み出した。 有名なツールの1つはホスティングプラットフォームの[ Bit.dev](https://bit.dev)ならびに[Bit](https://github.com/teambit/bit)だ 。

厄介で高度に結合されたコンポーネントライブラリを構築するために一生懸命働く代わりに、ビットを使用して、既存のコンポーネント同士の分離、動的に再利用可能な共有コレクションへのエクスポートを継続的に行おう。

[Bit（GitHub） ](https://github.com/teambit/bit)を使うことによって、 UIコンポーネントの分離、バージョン管理、ビルド、テスト、更新を独立して行うことが可能だ。 Bitを使えば既存のアプリにあるコンポーネントの単離、リモートコレクションへの保存、場所を問わない使用のプロセスを合理化できる。 すべてのコンポーネントは、プロジェクトの外部でのビルド、テスト、レンダリングが可能だ。 また、アプリ全体ではなく、単一のコンポーネント（およびその依存コンポーネント）を更新することができる。

[![](https://miro.medium.com/max/1600/1*c6475ieLqqEzb4htt3T94Q.gif)](https://bit.dev)

Bit.devプラットフォーム（または独自のサーバー）では、コンポーネントをリモートでホストし、異なるチーム向けに編成できるため、それを使ってすべてのチームが独自のコンポーネントの開発を行うことができる。 すべてのチームはコンポーネントを共有して再利用できるが、コンポーネントの独立性と制御は保つことができるのだ。

このプラットフォームは、すぐに使える共有コンポーネントのオールインワンエコシステムも提供している。UIコンポーネントを自動ドキュメント化し、インタラクティブなプレイグラウンドでコンポーネントをレンダリングし、npm/yarnを使用してコンポーネントをインストールするための組み込みレジストリを提供してさえくれる。 さらに、どんなリポジトリでも変更のために`` `bit import` ``でコンポートネントをインポートできる。

[![](https://miro.medium.com/max/1600/1*RZP_jNEEilVtmjGH4O4UHQ.gif)](https://bit.dev)

短期的に見ると、これは以前のCDミュージックアルバムを介した音楽の共有プロセスをSpotify / iTunesが変えたのと同じように、コンポーネントを共有および作成するプロセスに革命をもたらしている。 これは、誰もがコンポーネントを共有して一緒に使用できるようにする動的かつモジュール式のソリューションだ。

長期的に見れば、Bitはマイクロフロントエンドへの道を開拓するのに役立つ。 なぜかって？ それはUIアプリケーションの一部分のバージョン管理、テスト、ビルド、更新を独立して実行することができるようになっているからだ。 2020年にBitには独立したデプロイメント機能が導入され、最終的にはさまざまなチームがアプリの一部をエンドツーエンドで所有できるようになる。分離されたシンプルなコードベースを維持し、チームが慎重かつ継続的に段階的にUIの更新をビルド・デプロイし、フロントエンドを構成することができるようになるということだ。

###
> [再利用可能なコードコンポーネントをチームとして共有する・Bit](https://bit.dev)

> [UIコンポーネント設計システム・Bit](https://bit.dev/collections)

> [teambit / bit](https://github.com/teambit/bit)

## 7. 状態管理：ばいばい Redux？ （いや...）

![](https://miro.medium.com/max/2290/1*6oeKSYnPG2pbg8vdaiteYg.png)

[ Reduxは倒すのが難しいビーストだ](https://blog.bitsrc.io/state-of-react-state-management-in-2019-779647206bbc) 。 フロントエンドがモジュール化されるにつれて、アプリの状態をグローバルに管理することの苦痛はより明確になるが、Reduxの有用性の高さは多くのチームにとって頼りになるソリューションだ。

では、2020年にReduxに別れを告げることになるのだろうか。 おそらく完全にそうなることはないだろう😄

ただし、状態を処理するフレームワーク内の新機能（React hooks、Context-APIなど）の誕生は、グローバルストアのない未来への道を描いている。 [Mobx](https://github.com/mobxjs/mobx)のようなツール群は1年前に採用されたばかりだが、それらコンポーネント指向でスケーラブルな性質のおかげで、ますます人気が高まってきている。 [ここでより多くの選択肢](https://blog.bitsrc.io/state-of-react-state-management-in-2019-779647206bbc)を見つけることができる。

_参考_：[_React Hooksを理解する_](https://medium.com/@dan_abramov/making-sense-of-react-hooks-fdbde8803889) — [ Dan Abramov](https://medium.com/u/a3a8af6addc1?source=post_page-----cea8a629b08----------------------)

## 8. ESM CDN

![](https://miro.medium.com/max/4000/1*dSWVWelaiGClQXD6nGhBuA.jpeg)

ESモジュールは、ブラウザでJSのモジュールを操作するための標準規格であり、ECMAScriptによって標準化されている。 ESモジュールを使用すると、CDNなどを介して使用できるモジュールに機能を簡単にカプセル化できる。 Firefox 60のリリースにより、すべての[主要ブラウザが ESモジュールをサポートするようになる](https://hacks.mozilla.org/2018/03/es-modules-a-cartoon-deep-dive/)。Node mteamはESモジュールサポートを[ Node.js](https://nodejs.org/en/) に追加する作業に取り組んでいる。 また、[WebAssemblyに向けてのESモジュール統合](https://www.youtube.com/watch?v=qR_b5gajwug)が今後数年間に対応されるだろう。  CDNを介して、モジュール式[Bit](https://github.com/teambit/bit)UIコンポーネントをアプリに組み込めることを想像してみよう...

- [ESモジュール：漫画の詳細— Mozilla Hacks — Web開発者ブログ](https://hacks.mozilla.org/2018/03/es-modules-a-cartoon-deep-dive/)
- [denoland/deno](https://github.com/denoland/deno)


## 9. プログレッシブWebアプリケーション。 まだまだ成長中。

[プログレッシブWebアプリケーション](https://developers.google.com/web/progressive-web-apps)は最新のテクノロジーを活用して、[Webアプリとモバイルアプリのいいとこどり](https://www.smashingmagazine.com/2016/08/a-beginners-guide-to-progressive-web-apps/)をしたものだ 。 これは、ウェブテクノロジーを使用して構築されたウェブサイトであるが、モバイルアプリのようなふるまい、UXをもつものであると考えればよい。 Service Worker、Cache API、Push APIの可用性向上とブラウザの近年の進歩により、Web開発者はモバイルユーザーのホーム画面にWebアプリをインストールし、プッシュ通知を受信させ、さらにはオフラインで機能させることさえ可能になった。

PWAは快適なユーザーエクスペリエンスを提供できるようにしているためか、すべてのネットワークリクエストはサービスワーカーを介して傍受される可能性があるため、アプリをHTTPS経由でホストして中間者攻撃を防止し、セキュリティを強化することが不可欠だ。 [ここでFacebookの開発者Omer Goldberg](https://medium.com/u/49b16006351c?source=post_page-----cea8a629b08----------------------)によるPWAのベストプラクティスの概要の解説を読むことができる。


## 10. デザイナーと開発者の統合

[![](https://miro.medium.com/max/1600/1*55RGwH_5D3mIZoVhSCXWOA.gif)](https://bit.dev)

[プロダクトやチーム全体で一貫したU](https://blog.bitsrc.io/building-a-consistent-ui-design-system-4481fb37470f)を実現する[コンポーネント駆動設計システム](https://dev.to/jonisar/ui-component-design-system-a-developer-s-guide-19fg)の誕生とともに 、デザイナーと開発者の間のギャップを埋めるための[新しいツールが登場した](https://blog.bitsrc.io/7-tools-for-building-your-design-system-in-2020-452d9c9b3b8e)。 [とはいえこれは簡単な作業ではない](https://codeburst.io/ui-design-system-and-component-library-where-things-break-d9c55dc6e386)。実際にはコード自体が唯一の真の情報源だが（コードこそがユーザーに実際にいきわたるものだ）、ほとんどのツールはデザイナー側からのギャップを埋めようとしている。 このカテゴリには、Framer、Figma、Invision DSMなどがある。


開発者側からの視点では、[Bit.dev](https://bit.dev)のようなプラットフォームが 、次世代のコンポーネントライブラリをホストし、共有コンポーネントの採用を支援している。 このプラットフォームは、実際のソースコードのレンダリングして視覚化してくれるため、デザイナーは開発者と共同で作業し、ソースコード自体について視覚的な方法でディスカッションできるようになる。

注意すべきもう1つの有望なアイデアは、[design-tokens](https://css-tricks.com/what-are-design-tokens/)だ 。 トークンをコードに配置することにより、デザイナーは外部のコラボレーションツールを介して単純なスタイリングの側面（色など）を直接制御できる。 これはBit.devのようなプラットフォームと統合されており、これまでよりも厳しいワークフローを作成できる。

> [UIコンポーネント設計システム：開発者ガイド](https://dev.to/jonisar/ui-component-design-system-a-developer-s-guide-19fg)

> [UIデザインシステムとコンポーネントライブラリ：物事が壊れるところ](https://codeburst.io/ui-design-system-and-component-library-where-things-break-d9c55dc6e386)

> [2020年にデザインシステムを構築するための7つのツール](https://blog.bitsrc.io/7-tools-for-building-your-design-system-in-2020-452d9c9b3b8e)

## 11. Webアセンブリ — 未来へ？

[ Webアセンブリ（Wasm）](https://webassembly.org/) はWeb開発に言語多様性をもたらし、JavaScriptによってもたらされた隔たりを埋めてくれる。 Wasmは、「スタックベースの仮想マシン用のバイナリ命令フォーマット」として定義されている。 Wasmは、C / C ++ / Rustのような高水準言語のコンパイル用のポータブルターゲットとして設計されており、クライアントアプリケーションおよびサーバーアプリケーションのWebへの展開を可能にしてくれる。

[ Eric Elliott ](https://medium.com/u/c359511de780?source=post_page-----cea8a629b08----------------------)は彼の投稿でそのコンセプトの利点を次のようにエレガントに概説している。</p> 

- **JavaScriptの改善：** wasmでパフォーマンスが重要なものを実装し、標準のJavaScriptモジュールのようにインポートできる。
- **新しい言語：** WebAssemblyコードは、**バイナリ形式**で表されるAST（抽象構文ツリー）を定義できる。 **テキスト形式で書いてデバッグ可能だ**。つまり可読性が高い。
- **ブラウザの改善：** **ブラウザはバイナリ形式を理解できる**。これは、現在使用しているテキスト形式のJavaScriptコードよりもより高くい圧縮率をもつバイナリバンドルをコンパイルできることを意味する。 ペイロードが小さいほど、配信が速くなる。 また、**コンパイル時の最適化のケース**によっては、WebAssemblyバンドルもJavaScriptよりも高速に実行されるかもしれない！
- **コンパイルターゲット：** 他の言語がWebプラットフォームスタック全体でファーストクラスのバイナリサポートを取得する方法である。

なぜそれが有用で、どこで使用されるようになるのか、そしてなぜまだ目にしないのか、このコンセプトについてさらに理解するためには、[この素晴らしい投稿](https://medium.com/javascript-scene/why-we-need-webassembly-an-interview-with-brendan-eich-7fb2a60b0723)と[この素晴らしいビデオ](https://www.youtube.com/watch?v=aZqhRICne_M&feature=emb_title)を見ることをおすすめする 。



> [WebAssemblyが必要な理由：Brendan Eichへのインタビュー](https://medium.com/javascript-scene/why-we-need-webassembly-an-interview-with-brendan-eich-7fb2a60b0723)

---

## もっと詳しく


> [Reactでのコード再利用を最大化する](https://blog.bitsrc.io/maximizing-code-reuse-in-react-35ee20ad362c)

> [2020年のトップ13のReactコンポーネントライブラリ](https://blog.bitsrc.io/13-top-react-component-libraries-for-2020-488cc810ca49)


> [2020年のトップ11のAngular開発者ツール](https://blog.bitsrc.io/11-top-angular-developer-tools-for-2020-3d2621f1e157)


> [2020年のトップ11のVue開発者ツール](https://blog.bitsrc.io/top-10-vuejs-developer-tools-becd61375447)


# 翻訳協力
Original Author:  **[Jonathan Saring](https://blog.bitsrc.io/@JonathanSaring)** 
Original Article: [11 Must-Know FrontEnd Trends for 2020](https://blog.bitsrc.io/11-must-know-frontend-trends-for-2020-cea8a629b08)
Thank you for letting us share your knowledge! 

この記事は以下の方々のご協力により公開する事が出来ました。
改めて感謝致します。
選定担当: @_masa_u
翻訳担当: @_masa_u 
監査担当: @r_pg10
公開担当: @_masa_u 

# ご意見・ご感想をお待ちしております
今回の記事は、いかがだったでしょうか？
・こうしたら良かった、もっとこうして欲しい、こうした方が良いのではないか
・こういったところが良かった
などなど、率直なご意見を募集しております。
いただいたお声は、今後の記事の質向上に役立たせていただきますので、お気軽にコメント欄にてご投稿ください。[Twitter](https://twitter.com/BabyDegu?lang=ja)でもご意見を受け付けております。
みなさまのメッセージをお待ちしております。