「【We Are JavaScripters! 3周年記念】 WeJS Festival !」に参加してきました

勉強会メモ
  • 【We Are JavaScripters! 3周年記念】 WeJS Festival !に参加してきました。

wajs.connpass.com

  • WeJSの3周年記念のイベントに参加してきました
  • 自分が初めてWeJSに参加したのも2017年7月に開催された9thなのでもう2年以上前です。勉強会に行き始めたころなので懐かしいものです。
発表枠 タイトル 発表者
初心者LT はじめてのユニバーサルJavaScript @りゅーそう
初心者LT A story about making a cli twitter client with typescript @azawakh
初心者LT styled-components の ` ←について @kimizuy
初心者LT 逆算して考える広告ライブラリ @ta__ho
初心者LT Node.js/serverlessでおこなうDX改善 @Ayami Otani
通常LT おさらいVue Composition API Morita_Masatoshi
通常LT Lighthouse CI入門 @yinm
通常LT Reactの歴史 @mqtsuo02
通常LT 執筆の進捗を支える技術〜Could RunでBot作ったらとても便利だった件〜 @kyasbal
通常LT angular歴3ヶ月がAngularと本気で向き合ってみた @EmiYaegashi
Demo LT PlayCanvasでできたこととデモ @sushucorn
Demo LT TensorFlow.jsとobnizで作る笑顔あふれる職場 @boiyama
Demo LT Ma_gician ＜Vue にはできないこと(2)＞ @StewEucen
Demo LT 今日から始めるWeb USB @takanorip
Demo LT Joy-ConをJavaScriptでプレゼンリモコンにした話 @mascii_k
Short Session Introduction to ReasonML @Naturalclar
Short Session JSXでつくる宣言的プレゼンテーション @mottox2
Short Session JSでの時間の使い方の話 @chikoski
Long Session Behind the scene @brn227
Long Session Babel plugin を作って AST と Babel を学ぶ(ライブコーディング) @mki_skt

Introduction to ReasonML

  • @Naturalclarさん

Reason

  • State of JS 2018
    • 半分は聞いたこと無い
    • 使ってる人の満足度は高い
  • Reactの作者Jordan Walkeが作っている
  • Ocamkを別のSyntaxで書いたもの
  • 強力な型
  • BuckleScript
    • JSにトランスパイルする
  • 特徴
    • JSのように書ける
    • React書ける人は馴染みやすい
  • 利点
    • ビルドが高速
      • 規模が大きくなっても数秒
    • バンドルサイズが小さい
      • 結果が自明なものはトランスパイル時に変換してくれる
    • Prettier完備
      • もともとはReasonのフォーマッターが優秀でそれをJSでも使えるように作ったのがPrettier
    • 型安全性
    • エラーメッセージがわかりやすい
  • gentype
    • tsxを生成したりできるライブラリ
    • 徐々に移行したいときはこれを使うといい
  • reason-react-native
  • reason-native

JSXでつくる宣言的プレゼンテーション

  • @mottox2さん

KOBIT

  • GoogleAnaryticsと連携するとPowerPointのレポートができるサービス
  • PowerPointはzipされたxmlの集合体
  • レポートなのでmarkdown to pptxでは表現できない

課題

  • コードから生成後の見た目が想像しづらい
    • JSXで宣言的に書く
  • 座標計算が大変
  • JSXからSketchを生成するReact Sketch.appを参考に

仕組み

  • react-test-renderer
    • JSXをObject化できる

github.com

JSでの時間の使い方の話

  • @chikoskiさん

JavaScriptの実行タイミング

  • どんな順番で呼ばれるの？
    • addEventListener
    • requestAnimationFrame
    • requestIdleCallback

EventQueue

  • タスクはキューにたまっていく
  • キューの中の処理でスタックがたまっていく
  • いろんな処理が全て同じキューに溜まっていく(メインスレッド)
  • Chromeのdevtoolsのperformanceでタスクキューを見れる

実行の順序

  • Dont yield
    • 普通のJSの処理
  • Microtask
    • awaitとか
  • requestAnimationFrame
  • Inter-frame
  • requestIdleCallback
    • CPUが暇な時に動く

Worker

  • 全部メインスレッドでやるのをやめようという話もある
  • UIスレッドをわける
  • Worker
    • EventQueueをもう1つ作る
    • 並列に実行される
    • コンストラクタの第2引数に{type: module}でESModulesも使えるようになる
    • postMessageはJSオブジェクトなら渡せる
      • コピーして渡される
        • 処理時間は無視できる程度
  • Comlink
    • postMessageを抽象化してくれる
  • SchedulingAPI
  • 無限ループを書きたい時
    • priorityを設定できるようになる仕組みも考えられている
    • それを使えばブロックしないようにできる

Behind the scene

  • @brn227さん

Scriptのクリティカルパス

  • HTMLをparse
  • リソースをfetch
  • V8が実行

Resource Fetch

Scriptタグの種類

  • ClassicScript
    • 普通のscriptタグ
  • ModuleScript
    • ESModleに対応したscriptタグ
    • import/exportを解決できる
  • Async
    • scriptタグの順番待ちが発生しないロードも実行も非同期
  • Defer
    • ロードは非同期だけど実行は順番を待つ

Connection

  • HTTP1.1だと同時接続数の上限がある
    • 大抵のブラウザは6まで
    • なので非同期で同時にたくさん取りに行っても上限を超えると待たされる
  • HTTP2だと1つのコネクションで複数のやりとりできるので解決される

Fetching

  • ブラウザキャッシュがあるかチェック
    • ETag
      • リソースに対して一意に発行されるハッシュ
      • Cache-ControlとETagを組み合わせてキャッシュを使うか決める
    • ServiceWorker
      • リクエストをインタラプトできる
      • ChacheStorageに入れておいてそれを返すことができる

最適化

  • Preload
    • link rel=preload
      • 事前にリソースをリロードさせておける
  • Compress response
    • gzipではなくBrotliを使うと更に圧縮率高められる
  • CDN
    • 地理的に近いところから取得
  • webpackプラグイン
    • Workbox
    • sw-precache
  • Code Splitting
    • 必要なものだけを取得できるように

Futuer

  • HTTP/3 Quic
    • Transport層を置き換える
  • Priority-hints
    • linkやscriptにimportance属性が追加される
    • highがついてれば優先的に取得する等
  • WebBundle/WebPackaging
    • Webのコンテンツを1つにパッケージングして配信
      • 画像でも動画でも全部
      • request/responseとか証明書とかも
      • Webサイトまるごとpackagingして配信して使える

Parsing

  • fetchしたscriptをASTに変換するフェーズ
  • parse処理は重い
    • ページする度に全部parseしてるとおもすぎる
    • 最初は関数と行数だけparseしておく
    • 呼び出されると関数の中身までparse
  • parseも全部メインスレッドで動いている
    • parseが始まった段階でHTMLの表示がとまる
    • deferとかasyncをつけると変わる

Streaming

  • Streamingで逐次取得しながらparseする

bundle size

  • 50-100KB目安に分割するとよい
    • モバイルとかも考えると
    • CPU/メモリ使用量がかかる

Transpile

  • 古いブラウザようのコードは新しいブラウザにとっては無駄なコード
  • ブラウザに応じて調整すると無駄なものを減らせる

JSON.parse

  • objectにこれをつけておくと遅延してparseされるのではやくなる

Polyfill

  • CoreJS全部入れちゃったりすると無駄が多すぎる
  • polyfill.ioを使って必要なものだけにするといい

Futuer

  • Binary AST
  • ASTで直接配信する
    • ブラウザごとに共通仕様ができればいける

Babel plugin を作って AST と Babel を学ぶ(ライブコーディング)

  • @mki_sktさん

AST

  • Abstract Syntax Tree
  • プログラムの構造を示したデータ
  • JSではJSON
  • 仕様はESTreeに準拠
  • AST Explorerを使うとJSのコードがどう変換されるか見られる

astexplorer.net

Babel

  • JSのコンパイラー
  • もともとは6to5だった
    • ES6 to ES5
  • そこからいろんな機能が追加されていった
  • 新しい構文で書いたJSを古いブラウザでも動かしたい時に使う

構文変換

  • TS/JSX/JSなど -> Babel -> JS
  • 変換のフェーズ
    • Parsing
    • Transformation
    • Code Generate
Parsing
  • @babel/parser
  • コードをparse関数に通すとJSONで出力される
  • acorn
    • 軽量なJS parser
    • webpackで使われてる
Code Generate
  • @babel/generate
  • ASTをJSに変換する
Transformation
  • @babel/traverse
  • constとletをvarに変えるといった変換を行う

ライブコーディング

github.com