Right now when I instanciate systems, I can give them set of attribute they can access via this.options.someResource.

Instead I could store it on the main Systems module as a Static property.
System.resources.tilemap
System.resources.entities
etc ...

• Require every object to extends Events class
• Allow a great granularity: entity.trigger('collision')
• Increase programming complexity by adding small event logic

  class Entity extends Events
  contextObj = new Entity()
  contextObj.on('test', fn)
  ContextObj.trigger('test', { stuff: 1, thing: obj})

VS

• Only few event manager instance (one is enough I think)
• Granularity require as much conditional block as cases (e.g. if or switch)
• Add an additional dependancy all over the program
  -> require less ram
• Need for more complex event name

  e = new Events()
  e.on('test', fn)
  contextObj = new Entity()
  e.trigger('test', contextObj, { stuff: 1, thing: obj})

Thinking Notes:
Those are two very different event manager, the first is more entity wise when the second is more applicatin wise.
Maybe we could combine both, ...
allowing us to get the great granularity, small ram usage, and having one common single object (reducing programming complexity):

  e = new Events()
  contextObj = new Entity()
  e.eventize(contextObj)
  contextObj.on('test', fn)
  ContextObj.trigger('test', { stuff: 1, thing: obj})

Last time I taught a friend how to make game with gamecs, he encoutered lots of guessing and remembering how the function were working.

For example the rect can be created from very various parameter:
new Rect(pos.x, pos.y, w, h)
new Rect([pos.x, pos.y], [w,h])
new Rect([pos.x, pos.y, w, h])
new Rect(rect)

WHEN Surface is:
new Surface(w, h)
new Surface([w, h])
new Surface(rect)

WHEN rect.blit is
rect.blit(src, [pos.x, pos.y] ...
rect.blit(src, rect ...

WHEN draw.rect is only
rect (surface, color, rect,

Further more when we want to access property
Rect has:
rect.x, rect.left
rect.pos, rect.topleft
rect.y, rect.top
rect.height
rect.width
rect.inflate(x, y)
union(rect)
clip(rect)

WHEN Surface has:
Surface.getSize

etc ...

the most allocation in video game are made by entities (aka sprites).
generating pool of sprite and manging their lifespan with a boolean and a dedicated garbage collector could spare lots of resources.

In multiple canvas example, on each system we test on every entity if it has a relative components.
For example, the CollisionSystem tests if the property entity.components.Collidable exists before processing it.

We could generate cache by creating array for each component type.

Working on a flash project I had some problems using an inputEvent Stack to get keyboard inputs.

What happened was sometime when I pressed a key and realease it, following event were triggered:
[keyDown, KeyDown, keyDown, keyUp, keyDown]
instead of:
[keyDown, KeyDown, keyDown, keyUp]

I had to use a state array/hash that seems to work like charm, example:
state[Keyboard.UP] = true (when keyDown)
state[Keyboard.UP] = false (when keyUp)

The state array solution sounds faster on paper, could be interesting to check it with benchmark.

Animated and visible both set an image property,
we just need in the update() of System.Rendering to check if the visible component is an animation by checking if the property animation exists.

Note: attribute size of Animated was used to cut spirteSheet, when attribute size of Visible forced the size of the final image. Renamed Animated's size into cutsize or anything else more appropriate.

The uid generated in entity should not be settable, add a setter with an exception.