To address a couple of things that you said more directly:

> Are you serious, or are you really just that out of touch with how we work on desktop and mobile apps?

Yes, I have been serious, and sincere, throughout this dialogue. I guess I really am that out of touch with how truly excellent desktop and mobile apps are developed. I have done most of my work in dynamically typed languages (Python, Lua, and JavaScript), with little regard for performance. When developing any UI more complex than a yes/no dialog on Windows, I have generally reached for HTML (embedded MSHTML to be specific), despite its shortcomings. On Mac and iOS, I have been lucky in that I can use Lua while still having a native UI and platform integration.

It seems to me that while mainstream desktop and mobile platforms have been mediocre in their various ways, none has forced mediocrity upon the application developer as much as the Web platform.

> - The ability to use the right language for the job. The right language isn't the right language if the performance is pot, so no, Emscripten isn't a solution. I'm talking about everything from exposing SIMD intrinsics when writing time-critical software to languages that actually support compiler-checked type-safety.

When I was defending Mozilla and the Web platform, my response (in true quasi-religious fashion) would have been to keep having faith in the almighty tracing JIT compiler. But I was reading yesterday about tracing JIT compilers, and I noticed that they need guards around loads and stores in case the inputs to a particular invocation of a trace are of different types than the types for which the trace was compiled. You're right to point out that compile-time type safety has some performance benefit. For truly performance-critical code, asm.js does provide for static type checking and AOT compilation. Still, we have yet to see how many browser makers will implement these things.

> - Common widget toolkits providing a common user-experience across applications, from which users can learn platform conventions and be immediately comfortable and familiar with an application. These toolkits allow us to reinventing the wheel every single time. No, bubblegum and spit collections of JavaScript and CSS are not the same thing.

Yes! Yes! I most emphatically agree with this point. It seems to me that modern web application UIs are still a free-for-all, with many app and toolkit developers defining their own widgets as they see fit. In contrast to the Apple platforms, GNOME, and even Windows IIRC, there's no set of human interface guidelines for the Web platform.

> - Platform integration. This isn't just "cameras". It's also the iTunes/Media query APIs, in-app purchase, airplay, spotlight plugins, quickview plugins, menu items, and the mountain of other things that platform vendors implement to provide an integrated and coherent experience. Platform vendors push forward the user experience by providing richer platforms. Web vendors don't.

Mozilla is introducing new APIs to expose more platform features, at least for Firefox OS and Firefox for Android. But that does little good for today's mobile application developers. And I guess it's a distinctive behavior of any "true believer" to have faith that promises will be fulfilled at some indeterminate future time, and encourage others to do the same.

> - Unification of code, UI, and styling. The DOM has to go, as does CSS and JS as separate entities. It's a ridiculous model for UI development and it makes producing genuinely re-usable and interoperable component toolkits very difficult.

I'm not quite convinced on this one. Reusable component toolkits do exist for the Web platform, so presumably most application developers don't have to do this very difficult work. Can you elaborate some more on what's wrong with the HTML/CSS/JS trio, or point me at an existing critique that you think is on target?