41
17

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

Angularはなぜ敬遠されがちなのか?についての一考察

Posted at

はじめに

jQuery時代からSPA時代になって10年経ちました。

フロントエンドの3大フレームワーク・ライブラリと言えば、Angular、Vue.js、Reactですが、今はReact一強になってきており、例えばTypescript系の新たなライブラリが出ると、まずReactに対応しているか?を気にされることが多くなってきているかと思います。
また、Vue.jsについても日本語書籍の数が多くなってきています。

とはいえ、この3つのソフトウェアでSPAとして実現できることはそんなに大差ないはずです。

Angularにも良さはあるはず、と思い、今回、Angularがなぜ敬遠されるのか?をReactと比較しながら紐解いてみました。

1. 各フレームワークの評価

2018年頃と現在(2024年)で、各フレームワーク・ライブラリを比較してみました。

(1) 人気

まず、様々な記事で出てくるGoogle Trendsによる客観的な比較です。

2016年時点では、AngularとReactはほぼ同じくらいでしたが、2018年にはReactはかなり優勢になっています。現時点(2024年)では、React一強ですが、Angular vs Vue.jsで見ると、米国ではそこまで差がなく、Angularもある程度人気があります。Vue.jsについては全世界的には高い傾向にありますが、その中でも主に中国からのアクセスが多いと思われます。Vue.jsの作者であるEvan You氏が中国人なことも関係あるかもしれません。

2024年現在になると、Reactの一強になっているのが明らかに分かるかと思います。

全世界(青:Angular、赤:React、黄:Vue)

angular_vs_react_全世界.png

日本(青:Angular、赤:React、黄:Vue)

angular_vs_react_日本.png

アメリカ合衆国(青:Angular、赤:React、黄:Vue)

Angular_React比較_米国.png

中国(青:Angular、赤:React、黄:Vue)

Angular_React比較_中国.png

(2) 機能比較:2018年頃

次に機能面などの評価です。こちらは、あくまで作者の個人的な評価ということでご容赦ください。

まずは2018年1月時点で実装されている機能や外部情報をもとに比較表を作ってみました。

比較観点 Angular React
開発元 Google Facebook
リリース年 2016年 (Angular JSは2012年) 2013年
最初に覚えるべきこと △ 多い ○ 少ない
大規模システム対応 △(※本文参照)
状態管理 ○ 標準機能 △ Reduxを導入要
ルーティング ○ 標準機能 △ React Routerを追加導入要。
カスタマイズ性は高いものの、
設定が難しい
エコシステム ○ Google関連やAngular Material等が存在 ◎ サードパーティ含めて充実
テンプレート ○HTMLで可能
⇒デザイナーが協業しやすい
△jsxで可能
⇒デザイナーが協業しにくい

この時点では、Angular=大規模用、React=お手軽導入用 といった感じでしょうか。

Angular

Angularが大規模対応になっているのはエンタープライズシステムでの導入において有難いのですが、その分理解がしづらいという評価になっている気がします。

その理由として、他言語での様々な「取組」を全部盛りしているからと思われます。

例えば、ASP.NETやJavaServer Faces(JSF)を経験したことがある人には、ビューにデータを埋め込む方式は親しみがあるものだと思います。また、後述するDIの考え方は、Spring FrameworkやJakartaEEのCDIを使用したことがある方にはお馴染みの考え方です。ですが、これら言語・フレームワークを経験したことがない人にとって、難易度が高いのも事実です。

またそもそも、Angular JSが2012年に出て、Angular Version 2が2016年に出るのですが、この両バージョン間に互換性が無かったことも敬遠される原因となってしまったかもしれません。新生ファイナルファンタジーXIVのように移行ができれば良かったのですが、Angular JSのイメージは拭えていないのかもしれません。

React

一方、Reactの2018年当時の印象ですが、純粋なSPAには使いやすいなと思ったのですが、いざ大規模システムを作ろうと思ったときに、画面パス遷移やデータ移送の実装方法が難しい気がします。

例えば、ページを他人に共有したいケースを想定して、パスパラメータを使用したいとします。ルーティング機能が必要になるのですが、それには、まず、React Router、Reduxといった追加パッケージをいくつかインストールが必要となります。そして、これらモジュールの使い方についても、そもそもReactについて確り理解してからでないと理解しづらいと思います(少なくとも、私はReduxを理解するのにだいぶ苦戦しました)。

(3) 2018年以降におけるReactの進化・改善

ただ、その後、Reactにはver16.8でReact hooksという仕組みが導入され、状態管理においてもステートフックという強力な仕組みが導入されます。このお陰でReduxを使用しなくても状態管理をある程度実現できます。

