Thoughts on a runloop?

[lancejpollard]

This project looks awesome. I'm excited to use this instead of Ember soon.

I get the goal of component in general, keeping the modules small and accomplishing one specific task. But I'm wondering what you guys think of including a run-loop (like in Ember).

Basically, instead of emitting events and having them directly update the DOM, you wait until the next frame to update the DOM in one big chunk. To do this, it requires:

• Grabbing the property/method value on the next frame, rather than emitting the event and grabbing the property all in the current frame (examples/computed.html#L58). This way if the property changes multiple times, the DOM only gets modified once.
• Having the dom render/paint only once when any number of properties change. I'm not sure exactly how browser rendering works, but say you had a table with 20 rows with a column status and the properties all changed from pending to active. With the current implementation it would update the DOM one row at a time, which slows down as there are more elements. Eventually this method slows to a crawl (even with a modest number of elements). From my knowledge the ideal way of handling this is to remove the parent-most DOM element containing the elements that will be updated, and then updating all of the properties, then re-appending the DOM element to the page. Is this correct?

What are your guys' thoughts on the ideal implementation for this? It seems that this sort of "run loop" would be implemented at the level of the require('emitter'), which wouldn't actually dispatch the events until the next frame. Not sure though.

[lancejpollard]

Here are some links to the implementation Ember has (pretty over complicated, but includes all the key stuff):

• ember-metal/lib/computed.js
• ember-metal/lib/run_loop.js
• ember-metal/lib/observer.js
• ember-metal/lib/events.js
• ember-metal/lib/watching.js

Specifically, observer.js#L63-L72 shows how property changes are batched up.

[tj]

you're free to implement whatever you want really with components, I think if everything was coupled to it that would be the wrong abstraction though. I wouldn't try to cheat browsers too much, they have all sorts of tricks to avoid unnecessary painting etc, plus we can profile these sorts of things for individual components

[lancejpollard]

This is a problem with most/all frameworks that have tried to implement binding, just seems like there should be a standard component/solution to the issue. This is one area where the browsers don't have the appropriate tricks, though they're starting to with the shadow dom and built-in observers.

[tj]

still, a component is just an arbitrary chunk of js, so we can implement things without coupling everything else to it. Just like Emitter happens to be what I use for lots of things, it's not the canonical component solution or anything like that, but that's the great thing about component, you're only opting in to smaller chunks of logic vs a massive framework. For right now I'd favour a nice api over a mess like ember, if anyone hits perf issues we can look into it. So far our app is a lot more responsive than ember stuff like travis etc, anything else would be a premature optimization IMO

[subtleGradient]

Essentially all you need in order to make everything optionally run-loop compatible is a way to opt into do-nothing-until-I-call-flush mode. Then call flush in your run loop as often or infrequently as you like.

So, any chance for that mode in reactive?

[tj]

that should be pretty easy with the adapters, just queue up changes and remove dups etc
https://github.com/component/reactive/blob/master/test/adapters.js#L18

we have a lotttt of moving parts in our app and have yet to see any slow downs from rendering that aren't related to image decoding, that's about the only problem we have right now

[tj]

decided with the upcoming changes it would be good to get these in, but we definitely can do it in ~30 or less lines of code, we don't need all that crazyness, however I still think we should do some thorough profiling. Re-rendering attributes or text multiple times in a tick may be less expensive on average than managing duplicates, or it might be completely negligible, I have an example with 1500 dom reactive templates and it barely registers on the profiler

[defunctzombie]

I think dom stuff already handles waiting on painting until it has to tho request animation frame might be good to throw in the bindings. A runloop is out of scope for now tho.