Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

DeNA_Tech
March 03, 2021

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

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

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

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

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

DeNA_Tech

March 03, 2021
Tweet

More Decks by DeNA_Tech

Other Decks in Technology

Transcript

  1. 髙橋伸弥

    View full-size slide

  2. 髙橋伸弥
    ● デザイン本部マネージャー
    ● UX/UI デザイン、ソフトウェアエンジニアリング

    View full-size slide

  3. ● エンジニア出身の経営・企画・PM の方
    ● フロントエンド指向なエンジニアの方
    ● ウェブアプリの UX/UI の最適化や
    コストの削減に興味のある方
    ● ウェブアプリのテックリードの方
    (サーバーサイドエンジニア含む)

    View full-size slide

  4. ● Vue, React 以外のフレームワークも(意味的に)含みます
    ○ Angular, Gatsby, Next, Nuxt, Svelte, Flutter とかもね
    ● 一定端折ります
    ● 一定ポジショントークです

    View full-size slide

  5. 「UX/UI を突き詰めたサイトにしたいです。
     けど React とかでガチガチにされると
     手がつけられないのでやめて欲しいです」

    View full-size slide

  6. 「UX/UI を突き詰めたサイトにしたいです。
     けど React とかでガチガチにされると
     手がつけられないのでやめて欲しいです」
    「デザインを実装する人が欲しいです。画像を切り出して、
     HTML+CSS を組んでくれればいいです。
     (hoge文法の)
    テンプレ組み込みもね!」

    View full-size slide

  7. 「JavaScript の開発で手こずっているみたいなので、
     (サーバーフレームワークの)
    HTML テンプレートベースの開発
     フローにできないっすかね」

    View full-size slide

  8. 「JavaScript の開発で手こずっているみたいなので、
     (サーバーフレームワークの)
    HTML テンプレートベースの開発
     フローにできないっすかね」
    「jQuery でできませんか?
     Vue.js とか入れる必要ありますか?」

    View full-size slide

  9. ● UX/UI を妥協しないといけない
    ○ 今のフロントエンド技術が、事業オーナーの敬遠・誤解で使えない
    ○ 手触り感などは CSS+jQuery アニメーションなどでお茶を濁す程度
    ● プロダクトとしてイケてないものを
    作らせることになる懸念

    View full-size slide

  10. ● 作って納品・範囲が限定的でキャリアが伸びない
    ○ 短納期で事業理解も不要なことが多い
    ● 技術的な学びが少なくスキルが伸びない
    ○ 新しく技術的に学べることは
    フレームワークごとのテンプレ文法ぐらい
    ○ 画像切り出して HTML+CSS+jQuery
    ● 成長させにくい懸念

    View full-size slide

  11. ● サーバーサイドに任せっきりにしてしまうと、パフォー
    マンス・負荷軽減をフロントエンドで最適化できない
    ○ 中長期的なリスクを増やしてしまう恐れ
    ● プロダクト戦略全体としての懸念

    View full-size slide

  12. ● 中長期的にリファクタリングが難しくなる
    ○ 整頓されていない・されにくいコードのプロダクトを
    いずれまた誰かにスイッチさせないといけない
    ● 結果的にアサイン難易度が上がったり、
    組織的な弱体化につながる懸念

    View full-size slide

  13. ● 「世の中的に伸びているプロダクト」
    「よく使う」「イケてるウェブサイト」は
    簡単に作られていない
    ○ 画面に表示されない諸々も大事
    ● いつまでもフロントエンドは簡単でいいという
    誤解が残り続ける懸念
    ○ 「簡単」を売り文句にしていたツケ?

    View full-size slide

  14. 1. ユーザー体験のため

    View full-size slide

  15. 1. ユーザー体験のため
    2. ビジネスコストの削減のため

    View full-size slide

  16. 1. ユーザー体験のため
    2. ビジネスコストの削減のため
    3. 開発の効率化・中長期の開発体制のため

    View full-size slide

  17. 1. ユーザー体験のため
    2. ビジネスコストの削減のため
    3. 開発の効率化・中長期の開発体制のため
    4. 安全なウェブサービスの運用のため

    View full-size slide

  18. 突然変異による進化でフロントエンドの声が
    大きくなっているというのではなく、
    連続的な進化の果てに今のフロントエンド開発がある
    ウェブサイトの歴史をおさらいしてみましょう

    View full-size slide

  19. 静的なコンテンツを配信するウェブサーバーのみ

    View full-size slide

  20. 動的な機能のためサーバーで HTML を生成するプログラムを
    動かす
    昇順 検索

    View full-size slide

  21. 色々なプログラムを実行したり...
    昇順 画像生成
    検索

    View full-size slide

  22. サーバー間での通信を行ったり...
    昇順
    いいね 画像生成
    検索 遷移

    View full-size slide

  23. サーバー間での通信を行ったり...
    昇順
    いいね 画像生成
    検索 遷移 フォロー
    無限スクロール
    ロード

    View full-size slide

  24. ブラウザの JavaScript エンジンが高速化され
    動的処理をブラウザに任せられるようになってきた
    ①一旦 JavaScript を含む静的なデータを受け渡し ②ブラウザで JavaScript を実行させて動的な
    データをやりとりする・処理を行う
    昇順
    画像生成
    検索
    遷移
    いいね
    フォロー
    無限スクロール
    ロード

    View full-size slide

  25. ● 負荷がかかる処理をサーバーで実行しなくて
    良くなる
    ○ チリツモになる HTML レンダリング、ルーティング、
    ファイル処理...
    ○ アクセス集中によるスパイクを回避できる

    View full-size slide

  26. ● 負荷がかかる処理をサーバーで実行しなくて
    良くなる
    ○ チリツモになる HTML レンダリング、ルーティング、
    ファイル処理...
    ○ アクセス集中によるスパイクを回避できる
    ● サーバーのインスタンスサイズを過剰にでか
    くしなくてもよくなる

    View full-size slide

  27. ● 負荷がかかる処理をサーバーで実行しなくて
    良くなる
    ○ チリツモになる HTML レンダリング、ルーティング、
    ファイル処理...
    ○ アクセス集中によるスパイクを回避できる
    ● サーバーのインスタンスサイズを過剰にでか
    くしなくてもよくなる

    View full-size slide

  28. ● jQuery または素の JavaScript で HTML を
    動的に組換えないといけない
    ○ 複数の API からグローバルにデータを保管し、状態を算
    出し、その分岐処理・フィードバックを行う

    View full-size slide

  29. ● jQuery または素の JavaScript で HTML を
    動的に組換えないといけない
    ○ 複数の API からグローバルにデータを保管し、状態を算
    出し、その分岐処理・フィードバックを行う
    ● 機能やデータの追加はどれがなにか調査から
    ○ ドキュメント整理しておくか、サーバーのレンダリング
    関数やモデルクラスを読み解く必要がある

    View full-size slide

  30. ● jQuery または素の JavaScript で HTML を
    動的に組換えないといけない
    ○ 複数の API からグローバルにデータを保管し、状態を算
    出し、その分岐処理・フィードバックを行う
    ● 機能やデータの追加はどれがなにか調査から
    ○ ドキュメント整理しておくか、サーバーのレンダリング
    関数やモデルクラスを読み解く必要がある

    View full-size slide

  31. フロントエンドに秩序をもたらすもの
    結果「サービスの全体的な最適化」を
    しやすくしてくれる

    View full-size slide

  32. 1. 導入・学習のスロープが存在する

    View full-size slide

  33. 1. 導入・学習のスロープが存在する
    2. 世界的に流行し、デファクト化してきている

    View full-size slide

  34. 1. 導入・学習のスロープが存在する
    2. 世界的に流行し、デファクト化してきている
    3. 仮想 DOM で UX/UI が最適化される

    View full-size slide

  35. 1. 導入・学習のスロープが存在する
    2. 世界的に流行し、デファクト化してきている
    3. 仮想 DOM で UX/UI が最適化される
    4. コンポーネント指向型で開発効率がよい

    View full-size slide

  36. 1. 導入・学習のスロープが存在する
    2. 世界的に流行し、デファクト化してきている
    3. 仮想 DOM で UX/UI が最適化される
    4. コンポーネント指向型で開発効率がよい
    5. 安全にウェブアプリを開発するための
    TypeScript サポートも充実している

    View full-size slide

  37. ● 一枚板のフレームワークと異なり、
    少しずつ導入していけるように設計されている
    ○ 最初は View 層のみに適用し、違う層(Routing や、Store など)にも適
    用したり、ウェブアプリの大枠をこれでまかなう、という発想ができる

    View full-size slide

  38. 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, ...

    View full-size slide

  39. ● 学習が完了したら少しずつ導入してみよう
    ● jQuery・JavaScript ベースのプロジェクトだと
    全て一から自分でこれらを作らないといけない
    ● npm (Node Package Modules) のエコシステムの恩恵を得て
    その仕事で一番大事なことに集中しよう
    ● Vue, React にはいろんな人が考えて、試験して、
    良くしてきたしっかりとしたライブラリがある

    View full-size slide

  40. Vue:
    2013年7月29日
    レポジトリ作成
    React:
    2013年5月25日
    レポジトリ作成

    View full-size slide

  41. GitHub 累計スター数
    全レポジトリ中
    Vue 3 位・React 5 位
    Flutter 110K
    Angular 69.3K
    jQuery 54.4K...

    View full-size slide

  42. HTML は DOM (Document Object Model)
    というツリー

    View full-size slide

  43. HTML パース→
    DOM ツリー構築→
    ウェブページレンダリング
    ウェブページを遷移するたび
    に上のフローを踏まないとい
    けない

    View full-size slide

  44. JavaScript データモデルとし
    てメモリ上にパース済みの
    DOM を保持
    画面差分のみを更新するなど
    表示高速化が実現できる

    View full-size slide

  45. ● グラフやデータ表示などに効果大
    ○ 「フィルター」「検索」「ソート」などデータを
    切り替える機能でいちいち画面を全更新しなくてよい
    ● ウェブページの遷移が高速化
    ○ 画面離脱率を低下、より見せたいものを見せられるように

    View full-size slide

  46. プログラムを部品ごとに分割
    Vue, React 構造は違うがど
    ちらも部品単位で作って合体
    してアプリにするという考え

    View full-size slide

  47. コンポーネント単位で HTML + スクリ
    プト + スタイルをひとまとめにした
    「Single File Component」を組み合わ
    せる

    View full-size slide

  48. Javascript の中で部品を組み立てていく
    この時の HTML を JSX と呼ぶ
    スタイルの当て方は比較的色々なやり方が
    ある

    View full-size slide

  49. ● ライブラリで一定書き方が定められている
    ● コンポーネントを単位としたプログラムになる
    ○ コードの一貫性・保守性を保つことができる
    ■ 見通しがよく・変更しやすく・不要になった際は捨てやすい
    ○ デザイン的な一貫性も保てる

    View full-size slide

  50. ● 静的型付けが可能な JavaScript の代替言語
    ○ 型付けられたら良いけど付けないのも可
    ○ 型推論もあるよ
    ● JavaScript の上位互換
    (と言ってもいいのではと思っています)

    View full-size slide

  51. コードヒントが出せるので、型定義すれば
    オリジナル API もドキュメント不要にできる!
    string に使えるプロパティ・メソッドが
    ずらっと表示。タイピングも短縮。

    View full-size slide

  52. ビルド時やコーディング中に型チェックで
    予期しない値が入らないようガードしてくれる!
    「string 型を渡さないといけないところに
     number を渡してますよ」

    View full-size slide

  53. ● 開発効率を高められる
    ● バグの早期発見/防止を実現できる
    ○ tsconfig.json ファイルのオプションで、型必須にすることもできる
    ● React、Vue も TypeScript を活用できるように
    サポートが充実している

    View full-size slide

  54. ● DeNA では 5:5 ぐらいで使われている
    ● HTML + CSS + JavaScript で従来と近い形で
    SPA に構築したいなら Vue
    ● JavaScript でプログラマブルに
    SPA を構築したいなら React

    View full-size slide

  55. https://www.npmtren
    ds.com/react-vs-vue-
    vs-jquery-vs-@angul
    ar/core

    View full-size slide

  56. 必要な機能はそれぞれの陣営で
    開発されていてどちらを使って
    も大丈夫
    国やライブラリによって活発度
    合いが若干違うので総合的に判
    断してみるとよい

    View full-size slide

  57. 1. 中長期に運用されて、多くの動的な
    情報が蓄積・表示切り替えされるサ
    イト
    2. UX にこだわりたいサイト
    3. SaaS や管理画面のようなビジネス活
    用サイト
    4. 画面を多く遷移する EC や SNS ほか
    高機能なウェブサービスのサイト

    View full-size slide

  58. というか入れる必要がないと思うサイト
    1. キャンペーン・イベント告知等の
    短命なサイト
    ※TechConサイトのような複数画面を用意する SPA は除く
    2. 画像を並べるだけのサイト
    3. マーケティング LP のような量産
    広告型(訴求内容を多く変えて)の
    ウェブページ

    View full-size slide

  59. ● 技術的投資のリターンが一定見込めるかどうか
    ○ 向いていないサイト・チームかどうかちゃんと見極める
    ● チームサイズやプロダクトに合わせた設計を
    ○ 小規模なサイト・ジュニアなチームにも過剰なチェック機
    構(型・lint・e2e)必須のワークフローにしないように
    ○ 無理なルールを導入せず良きバランスのところを探ろう
    ● 高速にチームが改善できる範囲で少しづつ導入
    ○ エンジニアなら強くないといけない ×
    チーム開発でのスループットを見極めて導入 ○

    View full-size slide

  60. 1. ユーザー体験のため
    2. ビジネスコストの削減のため
    3. 開発の効率化・中長期の開発体制のため
     
    4. 安全なウェブサービスの運用のため
     

    View full-size slide

  61. 1. ユーザー体験のため→表示速度やUIを改善可能
    2. ビジネスコストの削減のため
    3. 開発の効率化・中長期の開発体制のため
     
    4. 安全なウェブサービスの運用のため
     

    View full-size slide

  62. 1. ユーザー体験のため→表示速度やUIを改善可能
    2. ビジネスコストの削減のため→サーバー負荷解消
    3. 開発の効率化・中長期の開発体制のため
     
    4. 安全なウェブサービスの運用のため
     

    View full-size slide

  63. 1. ユーザー体験のため→表示速度やUIを改善可能
    2. ビジネスコストの削減のため→サーバー負荷解消
    3. 開発の効率化・中長期の開発体制のため
     →効率的な開発フロー
    4. 安全なウェブサービスの運用のため
     

    View full-size slide

  64. 1. ユーザー体験のため→表示速度やUIを改善可能
    2. ビジネスコストの削減のため→サーバー負荷解消
    3. 開発の効率化・中長期の開発体制のため
     →効率的な開発フロー
    4. 安全なウェブサービスの運用のため
     →見通しのよいコードベース

    View full-size slide