また、ルーティングについても同様で、Next.jsの台頭もReact流行の後押しになったと思います。実際、日本で販売されているReact関連の書籍の多くもNext.jsも利用する前提としているものが多くなってきています。
React Routerは設定方法が比較的複雑ですが、Next.jsの最新ルーター機能であるApp Routerはappフォルダ配下で、pages.tsxがあるフォルダパスがそのままURLパスになります。

Vue.jsとの比較でいうと、Vue.jsが中小規模向け、Reactが大規模向け、と評価している人もいるようです。
Reactが人気も実力も一歩抜き出しているのは明らかです。

以上を踏まえて、機能比較表を2024年時点に更新してみました。

比較観点 Angular React
開発元 Google Facebook
リリース年 2016年
(Angular JSは2012年)
2013年
大規模システム対応 ○ 下記の通り機能が充実
ルーティング ○ 標準機能 ○ Next.jsを使えば
お手軽に実現可能
状態管理 ○ 標準機能 ○ React hooksで対応可能
エコシステム ○ Google関連や
Angular Material等が存在
◎ サードパーティ含めて充実
テンプレート ○ HTMLで可能
⇒デザイナーが協業しやすい
○ jsxで可能
⇒Storybook等のツール導入により、デザイナーとUI部品を共用1

では、本当にReact一択となるのでしょうか?

米国だとVueよりもAngularの方が人気ありそうですし、日本では、多くの大手ベンダーがAngularを推しています。

ということは、日本市場において利点もそれなりにあるはずだと思っていますので、もう少し掘り下げて考えてみました。

2. Angularの特徴

Angularは大規模向きも、複雑で学習コストが高いとよく言われます。その特徴について深堀してみました。

特徴(1) オールインワン

オールインワンなので多くの機能を知らないと使いこなせないという評価ですが、全てを理解しようとせず、「おまじない」として整理して動かすだけであれば、そんなに苦労はしません。

例えば、ng new 【新アプリ名】でアプリを一から作ると、この1コマンドだけでAngularで動くアプリは作れます。これはAngularに限った話ではなく、Reactはじめとするフロントエンドもそうですし、最近だとSpringBootやQuarkusといったバックエンドアプリもそうですが、環境設定に時間がかからず色々なことをPoCできる点においてAngularとReactで差はないと思います。

それに加えて、状態管理やルーティングといった機能が標準装備されていますし、パイプというデータ表示の加工部品もデフォルトで用意されています。これらを自ら開発するのではなく、作られた部品として使用することを考えると、当然全部を覚える必要がなく、必要な機能(イディオム)のみを覚えるだけで、十分、フロンド開発が可能です。

逆に、純粋なSPAでURLを変える必要がなければルーティング機能は不要ですし、表示データを加工する場合にも、純粋なTypescriptで作れるため、自ら独自のパイプも作る必要はありません。これら機能を全部使おうとしなければ、学習コストも下がると思いますし、この観点でもReactと差がないように思えます。

特徴(2) レイヤードアーキテクチャの採用

昔ながらのJavascriptライブラリであるprototype.jsやjQuery、あと私は永らくYahooUIを使用していましたが、これらはHTMLやJSP・ASP等のサーバーサイドレンダリング(SSR)での利用が前提になっていました。いわば、既存のHTMLの仕組みありきで、アドオンで機能を強化・補助する仕組みで実装されていました。

ただ、SPAはクライアント側でレンダリングするため、例えばサーバへの問い合わせや状態管理などを全て1枚のHTMLで実現しようとなると、たくさんの要素がHTMLに詰め込まれてしまいます。

これを良しとしなかったのがAngularと言えるかもしれません。プログラムの役割分担とレイヤー化を徹底させたオブジェクト指向言語の思想を踏襲しており、ASP.NETやJavaServer Faces、Ruby on Rails等、サーバーサイドのフレームワークの位置付けで実装されているように思えます。ですので、ViewであるテンプレートHTMLとModelであるコンポーネントを分離することが可能です。

一方で、Reactは部品化に優れていますが、部品化すれば、jQueryのように気軽に使用することもできます。まさにReactが自らをライブラリと自称していてフレームワークではないと位置付けいている通り、HTMLの補助ライブラリとして機能します。だからこそ、サーバサイド(バックエンド)の経験がないフロントエンドエンジニアにとっても、理解しやすかったのでは?と思います。

ちなみに、Vueも同様で、一部分だけに気軽に使用できるところが特徴です。

