Node学園 30時限目 に行ってきたメモ #tng30

Node.js

• semverで運用
• v4.xは4/30でEndOfLife
  • LTSになったバージョンは2年半くらいがサポート期間
• あらゆるOS x CPUで動く

Node v10でアップデートされるV8の新機能

• V8が6.2から6.6に
• AsyncItelator
  • `for await (const x of y) {}`できるように
  • Stream系の処理と相性がよい
• `Promise.prototype.finally()`
• RegExp
  • キャプチャグループに名前付けられるやつ
  • Unicodeプロパティ
• `catch(err) {}` を `catch {}`と書けるように
• `String.prototype.trim(Start|End)()`

Node v10.x

• Depricatedいろいろ
  • `require('assert').strict`
  • `util.type.isXxx()`を使おう
• `Error.code`が付与されるように
  • 今後は`message`ではなく`code`を見るように

クラス図から読む

• GitHub - darai0512/node-class-diagram: Licensed by Creative Commons.
• EventEmitter
  • ついに`off()`が`removeListener()`のエイリアスに
  • `_events`の代わりに`rawListener()`
• Stream
  • ReadableStreamに`Symbol.asyncIterator`が（Experimental）
  • `finished`により途中でabortされても拾えるように
  • `pipeline()`でまとめてエラー処理
• net / http
• fs
  • `require('fs/promises')`で、Promise化されたものが使えるように
  • `util.promisify()`しなくてもネイティブ化されたパフォーマンスの良いもの
• assert
  • `require('assert').strict`
  • `null`と`undefined`が判別できたり
• isXxx
  • `process.binding('util').isXxx()`が、`util.types.isXxx()`に
• `URL`, `URLSearchParams`が追加
• 他にもいろいろ
  • N-API
  • ESM

振り返り

• 2009年に誕生
• 2015年にio.jsの分裂、からのNode Foundation
• v4.xがEOLになることで、はじめてリリースラインを全うしたことに
  • 最初は誰も3年メンテできると思ってなかった
• おこった変化
  • 民主化によってコントリビューターが増えた
• semver, LTS
  • V8（Google）の協力も大きい
• Issueが増えたり要求が増えたりいい話ばかりではない
  • 新しいことをやるのも難しい

過渡期を越えたNode.jsのこれからに乞うご期待！

Worker

• JavaScriptでマルチスレッド処理をする
• 惑星DOMから打ち上げられた衛星WebWorker
• 最近のWebアプリはだいたい非同期で取ってきたJSONをこねて画面を出す
  • そこをWorkerでやればワンチャン・・？
  • って思ったけど、使いづらい

ポイント1

• スケジューリングや複数のWorkerを協調させる部分は自前でやるしかない
  • Parallel JSというプロポーザルもあった
  • C#とかRxKotlinやらErlangから学べないか模索中

ポイント2

• `postMessage()`以外で結果を共有できない
  • さよなら`SharedArrayBuffer`
  • Concurrent JavaScript: It can work! | WebKit
  • `TransferableStream`
• ライブラリもいろいろある
  • https://github.com/GoogleChromeLabs/comlink
  • https://github.com/GoogleChromeLabs/clooney

ポイント3

• WebWorkerは別ファイルにしないといけなくて面倒
• JavaScript Tagged Blocks
  • Tagged Templateみたいに書くと、その部分が別スレッドで動くように

ポイント4

• スレッドモデルかタスクモデルか

マルチスレッドでどういうコードを書きたいか・・ブラウザ作ってる人たちは、Webエンジニアのご意見を絶賛募集中だそうです！

LAPIs

• LayeredAPIs
• 2014年頃にあったExtensibleWebという動き
• 高レイヤーな部分は標準化のスコープではやらない
• 低レイヤーな部分を標準化する = 整理する
  • Encoding, URL, Fetch, Stream, CustomElement, etc.

AsyncLocalStoreage

• WorkerでLocalStorageが使えない
  • 非同期ではないから
• ちょっとしたデータを保存するのにIndexDB使いたくない
• Cache APIの汎用性のなさ
• 別にDOMでも同期のAPIを使いたいわけではない
• 提案したけどあしらわれたあの頃
  • それxxでできるよ
• すると1年後に改めてプロポーザルが出てきた
  • Async Local Storage
  • そこで触れられてたのがLAPIs

LAPIs

• GitHub - drufball/layered-apis: A new standards effort for collaborating on high-level features.
• LowLevelなAPIの策定が進んできた今こそ
• ややHighLevelなものも標準化の流れに取り込んでもいいのでは？という動き
  • もちろん一般的なFWほど具体的なものはしない
• たとえば`import`も数が多すぎるとwebpackのパフォーマンスに勝てない
  • こういうのも標準化すれば、ネットワークコストやパフォーマンスの向上にも
• `std:`プレフィックスをつけて`import`することで使えるように
  • `import { storage } from "std:async-local-storage|https://other.cdn.com/async-local-storage.js";`
  • 使いたい人だけが使う
  • Polyfillできないものはダメ
  • `window.xxx`も`xxx.prototype.xxx`も拡張しない方針

これから

• とりあえずGoogleが「やっていこう」と表明したくらいの進捗
• async-local-storage
  • https://github.com/domenic/async-local-storage
• infinite-list
  • https://github.com/domenic/infinite-list-study-group
• tasklets
  • https://github.com/GoogleChromeLabs/tasklets
• premature-polyfill問題
  • いざブラウザにその機能が載った時、そのPolyfillと挙動が違ったら・・・？

🍕がきてしまったのでメモはココまで！