どうも、フロントエンドエンジニアの小松です。
エンジニアブログなのに非エンジニア向けの記事になり恐縮ですが、最近社内で
『このプロジェクトはJSフレームワークを導入した方がいいの？』
『どのフレームワークがオススメなの？』
『そもそもどんなときに必要なの？』
的なやり取りをする機会が増えたので、エンジニア目線でそこらへんの認識を記事にしてみようかと思います。
あくまでエンジニアでない方々にわかりやすく伝えるために相当乱暴な表現をしてますが、
ギークでジェントルマンなエンジニアな方々はどうぞ見過ごしてやってください…
目次
まず「JavaScriptフレームワーク」ってなに
「JavaScriptフレームワーク」と聞いて真っ先に何を思い浮かべましたか？
先に個人的見解になりますが、2018~2019年を生きる皆さんはReact/Vue/Angularのいずれかを指していると考えてよいのではと思います。
ギークでジェントルマンなエンジニアな方々はどうぞ見過ごしてやってください…
例えば、クライアント先や社内の開発会議で『JSのフレームワークは何か導入しますか？』的な話が出たとして、ディレクターが『まずはjQuery入れるよな』とは思いませんよね(思いませんよね？)。
もしくは『BootStrap入れるか』とも思いませんよね。
それらの認識は概ね合っており、jQueryやBootStrapはライブラリと呼ばれるものになります。
すると次に『ではフレームワークとライブラリの違いとは…』と考えるかもしれませんが、考えるのはやめましょう。
フレームワークは仕組み・枠組みでライブラリは集合体、程度の曖昧さを持っていたほうが社内外で打ち合わせする際は話しやすいかと思います。
ちなみに『ReactはライブラリでVueとAngularはフレームワーク』と聞くかもしれませんが、
この記事のターゲットである皆さんはとりあえずそれ以上考えるのはやめましょう。
JavaScriptフレームとは、React/Vue/Angularのいずれかという頭で以下話を進めていきます。
どんなときに採用すればいいの
環境やセキュリティやスキル面での制約が無い限り、基本的にはどんなプロジェクトにも適用できます。
ので、逆にここは皆さんが最も悩む部分で『じゃあ結局どうしたらいいの…』とモヤモヤしますよね。
早速ここでも超個人的見解ですが、Webアプリと呼べるものに対してのみ導入を検討するでOKだと思います。
例えばですが、青汁のLPはWebアプリと呼びますでしょうか？
(もちろんクライアント側のインターフェイスとWebサーバーが通信をすることで表示されているので立派なWebアプリですが…)
この記事を目にしている方々の周囲において「Webアプリ」とは、ユーザーからの入力を受け付け、登録・変更・削除などを行い、ユニークなステートを管理するWebサイトのことを指しているのではないでしょうか。
こうしたWebアプリでは下記を担保しないとスケールし辛いので、これらを補うためにフレームワークを導入すべきという考えになります。
- 開発手法・構成の統一
- 開発コストの削減
- 拡張性
- コンポーネント思想
おさらいをすると、Webアプリと呼ばれるものを作る際は、React/Vue/Angularのいずれかを導入する可能性があるです。
俺たちのjQueryがあるではないか！
数々の修羅場を乗り越えてきたベテランディレクターの方々はこの時点で『でも今までjQueryでいけたから、別に導入しなくてもいいのではないか』と思われたかもしれません。
その疑問に対しては、『そうかもしれませんね』としか言えません。
というのも、実際jQueryで(頑張って)書いて成り立っているサービスもあるため、フレームワークの導入が必要かどうかはそのプロダクト次第だからです。
ですが、下記のケースは経験上導入を検討した方がよいかなと思います。
- ユーザーからの操作とインターフェイスが密接に関連している(管理画面とか)
- データ更新の結果UIを頻繁に更新するようなデザイン・設計になっている
- サービス全体をSPA(シングルページアプリケーション)にしたい
- 機能を有したコンポーネントを頻繁に流用する
- 中〜大規模のプロダクトで開発者が複数人いる
- 仕様をエンジニアに伝えた後に『これjQueryで全部書いて？』と言ったら辛そうな表情になった
- サーバーサイドエンジニアが『俺はもうAPIしか作らねぇ！』と言って話を聞かない
これらの判断ですが、おそらく非エンジニアの方だけでは難しいのではと思いますので、極論ですが身近なフロントエンドエンジニアに相談するのがベストです。
フロントエンドエンジニアはUIとロジック部分を橋渡しするプロなので、上記のような様々な要因を考慮して適切な判断を行ってくれると思います。
くれぐれも『よく分からないんで、とりあえずjQueryだけでお願いします。』という判断はしないようにしましょう。
どれにしよう
慎重に事を進めた結果、めでたく?JavaScriptフレームワークを導入することが決定しました！
まるで3匹のポケモンの中から好きなものを選ぶような状況のようでワクワクしますね。
余談ですが、Reactがゼニガメ・Vueがフシギダネ・Angularがヒトカゲという認識は全世界共通だと信じています。
『よし、なんか強そうだから俺たちはAngularでいくぜ！！』ではなく、どのフレームワークを選定するかも慎重に考えましょう。
正直ここまでくると宗教論争の世界なので書くのが怖いのですが、以下の判断要素をもとに選定していくことになるかと思います。
- プロダクトのフェーズ
- 学習コスト
- 将来性
- その他
プロダクトのフェーズ
今導入を検討しているプロダクト(=サービス)のフェーズはどんな状態でしょうか。
ある程度運用しているサービスで、jQueryでゴリゴリとフロントエンドの処理を書いているような場合、自分であればReactかVueを選びます。
理由としては、小さく始めることができるからです。
Angularは他の2つと比較するとフルスタックなフレームワークとなっており、既存のロジックと重複する部分が多くなるため新規開発時に選定することで更に恩恵が受けられるかと思われます。
一方、ReactやVueは、MVCでいうところのView(見た目の部分)の制御に特化しており、小さなコンポーネントから導入するができるメリットがあります。
特にVueは「Progressive JavaScript Framework」と紹介されているように、段階的に導入すること視野に入れて設計されているため、部分的な導入がしやすいです。
学習コスト
これに関しては、圧倒的にVue.jsに軍配が上がります。
その理由としては…
- ドキュメントが日本語対応している
- HTML,CSS,JavaScriptの基礎部分を知ってさえいればすぐに使えるレベルのシンプル設計
- JSX,RxJS,TypeScriptなど、フレームワークとセットで学習するものが基本的にない(もちろんVue特有の記法はあります)
などが挙げられ、公式サイトでも
Already know HTML, CSS and JavaScript? Read the guide and start building things in no time!
と言うくらいに、「とりあえず使ってみる」の敷居が低いです。
僅差でReact、そしておそらく最も学習コストが高いのがAngularかと思われます。
しかし、学習コストが高いということはフレームワークとしてのルールが厳格なため、開発者による実装の揺れが少なくなり一概にデメリットとは言えません。
以上から学習コストの大小はフレームワーク選定において優先度の高い判断要素ではなく、開発メンバーのスキルセットや長期的な目線とセットにして加味する要因だと思われます。
将来性
残念ながらフロントエンドの世界、特にJavaScript界隈の流行り廃りのスピードは尋常ではありません。
当時イケてると言われていた技術に憧れて勉強し始めたものの、プロジェクトに導入する頃にはオワコン化していることも全然珍しくない、そんな世知辛い世界です…
これから開発する大切なプロダクトに、1年後にサポートが打ち切られるようなフレームワークは入れたくないですよね。
そんなわけである程度長期的に使えそうなフレームワークを選ぶ必要があり、下記を目安に判断するとよいかもしれません。
- githubが賑わっているか
- 有名どころのサービスが採用しているか
- 公式サイトで今後の展望がオープンになっているか
- JavaScript自体の仕様改変を積極的に取り入れているか
などなど書きましたが、今回対象にしている3つのフレームワークは大御所なのですぐに廃れる心配はありません。
逆に、これら以外の場合は注意が必要です。
その他
さらに下記要素も選定に影響してくる可能性がありそうです。
- 開発者のバックグラウンド(サーバーサイド上がりの方ならClassベースのAngularが合う?)
- jQuery等のライブラリを使わない開発の有無(比較的Reactは素のJavaScriptを書く機会が増えるため)
- 土台となるフレームワークとの相性(Larabelは特にVue.jsと相性が良いそうです)
- ブラウザ対応(IE…)
こうして色々と書くと逆にどれを選べばよいのかと悩んでしまいそうですが、
正直なところどれを選択しても基本的に同じものは作れるので、上記の要因に対して絶望的に一致していない限りは最後はエンジニアとエイヤッと決めてよいかと思います。
しかしまだ始められない開発
おめでとうございます、度重なる審議の結果めでたく何かしらのフレームワークを採用することが決定しました！
ディレクターも胸をなでおろし会議室から去ろうとすると、エンジニアが例えばこんなことを言い始めるかもしれません。
『環境構築はどうします？』
『Webpack使うんですよね？』
『SSRします？』
このようにフレームワークを決めた後には
- jQueryみたいに簡単には導入できないので、環境構築と設定のカスタマイズが必要
- その上、様々な方法で実現できてしまうのでまた実現方法の選定が必要
- SEOとかセキュリティとか表示パフォーマンス面でSSR(サーバーサイドレンダリング)するか検討する必要がある
みたいな状況が待っています。
今回はこれらの詳細には触れませんが、JavaScriptフレームワークを導入する際は開発までに確認・定義すべき点が多く、しかもエンジニアでないと理解し辛い内容を含んでいるため、ディレクターがそれらの判断裁量を背負ってしまうと危険です。
可能であれば、開発チームの中から技術選定・開発環境定義を行うエンジニアを抜擢し、
プロダクトの中でのプライオリティや制約など、判断材料となる情報を提供し二人三脚で進めるのが理想かと思います。
伝えたかったこと
長くなってしまい何が言いたいのかよく分からない感じになってきたので、
最後にJavaScriptフレームワークと向き合うことになった非エンジニアに方に向けたまとめで締めたいと思います。
- JavaScriptフレームワークの話になったらReact/Vue/Angularあたりをイメージしておけば多分大丈夫です
- 青汁のLPとかには導入する必要ありません
- jQueryは万能ではありません
- 導入の可能性が出たら、フロントエンドエンジニアと相談できる体制を立てましょう
- どのフレームワークを導入するかは多角的な視点をもって慎重に決めましょう
- でもどれを選んだとしても詰むことはありませんので大丈夫です
- 導入が決まった後にも決めることはたくさんあるのでスケジュール管理にはお気をつけて
- Vue.jsおすすめです