Angular 2018年進路予想

この記事は Angularアドベントカレンダー2017 の1日目の記事です。

こんにちは、lacoです。Angular 2.0.0のリリースから1年以上経過し、SemVerによるアップデートポリシーやタイムベースのリリーススケジュールの運用も、すっかり軌道に乗って定着してきました。メジャーバージョンも2から5へ上がり、来年には6、7とアップデートが続けられていきます。

この記事では2017年のAngularの動きを振り返りつつ、2018年のAngularが進んでいく進路について、筆者が知る情報を元に予想します。

2017年のAngular

2017年に起こった出来事を振り返りながら、Angularが進んでいる方向を再確認しましょう。

1月: ブランディングガイドラインの策定

それまで “Angular2” や “AngularJS 2” など名称が定まっていなかった新しいAngularについて、ブランディングのガイドラインが正式に策定されたのが2017年1月のことです。 #ItsJustAngular というハッシュタグも作られ、Angular2ではなくAngularと呼ぶように、世界的に統一が進められました。いまではかなり定着してきましたね。

3月: Angular 4.0.0のリリース

2.0.0のリリースから半年が経過し、予定通りメジャーバージョンが4.0.0にアップデートされました。ちなみにv2の次がv4であることは2016年12月の時点で発表されていました。

4.0で導入された *ngIf*ngForas サポートはObservableを扱う上で欠かせない当たり前の機能になりましたし、Angular Universalから移植された platform-server パッケージもすっかり安定しました。Angularになってからはじめてのメジャーバージョンアップでしたが、大きな混乱はなく少し拍子抜けするほどでした。

4月: GoogleがTypeScriptを社内標準言語に採用

ng-conf 2017でアナウンスされたこのニュースはAngularコミュニティを越えて開発者たちの間に波紋を呼びました。AtScriptの時代から紆余曲折を経てTypeScriptを採用したAngularチームは、TypeScriptチームと共同でAoTコンパイラやLanguage Serviceなどの開発に取り組んできました。この頃からAngular以外の文脈においても、GoogleからTypeScriptへのコントリビューションが増えています。最近ではBazelのTypeScript用ビルドルールや、gtsというGoogle製のTypeScriptフォーマッターも公開され、これからもGoogle社内におけるTypeScript開発ツールのオープンソース化が勧められるでしょう。

7月: Angular 4.3のリリース、HttpClientの導入

v4.3はある意味ではv4.0のリリースよりも大きな影響がありました。それまでの標準パッケージであった @angular/http パッケージにかわり、新しい @angular/common/http パッケージで提供されるHttpClient APIが導入されました。実はv4.0の時点でリリースされる計画だったのですが、実装が長引いてv4.3での導入になりました。

10月: Angular Labsの発表

10月に開催されたAngularMixというイベントで、 Angular Labs という新しい取り組みについて発表されました。Angular Labsは実験的な機能の総称で、MaterialチームのComponent Dev Kitや、BazelとClosure Compilerを組み合わせたビルドシステム(ABCプロジェクト)、CLIチームのSchematicsなどが含まれます。また、AngularコンポーネントをWeb Components化する Angular Elements プロジェクトについても同時に発表がありました。

11月: Angular 5.0.0のリリース

v5.0ではDatePipeをはじめとした幾つかのパイプに破壊的な変更が加わりました。v5.0での変更については次のスライドや動画で解説しています。

2018年のAngular

2017年(まだ1ヶ月残っていますが)のAngularについて大きなイベントを振り返りましたが、2016年のアドベントカレンダーの最後で述べた「2017年のAngular」というセクションの内容はどれほど当たっていたのか確認してみます。

Service WorkerとPWAs

mobile-toolkitはほぼ動きがないままで、Service Workerだけが angular/service-worker パッケージだけが分離されてコアリポジトリに合流しました。ぜんぜん当たりませんでしたね。

ngIfの新機能

これは若干構文の変更はありましたが、ほとんどそのまま入りました。

DOM EventのCold Observable化シンタックスサポート

これは完全に何も動きませんでした。申し訳ない 🙇

4.0に向けて今からできること

