「MANABIYA」に参加してきました

MANABIYA

The Angular World

Angularの紹介

  • フロントエンドのフレームワーク
  • 統合された開発プラットフォーム
  • 開発者のエコシステム

フロントエンドのフレームワーク

  • CoreとFeaturesに分かれてる
  • npmパッケージは細かくわかれてる
  • 実行環境はブラウザでもnode上でも
フルスタックのよさ
  • 同じ知識の共有
  • 公式で全てテストしてくれる
  • VUP遅れることもない

統合された開発プラットフォーム

  • 開発者を支援する仕組みも含めて
開発者ツール
  • Angular Language Service
    • tsのLanguage Serviceを活用
    • 入力補完が強力になる
  • Angular CLI
    • プロジェクト生成
    • テスト/ビルド/起動
    • webpackなんかを隠蔽してくれている
      • パフォーマンスチューニングしてくれてる
  • codelyzer
    • tslintの拡張
    • Angularならではの部分もチェックしてくれる
  • Stackblitz
    • Angular公式が協力して作ってる
    • コードの実行環境
    • ブラウザで開発できる
Angular for Mobile
  • PWA
    • Angular CLIで対応済みプロジェクト作れる
  • Ionic
    • ネイティブ用のコンポーネントが提供されている
    • ネイティブのUIに近い見た目を作れる
  • NativeScript
その他
  • Angular Material
  • Component Dev Kit
  • Angular Elements

開発者のエコシステム

  • 世界中でAngularは使われてる
  • バージョン
    • メジャーバージョンは半年ごと
    • マイナーバージョンは毎月
    • パッチバージョンは毎週
  • リリース前にかならずGoogle社内で使ってる
  • LTS(1年間)
    • V4, V6
  • AngularとAngularJS
    • Angularの方が多数はになってる
    • AngularJSは2018/7からLTS2021/6で終了
  • Google社内のAngularJSアプリは25%Angularにマイグレーション
  • who-use-angular-in-japan
    • 24社掲載

Angular Roadmap

  • Angular Labs
    • 実験的機能が入ってる

Angular Elements

  • WebComponents対応
  • 実装がAngularで出力はWebComponents
  • 小さいAngularアプリって感じ
    • 例えばdatepickerとか

ngivy

  • 目指す所
    • Faster
    • Smaller
    • Simpler
  • HelloWorldが3kbでできる
  • V6ではオプショナル

Angular Buildtools Convergence

  • ビルド時のツールチェーンをGoogle社内のものと同じようにしようというもの

Angular Real World

2018年のWeb標準

2018年のWeb標準

  • ServiceWorker
  • WebComponents
  • WebPayments

ServiceWorker

  • キャッシュがあってもオフラインでは取得できなかった
  • ServiceWorkerがインストールされてればバイパスできる
  • オンラインへの復旧を検知できる
  • プッシュデータの受信

まとめ

  • 機能が強力
    • しかも現状に後から追加できる
  • ブラウザサポートも大きく好転

WebComponents

機能が強力

  • CustomElemetns
    • 自分で作ったClassがHTMLタグとして使えるようになる
  • ShadowDOM
    • DOM要素の下にShadowDOMというスコープの閉じた要素を作り出す機能
  • ES Modules
    • ESのimport/export

JSFWとの比較

  • ビルドフェーズの単純化
  • 仮想DOMはないからそこは劣る
    • lit-htmlで仮想DOM的な差分描画できる

まとめ

WebPayments

  • PaymentRequestAPI
    • 共通的なブラウザUIを提供
  • クレジットカードの脆弱性
    • リスクが大きい
  • PCI DSS
    • クレジットカード情報を扱う場合に守らないといけない基準
  • カード情報を扱わないために
    • 決済部分だけ代行業者のページへ

WebPaymentsのコンセプト

  • カード情報をやりとりしなければいいのでは
  • PaymentRequestAPI
    • PaymentAppを使いやすくするもの
  • chromeとedgeすでに使える

まとめ

  • 決済機能あるなら使うべき
  • UIも統一される
  • クレカ番号毎回入れるのもうやめる

Vue.jsの今後と次世代のWeb開発に向けて

2017年のVue

  • github star フロントエンド部門1位(2年連続)
  • VueConf2017開催(ポーランド)
  • storybookのVue対応
  • Nuxtv1.0リリース
  • NativeScriptのVueサポート

コアチーム体制による開発状況

Style Guide

  • 公式にスタイルガイドがある
    • betaリリース済
    • 日本語も

Cookbook

  • よくある落とし穴の対処
    • 最近betaリリース
    • 日本語はまだ
  • レシピが順次追加されてる

eslint-plugin-vue

  • 公式のeslintプラグイン
  • v4.0リリース済
  • スタイルガイドの対応中

Vue Test Utils

  • 公式のunitテストライブラリ
  • 1.0にむけて最終作業中

vue compoonent compiler

Vue CLI

  • v3.6

Core

  • 今v2.5
  • 2.6に向けてと3.0に向けてにブランチ分かれてく
  • 3.0はes2015動くブラウザのみが対応になる
    • IEはおとされる
  • クラスベースのAPI
    • ES側の対応が進んだら(class fieldとか)

