The slowness is not in the JS and markup itself, but because in the past the rendering engines (browsers) didn't know how to interpret most of the JS calls as d

The slowness is not in the JS and markup itself, but because in the past the rendering engines (browsers) didn't know how to interpret most of the JS calls as defined UI changes. With requestAnimationFrame, CSS animations, and WebGL this is changing -- Browsers are now being told directly which code is UI-specific, so it can be accelerated with hardware and the timing can be synchronized. Translating JS into these more 'native' UI calls across multiple devices and software stacks is already shown as profitable with tools like Appcelerator (iOS, Android, BB, Desktop) and PhoneGap -- which appear native to the average user. Also don't forget that internally the Mozilla suite and many other desktop 'native' apps are built largely with JavaScript, not to mention Palm's WebOS. JS itself is very fast and creating fluid UIs was always possible with a native wrapper (or plugin, as you mention) but now that the tech is making its way into the average browser we will be seeing more and more 'crisp' interfaces on 'average' websites. 'Hard coded' apps will always have their place, but look out: many portable, JS-driven apps are very successful, and are already changing the future. Many people who just think of JS as browser script are being left behind.