ECMA, TC39 Meeting 2014-11のメモ

TC39 MTG 11月が行われた

rwaldron/tc39-notes にそのミーティングノートが上がる予定

上がってからミーティングノート見ながらTC39 MTG MTGをする予定。

幾つか今までの変更が上げられているので、TC39 MTG MTGの前にメモ書き。

Angularが好き嫌い(Ver 1.x)

Angular V1の頃のメモ

Ver2発表後

ちなみにAngularJS ver2はangular/angularで開発中

rebuild.fm後

Rebuild: Aftershow 67: Sacrifice Your Code (Naoya Ito)

Reactive MVC and the Virtual DOMのメモ

Reactive MVC and the Virtual DOM — Futurice のメモ。

Model-View-Intent and the Virtual DOM の記事版という感じ

  • React/Fluxは最近話題になってる
  • React/FluxはリアクティブプログラミングであるがAPIが少し違う
    • Reactはリアクティブとインタラクティブなパターンを混ぜた感じ
  • ゼルダのように昼と夜で同じマップだけど違う世界のように2重となるようなケースを考える
  • The dual of Interactive is Reactive
  • 普通のインラクティブの場合は、Xをに影響を与えるものを探す場合、他のモジュールでX.update()を探す必要がある
  • しかし、リアクティブパターンの場合はXの中を探せば良くなる

どうやってリアクティブパターンを実装するか?

  • event emittersの導入
  • Xからあるイベントをsubscribeするだけ
  • FluxもReactiveも別にRxJSやBacon.js等の必要はなく、EventEmitterだけでも事足りる
  • EventEmitter : RxJS == roller blades : cars.
  • RxJSではObservablesがEventEmitter的なもの

Reactive MVC?

  • まずはControllerを取り除くことから
  • Controllerはインタラクティブなコンポーネントだから
  • ModelはデータイベントのObservablesをexportする
  • ViewはModelのObservableに対してSubScribeする
  • MV*と言われるやつはControllerでユーザイベントを監視して、Modelのupdateを呼び出すスタイルを取る
  • Reactiveの場合はModelが”Reactive Controller”を監視する
  • この”Reactive Controller”を”Intent”といったりする

Model-View-Intent

  • Intentはユーザーイベントをモデルが監視しやすいEventに翻訳する(Intent Event)
  • ModelがこのIntent Eventをsubscribeし、モデルのデータを変更する
  • Intent -> Model -> View の一方通行の流れができる

    Model
    Input: user interaction events from the Intent.
    Output: data events.

    View
    Input: data events from the Model.
    Output: a Virtual DOM rendering of the model, and raw user input events (such as clicks, keyboard typing, accelerometer events, etc).

    Intent
    Input: raw user input events from the View.
    Output: model-friendly user intention events.

Virtual DOM to DOM

  • Model-View-Intent ではViewが実際のレンダリングをしないでもいい
  • ViewがVirtual DOMを使うRendererに処理を移譲してあげる

サンプル

How is this different to React/Flux?

  • Pureなリアクティブである
    • React/Fluxはリアクティブとインタラクティブをmixした感じ
  • MVIは中心となるものを持たない
    • FluxはDispatcherなど中心となるやつを推奨してる(シングルトン)
    • Model(Store)間の依存はそれぞれのモデル内で定義出来る
    • MVIはModels observe other Models.
  • RxJSパワー
  • RendererをViewと切り離せる
  • Rendererが副作用がある所なのでそれを分けることでテストしやすくなる
  • No internal state – SteteはViewにはなく、Modelのみに存在する
  • No reusable UI components
    • Reactは再利用可能なComponentsであることを主張してる
    • MVIの場合はそのような再利用可能なComponentsはWeb Componentsのレイヤーで持っておいて
    • それをVirtual DOMで使うとかそういう方向をイメージしてる

A State of Change — On the future of Object.observeのメモ

A State of Change — On the future of Object.observe

Object.observeについてのスライド。
Object.observeはオブジェクトの変更を監視できるが、imuutabilityとは逆の事になってしまう。
Immutableなしくみを提供するmori、同様にDOMでもStatelessなDOMを提供するReactやVirtual DOMがある。
ただ、全体としてのUI状態を管理するImmutableオブジェクトは必要。

Immutableなオブジェクトでやるいいところは、Undoの実装が簡単になる。

  • 現在のシンプルなバインディングはMutableデータをStateful DOMへ結びつける
  • 未来のレンダリングはImmutableデータをStateless DOMにする

r21834 – v8 – V8 JavaScript Engine のfast property名の制限

Allow all Names to be fast property names

引用元: r21834 – v8 – V8 JavaScript Engine – Google Project Hosting.

via Community Round-up #22 | React

このReactの人出したIssueによって、V8でfast propertyとなるプロパティ名の制限がなくなった。

