JS (JavaScript) has always been an amazing language and has lasted the ages unlike many other languages who have came and long since died. Because of this I have to be very convinced that switching language from JS to say Flash back in the day or similar will be better.

However all Browser games that do not run by plug-ins not matter your language all suffer a fundamental flaw which is that we are forever rendering the output direct to the browser DOM. For those not programming savvy or such this is much like watching live television - it must be right 1st time, however actual games you install on your PC often use a render window in the background to \"draw\" the content and then what you see is a smooth front window which just takes the frames it needs.  Again this is like a pre-recorded TV show where they have the chance to filter out the bad stuff and only leave the good.

Because browsers lack this fundamental tool for filtering out bad frames, stuttering and unless correctly managed frames per second that alter on different devices slightly.


So the answer? - [ IMO! ]

Well once upon a time this would be a tall order but with additions of tools like Chromes built in element inspector and the vast range of other developer tools it\'s now more than possible.

If the browser window allowed for a back rendering area to be created and brought forward to develop in (for example declaring an element (whatever you use) as  id=\"render_canvas\" and that using CSS3 declare a flag if the area should be displayed in DOM for developer use or hidden for live use. By this I do not mean display:hidden but a specific unique flag.

Then within HTML5 along the lines of if \"render_canvas\" and \"canvas\" are both in use to update \"canvas\" with \"render_canvas\" content at a specified interval (25,30,35 FPS).


Managing thread time

Of course different devices will be hardware dependent to their capabilities which is why the browser DOM itself should micromanage the \"render_canvas\" usage by managing its dedicated thread time within the DOM most of which is already possible to view in developer tools.  If the DOM detects the \"render_canvas\" is degrading performance to limit its resources for task operations or maybe switch the allowed FPS to actual canvas to a lower setting. The possibilities are endless and my ideas of how it should work are just ideas, the benefit of buffering via a back render canvas however should be clear as day.

This would give the browser video display settings much like real platform games on a more basic level. Given the trend of 3D enviroment games since the birth of CSS3 and HTML5 things like buffering are a need not a desire..