[ant57]

I don't want to dismiss these out-of-hand, but they're really not a replacement for a modern application development framework.

Beyond functionality (of which these can and do provide considerably less), part of what makes a platform like Cocoa/UIKit so valuable -- it is used by every application on the device. The applications will interoperate both with each other and with the OS (background services/tasks, quicklook, spotlight, etc, etc, etc). The interaction model will already be familiar to the user, visual cues will be understood, the speed and inertia of animations (such as scrolling) will be expected. There is an enormous value to being able to leverage user expectation, and this is where too many choices falls down.

[papertiger]

I have seen many apps (on all platforms -- iPhone, Android, OS X, Windows, etc.) that deviate from user expectations. Ultimately, meeting user expectations is the responsibility of the developer not the framework.

HTML has its own set of visual cues that you and millions of others easily interact with every single day. I would argue that the interaction model of HTML/JS apps may be as familiar or more familiar to users.

I don't disagree that HTML/JS apps can be difficult to develop, but I do not think they are going to "lose". (I don't think they are going to win either. It's not a win/lose situation.)

Since it seems that your background is in native applications, I just wanted to provide you with some references to frameworks that provide something a little more advanced than jQuery and interactive documents.

Obviously, each team needs to look at its project and goals and choose whether a native app, an HTML/JS app, or both is appropriate.

[joelgwebber]

I'd like to point out a couple of things about these choices for examples of rich UI libraries: All three of them throw most of the DOM, and reimplement almost everything from scratch: structure, layout, and most behavior (outside of that provided by input elements that can't realistically be implemented by hand). I don't think you can ask for a stronger indictment of the DOM and related APIs with respect to implementing applications.

And that's the problem. It's not [p]NaCl vs. Javascript. It's whether the core APIs are designed for the task, which in the case of web applications they clearly aren't. The most egregious failings of web applications stem directly from bad APIs, and if you look at their counterparts (for example) in iOS and Android, there's absolutely no comparison. A better script engine (and yes, almost anything would be better than Javascript) would be nice, but would do very little to solve the API problem (don't forget that NaCl can't call anything not provided by the browser, so it can't serve as an "escape hatch").

There are those who suggest that the browser APIs are close to "good enough" and just need to be tweaked a bit to make it possible to create good, efficient web apps on par with modern native apps. I'd like that to be the case (my day job is working on browser application tooling and infrastructure), but so far it's not happening where it matters most -- on mobile devices. On the desktop you can usually get away with murder because the machines are so fast (and have so much memory), but on more limited mobile platforms (and by limited I mean ~1GHz ARM with ~0.5G of memory) web apps aren't even close to their native counterparts. There are some laudable attempts out there (e.g. Gmail mobile, the Sencha Touch demos), but if you poke on them a bit you start to notice obvious performance and memory issues (e.g., when Safari Mobile crashes on the iPad it's usually out of memory).

Does this mean native apps in app stores will "win", and the web will "lose"? The web "won" on the desktop (for most kinds of apps, anyway), in spite of its severe limitations, because it provided a reasonably stable platform and super-simple deployment. App stores solve the deployment part of this problem reasonably well, but fail badly at the cross-platform part. Can the web be made "good enough" in time to win again? I don't think anyone can accurately predict the outcome at this point.

[Daishiman]

Yeah, well, web is not native, it's not meant to be, and it will never be, and I for one am glad that it's so different from native development.