Angular Roadmap – Angularの過去・現在・未来

Angular Updatesを紹介します。 What’s New in Version 11

2020年11月現在、Angular バージョン 11.0.0 が提供されています。 このリリースはプラットフォームに多くのアップデートをもたらしますが、最も重要な機能には、TypeScript 4.0による高速なビルド、コンポーネント テスト ハーネス、ESLintのアップデートなどがあります。

Paleolithic JavaScript – SproutCore

当初、SproutCoreが存在しました。 これは、デスクトップ品質のシングルページ Web アプリケーションを簡単に構築できるようにすることを目的とした、最初の包括的な JavaScript フレームワークでした。 以前から可能だったというわけではありません。 GoogleがGmailをリリースしたとき、ウェブアプリケーションが複雑なデスクトップアプリケーションを本当に置き換えることができることを世界に示しました。 Google は、Gmail の構築に使用した一連のライブラリと最適化コンパイラである Closure ツールキットをオープンソースにしました。

問題は、Google の Closure ツールがあまり開発者にやさしくないということでした。 Java に大きく依存していたため、JavaScript、PHP、Ruby、および Python で作業することに慣れている Web 開発者は疎外されました。 Gmailは何が可能かを示す素晴らしいデモでしたが、同様のアプリケーションを開発することは、多くの人にとってまだ手の届かないことだと感じていました。

一部の勇敢な開発者は、jQuery、ガムテープ、および希望を組み合わせて、驚くべきシングル ページ アプリケーションを作成することに成功しました。 これらのアプリはエンドユーザーにはすばらしく見えますが、それに取り組んでいる開発者にとっては、アプリはすぐに技術的負債の山になり、開発チームは朝仕事に向かうのが嫌になりました。

その結果、少数の積極的な開発者が、Gmail のようなアプリを世界中の Web 開発者が簡単に使えるようにするためのフレームワークに取り組み始めました。 SproutCore は、これらのフレームワークの中で最初に軌道に乗ったものでした。 SproutCoreにはウィジェットの完全なセットが付属しており、HTMLやCSSに触れることなく複雑なウェブアプリケーションを構築することが可能でした。

これは、Web に引きずり込まれて悲鳴を上げている元デスクトップ開発者にとっては素晴らしいことでした。 GWT と Cappuccino が最も顕著で、同様の目標を持つフレームワークがさらにいくつか出現しました。 これらのフレームワークは、他の言語をJSにトランスパイルすることで、JavaScriptを回避することさえできました。 これもまた、デスクトップ開発者にとっては素晴らしいことでした。 しかし、情熱的なウェブ開発者は冷遇され、せっかく身につけたHTML、CSS、JavaScriptのスキルに価値がないかのように感じられてしまいました。

そのため、ウェブを覆って別のものであるかのように装うのではなく、ウェブを真に受け入れるフレームワークのための口火が切られたのです。 いくつかの初期のフレームワーク (Backbone と Knockout) が登場し、そこそこの成功を収めました。 Emberもこの頃に登場した。 EmberはSproutCoreを骨抜きにし、真にWebに適したものに作り直そうとした。 Emberは、JavaScript界のSix Million Dollar Manになることを目指していました。

これらのフレームワークのうち、人気が急上昇するようなものはありませんでした。 世界はより良いものを待っていたのです。 2010年、その優れたものが現れ、Angularと名付けられました。

The Golden Age of Angular

Angular バージョン 1.0 がリリースされる前に、Angular はフロントエンド開発界に嵐を起こしました。 ついに、HTML を一流の市民として扱う、使いやすい JavaScript フレームワークが登場したのです。 開発者とデザイナーが一緒になって、素晴らしいシングルページアプリケーションを構築できるようになったのです。 旧来のフレームワークがHTMLやCSSを野蛮人の道具、文明的な開発者が触るべきではない道具として扱っていたため、イライラしたり気分を害したりしていたデザイナーにとって、これは救いでした。

初めて Angular を試した開発者にとって魔法のように思えた最初のことは、双方向のデータバインディングでした。 これ以前は、ほとんどの開発者は、WPF や Windows Forms などのデスクトップ フレームワークでこの種のデータ バインディングを見たことがあるだけでした。 フォームやその他のUI要素をJavaScriptのモデルオブジェクトにバインドできるのは、素晴らしいことでした。 双方向のデータバインディングは使いすぎるとパフォーマンスの問題を引き起こしますが、適切に使用したチームは、Angularによって複雑なフロントエンドアプリケーションを以前よりずっと速く作成できるようになったことを知りました。