しかしながら、一部だけ気軽に使用できるということは、フロントエンドシステム全体としてガバナンスを効かせるのが難しいとも言えます。Aさんが作る機能はReactが一部使われていて、Bさんが作る機能はVueが一部使われている、となると、メンテナンスする人は両方の知識が必要になってしまいます。保守は、得てして開発時より人が少なくなるため、保守するエンジニアが広範なスキルを求められることとなってしまいます。

Angularであれば、一部でライブラリ的に導入することができない反面、Angular以外で実装されることがなくなるため、全体として統一感あるアプリケーションになるかと思います。大規模システムであってもアーキテクチャのガバナンスが効くと思います。

特徴(3) DIの存在

特徴(2)とも絡む話ですが、Springを使用した経験がある人だと、DI(Dependency Injection/依存性注入)という考え方があります。Angularにはこの依存性注入が具備されているのですが、この考え方もバックエンド、特にJava等のオブジェクト指向言語で大規模システムをやったことがある方でないと、初見になってしまいます。

また、DIにより宣言しなければいけない箇所が複数(少なくとも2箇所)存在します。

  • app.module.tsに使用するクラスを宣言
@NgModule({
// 中略
  providers: [
     { provide: AaaService, useClass: AaaService }
  ],
// 後略
})
  • コンポーネントクラスのコンストラクタの引数での宣言
import { Component } from '@angular/core';

@Component({
   selector: 'app-bbb',
   // templateUrl属性等は省略
})
export class BbbCommponent {
   constructor(private service: AaaService) { }
}

Javascriptの一般的なモジュールに加えて、NgModuleというAngular独自のモジュールが出てきたり、言葉も複雑ですし、これら概念・スキルを理解するのにハードルが高いと思います。

ただ一方で、DIが特段難しいとも思いませんし、プログラミングを経験したことがある方なら、特に保守開発の経験があると、きっとメリットが分かっていただけるものと思っています。例えば、

  • 追加サービスを作るとき。あるサービスを丸々コピーして一部修正するアプローチの場合、同じロジックを修正するときに両方のサービスにメンテが必要
  • サービスをレベルアップしたい場合。新サービスの差し替えが容易ですし、旧サービスへの戻しも簡単
  • モックを使ったテストをしたい場合。外部連携モジュールを擬似的に再現してくれるモジュールに入れ替えが可能

等が実現できます。ですので、考え方として導入することで品質向上や、アプリ保守改定時の工数削減に繋がります。

ですので、エンタープライズシステムのプロフェッショナル開発として考えると、これら機能があった方が良いとも言えます。

各種機能への理解の必要性

上記特徴を理解する必要が出てくるため、覚えることも盛り沢山、と身構えてしまうのはよく分かります。その他にもディレクティブやRxJS(Observable)等の概念が出てきます。

ただ、これらは拡張するときに使う機能で、これらを覚えないとAngularを使えないということにはならないと思います。言い換えると、多くのSEは、これら難易度が高い機能を触らなくても開発できると思います。

例えば、OpenAPI Generatorを使った下図のようなアーキテクチャが考えられます。
図1.png

青色部分が、開発者が実装しなければいけない箇所です。黄色の部分である、画面部品や画面遷移は一人の優秀なSEが作ればいいところだと思っています。(あくまで大規模開発において、ですが)。

また、緑色の部分はバックエンドとの接続機能になりますが、ここはOpenAPI Generatorのようなソースコード生成ツールも出てきています。get/postなどによるAPIアクセスは完全に自動生成できるので、開発者はその関数を呼び出すだけで良いです。(ただ、バックエンドからRxJSの機能であるObservableで返ってくるため、Observableは理解していないといけないのですが、とはいえ、コーディング方法を手順化できます)

すなわち、Angularエンジニア=全部ができないとダメ、ということではないです。
これは、JavaEEでも.NETでも何でも同じで、20年前、サーブレットやEJBの仕組みを完全に理解しているエンジニアなんて、そう多くはなかったと思います。だからこそ、手軽に開発できるStrutsが流行ったのだと思います。

お伝えしたかったことを最後にまとめました。

Angularの特徴

  • バックエンド(特に大規模)のアプリケーション開発経験者にとって理解しやすいフロントエンドのフレームワーク
  • 全機能を理解する人は一部のスーパープログラマーのみでOK! 
    多くの方はHTMLとTypescriptの文法を理解していれば事足りる

3. 【最新版(2024年5月時点)】機能比較表

以上を踏まえて、機能比較表を2024年時点に更新してみました。