以前、lodashで以下みたいな回避するコミットとかもあった。

JavaScript Memory Management Masterclass のメモ

JavaScript Memory Management Masterclass // Speaker Deckのメモです。

Q. メモリリークはどうやってチェックするの?
A. DevToolsでSnapshotsを取って比較

Hidden Classes

V8にはHidden Classesがあるので、deleteするのは最適化を逆に妨げる。

Closures

循環参照によるリーク

DOM Leak

DOMツリーは親を消しても、子のどれかを保持してる場合は、
そのツリーはGCによって回収されないので、
子もちゃんとnullなどして回収されるようにしないといけない。

Timers

ES6 WeakMaps

WeakMapsはメモリリークを避けるために必要。
普通にオブジェクトを使うと強参照になるので、GCで回収されない。

Memory Checklist

  • 不必要なDOM elementへの強参照を避ける
  • 循環参照を避ける
  • 適切なスコープを使う
  • 必要なくなったevent listenersは解除する
  • ローカルキャッシュを管理する
    • 管理する事で古いオブジェクトを捨てる

メモリ管理の基礎

Core Concepts

  • 値の型は何?
  • メモリ上で値はどうやって管理されてる?
  • garbadgeって何?
  • leakって何?

garbadgeって何?

Garbageとはroot nodeから辿りつけない値達の事

garbage collection はそれらのgarbageをシステムに伝える事

memory leakって何?

JavaScript DOM node

JavaScriptからDOM nodeへの参照を持っていると、
そのnodeをDOMから消しても、JavaScriptの参照があるためリークする
(JavaScript側からの参照を消せば回収される)

V8 memory management

  • newや暗黙的にメモリをallocationする
  • Memory poolを使い切るとGCが走る
    • GCにはmillisecondsかかる
  • メモリのallocation気をつけないとGCによるフリーズが起きる

V8は世代別GC

  • Young valueとOld Valueに値は分けられる
  • 一定時間経つとyoung valueはoldに送られる

young generation

  • fast allocation
  • fast collection
  • よくcollect(GC?)される

old generation

  • fast allocation
  • solower collection
  • たまにcollectされる

なぜ、young generationは fast collection なのかというのは、
GCのコストはlive objectsの数に比例するため、
live obejctsが多いyoungのcollectionは早くないといけない。

Performance Tools

performance.memory

  • jsHeapSizeLimit : heap sizeのlimit
  • totalJSHeapSize : 今使ってるheap size
  • usedJSHeapSize : allocated,free spaceを含んだsize

DevToolsの解説

Closures には名前付き関数式を使ったほうが見やすい

どうやってメモリリークを見つけるか

  • Open DevTools
  • Snapshot #1
  • 操作
  • Snapshot #2
  • 操作
  • Snapshot #2
  • #1と#2のallocatedを比較する

Object Allocation Tracker

Allocation Stack Traces

JavaScriptの処理のビジュアライズ

ProfileをChartで見るとFlame Chart Viewで見られる

リソース紹介

JSでQueueとして配列を使った場合と自作したQueue(linked-list)での最適化の話

2 Since you’re queuing functions to be executed, you can use a more efficient data structure than a JS array. A queue that has only enqueue, dequeue and isEmpty operations can have all these operations be O1. A JS array probably doesn’t behave that way. See http://jsperf.com/jsqueue-vs-array

引用元: Benchmark NPO’s performance against other libs · Issue #8 · getify/native-promise-only.

JavaScriptの配列でpush()shift()のみでデータを出し入れするデータ構造のケースで、シンプルにそれ用のQueueを実装するとJavaScriptエンジンの最適化が効きやすい O(1)の処理

iOSのWebViewとSafariとかで計測した結果を比べたりすると分かりやすいけど、
WebViewだと最適化全然されないので微妙な結果だけど、SafariだとQueueの方が早くなる。

後、このコードだとQueueの実装はコンストラクタ関数でやってるので、
こういう繰り返し回すベンチマークだと、ここでhidden classesみたいな最適化が効いたりしてるのがでてるのかもしれないです。

デザイン的にはJavaScriptのArrayは自由なので、目的ごとにデータ構造を作るの基本良いことだと思います。

Bowerは悪かどうか

昨日あたりから、sinon.jsのcjnoさんが発端のBowerは本当にいいものなのかについての話題が中々面白そう。

この発言を書いたのは、Make syn installable through npm by cjohansen · Pull Request #53 · bitovi/synやsinon.jsでもBower supporを求められたりすることが多くて嫌気が刺したからだそうだ。

関連issue : [enhancement] Add missing bower.json. · Issue #6816 · joyent/node

@addyosmani さんとか@tjholowaychukさんとか@substackさんとかその辺のツールに関係ありそうな人たちのそれぞれの反応が面白い感じ