Angular は、HTML 要素へのデータの容易なバインディング以外にも人気があることがわかりました。 Angular ディレクティブは、再利用可能な HTML + CSS コンポーネントを簡単に作成する方法を提供しました。 他の JavaScript フレームワークが Angular よりも前にこれを提供していましたが、Angular は非常に人気のある最初のフレームワークでした。 再利用可能なコンポーネントは、サーバーサイドのフレームワークでは以前から使われていました。 ASP.NETのユーザーコントロールや、RailsやDjangoの部分テンプレートは、そのほんの一例です。

最後に、Angular は依存性注入をフロントエンド開発の世界で普及させました。 依存性注入はエンタープライズ アプリケーションで長い間人気がありましたが、それが JavaScript の世界で普及しなかった理由かもしれません。 フロントエンドの開発者は、不必要に複雑なエンタープライズソフトウェアのデザインパターンと見なされるものを長い間嫌ってきました。 この懸念に理由がないわけではありません。 アプリケーションを書く過程で、「ここで本当に必要なのは “SimpleBeanFactoryAwareAspectInstanceFactory” だろうか」

しかし、依存性注入はその価値を実証しています。 そして、Angular は、依存性注入を過去にあまり使用したことがないユーザーに対して、依存性注入を簡単に使用できるようにしました。 HTTP クライアントが必要ですか？ あるいは、アニメーションを行いたいですか？ 問題ありません。 Angularはそれらのためのビルトインサービスを持っていました。 要求すれば、Angularはそれをコンポーネントに注入してくれます。 自分で何かをインスタンス化する必要はありません。

あるいは、ブラウザの window または location オブジェクトを使用したいが、ブラウザの外でコンポーネントをユニット テストすることができないのではありませんか。 Angular には組み込みの $window と $location サービスがあるので、そこもカバーされています。 実行時に、期待通りのブラウザオブジェクトを取得することができます。 また、Node.jsでサーバーサイドのユニットテストを実行するときに、モックサービスをコンポーネントに渡して、さまざまなシナリオで期待通りの動作をすることを確認することができます。

これだけでは不十分な場合、Angular では、独自のサービスを簡単に登録および注入することもできます。 すべてのデータを DOM にバインドし、最善を望むことに慣れていた開発者にとって、これは素晴らしいことでした。 もしあなたが、使いすぎると会社に多大な損害を与えるようなAPIを呼び出す新しいフロントエンドアプリを書いていたなら、おそらく前もってテストを書いて、アプリケーションがTwilio APIを8億回呼び出すようなことをしないようにする方がいいでしょうね。

そこで、実行時に注入される Twilio サービスを作成します。 テスト時に、アプリケーションが行おうとしているすべてのAPIコールのコストを記録するモックサービスを作成します。 一般的な使用シナリオをカバーするテストを書き、これらのシナリオが会社に7桁の請求書を送る結果にならないことを確認するのです。 全体として、ほとんどの開発者は、Angularディレクティブと依存性注入を組み合わせることで、試行錯誤のソフトウェアエンジニアリング技術を使用して、モジュール化されたテスト可能なフロントエンドアプリケーションを書くことが可能であることに気づきました。 多くの開発チームはこれが幸せな状態であると判断し、Angularを全面的に採用することにしました。

Angular Decline? React の台頭

Angular の世界ではほとんど素晴らしい状況でしたが、すべてが太陽とロリポップというわけではありませんでした。 開発者は、あまりにも多くの DOM 要素にあまりにも多くのモデル オブジェクトをバインドしようとすると、深刻なパフォーマンス問題に直面するようになりました。 一部のアプリケーションでは、動作が遅くなることもありました。 許容できるパフォーマンスを得るためには、$digest を直接呼び出したり、その他の黒魔術が必要になり始めたのです。 同じ頃、新しいチャレンジャーが現れた。 Reactです。 当初、ReactはAngularにとってそれほど大きな脅威ではないように思われました。 何しろReactの変人たちは、わざわざJSXという、コードにマークアップを混ぜる方法のようなものを発明していたのですから。 私たちは、マークアップとコードの混在を避けるという明確な理由のために、テンプレート言語を発明するために多くの苦労をしたのではないでしょうか？

結果的に、React のアプローチは、フロントエンド開発コミュニティでかなり人気がありました。 ただし、ロケット式に人気が出たわけではありません。 Angular がまだ優勢であり、今後もそうであるように見えました。 しかし、Angularの人気は、Angularチーム自身という思いがけないところから、見事に一蹴されることになったのです。

The Introduction of Angular 2

