radioc@?

レディオキャットハテナ

【勉強会メモ】FRONTEND CONFERENCE 2018

2018.kfug.jp

毎年恒例のフロントエンド製作者向けイベントに行ってきました。近年、Webブラウザの進化に伴いフロントエンド技術のカバーする範囲はどんどん拡大しています。PWAやWASMのような他の技術領域にも踏み込んだ技術の話、大規模スクラムの事例などからもその状況をうかがい知ることができ、フロントエンド技術の拡大を改めて実感することができました。最後のセッションで後藤さんが次のように仰っていました。

バックエンド経験の上にフロントを積むのではなく、ニューゲーム感覚で、新しい気持ちで挑めば

分業を前提としたフロントエンドとバックエンドというコンテキストはもはや手法の1つでしかなく、Webに携わる者としてはより良い技術選択をしていくための手法として向き合うべきだと感じました。

WebMusicで何ができるか

okunokentaroさん

speakerdeck.com

※途中から参加しました。

WebAudioDesigner | g200kg

  • グラフィカルに確認してコードに落とし込む

Web MIDI APIとWeb Audio API

  • MIDIならブラウザを超えて連携できる

CSSで扱う音声の概念

  • createMediaElementSource() を使うことで <audio> と連携
  • Selectors Level 4 擬似クラス
    • Resource State Pseudos
      • :playing , :paused
    • Time-dimensional Pseudo-classes
      • :current , :past , :future

Web Musicのこれから

  • Web Audio APIによるゲームやWebXRにおけるBGMや効果音の表現WebRTCでの音声通信
  • WebMIDI APIによる多彩な機器制御、遠隔操作、演奏の同期
  • 関連サービスやサードパーティAPIでさらにおもしろくなる

Chrome Dev Summit Recap

宇都宮佑亮さん

Performance

  • 今年のセッションの全体的なテーマ
  • 去年はPWAが多かった

Perf Budgets

addyosmani.com

  • 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.dev BETA

  • Web開発のベストプラクティスやAuditモニタリングを網羅的に行う

LighthouseがCIに組み込みやすくなった

www.npmjs.com

bundlesize

github.com

画像・動画に関しても様々なベストプラクティス

  • Imagemin
  • Lazy Load Images
  • AV1

Native Lazy Loading

calibreapp.com

宣言的にLazyloadする・しないなどが選択可能

coliss.com

実際問題やるべきことはたくさん

  • 最近のマルチコア環境でシングルスレッドでは恩恵を受けられない
  • Workerをどのように活用できるかを考える

CSS Paint API

developers.google.com

  • Paint Workletを利用したOff main Thread

WebAssembly Threads

  • WASMも複数Workerで効率的にメモリを共有するThreadsのOriginTrialを開始

Workbox

  • Service WorkerはWorkbox

developers.google.com

  • workbox streamsを利用することでそれぞれを同時並行でストリーミング

squoosh.app

squoosh.app

  • 画像をWebで使ううえでのベストプラクティスをプロダクト

未来の話

  • アーリーステージの機能

Feature Policy

  • Webサイトにポリシーをつける
  • レポーティングのみに切り替えることも可能

Layered API

  • ハイレベルなAPI
  • スクロールでもNativeではスクロールAPIが用意されている
  • WebはFWがライブラリやコンポーネントを提供しているがそのぶん重くなる
  • ブラウザが標準でハイレベルなAPIを提供する
  • <virtual-scroll>

Web Packaging

  • Webのリソースを文字通りパッケージングする
  • Signed Exchange
    • 署名
  • Bundled Exchage
    • 集合
  • AMPのドキュメント
    • 署名済のドキュメントは取得元に関係なく署名もとのオリジンのものとして表示

asnokaze.hatenablog.com

Portal

  • Webで画面遷移が遅い
  • Portalを使うと早くなる

www.youtube.com

Chrome Dev Summitの参考情報

coliss.com

blog.asial.co.jp

10名超えのスクラムでフロントエンド開発する現場の声

上原晃人さん

speakerdeck.com

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つの気質
    • 楽したい
    • 便利にしたい
      • 社内環境もフロントエンド技術で便利にする
    • すぐ試してみたい
      • 新しいものが出てきたらとりあえず試してみる