これについては、「CLIにできるプロジェクトはCLIにしておきましょう」というアドバイスは間違っていなかったと確信しています。v4、v5とバージョンアップが進むたびに、Angular CLIはどんどん強力に、便利に進化しつづけています。最近では公式ドキュメント (https://angular.io) のクイックスタートやチュートリアルについても従来のSystemJSベースからCLIベースのコンテンツに更新されました。これからもCLIがAngular開発のベストプラクティスとして君臨しつづけるでしょう。


さて、長くなりましたが2018年のAngularについて今年も予想を行います。2018年は大きく2つの軸でAngularが大きく変わると見込まれます。

第一の軸: I18nの大改造

ひとつめはI18n機能の大改造です。v2.0からひっそりと存在し、地道なアップデートが続けられているAngularのI18n機能は、さまざまな理由によりごく僅かな開発者しか利用していません。今年Angularコアチームに参加したOlivier Combe (ocombe)氏は有名ライブラリ ng-translate の作者であり、伸び悩むI18n機能を発展させようとしています。

次のIssueはocombe氏によるこれからのI18n機能のロードマップです。v5.0ではまだ未達成のものがほとんどですが、v5系のどこかでテンプレート外のソースコード中でのI18nをサポートする予定です。また、AoTコンパイル時にローカライズするのではなく、ng-translateのようにランタイムで変換をおこなう機能もv6までには投入される見込みです。

第二の軸: 動的アプリケーションのサポート

ふたつめは動的アプリケーションのサポートです。これまでのAngularは静的なアプリケーションを安全に高速に構築するという方針で、AoTコンパイルに力を入れてきました。この方針によりハイパフォーマンスでスケーラブルなアプリケーション開発エコシステムを作り上げることに成功しましたが、従来のAngularJSユーザーに好まれていたウィジェット的なユースケース、Webページの中でダイナミックに実行されるための仕組みはありませんでした。

この課題はAngular v2のリリース前から指摘されていましたが、コアチームは一貫して「アプリケーションは静的であるべき。動的なウィジェットに頼るのをやめよう」と開発者たちを諌めてきました。しかしこの流れは奇しくもコアチーム自身の手で断ち切らざるを得なくなります。Angular公式ドキュメントである angular.ioがAngularで実装されなおされましたが、その実装のために彼らは動的なドキュメントコンテンツとAngularアプリケーションの共存の問題にようやく正面からぶつかりました。そして行き着いたのが EmbeddableComponent という泥臭いハックです。その顛末はAngular Connect 2017で赤裸々に語られています。

セッション中でも述べられていますが、こうした動的なアプリケーションに対する解決策として進められているプロジェクトのひとつが、Angular Elements です。Angular ElementsはAngularアプリケーションをひとつのCustom Elementsに固めて、標準のHTML上でウィジェットのように配置することができる仕組みです。Angular Elementsはv6.0でLabsを卒業してStableにリリース予定です。最新のステータスについてはAngular Connect 2017のRob Wormaldのセッションを見ましょう。

そして実は動的なアプリケーションをサポートするためのプロジェクトがもうひとつあります。それが iv です。ivはAngularによる動的なビュー構築を支援するためのまったく新しいアーキテクチャです。ある時期だけmhevery氏の個人リポジトリとして公開されていて開発中のソースコードを読むことができましたが、いまは非公開にされています。実態は謎に包まれてしまいましたが、先日Chrome Dev Summitに参加した際に偶然会ったRob Wormaldにこっそりivについて聞いてきました。

Rob曰く、ivはAngularの新しいビュー構築の仕組みです。現在のAngularでビューを構築するには、コンポーネントを作りコンポーネントのテンプレートを使うしかありませんが、ivはその壁を打ち破ります。イメージとしては現在のNgFactoryのようなDOMの命令的な組み立て処理を、ヒューマンリーダブル・ライタブルなAPIで手書きできる仕組みで、コンポーネントよりも低レイヤー、NgFactoryよりは高レイヤー、という中間の層として存在します。ivの目的は3つあります。

  1. より高速で軽量なビューエンジンとなること
  2. AoTコンパイルされたビューと動的なビューが共存するビューの構築をpublic & stableなAPIで手書きできること
  3. 柔軟でポータブルなAPIとなること

ivはAngular Elementsとは逆に、Angularアプリケーション中に動的なビュー組み立てを取り込むための仕組みです。Robによるとその思想はEmberにおけるGlimmerに近い、とのことでした。コンポーネントでもディレクティブでもない新しい概念、ivはv6でのリリースを目標にしているとのことで、筆者が2018年もっとも注目するトピックです。

ちなみに iv という名前は “Isomorphic Viewengine”ですか?とRobに聞いたところ、”maybe(笑)” という感じでした。仮称なので再び表に現れるときには違った名前になっていることでしょう。


ずいぶん長くなってしまいましたが、2017年の振り返りと、2018年の進路予想はいかがでしたでしょうか。順調にいけばv6のリリースは4月頃、ちょうどng-conf 2018の時期になります。春には予想がどれくらい当たっていたか答え合わせができそうです。また、アドベントカレンダーの25日目には特別ゲストからの寄稿を掲載予定です。もしかするとそこでいろいろと語られてしまうかもしれません。お楽しみに。

それではみなさん良いお年を。2018年もAngularをよろしくお願いします。

2日目は Quramyさんです。

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.