ウェブフロントエンド開発に Vue や React を選択する理由【DeNA TechCon 2021】/techcon2021-17

フロントエンド開発について「サーバーサイドテンプレートでHTMLレンダリングすれば良いのでは？」「Vue や React の学習コストかける意味ある？」「jQueryコピペですぐできるでしょ」と思う方もいるのではないでしょうか。

DeNAでは、ウェブアプリケーションのフロントエンド開発のプロジェクトにおいて、以下が混在していますが、前者をベースにした開発のプロジェクトが増加しています。

・SPA ベース：Vue や React をベースにしたフロントエンド開発のプロジェクト
・テンプレートベース：Xslate や Smarty、Slim や ERB、Thymeleaf などをベースにしたフロントエンド開発のプロジェクト

ウェブアプリケーションサービスのフロントエンドをどう作るか。テンプレートエンジンによるレンダリングベースではなく、React や Vue で開発することについて、フロントエンドエンジニア以外の様々なエンジニアの皆様にご紹介します。

Transcript

1. 髙橋伸弥
2. 髙橋伸弥 • デザイン本部マネージャー • UX/UI デザイン、ソフトウェアエンジニアリング
3. • エンジニア出身の経営・企画・PM の方 • フロントエンド指向なエンジニアの方 • ウェブアプリの UX/UI の最適化や コストの削減に興味のある方 • ウェブアプリのテックリードの方 (サーバーサイドエンジニア含む)
4. • Vue, React 以外のフレームワークも(意味的に)含みます ◦ Angular, Gatsby, Next, Nuxt, Svelte, Flutter とかもね • 一定端折ります • 一定ポジショントークです
10. 「UX/UI を突き詰めたサイトにしたいです。 　けど React とかでガチガチにされると 　手がつけられないのでやめて欲しいです」
11. 「UX/UI を突き詰めたサイトにしたいです。 　けど React とかでガチガチにされると 　手がつけられないのでやめて欲しいです」 「デザインを実装する人が欲しいです。画像を切り出して、 　HTML+CSS を組んでくれればいいです。 　(hoge文法の) テンプレ組み込みもね！」
12. 「JavaScript の開発で手こずっているみたいなので、 　(サーバーフレームワークの) HTML テンプレートベースの開発 　フローにできないっすかね」
13. 「JavaScript の開発で手こずっているみたいなので、 　(サーバーフレームワークの) HTML テンプレートベースの開発 　フローにできないっすかね」 「jQuery でできませんか？ 　Vue.js とか入れる必要ありますか？」
15. • UX/UI を妥協しないといけない ◦ 今のフロントエンド技術が、事業オーナーの敬遠・誤解で使えない ◦ 手触り感などは CSS+jQuery アニメーションなどでお茶を濁す程度 • プロダクトとしてイケてないものを 作らせることになる懸念
16. • 作って納品・範囲が限定的でキャリアが伸びない ◦ 短納期で事業理解も不要なことが多い • 技術的な学びが少なくスキルが伸びない ◦ 新しく技術的に学べることは フレームワークごとのテンプレ文法ぐらい ◦ 画像切り出して HTML+CSS+jQuery • 成長させにくい懸念
17. • サーバーサイドに任せっきりにしてしまうと、パフォー マンス・負荷軽減をフロントエンドで最適化できない ◦ 中長期的なリスクを増やしてしまう恐れ • プロダクト戦略全体としての懸念
18. • 中長期的にリファクタリングが難しくなる ◦ 整頓されていない・されにくいコードのプロダクトを いずれまた誰かにスイッチさせないといけない • 結果的にアサイン難易度が上がったり、 組織的な弱体化につながる懸念
19. • 「世の中的に伸びているプロダクト」 「よく使う」「イケてるウェブサイト」は 簡単に作られていない ◦ 画面に表示されない諸々も大事 • いつまでもフロントエンドは簡単でいいという 誤解が残り続ける懸念 ◦ 「簡単」を売り文句にしていたツケ？
24. 1. ユーザー体験のため
25. 1. ユーザー体験のため 2. ビジネスコストの削減のため
26. 1. ユーザー体験のため 2. ビジネスコストの削減のため 3. 開発の効率化・中長期の開発体制のため
27. 1. ユーザー体験のため 2. ビジネスコストの削減のため 3. 開発の効率化・中長期の開発体制のため 4. 安全なウェブサービスの運用のため
29. 突然変異による進化でフロントエンドの声が 大きくなっているというのではなく、 連続的な進化の果てに今のフロントエンド開発がある ウェブサイトの歴史をおさらいしてみましょう
30. 静的なコンテンツを配信するウェブサーバーのみ
31. 動的な機能のためサーバーで HTML を生成するプログラムを 動かす 昇順 検索
32. 色々なプログラムを実行したり... 昇順 画像生成 検索
33. サーバー間での通信を行ったり... 昇順 いいね 画像生成 検索 遷移
34. サーバー間での通信を行ったり... 昇順 いいね 画像生成 検索 遷移 フォロー 無限スクロール ロード
35. ブラウザの JavaScript エンジンが高速化され 動的処理をブラウザに任せられるようになってきた ①一旦 JavaScript を含む静的なデータを受け渡し ②ブラウザで JavaScript を実行させて動的な データをやりとりする・処理を行う 昇順 画像生成 検索 遷移 いいね フォロー 無限スクロール ロード
36. • 負荷がかかる処理をサーバーで実行しなくて 良くなる ◦ チリツモになる HTML レンダリング、ルーティング、 ファイル処理... ◦ アクセス集中によるスパイクを回避できる
37. • 負荷がかかる処理をサーバーで実行しなくて 良くなる ◦ チリツモになる HTML レンダリング、ルーティング、 ファイル処理... ◦ アクセス集中によるスパイクを回避できる • サーバーのインスタンスサイズを過剰にでか くしなくてもよくなる
38. • 負荷がかかる処理をサーバーで実行しなくて 良くなる ◦ チリツモになる HTML レンダリング、ルーティング、 ファイル処理... ◦ アクセス集中によるスパイクを回避できる • サーバーのインスタンスサイズを過剰にでか くしなくてもよくなる
39. • jQuery または素の JavaScript で HTML を 動的に組換えないといけない ◦ 複数の API からグローバルにデータを保管し、状態を算 出し、その分岐処理・フィードバックを行う
40. • jQuery または素の JavaScript で HTML を 動的に組換えないといけない ◦ 複数の API からグローバルにデータを保管し、状態を算 出し、その分岐処理・フィードバックを行う • 機能やデータの追加はどれがなにか調査から ◦ ドキュメント整理しておくか、サーバーのレンダリング 関数やモデルクラスを読み解く必要がある
41. • jQuery または素の JavaScript で HTML を 動的に組換えないといけない ◦ 複数の API からグローバルにデータを保管し、状態を算 出し、その分岐処理・フィードバックを行う • 機能やデータの追加はどれがなにか調査から ◦ ドキュメント整理しておくか、サーバーのレンダリング 関数やモデルクラスを読み解く必要がある
42. そこで
44. フロントエンドに秩序をもたらすもの 結果「サービスの全体的な最適化」を しやすくしてくれる
46. 1. 導入・学習のスロープが存在する
47. 1. 導入・学習のスロープが存在する 2. 世界的に流行し、デファクト化してきている
48. 1. 導入・学習のスロープが存在する 2. 世界的に流行し、デファクト化してきている 3. 仮想 DOM で UX/UI が最適化される
49. 1. 導入・学習のスロープが存在する 2. 世界的に流行し、デファクト化してきている 3. 仮想 DOM で UX/UI が最適化される 4. コンポーネント指向型で開発効率がよい
50. 1. 導入・学習のスロープが存在する 2. 世界的に流行し、デファクト化してきている 3. 仮想 DOM で UX/UI が最適化される 4. コンポーネント指向型で開発効率がよい 5. 安全にウェブアプリを開発するための TypeScript サポートも充実している
52. • 一枚板のフレームワークと異なり、 少しずつ導入していけるように設計されている ◦ 最初は View 層のみに適用し、違う層(Routing や、Store など)にも適 用したり、ウェブアプリの大枠をこれでまかなう、という発想ができる
53. 1. View 層 (Vue.js, React.js) 2. コンポーネント分割 (VSFC, JSX) 3. Routing 層 (vue-router, react-router) 4. Store 層 (vuex, redux) 5. SSR、SSG (Nuxt, Next) 6. プラグイン, webpack, ...
54. • 学習が完了したら少しずつ導入してみよう • jQuery・JavaScript ベースのプロジェクトだと 全て一から自分でこれらを作らないといけない • npm (Node Package Modules) のエコシステムの恩恵を得て その仕事で一番大事なことに集中しよう • Vue, React にはいろんな人が考えて、試験して、 良くしてきたしっかりとしたライブラリがある
56. Vue: 2013年7月29日 レポジトリ作成 React: 2013年5月25日 レポジトリ作成
57. GitHub 累計スター数 全レポジトリ中 Vue 3 位・React 5 位 Flutter 110K Angular 69.3K jQuery 54.4K...
58. 🇵
59. 🇸 🇳
61. 🇵
63. HTML は DOM (Document Object Model) というツリー
64. HTML パース→ DOM ツリー構築→ ウェブページレンダリング ウェブページを遷移するたび に上のフローを踏まないとい けない
65. JavaScript データモデルとし てメモリ上にパース済みの DOM を保持 画面差分のみを更新するなど 表示高速化が実現できる
66. • グラフやデータ表示などに効果大 ◦ 「フィルター」「検索」「ソート」などデータを 切り替える機能でいちいち画面を全更新しなくてよい • ウェブページの遷移が高速化 ◦ 画面離脱率を低下、より見せたいものを見せられるように
68. プログラムを部品ごとに分割 Vue, React 構造は違うがど ちらも部品単位で作って合体 してアプリにするという考え 方
69. コンポーネント単位で HTML + スクリ プト + スタイルをひとまとめにした 「Single File Component」を組み合わ せる
70. Javascript の中で部品を組み立てていく この時の HTML を JSX と呼ぶ スタイルの当て方は比較的色々なやり方が ある
71. • ライブラリで一定書き方が定められている • コンポーネントを単位としたプログラムになる ◦ コードの一貫性・保守性を保つことができる ▪ 見通しがよく・変更しやすく・不要になった際は捨てやすい ◦ デザイン的な一貫性も保てる
73. • 静的型付けが可能な JavaScript の代替言語 ◦ 型付けられたら良いけど付けないのも可 ◦ 型推論もあるよ • JavaScript の上位互換 (と言ってもいいのではと思っています)
78. コードヒントが出せるので、型定義すれば オリジナル API もドキュメント不要にできる！ string に使えるプロパティ・メソッドが ずらっと表示。タイピングも短縮。
79. ビルド時やコーディング中に型チェックで 予期しない値が入らないようガードしてくれる！ 「string 型を渡さないといけないところに 　number を渡してますよ」
80. • 開発効率を高められる • バグの早期発見/防止を実現できる ◦ tsconfig.json ファイルのオプションで、型必須にすることもできる • React、Vue も TypeScript を活用できるように サポートが充実している
82. • DeNA では 5:5 ぐらいで使われている • HTML + CSS + JavaScript で従来と近い形で SPA に構築したいなら Vue • JavaScript でプログラマブルに SPA を構築したいなら React
84. https://www.npmtren ds.com/react-vs-vue- vs-jquery-vs-@angul ar/core
85. 必要な機能はそれぞれの陣営で 開発されていてどちらを使って も大丈夫 国やライブラリによって活発度 合いが若干違うので総合的に判 断してみるとよい
86. 1. 中長期に運用されて、多くの動的な 情報が蓄積・表示切り替えされるサ イト 2. UX にこだわりたいサイト 3. SaaS や管理画面のようなビジネス活 用サイト 4. 画面を多く遷移する EC や SNS ほか 高機能なウェブサービスのサイト
87. というか入れる必要がないと思うサイト 1. キャンペーン・イベント告知等の 短命なサイト ※TechConサイトのような複数画面を用意する SPA は除く 2. 画像を並べるだけのサイト 3. マーケティング LP のような量産 広告型(訴求内容を多く変えて)の ウェブページ
88. • 技術的投資のリターンが一定見込めるかどうか ◦ 向いていないサイト・チームかどうかちゃんと見極める • チームサイズやプロダクトに合わせた設計を ◦ 小規模なサイト・ジュニアなチームにも過剰なチェック機 構(型・lint・e2e)必須のワークフローにしないように ◦ 無理なルールを導入せず良きバランスのところを探ろう • 高速にチームが改善できる範囲で少しづつ導入 ◦ エンジニアなら強くないといけない × チーム開発でのスループットを見極めて導入 ◦
90. 1. ユーザー体験のため 2. ビジネスコストの削減のため 3. 開発の効率化・中長期の開発体制のため 　 4. 安全なウェブサービスの運用のため 　
91. 1. ユーザー体験のため→表示速度やUIを改善可能 2. ビジネスコストの削減のため 3. 開発の効率化・中長期の開発体制のため 　 4. 安全なウェブサービスの運用のため 　
92. 1. ユーザー体験のため→表示速度やUIを改善可能 2. ビジネスコストの削減のため→サーバー負荷解消 3. 開発の効率化・中長期の開発体制のため 　 4. 安全なウェブサービスの運用のため 　
93. 1. ユーザー体験のため→表示速度やUIを改善可能 2. ビジネスコストの削減のため→サーバー負荷解消 3. 開発の効率化・中長期の開発体制のため 　→効率的な開発フロー 4. 安全なウェブサービスの運用のため 　
94. 1. ユーザー体験のため→表示速度やUIを改善可能 2. ビジネスコストの削減のため→サーバー負荷解消 3. 開発の効率化・中長期の開発体制のため 　→効率的な開発フロー 4. 安全なウェブサービスの運用のため 　→見通しのよいコードベース