この気質で社内の業務効率化を解消するためにスマートシェアボードのプロトタイプを作った

業務システムでこそ使えるPWA

中津川篤司さん

speakerdeck.com

Web業務システム用のHTML5フレームワーク

www.htmlhifive.com

  • MVC
  • jQuery/EJS
  • IE8など古いブラウザサポート
  • 慎重なアップデート(エンプラ系なので)

PWAで必須ではない

  • アプリ化
  • プッシュ通知
  • Chache API使用

必要なこと

  • 導入しやすいものから徐々に
  • 最良なものから取り入れる
  • ユーザー体験向上

技術的なアプローチ

  • レスポンシブWebデザイン/HTTPS
  • ストレージ
  • WebAuthn
  • Service Worker
  • マニュフェスト

ダイアログ・ヘル

  • マニュフェストは必須ではない
  • スマホにあふれるダイアログ・バナー
  • 無意識に無視・拒否
  • 現在はアドレスバーにアプリを知らせるアイコンが出る案を試している
    • 気づきにくい
  • ボタンを押してアプリをインストールしてもらうのは最優先ではない

速度改善

  • 旅行中500M/日
    • 切れると速度制限
    • jQueryの読み込みでエラー
    • よく使うファイルだけでもキャッシュすれば高速化できる
  • いきなり100%ではなく10%改善から始める

B2B Web App

  • 黎明期
    • iPad登場以降タブレット版業務アプリ増
    • プッシュ通知、位置情報、オフライン利用がメイン
  • 利用技術
    • Cordovaの利用
    • アプリ化することで審査が発生
    • JavaScript部分では落ちないがプラグイン(ネイティブコード)部分で落ちることがある
    • 速度が…(最近は改善)
  • メリット
    • 生産現場
    • ネットワークがあればどこでもアクセス
  • デメリット
    • OSの進化に追従できない
    • 審査で落ちる
    • アプリの更新が反映されない(アップデートしてくれない)

PWAの登場

  • 審査なし
  • 配布の手間なし
  • アップデートの自動適用
  • HTML5 APIで大抵の目的が果たせるようになってきた
  • JavaScriptが高速化し実用化レベルになった
  • メモリが大きくなってWebブラウザが落ちなくなった
    • 遅くなっても落ちないので業務アプリにとって最適

業務システムのPWAメリット

  • 利用者が限定される
  • 定常的な利用が期待できる
  • 高度なUIは求められない
  • Webブラウザ上で確実に動作する
  • オフライン化、表示の高速化
    • 生産性向上
  • 標準技術の採用による普遍性
    • 5〜10年以上の保守・運用
  • Web技術の採用

Technology

ServiceWorker

  • ワーカースレットで動作するのでバックグラウンド処理ができる

CACHE API

  • SW内で動作するキャッシュシステム
  • キャシュパターン workbox

Webプッシュ通知

  • VAPID
    • FCM不要
  • 独自
  • ブラウザごとに対応状況が違う

IndexedDB

  • Cookie
  • localStorage
  • IndexedDB

WebAssembly

  • コードの暗号化
  • キーの隠蔽化
  • Webアプリケーションの高速化
  • RustもいいけどGoがオススメ

WebAuthn

  • ハードウェアキーを使った認証
  • Krypton

マニュフェストファイル

  • manifest.jsonでアプリ名やアイコンを設定

Tips

  • キャッシュは注意
    • 有効期限なし
    • 強力なキャッシュ
    • 消えなくなる
  • Chrome for Androidでの設定
  • Lighthouseの利用
  • オフラインを再現
  • デスクトップでも使う
    • デスクトップアプリのように使える
  • ネットワーク対応
    • navigator.onLineで判定
    • window.addEventListener 'online' 'offline'でイベント発火

PWAハンズオン資料

github.com

Rust+WebAssemblyで広がるWebの世界

尾上洋介さん

speakerdeck.com

フリーランチの終焉

  • フロントエンド開発への要求は高まる
  • ハードウェア、JSエンジンの性能向上の恩恵を知らないうちに受けていた時代は終わるかも?
  • フロントエンドエンジニアがJSプログラムの速度に負う責任が増す
  • asm.jsを効果的につかえばこれまでWebでできなかった種類のアプリケーションが実現できる
  • WebAssemblyによる進化に期待
  • RustでWebの部品を作れる未来はそう遠くないかもしれない