Angular 2 は、2014 年の ng-europe カンファレンスで初めて発表されました。 Angular チームの計画は、控えめに言っても、Angular コミュニティにとって衝撃的なものでした。 Angular開発者からの反応は迅速かつネガティブなものでした…そしてそれは理由がないわけではありませんでした。 Angular 2はAngular 1から多くの馴染みのあるコンセプトを取り除き、新しい、互換性のないテンプレート言語を導入します（ついでに言うと、全く新しい言語を使ってプログラムされることになります）。

AngularJS

Angular 1 と Angular 2 の両方は「Angular」と呼ばれていましたが、実際には、いくつかの共通点がある非常に異なるフレームワークでした。 混乱を防ぐために、Angular チームは、古いバージョンの Angular を「AngularJS」と呼び、新しいバージョンを単に「Angular」と呼ぶようになりました。 AngularJSはJavaScriptで書かれており、Angularはそうではないので、これは直感的に理解できる。 フレームワーク間の区別を明確にするために、これ以降、Angular 1 を AngularJS と呼ぶことにします。

このすべての結果、AngularJS の開発者はフレームワークの将来への信頼を失いました。 彼らは、今後のプロジェクトでは新しいフレームワークに移行すると脅し、多くの開発者がまさにそれを実行しました。 Reactは、AngularJSからの大量離脱の最大の受益者だったのです。

ReactはAngularJSほどのことはできませんでしたが、ある意味でそれはポジティブなことでした。 すべてのものとキッチンシンクを含めようとしないビューライブラリを使用している場合、そのライブラリの開発者が将来的にあなたの下から敷物を引き抜くことは、より困難になります。 当初、Reactを使うのはAngularJSに比べて少々面倒でした。 AngularJSが提供する機能をカバーするためだけに、ライブラリのパッチワークをこしらえなければならなかったのです。

多くのチームはこれをリスクを減らすための良い方法だと考えました。

The Emergence of Vue

AngularJS の苦境をさらに悪化させたのが、Angular 2 をめぐるドラマとほぼ同時期に登場した Vue という名前の別のフレームワークです。 Vue は AngularJS に触発されましたが、それを単純化し、Vue の作成者が不必要な複雑さとみなしたものを取り除くことを目的としていました（したがって、Vue は既存の AngularJS 開発者にとって非常に親しみやすく感じられました）。 Vueは、Reactに移行したくない多くのAngularJSの開発者に安全な避難所を提供しました。

これは、AngularJS 開発者が Angular 2 の登場を辛抱強く待っていなかったことを意味するものではありません。 しかし、Angular 2 の計画による不確実性のために、AngularJS から React と Vue への大量流出があったことは明らかです。

Rising From the Ashes with Angular 2

やがて、Angular 2がリリースされました。 予想されたように、AngularJS から多くの馴染みのある概念を取り除きましたが、サービスや依存性注入のような最高の部分をいくつか残しました。 開発者の正気にとって幸運なことに、Angular は、当初計画されていたようなフォークではなく、プレーンな TypeScript を使用しています。

事態をさらに混乱させるために、Angular チームは、TypeScript の代わりに Dart プログラミング言語を使用する新しいフレームワークのフォークを維持しました。 当初、TypeScript と Dart のバージョンは同期して開発され、単一のコードベースから生成されました。 最終的に、Angular の TS 版と Dart 版は別々の道を歩むことを決定し、Angular Dart は現在独自に存在しています。

この混乱の中でも、Angular 2 のリリース後に Angular の人気は再び上昇しはじめました。 それはゆっくりと起こりました。 ソフトウェア開発ではよくあることですが、トレンドが変化しました。 開発者は、大きな、バッテリーを含むフレームワークが実際に有用である可能性があることに気づきました。 結局のところ、アプリケーションが十分に大きくなったとき、すべてのバッテリーが実際に必要になるのです。

特にエンタープライズ開発者は、Angular に回帰し始めました。 これは理にかなっています。 通常、エンタープライズ Web アプリケーションを開始するとき、それが複雑になることは分かっているはずです。 アプリケーションが行うことを期待される 87 のすべてのことが最初からわかっている場合、小さな MVP から始めることに意味はありません。

Angular 3は？

Angular 2は完璧ではありませんでしたが、複雑なWebアプリケーションの多くの開発者は、新しく改良されたAngularが彼らのニーズに合っていることに気付き始めました。 彼らにとって幸運なことに、Angular にはエキサイティングな改良がいくつか用意されていました。 より重要なのは、Angular チームが、バージョン間でほとんど変更を加えることなく、一貫してフレームワークの新しいバージョンを公開できることを実証したことです

