If that's really true for Ember.js that's great! I'm curious as to why it performs so badly? http://www.petehunt.net/react/tastejs/benchmark.html

I looked at that benchmark and there's a few huge red flags right away:

1. It's not running Ember in production mode which is much faster.

2. It's running an older release candidate version of Ember.

3. It is purposely wrapping individual events in run loop executions rather than just letting ember figure out when you put things into run loops.

I re-ran the benchmarks with the latest production mode Ember.js and removed the incorrect run loop usage got the following results:

https://gist.github.com/eviltrout/8058560

It's still slower than ReactJS but much less so than before. In fact it's now #3 in that benchmark suite behind ReactJS and Backbone (and much faster than ReactJS in the completing benchmark), although I wouldn't be surprised if the other frameworks were set up as incorrectly too.

Thanks for the clarifications!

The project is async-tut1 not async-tutl. Look at your project.clj.

ClojureScript has had performance escape hatches for some time. It's pretty much always possible to get the performance of hand written JS, important otherwise our data structures would be lame. We'll likely document these techniques in the future.

No the post advocates generators plus a competent channel abstraction. It's going to be hard to compare generator libraries to core.async, far as I can tell none employ the comprehensive set of optimizations that we do for time and memory. Perhaps when someone ports our ideas to JavaScript a real comparison can be made.