比較観点 Angular React
開発元 Google Facebook
リリース年 2016年 (Angular JSは2012年) 2013年
向き・不向き バックエンドの開発経験
が多い人向け
フロントエンドの開発経験
が多い人向け
大規模システム対応 ○ 下記の通り機能が充実
ルーティング ○ 標準機能 ○ Next.jsを使えば
お手軽に実現可能
状態管理 ○ 標準機能 ○ React hooksで対応可能
エコシステム ○ Google関連やAngular Material等が存在 ◎ サードパーティ含めて充実
テンプレート ○ HTMLで可能
⇒デザイナーが協業しやすい
○ jsxで可能
⇒Storybook等のツール導入により
デザイナーとUI部品を共用
1

Reactは優秀なOSSだと思います。ただ、Angularも決して負けてないですし、大規模であれば大規模なほど、ガバナンスを効かせるために、一部のスペシャリストによる「カプセル化」が効いてきます。

4. まとめ

いかがでしょうか? Angularの機能は、むしろ、昔からSEをやってきた人にとって、馴染みのある機能が多く含まれているため、理解しやすい側面もあると思います。

一方で、最近、SEになってMVC時代のWeb開発の経験が少なかったり、大規模システム開発経験が少ない方からすると、とっつきにくさはあると思います。

ですが、開発標準化が大変進めやすいと思います。一部のスーパーエンジニアが制御系のアプリを作り込み、開発手順を整備すれば、多くのSEは業務ロジックの実装に専念できます。
そして、その実装にあたって必要なスキルは最低限の「TypeScriptの文法」だけです。

大規模システムでスーパープログラマーばかりを揃えることが難しい案件では、Angularは重宝されても良いかなと思いますが、いかがでしょうか?

P.S.

尚、本記事は、ReactやVue.jsを否定するものではなく、Angularも含めて適材適所で使っていけますよ!ということを意図しています。Vue.jsは勉強不足ですが、機会があればReactについても見解を述べさせていただければと思います。

参考

最後に、Angularについての情報サイトをリンクしています。
改めて検索してみると、書籍は少ないものの記事は多かったりするのですが、それも2021年くらいまでがほとんどでした。もうちょっと増えて欲しいですね。

Angular公式ページ

https://angular.jp/
情報は充実している気がします。
日本語化されていないページもありますが、今となっては翻訳機能がブラウザについてますので、問題ないです。
とはいえ、ベンダーマニュアルによくある難読な感じは多少あるかもです。軽く眺めて欲しい情報がすぐ取れるか?というと難しいですが、それはクラウドベンダーの説明サイトもそうですし、昔の製品のマニュアルはもっと難読だった気もします(・・・と昔話をしてしまうところは、おじさんの戯言としてスルーしていただけると幸いです)

Angular日本ユーザ会

https://community.angular.jp/
日本のAngular開発者によるユーザーコミュニティで、イベントの開催や、公式マニュアルの翻訳などの活動をしています。
2024年現在では、月次で最新情報を紹介しています。

10 Best Examples of Websites and Apps Built with Angular

https://seclgroup.com/10-best-examples-of-websites-and-apps-built-with-angular/
Angularを使用して開発されている製品について紹介されているブログです。
Gmail、YouTube等のGoogleサービス以外にもPaypal等の企業でも使用していますし、Angularを利用するメリットについても記載されています。

書籍「Angular アプリケーションプログラミング」(山田祥寛 著)

https://gihyo.jp/book/2017/978-4-7741-9130-0
有名なライターの山田さんの書籍だってあって個人的には理解しやすかったです。2017年発行と多少古いですが今でも十分に使えます。カラーだともっと親しみが沸くかなと感じました。

Angular初心者がハマりがちなポイントとその学習法

https://zenn.dev/knts0/articles/angular-stuck-points
考察するにあたって拝見させていただきましたが、多くのAngularエンジニアが躓く壁を丁寧に説明している良いサイトと感じました。

実は進化してる!Angularを使う理由をお話します

https://note.hubble-docs.com/n/neb9b8119bb23?gs=a91575aacf28
Angularの使う理由について、この記事とは違った観点で書かれていました。この記事だけではなく、Angular界隈の方は、ブログ等で啓蒙活動をされている熱い方が多いと思います。また、Angularが盛り上がる時期がくると良いなと思っています。Pythonが機械学習のライブラリ群が充実化したり、.NETもUnityやUnreal Engineでさらに使われるようになったりしているので、キラーコンテンツとなるライブラリが出てくると状況が変わる気もします。

  1. Reactのテンプレートのところも実は⚪︎に変更していますが、StorybookやAtomicデザインの浸透については、また別の機会にお話できればと思います。 2

41
17
2

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
41
17

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?