当時は奇妙に思えた動きですが、Angular チームはバージョン 3 を完全にスキップしてバージョン 4 に移行することを決定しました。 Angular のルーター パッケージに取り組んでいるチームはすでにバージョン 3 をリリースしており、残りの Angular はまだバージョン 2.3 でした。 彼らはすべてのAngularパッケージのバージョンを今後同期させることを決定し、次のリリースですべてをバージョン4に引き上げることが、これを達成する最も簡単な方法となりました。

Angular 4

Angular 4 にはいくつかの重要な変更があり、先行コンパイルが追加され、プロダクション JavaScript バンドルを小さくしてアプリケーションのロード時間を短くすることに成功しました。 サーバーサイドレンダリングのサポートが追加され、初期ロードパフォーマンスを向上させるためにアプリを前もってレンダリングしたいチームにとって後押しとなりました。 その他にも多くの改良がフレームワーク全体に加えられたが、Angular 2から4へのアプリのアップグレードは、ほとんどの場合、迅速かつ苦痛なく行われた。

Angular 4.3 および Angular 5

Angular 4.3 には、古い HTTP サービスよりも使いやすい新しい HTTP クライアントが追加されました。 Angular 5 では、古い HTTP サービスは非推奨となり、次のリリースで削除される予定です。 この不便さにもかかわらず、ほとんどの場合アップグレードは簡単だったため、不満の声は比較的少なかったようです。 Angular 5では、より優れた国際化サポートとさらなるビルドの最適化も追加されました。

Angular 6 and 7

Angular 6 と 7 は、一部の開発者にとって期待はずれでした。 大きな変更はありませんでしたが、特に Angular CLI ツールには、多くの小さな生活の質の向上がありました。 目に見える変更の数が減っていることは、Angular チームが革新を止めたことを示すものではありません。 むしろ、フレームワークが成熟していることを示しています。そのため、開発チームは舞台裏でより自由に、バグを修正したりパフォーマンスを向上させたりすることができるようになったのです。

Angular 2のリリース以降のフレームワークの安定性は、旧来のAngularJSの開発者をAngularの世界に引き戻しました。 また、企業の開発チームの注目も集めています。 何十年も生き続けるかもしれない企業向けアプリを構築する場合、予測可能なスケジュールで新しいリリースを取得しつつ、あまりに急速に変化しないフレームワークを使用することが理想的です。 Angular 2しか使ったことがない開発者が、数分でAngular 7アプリを立ち上げ、貢献することができるのです。

Angular 8 と Angular Ivy

そして、今日に至ります。 これまで見てきたように、Angular は長い道のりを歩んできました。 Web 開発者に愛されることから、酷評されること、そして、初期のように再び愛されることはまだないものの、賞賛されるようになりました。

地平線上には、Angular 8があります。 Angular 8 では、Bazel ビルド システムで使いやすくするために大量の作業が行われました。これは、Google 以外で使用している 3 人の開発者すべてにとって絶対に素晴らしいニュースです。 Angular 8の変更点について読む。

よりエキサイティングなことに、Angular チームは Angular Ivy と呼ばれる新しいレンダリングに懸命に取り組んでいるところです。 これは、現在のレンダリングをドロップインで置き換えることを意図しています。 ほとんどの場合、現在のアプリは Angular Ivy を使用するために何も変更する必要はありません。

Angular Ivy がドロップイン リプレースメントである場合、開発者はなぜ気にする必要があるのでしょうか。 2 つの重要な理由、すなわち、速度、およびバンドル サイズです。 数年間、ウェブ開発者は少しおかしくなっているように見えました。 5MB、10MB、あるいはそれ以上の大きさのJavaScriptバンドルを出荷し、これには問題がないと考えているチームがあったのです。 結局のところ、そのアプリケーションは開発者の i7 搭載 MacBook Pro で完璧に動作していたので、誰にとっても問題なく動作するはずだったのです。

残念ながら、現実の世界では、誰もが最新かつ最高のハードウェアを動かしているわけではありません。 何億人もの人々が、ダイヤルアップより少し速いインターネット接続を介して、ジャガイモよりわずかに処理能力の高い古い Android 携帯電話のみでインターネットにアクセスしています。 このようなユーザーにとって、巨大なJavaScriptのバンドルは、読み込みに時間がかかり、デバイスが解析して実行するまでにはさらに時間がかかります。 それほど極端なケースでなくても、最新・最高のハードウェアを使っていないユーザーは世界中に無数にいます。 彼らにとっては、巨大なJavaScriptアプリは使い勝手がよい（しかし苦痛である）のです。

