4 ms·

I don't think there's a good reason such a distinction exists. You have ChromeOS and FirefoxOS, which prove that web applications given access to system APIs ar

by just2n 13y ago

I don't think there's a good reason such a distinction exists. You have ChromeOS and FirefoxOS, which prove that web applications given access to system APIs are just as capable as ObjectiveC and Java. But there's still a "web" vs "native" distinction. Why can't Android or iOS launch a "web" application with JS having access to privileged API and HTML/CSS simply rendering the UI? When did we decide to build worlds where your programming language dictates whether your application is "real" or not?

CmonNoReg 13y ago
It is a one word explanation to users asking why their app is slow/drains battery/doesn't feel like other apps.
Zigurd 13y ago
Not all Android APIs make sense in a Web browser. How does one implement an AppWidget, or violate the browser sandbox with a remote API? Different runtime environments and different OSs have real differences. For some apps those differences don't matter. For others, they can make the difference between useful functionality and a pleasurable UX and a dull trudge through interactions that don't benefit from native platform capabilities. Maybe Web apps will find their highest expression in OSs that feature Web runtimes. Java was supposed to be "write once, run anywhere" but, for interactive apps, it only became popular once Google wrote an OS and class library specific to that Java OS.
millstone 13y ago
ChromeOS is a strange choice, because of the box, ChromeOS is not especially capable. That's why there's interest in tools like Crouton. What distinguishes native apps is not whether they are rendered with HTML (many native apps use HTML rendering for parts), or whether they have access to privileged APIs, but instead whether they conform to the behaviors and conventions of the platform. Getting that conformance requires using the APIs the platform gives you - you cannot adequately copy it, as Java Swing has proven. For example, Light Table fits your criteria: it's a double clickable .app file with access to privileged APIs, with HTML and CSS rendering the UI. But it's obviously not a native app, and will never feel like one. Note that I didn't say "real". Light Table is certainly a _real_ app. But the distinction is inescapable: it's impossible to miss the fact that Light Table is non-native.

by just2n 13y ago

CmonNoReg 13y ago

It is a one word explanation to users asking why their app is slow/drains battery/doesn't feel like other apps.

Zigurd 13y ago

Not all Android APIs make sense in a Web browser. How does one implement an AppWidget, or violate the browser sandbox with a remote API? Different runtime environments and different OSs have real differences. For some apps those differences don't matter. For others, they can make the difference between useful functionality and a pleasurable UX and a dull trudge through interactions that don't benefit from native platform capabilities. Maybe Web apps will find their highest expression in OSs that feature Web runtimes. Java was supposed to be "write once, run anywhere" but, for interactive apps, it only became popular once Google wrote an OS and class library specific to that Java OS.

millstone 13y ago

ChromeOS is a strange choice, because of the box, ChromeOS is not especially capable. That's why there's interest in tools like Crouton. What distinguishes native apps is not whether they are rendered with HTML (many native apps use HTML rendering for parts), or whether they have access to privileged APIs, but instead whether they conform to the behaviors and conventions of the platform. Getting that conformance requires using the APIs the platform gives you - you cannot adequately copy it, as Java Swing has proven. For example, Light Table fits your criteria: it's a double clickable .app file with access to privileged APIs, with HTML and CSS rendering the UI. But it's obviously not a native app, and will never feel like one. Note that I didn't say "real". Light Table is certainly a _real_ app. But the distinction is inescapable: it's impossible to miss the fact that Light Table is non-native.