【勉強会メモ】FRONTEND CONFERENCE 2018
毎年恒例のフロントエンド製作者向けイベントに行ってきました。近年、Webブラウザの進化に伴いフロントエンド技術のカバーする範囲はどんどん拡大しています。PWAやWASMのような他の技術領域にも踏み込んだ技術の話、大規模スクラムの事例などからもその状況をうかがい知ることができ、フロントエンド技術の拡大を改めて実感することができました。最後のセッションで後藤さんが次のように仰っていました。
バックエンド経験の上にフロントを積むのではなく、ニューゲーム感覚で、新しい気持ちで挑めば
分業を前提としたフロントエンドとバックエンドというコンテキストはもはや手法の1つでしかなく、Webに携わる者としてはより良い技術選択をしていくための手法として向き合うべきだと感じました。
しっかりフロントエンドに向き合って強くてニューゲームをPlayしていかねばと思いました。 #frontkansai
— radiocat (@radiocatz) 2018年11月24日
WebMusicで何ができるか
okunokentaroさん
※途中から参加しました。
- グラフィカルに確認してコードに落とし込む
- MIDIならブラウザを超えて連携できる
CSSで扱う音声の概念
createMediaElementSource()
を使うことで<audio>
と連携- Selectors Level 4 擬似クラス
- Resource State Pseudos
:playing
,:paused
- Time-dimensional Pseudo-classes
:current
,:past
,:future
- Resource State Pseudos
Web Musicのこれから
- Web Audio APIによるゲームやWebXRにおけるBGMや効果音の表現WebRTCでの音声通信
- WebMIDI APIによる多彩な機器制御、遠隔操作、演奏の同期
- 関連サービスやサードパーティAPIでさらにおもしろくなる
Chrome Dev Summit Recap
宇都宮佑亮さん
Performance
- 今年のセッションの全体的なテーマ
- 去年はPWAが多かった
Perf Budgets
- Webサイトは重い
- Image,JSのロードに時間がかかっている
- 各環境に応じたBudgetを用意することを推奨
Split your bundle
- JSで何ができるかというとCode-Splitting
- 各ページで使えるものだけをロードさせる
- RollupやWebpackではDynamic ImportされるモジュールをCodeSplitしてくれる
- linkで
rel="preload"
すれば先行取得
ユニクロカナダのモバイル版サイトの事例
- 必要なものだけをbundleに入れる
- Preact(React.jsの軽量版)を使って成果を出している
Perf Budgetやスピードに関するツール
- PSIが新しくなりLighthouseが組み込まれた
- Web開発のベストプラクティスやAuditモニタリングを網羅的に行う
LighthouseがCIに組み込みやすくなった
bundlesize
画像・動画に関しても様々なベストプラクティス
- Imagemin
- Lazy Load Images
- AV1
Native Lazy Loading
宣言的にLazyloadする・しないなどが選択可能
実際問題やるべきことはたくさん
- 最近のマルチコア環境でシングルスレッドでは恩恵を受けられない
- Workerをどのように活用できるかを考える
- Paint Workletを利用したOff main Thread
WebAssembly Threads
- WASMも複数Workerで効率的にメモリを共有するThreadsのOriginTrialを開始
Workbox
- Service WorkerはWorkbox
- workbox streamsを利用することでそれぞれを同時並行でストリーミング
squoosh.app
- 画像をWebで使ううえでのベストプラクティスをプロダクト
未来の話
- アーリーステージの機能
Feature Policy
- Webサイトにポリシーをつける
- レポーティングのみに切り替えることも可能
Layered API
- ハイレベルなAPI
- スクロールでもNativeではスクロールAPIが用意されている
- WebはFWがライブラリやコンポーネントを提供しているがそのぶん重くなる
- ブラウザが標準でハイレベルなAPIを提供する
<virtual-scroll>
Web Packaging
- Webのリソースを文字通りパッケージングする
- Signed Exchange
- 署名
- Bundled Exchage
- 集合
- AMPのドキュメント
- 署名済のドキュメントは取得元に関係なく署名もとのオリジンのものとして表示
- Webで画面遷移が遅い
- Portalを使うと早くなる
※Chrome Dev Summitの参考情報
10名超えのスクラムでフロントエンド開発する現場の声
上原晃人さん
10名以上の場合はコミュニケーションコストが増えるためチームを分割する
3社合同チーム
- PO:2
- SM:1
- サーバサイド:6 -フロント:12
- デザイナー:4
- テストエンジニア:4〜
開発しているものは 2つのECサイト
開発の流れ
- 案件発生
- POからの依頼
- 主担当を決める
- 仕様検討
- デザイナー
- 画面遷移、UI、文言
- フロントエンドエンジニア
- データの取得方法やUIの実現性検討
- 相互に相談して実現性を検討する
- デザイナー
- デザインレビュー
- メインデザイナーが検討したデザインをチーム全員でレビュー
- チームのメンバーが共通認識を持てる
- 実装・テスト設計
- 細かい単位でタスクを作ってエンジニアが分担して進める
- GitlabのMRでレビュー
- テスト設計
- テストエンジニアから各エンジニアに質問して設計
- テスト実行
- デバッグ・保留検討
- 開発してみたがリリースを保留することもある
- リリース
プロジェクトの流れ
- 実際は複数の案件が並行で走る
- タイムボックスにわけて管理
- 案件別にチームがフレキシブルに生まれる
- 管理に使うツール
- Jira,Confluence,Sketch
スクラムイベント
- ふりかえり
- KPTでふりかえり、改善実施
課題
- 意味が広すぎるタスク
- 何をしたらいいかよくわからない
- タスクには明確な完了条件を設定
- 開発完了済機能の確認
- 実装を確認する際に確認が難しい画面がある
- デバッグ機能を用意
- デイリースクラムの長期化
- 人数が増えるにあたり時間が長くなる
- 案件別の報告
それぞれに得意領域を持つフロントエンドエンジニア
- クリエイティブ寄り
- デザインの糸を理解してHTML/CSS/JSで組み上げられる
- エンジニアリング寄り
- アプリケーションとして最適に構築
社内の推奨技術・ツール
- Vue
- React
- Angular
- RIOT-Riotx
- jQuery
- プロトタイプなどをさっと作るときに便利
どんな人がフロントエンドエンジニア?
- 様々なバックボーン
- 3つの気質
- 楽したい
- Greasemonkyやブックマークレット
- 便利にしたい
- 社内環境もフロントエンド技術で便利にする
- すぐ試してみたい
- 新しいものが出てきたらとりあえず試してみる
- 楽したい
この気質で社内の業務効率化を解消するためにスマートシェアボードのプロトタイプを作った
業務システムでこそ使えるPWA
中津川篤司さん
PWAで必須ではない
- アプリ化
- プッシュ通知
- Chache API使用
必要なこと
- 導入しやすいものから徐々に
- 最良なものから取り入れる
- ユーザー体験向上
技術的なアプローチ
- レスポンシブWebデザイン/HTTPS
- ストレージ
- WebAuthn
- Service Worker
- マニュフェスト
ダイアログ・ヘル
- マニュフェストは必須ではない
- スマホにあふれるダイアログ・バナー
- 無意識に無視・拒否
- 現在はアドレスバーにアプリを知らせるアイコンが出る案を試している
- 気づきにくい
- ボタンを押してアプリをインストールしてもらうのは最優先ではない
速度改善
- 旅行中500M/日
- 切れると速度制限
- jQueryの読み込みでエラー
- よく使うファイルだけでもキャッシュすれば高速化できる
- いきなり100%ではなく10%改善から始める
B2B Web App
- 黎明期
- 利用技術
- Cordovaの利用
- アプリ化することで審査が発生
- JavaScript部分では落ちないがプラグイン(ネイティブコード)部分で落ちることがある
- 速度が…(最近は改善)
- メリット
- 生産現場に
- ネットワークがあればどこでもアクセス
- デメリット
- OSの進化に追従できない
- 審査で落ちる
- アプリの更新が反映されない(アップデートしてくれない)
PWAの登場
- 審査なし
- 配布の手間なし
- アップデートの自動適用
- HTML5 APIで大抵の目的が果たせるようになってきた
- JavaScriptが高速化し実用化レベルになった
- メモリが大きくなってWebブラウザが落ちなくなった
- 遅くなっても落ちないので業務アプリにとって最適
業務システムのPWAメリット
- 利用者が限定される
- 定常的な利用が期待できる
- 高度なUIは求められない
- Webブラウザ上で確実に動作する
- オフライン化、表示の高速化
- 生産性向上
- 標準技術の採用による普遍性
- 5〜10年以上の保守・運用
- Web技術の採用
- 技術者のアサインがしやすい
Technology
ServiceWorker
- ワーカースレットで動作するのでバックグラウンド処理ができる
CACHE API
- SW内で動作するキャッシュシステム
- キャシュパターン workbox
Webプッシュ通知
IndexedDB
- Cookie
- localStorage
- IndexedDB
WebAssembly
- コードの暗号化
- キーの隠蔽化
- Webアプリケーションの高速化
- RustもいいけどGoがオススメ
WebAuthn
- ハードウェアキーを使った認証
- Krypton
マニュフェストファイル
- manifest.jsonでアプリ名やアイコンを設定
Tips
- キャッシュは注意
- 有効期限なし
- 強力なキャッシュ
- 消えなくなる
- Chrome for Androidでの設定
- Lighthouseの利用
- オフラインを再現
- Chrome Dev Tool
- デスクトップでも使う
- デスクトップアプリのように使える
- ネットワーク対応
- navigator.onLineで判定
- window.addEventListener 'online' 'offline'でイベント発火
PWAハンズオン資料
Rust+WebAssemblyで広がるWebの世界
尾上洋介さん
フリーランチの終焉
- フロントエンド開発への要求は高まる
- ハードウェア、JSエンジンの性能向上の恩恵を知らないうちに受けていた時代は終わるかも?
- フロントエンドエンジニアがJSプログラムの速度に負う責任が増す
- asm.jsを効果的につかえばこれまでWebでできなかった種類のアプリケーションが実現できる
- WebAssemblyによる進化に期待
- RustでWebの部品を作れる未来はそう遠くないかもしれない
- 1.0 has shipped in 4 majer browser engines
- バイナリーフォーマット言語
- 他言語からコンパイルして生成するのが一般的
- C/C++,Rust,Go,AssemblyScript
- 30以上の言語が取り組んでいる
- ネイティブ処理とWebのギャップを埋める
- メリット
- 高速
- 低レイヤーの操作
- 過去の資産活用
- デメリット
- 安全性
- 周辺ツールの不在
- 言語と一体化した周辺ツールが少ない
Rust
- 型安全
- TypeScriptよりも強力な型システム
- デフォルトで値が書き換えられない
- メタプログラミング
- パフォーマンス
- WebAssemblyをオフィシャルにサポート
WebAssemblyの出力
- wasm32-unknown-emscripten
- Emscriptenのライブラリを利用できる
- wasm32-unknown-unknown
- ランタイムなし
Setup
- rustupの導入
- rustup target add wasm32-unkonwn-unknown
ビルド
- cargo newでプロジェクト作成
- Cargo.tomlに設定ファイル
- create-type=["cdylib"] でC言語から呼び出せる種類
- cargo build
WebAssembly JS API
- .wasmフアイルを読み込んでWebAssembly.instantiateにわたす
- ArrayBufferを通じた低レイヤーな操作
- Number、TypedArrayを扱う関数のみ
wasm-bindgen
- RustオブジェクトとJSオブジェクトの相互変換レイヤーを定義して自動生成
- js-sys,web-sysによるJS、ブラウザAPIの操作
- webpackで予感時に読み込み可能
Introduction - The `wasm-bindgen` Guide
JSクラスの生成
- Rustの構造体、traitからJSクラスを生成
wasm-pack
- cargoへのtarget追加、ビルドの実行、npmパッケージの生成、配布までを自動化
Drawing Mandelbrot Set with Rust and WebAssembly
WwebAssemblyの今後
- Post MVP Features
- ツールのサポートの充実
Webのパフォーマンスを追求する意味
- コンピューターの性能向上&理論の発展
- よりパフォーマンス要求のきついものがWASM
- パフォーマンス追求がWebの可能性を広げる
フロントエンドで作る理由
後藤知宏さん
フロントできない理由
- バックエンド脳
- SPA案件がない
- まだ時期じゃない
まだ時期じゃない?
- フロントエンドはどんどん簡単になっている
- バックエンドでもできるから…は言い訳にならない
Vue.js
- HTML/JSベースでシンプルに導入可能
- とっつきやすさ、学びやすさは最高レベル
- 極論、JSできなくてもVue.jsできる
Nuxt.js
- SPA構築がここまで簡単になった
- Vue.jsの使いやすさはそのまま
vue-cli
- コマンドで簡単にプロジェクトの初期セットアップが可能
- 複雑なWebpack設定を自動で構築
Hosting
SPAはより身近に簡単に
- 数年前と比べるとフロント制作の地盤は大きく安定
技術選定の基準
- 実務で使える(安定性)
- みんなが使える(学習コスト)
- 効率化できる(メリット)
わかりやすさは正義
- 安定性と学習コストをクリアしたうえでどういうメリットを考えるかが重要
Why SPA?
SPA制作 - フロント設計
- ページ遷移が容易になる
- 適切なナビゲーションを添えてシンプルな画面デザインに
- E2Eは最初から無理に頑張らなくていい
- SPAにはSPAの作り方、慣れの問題
SPA制作 - API設計
- 無理に抽象化的なAPIを作成する必要はない
- APIの受け入れテストは簡単につくれる
- バックエンドをAPI化することで品質を担保
- 守りたいデータ資産の安全性がフロントと分離
- より挑戦的なフロント改善を促進
変わる制作プロセス
- SPAにはSPAの作り方がある
これまでの制作フロー
- 大きな複数機能を一度に進めるのはとても大変
SPA時代の制作フロー
- 機能を分割してスケジュール化する
- 1機能ごとにリリース
- リリース=外部リリースとは限らない
SPAの案件は「作る」
- よりよい制作のためにSPA
怖くないフロントエンド
- バックエンドでもできるの概念を捨ててフロントでつくるとどうなる?への挑戦
- 作り方の変化を制作フロー全体に反映させていく
強くてニューゲーム
- バックエンド経験の上にフロントエンドを積み上げるのではない
- ニューゲーム感覚で新しい気持ちで挑む
- フロントに親しむ
- フロントを当たり前に
※参考情報