次世代の開発に向けて

  • Vue CLIによってすぐに雛形ができる
  • 課題
    • 機能が雛形作るのみ
    • 質問事項多すぎ
  • 3.0でスクラッチで作り直し
    • .vuercに質問事項保存
    • webpack/babel/eslintの設定を隠蔽してくれるようになる
    • vue.config.jsで設定カスタマイズ
    • WebComponentsのビルドサポート
    • GUI版も開発中
  • Vue Dev Tool
    • ブラウザ拡張だけではなくelectron版も作ってる

Vueの思想

  • Simple Made Easy

Web Application 2018 From Performance Perspective

歴史

  • 200x年
    • good old web
  • 201x年
    • SPA
  • 2017

200x年

  • High Performance Web Sites
    • ユーザはフロントエンドで80~90%待機している
  • ページ遷移での処理がメイン
    • 毎回ページを描画しつつブラウザの機能を多用

パフォーマンス

  • リクエストしてからレスポンス返ってくるまで

パフォーマンスのためにやること

  • リクエスト回数改善
    • そもそもリクエストしない
    • CSS sprite
    • Cache Controle
    • CSSのインライン展開
  • レスポンス時間の改善
  • レスポンスするバイト数の改善
    • 画像のサイズ
    • minify/gzip

2010~2016年

  • High Performance Browser Networking
    • サーバ中心からブラウザへ移る
    • レイテンシを良くしろ
  • ネットワークレイヤでの最適化
    • HTTP2
    • Ajax/SPA
    • Partial Rendering
  • SPAを基本としてGUIアプリとしての側面が強くなった

パフォーマンス

  • Lighthouse
    • ベストプラクティスに則ってるか点数化してくれる
  • Real User Monitoring
    • 実際のユーザ体験を数値化
  • よりリアルなユーザを対象に
  • アプリ全体の時間を考慮するようになった

パフォーマンスのためにやること

  • 初回アクセスだけでなくその後の操作も最適化
  • レイテンシ削る
    • 1つのHTTP接続を無駄にしない
      • 毎回接続はコスト高い
  • HTTP2
    • 多重化されたリクエストを送る
    • 帯域幅が増えてもレイテンシが上がらないと高速化しない
  • HTTP1.1では
    • 同時接続6本まで
    • 7本目は待たされる
    • Head of Line Blocking
  • https://github.com/yosuke-furukawa/early-hints-demo

2016年~2018年

  • 超速本
  • 7 principles of Rich Web Applications
  • よりGUIアプリケーションとしてユーザ体験を向上させる進化
  • JSのサイズがでかくなってきてる
    • 80kbくらいだったのが450kb

パフォーマンスのためにやること

  • SSR
    • JS全部ダウンロードしないと画面が見えない
      • だからサーバ側でもページを作る
    • クライアントとサーバで同じロジックが動く
    • 初期表示時間を改善しつつSPAのよさ活かす
  • CSRだと
    • First Contentful Paintが長い(Loadingの時間)
    • First Meaningful Paintまでの待ちが長い
    • SSRするとこのまちをなくせる

2018年~

  • ユーザアクションが起きる前に動きを予測して投機的実行
    • レイテンシの壁を超える
    • オンマウスでprefetch
    • スクロールの動きをもとにprefetch
    • 機械学習
  • CDNをもっとアクティブに
    • Cloudinary
      • 画像の配信に特化したCDN兼画像変換
    • Fastly/netlify
      • Instant CacePurge
      • キャッシュの更新とかが簡単に
      • 動的なhtmlをキャッシュさせる
      • 経路の最適化

まとめ

  • パフォーマンスは文化である
    • パフォーマンス警察を育てよう
  • Webの動きを予想
    • Webの仕様を追う

Web Cross Session

Full SPA vs Partial SPA

  • 部分的なSPAをVueで
  • Vue + NuxtでSSR + SPA

SPA作ってて困ったこと

  • ServiceWorkerのキャッシュのパージ
    • ServiceWorker更新されたことのイベントは来る
    • ブラウザで画面リロード促してほしい
  • ブラウザデフォルトで動いてくれてることがSPAで変な動きしてしまうとよくない
    • 戻るでのスクロール位置とか
    • 状態の保持とか
  • Angularはでかいものをどんと作るにはいい
  • 小さいものはWebComponentsで作ってる

フロントエンドに疲弊してるか

今後のWeb標準で期待したいこと

  • WebAssembly
    • ポータビリティが上がってほしい
    • Web以外でネイティブでも動いてくれたりとか
  • template-instantiation
  • DOM changelist
    • DOM変更のリストをバッチにして渡せる
    • 仮想DOMのdiff patchの出力
  • ブラウザにもっと頑張って欲しい
  • 仮想DOMがやってることをWeb標準でやってほしい
  • async-dom

今後

  • Angular
    • SPAとしては完成している
    • いかに小さくはやく
    • SPAじゃない文脈でユースケースを増やす
  • Vue
    • Webの複雑なものを簡単に作れるようにする仕組み
  • Web標準
    • ServiceWorker
    • WebComponents
    • WebPayments