WebAssembly

  • 1.0 has shipped in 4 majer browser engines
  • バイナリーフォーマット言語
  • 他言語からコンパイルして生成するのが一般的
    • C/C++,Rust,Go,AssemblyScript
    • 30以上の言語が取り組んでいる
  • ネイティブ処理とWebのギャップを埋める

Emscripten

  • C/C++からWASMへのコンパイラ
  • Mozillaが中心で開発
  • 実装例「
    • Cで関数を作る
    • emccコマンドでcのファイルを生成
    • requireでロード
    • wasm().then で受け取る

C/C++

  • メリット
    • 高速
    • 低レイヤーの操作
    • 過去の資産活用
  • デメリット
    • 安全性
    • 周辺ツールの不在
      • 言語と一体化した周辺ツールが少ない

Rust

  • 型安全
    • TypeScriptよりも強力な型システム
    • デフォルトで値が書き換えられない
  • メタプログラミング
  • パフォーマンス
  • WebAssemblyをオフィシャルにサポート

WebAssemblyの出力

  • wasm32-unknown-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パッケージの生成、配布までを自動化

Egraph Examples

Drawing Mandelbrot Set with Rust and WebAssembly

WwebAssemblyの今後

  • Post MVP Features
  • ツールのサポートの充実

www.youtube.com

Webのパフォーマンスを追求する意味

  • コンピューターの性能向上&理論の発展
  • よりパフォーマンス要求のきついものがWASM
  • パフォーマンス追求がWebの可能性を広げる

フロントエンドで作る理由

後藤知宏さん

speakerdeck.com

フロントできない理由

  • バックエンド脳
  • SPA案件がない
  • まだ時期じゃない

まだ時期じゃない?

  • フロントエンドはどんどん簡単になっている
  • バックエンドでもできるから…は言い訳にならない

Vue.js

  • HTML/JSベースでシンプルに導入可能
  • とっつきやすさ、学びやすさは最高レベル
  • 極論、JSできなくてもVue.jsできる

Nuxt.js

  • SPA構築がここまで簡単になった
  • Vue.jsの使いやすさはそのまま

vue-cli

  • コマンドで簡単にプロジェクトの初期セットアップが可能
  • 複雑なWebpack設定を自動で構築

Hosting

  • 静的ファイル構成のメリットの1つに高速なホスティングが利用できる
  • Firebase Hosting
  • NetlifyならGithub連携での自動デプロイも可能

SPAはより身近に簡単に

  • 数年前と比べるとフロント制作の地盤は大きく安定

技術選定の基準

  • 実務で使える(安定性)
  • みんなが使える(学習コスト)
  • 効率化できる(メリット)

わかりやすさは正義

  • 安定性と学習コストをクリアしたうえでどういうメリットを考えるかが重要

Why SPA?

SPA制作 - フロント設計

  • ページ遷移が容易になる
  • 適切なナビゲーションを添えてシンプルな画面デザインに
  • E2Eは最初から無理に頑張らなくていい
  • SPAにはSPAの作り方、慣れの問題

SPA制作 - API設計

  • 無理に抽象化的なAPIを作成する必要はない
  • APIの受け入れテストは簡単につくれる
  • バックエンドをAPI化することで品質を担保
  • 守りたいデータ資産の安全性がフロントと分離
  • より挑戦的なフロント改善を促進

変わる制作プロセス

  • SPAにはSPAの作り方がある

これまでの制作フロー

  • 大きな複数機能を一度に進めるのはとても大変

SPA時代の制作フロー

  • 機能を分割してスケジュール化する
  • 1機能ごとにリリース
  • リリース=外部リリースとは限らない

SPAの案件は「作る」

  • よりよい制作のためにSPA

怖くないフロントエンド

  • バックエンドでもできるの概念を捨ててフロントでつくるとどうなる?への挑戦
  • 作り方の変化を制作フロー全体に反映させていく

強くてニューゲーム

  • バックエンド経験の上にフロントエンドを積み上げるのではない
  • ニューゲーム感覚で新しい気持ちで挑む
  • フロントに親しむ
  • フロントを当たり前に

※参考情報

twitter.com

www.youtube.com