Angular Ivy

Angular Ivy レンダラーはいくつかの点で役に立ちます：

1. 効率に注目して書かれているため、はるかに少ない CPU 命令を実行しながら同じタスクを達成することができます。 これは、バッテリ寿命と、それほど強力でないデバイスを持つユーザーの正気度の両方を向上させるでしょう。
2. レンダラーは、現在のレンダラーよりもはるかにモジュール化された方法で記述される予定です。 これにより、ツリーのシェイクとデッド コードの除去がより容易になります。 その結果、プロダクション JavaScript バンドルには、現在のレンダリングでしばしば起こるように、すべてとキッチン シンクを一緒にバンドルするのではなく、アプリケーションを実行するために必要なコードだけが含まれるようになります。 再構築時間は大幅に高速化されます。 そのため、開発モードでアプリを実行し、変更が表示されるのを待っている場合、待つ時間が大幅に短縮されます。
3. Template-type checking is improved, which means you’re catch more errors at compile time instead to runtime. ランタイム テンプレートのバグは、テスト中に噛み付くか、ユーザーがアプリを使用しようとしているときに噛み付くかどちらかであるため、厄介です。
4. Angular Ivy テンプレート コンパイラーは、現在の View Engine コンパイラーが行わない、人間が読むことのできるコードを生成します。 これは、困難なテンプレートのバグを追跡しようとするときに便利です。

最終的な結果は、より小さいアプリ、より速いアプリ、開発者の満足、そしてユーザーの満足です。

Angular 9

ここでは、Angular 9 の概要を説明します。

主なハイライトは次のとおりです。

• Built-in Angular Features
• Mature Development with Angular
• Understanding Angular View Engines
• Angular Ivy Solves Long-Stalled Problems
• Angular Ivy and Mobile

Selector-

• Selector-

Angular Ivy

• は Angular 9 の概要です。388>
• Angular Diagnosticsの改善
• Angular Ivyによる国際化
• DI と Angular 9のタイプセーフ
• Dependency Injection Angular Coreの変更
• Angular Benchmarks (Angular 8.0.1).2.7 vs. 9.0.0-next.5)

Angular 10

Angular Version 10.0.0 は2020年6月末にリリースされました。 メジャーリリースであるAngular 10では、Angular Materialの新しい日付範囲ピッカー、TypeScriptのバージョンアップ、ライブラリのバージョンアップなどの変更が行われています。

新機能は以下の通りです。

• Ngtsc Compiler Interface
• Configure Async Timeouts
• Stale Lock File Reporting
• Lazy Computation of basePaths
• Merging Translation Files
• Explicit Mapping

Angular 11

Angular バージョン11.New.New.New.Newは、以下のとおりです。0.0は、2020年11月にリリースされました。 Angular 11 のメジャー リリースでは、CLI やコンポーネント フレームワークなど、プラットフォーム全体のアップデートが提供されます。

重要な機能は次のとおりです：

• Faster Builds with TypeScript 4.0.0
• Component Test Harnesses
• ESLint Updates
• Updated Language Service Preview
• Updated Hot Module Replacement (HMR) Support
• Improved Reportings and Logging
• Automatic Font Inliining

Angular の過去。 現在と未来

Angular を初期の頃から今までずっと使っているのであれば、おめでとうございます。 多くの荒削りなパッチがありましたが、最終的には、楽しく使える高速でモダンなフレームワークになりました。

AngularJS の開発者であったが、React、Vue、または他のものに移行した場合、Angular をもう一度見てみることを推奨します。 今使っているものに固執することを決めたとしても、時間を費やす価値があります。

そして、Angularをまったく使ったことがないのであれば、試してみてはいかがでしょうか。

私たちは今、Angular の過去、現在、未来を通して旋風を巻き起こしています。 間違いなく、それはかなりの旅でした。 Angularのバックグラウンドに関係なく、このツアーを楽しんでいただければと思います。

あなたはどのフレームワークで作業していますか？ 質問またはコメントがある場合は、以下に入力してください。

フレームワーク非依存の UI コンポーネントをお探しですか? GrapeCity は、データ グリッド、チャート、ゲージ、および入力コントロールなど、JavaScript UI コンポーネントの完全なセットを持っています。 また、強力なスプレッドシートコンポーネント、レポートコントロール、および拡張プレゼンテーションビューも提供しています。 私たちは、Angular（および React と Vue）を深くサポートしており、最新の JavaScript フレームワークで使用するために私たちのコンポーネントを拡張することに専念しています。