「Angularって静的なWebサイトを吐き出せる技術とかないんですか」という質問を受けることがたびたびあります。 例えばGatsbyやGridsome、Next.js、Nuxt.jsなどのようなものですね。 サーバーサイドレンダリングの仕組みは自体はすでにAngular Universalがありますし技術的に難しいことではないので、コミュニティのなかでAngularベースで静的サイトを作るための新しいフレームワークが生まれてくることはあるかもしれません。 しかし僕の個人的な見解では、少なくともAngularチームが公式に提供することはないと思っています。
ではなぜAngularチームはそこにフォーカスしないのかということについて、今Angularが向かっている方向と一緒に理解してみましょう。
いまあるWebに溶け込んでいく
2017年の後半あたりから、Angularチームの主眼は静的なWebとの融合になってきました。 これまでAngularはSingle Page Applicationの開発を堅牢でスケーラブルにおこなうための一貫したフレームワークを提供してきました。 その文脈では一定の完成度に達し、開発者からも支持されるようになりましたが、Webの世界は広大で、その大半はいわゆるドキュメントとしてのWebサイト、Webページです。 WordPressをはじめとするCMSによるコンテンツがWebの大部分を構成しています。
そうしたWebのなかでAngularにできることを考えた結果が、Angular Elementsです。 Angularはアプリケーションではなくコンポーネントを開発するための基盤としての側面を持つようになりました。 Angular ElementsによってAngularコンポーネントからCustom Elementsを生成し、そのタグを静的コンテンツのなかに組み込んでいくことができます。 いまあるWebをそのままに、AngularとCustom Elementsがその体験を拡張していきます。
実例として、Angularの公式ドキュメンテーションサイト angular.io では、Markdownで管理されているドキュメンテーションのなかに書かれた独自タグが、Custom Elementsとして起動してリッチなコンテンツを提供しています。
<code-example> タグはAngular Elementsで作られたCustom Elementsとして存在しています。
## heroes コンポーネントを作成する Angular CLIを使用して､`heroes`という名前の新しいコンポーネントを生成します。 <code-example language="sh" class="code-shell"> ng generate component heroes </code-example>
技術的な課題
Angular Elementsのアプローチの概念実証として angular.io が作られましたが、バンドルサイズの課題がありました。 現状の実装では、Angular Elementsが依存するAngularコアランタイムが大きく、複数のAngular ElementsをWebサイトから読み込むのにパフォーマンスへの悪影響がありました。
これを解決するのがIvyで、Ivyが導入されればAngular Elementsが依存するAngularコアランタイムを最小限にとどめ、バンドルサイズを数KBに抑えることができるようになります。
まとめ
今後もAngularで静的サイトを作るためのフレームワークが生まれることは、少なくとも公式にはないでしょう。 Angularチームは、いまあるWebをAngular Elementsで拡張していくことを目指しています。 Custom Elementsはフレームワークに依存しないので、Angular Elementsで作成したタグをGatsbyやNuxt.jsなどで作られたサイトで利用することもできます。 タグを使う側からすれば、そのタグがAngularで作られていることは知る必要のないことです。
Angular Elements + Ivyによって、Angular Elementsの開発体験とユーザ体験を高めることが2019年の主要なテーマのひとつです。 Angularは単なるSPA開発フレームワークではなく、あらゆるWebのユースケースに対応できる開発プラットフォームとしてこれから進化していくことでしょう。
[追記] Nuxt.jsは静的サイトジェネレータ以外の用途もあるという指摘で、冒頭の部分で誤解を生みそうな点を教えてもらったので、修正しました。
