Slide 1

Slide 1 text

髙橋伸弥

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

No content

Slide 6

Slide 6 text

No content

Slide 7

Slide 7 text

No content

Slide 8

Slide 8 text

No content

Slide 9

Slide 9 text

No content

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

No content

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

No content

Slide 21

Slide 21 text

No content

Slide 22

Slide 22 text

No content

Slide 23

Slide 23 text

No content

Slide 24

Slide 24 text

1. ユーザー体験のため

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

No content

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

そこで

Slide 43

Slide 43 text

No content

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

No content

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

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

Slide 48

Slide 48 text

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

Slide 49

Slide 49 text

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

Slide 50

Slide 50 text

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

Slide 51

Slide 51 text

No content

Slide 52

Slide 52 text

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

Slide 53

Slide 53 text

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

Slide 54

Slide 54 text

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

Slide 55

Slide 55 text

No content

Slide 56

Slide 56 text

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

Slide 57

Slide 57 text

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

Slide 58

Slide 58 text

🇵

Slide 59

Slide 59 text

🇸 🇳

Slide 60

Slide 60 text

No content

Slide 61

Slide 61 text

🇵

Slide 62

Slide 62 text

No content

Slide 63

Slide 63 text

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

Slide 64

Slide 64 text

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

Slide 65

Slide 65 text

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

Slide 66

Slide 66 text

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

Slide 67

Slide 67 text

No content

Slide 68

Slide 68 text

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

Slide 69

Slide 69 text

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

Slide 70

Slide 70 text

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

Slide 71

Slide 71 text

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

Slide 72

Slide 72 text

No content

Slide 73

Slide 73 text

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

Slide 74

Slide 74 text

No content

Slide 75

Slide 75 text

No content

Slide 76

Slide 76 text

No content

Slide 77

Slide 77 text

No content

Slide 78

Slide 78 text

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

Slide 79

Slide 79 text

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

Slide 80

Slide 80 text

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

Slide 81

Slide 81 text

No content

Slide 82

Slide 82 text

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

Slide 83

Slide 83 text

No content

Slide 84

Slide 84 text

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

Slide 85

Slide 85 text

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

Slide 86

Slide 86 text

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

Slide 87

Slide 87 text

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

Slide 88

Slide 88 text

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

Slide 89

Slide 89 text

No content

Slide 90

Slide 90 text

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

Slide 91

Slide 91 text

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

Slide 92

Slide 92 text

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

Slide 93

Slide 93 text

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

Slide 94

Slide 94 text

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

Slide 95

Slide 95 text

No content

Slide 96

Slide 96 text

No content

Slide 97

Slide 97 text

No content