In my experience, even till this day, I still see more of a visual lag in entity movement / animation in JavaScript (Canvas) based games than I do in Flash based games.
Why is this - what exactly is the descrepancy at the most basic level between an JIT vs AOT compiler in the specific scenario of JavaScript vs. Flash.
It's not the compilation method that makes the games lag, it's the garbage collector, and the Flash garbage collector is separate from the browsers.
I think I can pretty confidently reason that you run Firefox, because the Firefox garbage collector is the worst piece of crap you can get, from a gaming point of view. If you open just one tab and run a light JavaScript game in it, it is usually tolerable, maybe even unnoticeable. But if you open a bunch of tabs, run something a bit more demanding or use Firebug you'll easily get regular lag spikes beyond 100 ms.
I haven't done any extensive testing for a while, but Chrome has always done really well in this regard, and both IE9 and Safari seemingly do an acceptable job as well.
I made a tool for testing JavaScript lag, you can play with it if you like: http://ebusiness.hopto.org/lagtest/
It's hard to say without looking at actual code but a few points:
Flash has been around longer. People who author tools and libraries for it have more experience handling animation. I'm not a big fan of the tools and the proprietary technology but I'll never knock an ActionScript dev who knows what s/he's doing.
JIT browsers are also relatively new to JS developers. The best choices for really fine-honed perf-intitiatives are still something we're sorting out as a community. Inline function defs used to be a borderline dumb thing to do in a lot of cases. Now it's a great way to boost perf in a lot of JIT scenarios.
Normalizing for umpteen browsers doesn't have to but often does result in failing to take full advantage of a given browser's full capabilities.
(edit: not quite right on this one but there might still be a point here - Erik) The Flash plug-in is vector friendly and it is widely understood how to take maximum advantage of that. Whether inheritance schemes will do us a ton of good with canvas context objects remains to be seen but I doubt it will be to the same degree of win you get out of vector.
One interesting thing that I'm surprised nobody has mentioned yet is the difference in the types of JIT compilation, because Flash is still JIT compiled, and, in most modern browsers, so is JavaScript, however Flash is a strongly typed language, which means there are a whole realm of optimizations that it can do (such as emitting a call to a method directly (something JavaScript cannot do)), that JavaScript cannot do because it is dynamically typed. You can replace the entire definition of a function in JavaScript at any point you want, and that new definition is what must be called. (it is still possible for JavaScript to do an indirect call that wouldn't be that much more expensive though) Field access on a field is actually a better example than method calling, because JavaScript cannot even do this indirectly, it has to first look the field up by name (hashed) on the current type of the object.
Another difference in performance is, as is already mentioned, the GC. I suspect (I've not checked) that most browsers use either a reference counting GC (because all memory the GC allocated for a page can be freed when the page is left, it's actually one of the best places to use a reference counting GC), or a conservative scanning GC (such as Boehm). The latter can be considerably slower than the former if it's not implemented right. (Boehm is an example of a right implementation) Flash on the other hand uses a precise GC (much easier to do in a strongly typed system). Because Flash uses a precise GC, it doesn't have the runtime overhead of reference counting. (which isn't huge, but is still there) A good example of a precise GC is Mono's SGen, which also compacts the heaps.
Then there comes the fact that JavaScript wasn't designed with animation in mind. (as was also mentioned) As far as I know, no browser will emit SSE-style instructions for the animating loops, where-as the core rendering functions in Flash have probably been hand optimized for peak performance. (in some places being written in raw assembly)
All-in all, it comes down to the fact that a dynamic language will always be slower than a statically typed one if it has to be compiled in a timely manner so as to not make the user complain about it's slowness.
IMHO that differnece comes from the fact that Flash was build from the ground to do exactly that, animations. Flash implements (even though poorly by major judgement) techniques for smoother visualization running by default, when in JS you would need to make those implementations manually.
There are examples of great implementations of JS/Canvas running even better then most Flash games I see around. It all comes to the developer making them.
aside from the GC, JIT aspect of these technologies, there is gap between the usage of hardware.
in the latest version of flash player, flash has began resort to hardware acceleration for rendering those images, which makes the rendering process faster and quality better. while on the other hand, JS driven games on some browsers( FF, CHROME ) haven's started this yet. There was one exception though, the IE9 browser has began to re-architect from the hardware abstraction layer, browsers from IE9 had made tremendous progress on making use of hardware acceleration, thus graphics rendering on these browsers is definitely better and faster than other browsers.
