Hacker News new | comments | show | ask | jobs | submit login

Comments like this demonstrate why web _applications_ will lose

The inertia and individual investment in HTML and JavaScript is so incredibly high that web players (from the browser makers such as Mozilla to the individual web developers) absolutely steadfastly refuse to evolve with changing requirements.

The belief that JS+HTML is "just fine" and no significant evolution is required to support application development is absolutely incomprehensible; what other application platform available today has seen iteration as glacially slow as the web? The browser makers have consistently stuck to their "HTML+JS is fine for everyone" guns, ECMAScript has failed to evolve almost entirely, and no common application development framework or platform has emerged.

HTML+JS libraries -- such as jquery -- are just fine for interactive document publishing, but are no replacement for Cocoa, Android, or Qt. The lack of common re-usable and extensible UI components is a travesty. Proponents like to advance the idea that this chaos is a benefit -- choose whatever tools you want -- but the rising popularity and the massive investment in application development on native app stores demonstrates a market desire for something simpler: A common well-defined application development platform is valuable, and the only barrier to adoption in the web world was a trustable distribution mechanism -- app stores.

The fact that you think App Stores will fade away is demonstrative of a failure to understand why the app store is so popular -- ease of distribution, easy to use common development platform, ease of payment processing, common UI (instant user familiarity), performance (!), open development platform (no JS sandbox, not all languages must be filtered through JS).

Ask yourself why Google has ChromeOS on one hand, Android on the other, and is working on technologies like NaCL that could bring many of the advantages of Android to Chrome?

Lastly, hopefully I can pre-empt the "JS is a common bytecode platform, just target that" crowd. Yes, you can emulate any other turing machine on top of a turing machine, but that doesn't mean it will be fast, clean, easy to use, easy to debug. It absolutely makes no sense to halt the evolution of the browser as a platform and instead tell everyone to use a high-level language like JavaScript as a common bytecode.


I also should mention, anecdotally, that I've had some long-winded conversations with a member of the Chrome App Store team -- me from the perspective of a long-time native developer, them from the perspective of being tasked with coming up with ways to improve the web as an application development platform.

From my conversation, which may or may not reflect reality:

There seem to be two schools within the Google App Store team. The first (and seemingly most common) belief that there's nothing terminally broken with the DOM, HTML and JavaScript, they just need to find a way to make it easier to implement re-usable UI components, perhaps a common model for namespaces, objects, and other small improvements to JS.

The second seems to believe that a fundamental re-imagining is required -- perhaps dropping the DOM entirely in favor of rendering with canvas and a traditional view/event hierarchy. Consider opening the playing field for more languages (eg, via NaCL).

I think the competing strategies within Google and the clear differences of popularity between them -- Android, Chrome/ChromeOS/Chrome AppStore -- provide an enlightening view as to the likely future of application development on the internet.

HTML+JS libraries -- such as jquery -- are just fine for interactive document publishing, but are no replacement for Cocoa, Android, or Qt. The lack of common re-usable and extensible UI components is a travesty.

Cappuccino http://cappuccino.org/

SproutCore http://www.sproutcore.com/

Ext JS http://www.sencha.com/products/js/

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.

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.

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.

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.

Mozilla would be happy to replace Qt/Cocoa/... with HTML+CSS+JS (or XUL). So it's obvious they'll be highly reluctant to have the exact opposite.

Microsoft once tried this in Windows 98 (thanks tightly-integrated IE) - and fairly succeeded. Since then, the attempts to "bring the Web to the desktop" are fairly constant.

Yet another new one is QT Web runtime: http://qt.nokia.com/developer/qt-roadmap (for lack of better link really)

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact