[skatepark]

We'd also need a full widget toolkit, set of foundation/standard libraries, and all the other functionality we take for granted on other platforms.

With all that in place, then I'd use whatever reasonable (JS isn't) language existed as a norm on the platform to write applications to target the browser, instead of Android, iOS, and Max OS X.

My only allegiances are to user experience and the quality tooling necessary to ensure it. The web as-is provides neither.

[mwcampbell]

> My only allegiances are to user experience and the quality tooling necessary to ensure it. The web as-is provides neither.

You assert this, but you haven't provided evidence. Web application developers are providing great user experiences. What tools do you need to provide a good user experience that the web as it is now doesn't have?

[skatepark]

> You assert this, but you haven't provided evidence. Web application developers are providing great user experiences.

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

> What tools do you need to provide a good user experience that the web as it is now doesn't have?

- Performance, performance, performance, performance.

- Performance.

- 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.

- Performance.

- 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.

- Standard library which provides the functionality necessary to conform with platform exceptions and integrate with the platform.

- Tools. Debuggers, compilers, and most especially, profilers and deep instrumentation.

- 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.

- 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 could probably go on all day. I WANT a non-proprietary, open, standardized application platform, but I need a platform that lets me provide the best available experience to end-users, and the web isn't it. I'm writing my software for my customers, and choosing technology over user-experience doesn't do my customers any favors.

[mwcampbell]

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?

[mwcampbell]

I will now relent of defending Mozilla, in which I have zero vested interest. Mozilla's mission and approach seem good on paper (or in HTML), but you make good points.

It seems to me, on reflection, that I have been playing the role of religious apologist, while you have been the skeptic. This is ironic, because I have been in the opposite sitaution with regard to my former real religion for the past couple of years.

It seems to me that Android is the closest thing we have to a non-proprietary application platform, and even that is more tightly controlled by one company than we might like.

For now, I guess the best approach to writing great apps is to write the UI-independent core in a reasonable cross-platform language, and then use each platform's native UI constructs. iOS makes this difficult for any language higher-level than Objective-C, since there can be no JIT compilation for iOS. But I'm thinking now that C# might be a reasonable cross-platform language, given Xamarin's work on Mono for mobile platforms.

[steven_wood]

> 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.

How does separating UI styling from UI construction code make creating reusable components more tricky exactly ? Other points might be close-ish to the mark but this one seems way off.