- JSConf JPに参加してきました。
- 1日目の参加メモです
タイムテーブル
| 時間 | タイトル | 発表者 |
|---|---|---|
| 13:00- | Opening talk | yosuke furukawa |
| 13:30- | The State of JavaScript | Raphaël Benitte and Sacha Greif |
| 14:15- | 「繋がり」の可視化 | Nadieh Bremer |
| WebAuthnで実現する安全・快適なログイン | Eiji Kitamura / えーじ | |
| JavaScript AST プログラミング: 入門とその1歩先へ | Takuto Wada | |
| 14:45- | 「オープンソース」の定義 | Henry Zhu |
| 覚醒するアクセシビリティ | Lena Morita | |
| 4年分のプロシージャルなJS | Andy Hall | |
| 15:30- | Building and Deploying for the Modern Web with JAMstack | Guillermo Rauch |
| Wrap-up: High Performance JavaScript | Sho Miyamoto | |
| JS開発者のためのSEOテクニック | Martin Splitt | |
| 16:00- | Write What Not How | Jorge Bucaran |
| How to Boost Your Code with WebAssembly | FUJI Goro / @gfx | |
| Playing Pokémon Together with Node.js | Samuel Agnew | |
| 16:45- | Deno - JavaScript の新たな道筋 | Kitson Kelly |
| Streams APIをちゃんと理解する | 加藤 健志 | |
| You might also like... | Maria Clara | |
| 17:15- | Headers for Hackers | Andrew Betts |
| Make it Declarative with React | Toru Kobayashi | |
| Web Accessibilityのすゝめ | Nazanin Delam | |
| 18:45- | 予測的 Prefetching によるパフォーマンス改善 | Praveen Yedidi |
| 18:55- | Web Components era phase 2 | Yoshiki Shibukawa |
| 19:05- | Cache Me If You Can | Maxi Ferreira |
| 19:15- | Node.js でつくる Node.js - WASM/WASI ミニミニコンパイラー | がねこまさし |
| 19:25- | React アプリのライセンス違反について | dynamis |
The State of JavaScript
- Raphaël Benitte
- Sacha Greif
JavaScriptの歴史
- 1995年JavaScript誕生
- 2006年jQuery誕生
ES2019
Array.flat()Object.formEntries()- Optional Catch Binding
フレームワーク
- React
- 使ってる人多いしそのほとんどがまた使いたいと言ってる
- Vue
- Reactよりは少ないけどのびてる
- Svelte
- 使ってる人は少ないけど学んでみたいという人は多い
- Gatsby
- 横ばい
- Next.js
- のびてる
- ホスティングサービスも充実してきている
- Netlify
- Now
- TypeScriptは60%くらいの人が使っている
WebAuthnで実現する安全・快適なログイン
- Eiji Kitamuraさん
パスワードの問題点
- Weak
- Forgotten
- Reused
- Stolen
パスワードどうやって盗まれるか
- フィッシング
- キーロガー
- Data breach
ハックされる確率
- キーロガーだと通常の40倍
- フィッシングだと500倍
- パスワード以外の情報もとられているケースが多いから
- 被害の80%がフィッシング
パスワードが盗まれないようにする対策
- 2段階認証
- ワンタイムパスワード
- SMS
- フィッシングには弱い
- 短時間有効なパスワードでもその場で送られたら意味がない
- そこでWebAuthn
WebAuthn
- これまでよりも強力なブラウザの認証
- EdgeもFFも対応
- Safariは部分的（でも時期に対応するだろう）
- ハードウェアの鍵を使う(Authenticator)
- 公開鍵暗号を活用した方式
- Authenticatorにキーペアを作らせる
- 公開鍵をサービスに送ってRegistrationする
- 秘密鍵で署名をしてそれをサービスに送る
- サービスは公開鍵で検証
- 同じハードウェアを持っている人であると証明できる
- 鍵はWebサイトのオリジンと紐付いて生成される
- フィッシングに強い
- たとえ盗んでも成功しない
二要素認証
- ハードウェアをもっているという認証 + 記憶による認証
- 多要素と多段階は違う
- 記憶、所持、生体といった要素を複数組み合わせるのが多要素認証
- セキュリティキー
- 署名をサーバに送って登録されているものと同一であることを確認する
- このサーバをFIDOサーバと呼ぶ
Authenticator
Roaming Authenticator
- Authenticatorの1つにセキュリティキーがある
- U2FかFIDO2に対応しているAuthenticatorであれば間違いない
- R持ち運びできるからoaming Authenticatorと呼ばれる
Platform Authenticator
再認証(Re-authentication)
- お金を払う手前とかで再度認証させるやつとか
- ログインしてる状態でもう一度認証を求めるやつ
- Pixel4の顔認証はまだ使えないけどChrome79から使える
参考
- https:/goo.gle/FIDO
- WebAuthnのコードラボもある
覚醒するアクセシビリティ
- Lena Moritaさん
アクセシビリティ
- 蔑ろにされることが多い
- 不便と思う人を低く見積もりすぎ
- 誰でも使えるようになることのよさを知らない
- 障害者/健常者という区別がよくない
- 環境や状況によって不便に感じることは誰でも起こりうる
Webにおけるアクセシビリティ
- Webは世界中どこからでもアクセスできる
- ブラウザの拡張などでカスタマイズできる
広義のアクセシビリティ
Wrap-up: High Performance JavaScript
- Sho Miyamotoさん
intro
Layers
- JavaScriptのレイヤー
- Product
- Runtime
- Node
- ブラウザ
- Electron
- Engine
- V8
- SpiderMonkey
- JavaScriptの実装
- サーバサイド
- クライアントサイド
RuntimeとEngine
- RuntimeとEngineどう違うか
Optimization
- 最適化
- Product-level
- memo化
- キャッシュ
- Runtime-level
- 非同期
- Engine-level
- インラインキャッシュ
- Product-level
- 効果
- Product > Runtime > Engine
- Micro Optimizationをするな
- 自分でやらなくてもエンジンがやってくれる
Optimization
Server Side runtime
- Node.js
- シングルスレッド
- 非同期ノンブロッキング
- V8が入ってる
- イベントループ
- 処理に時間のかかる動機処理があるとループをとめてしまう
- 非同期でできるものはそうした方がよい
- StreamAPI
- Fileの読み出しとかを効率的に行える
- Streamでないと情報を全てメモリにおいてそれを扱ってとなってしまって効率悪い
Client Side Runtime
- ブラウザでJSが動くまで
- fetch -> load -> parse -> compile -> execute
- できるだけCodeCachingを使う
- 次使う時にcompile済みになってるようにする
- 頻繁に使われるものはServiceWorkerでcacheするといい
- ESModules
- ブラウザ上でimport/export
- Preloading scripts
- 実行はしないけどparseとcompileをしておいてくれる
- idling
- Idle Until Urgent
- requestIdleCallbackを使うとCPUとかが暇な時に実行してくれる
Engine
- V8
- たくさん使われた処理ははやくとれるようにとか最適化してくれる
- Inline Cache
- Objectにどんな情報があるかを予め用意しておく？
- ヒットしたらはやい
How to Boost Your Code with WebAssembly
- FUJI Goroさん
WebAssemblyとは
WebAssembly前夜
- EmscriptenによってC/C++をJSにコンパイルすることができていた(2012)
- ただし動作が非常に遅い
- WebAssemblyに仕様議論開始(2015)
- ブラウザにMVPレベルのサポート完了(2017)
WebAssemblyの価値
- ブラウザにおいてはJSとできることは同じ
- JSよりも速い
- それが圧倒的価値
- JSだと遅くて現実的でないことが可能になる
- Cよりは数倍遅い
- 安全性のために未定義動作(UB)をなくしてるから
- この安全性が大きな利点
WebAssemblyのサポート状況
- IE11以外は使える
- 9割くらいのシェアのブラウザで使える
WebAssemblyの事例
- eBayの事例
- バーコードスキャナ
言語ごとの速度イメージ
- 1倍: C, C++, Rust
- 3倍: Java, C#, Go, Swift
- 5倍: JS(V8), Dart
- 50倍: Ruby, Python, Perl, PHP
- WebAssembly
- WasmをV8で動かすと5倍の中では速い方
Streams APIをちゃんと理解する
- 加藤 健志さん
StreamAPI
- Readable Stream
- Transform Stream
- Writable Stream
Readable Stream
- 読み込み可能なストリーム
- データを分割して少しずつ読み込むことができる
- fetchAPIのレスポンスのbodyは実はReadableStream
Writable Stream
- 書込み可能なストリーム
pipeTo()を使うとReadableStreemのデータをそのままWritableStremに書き込める- 書き込み時にPromiseを返すと解決するまで待つので順序を保証できる
- 分割されたデータを1つずつ順番に書き込むことができる
Transform Stream
- 変換ストリーム
- WritableStreamに書き込まれたデータをTransformStreamで変換してReadableStreamで読み込む
- ReadableStreamから
pipeThrough()でTransfirmStreamに渡してpipeTo()でWritableStreamに書き込める
バックプレッシャー
- キューに空きがなくなったら通知して止めてもらう
- Underlying Source
- Push Source
- 自発的にenqueueする
- Pull Source
- リクエストに応じてenqueueする
- Push Source
- QueuingStrategy
- highWaterMark
- キャパシティを設定する
- size(chunk)
- 何をもってキューのサイズを決めるか
- highWaterMark
Streamsの今後
- 5Gが来る
- これまでボトルネックとされていたことが改善される
大容量のファイルを配信できるようになる github.com
- クライアントがボトルネックになる - Streamが役立つ！
