Re:Unraveling HTML5 vs. Native
by millstone on Tuesday April 30, 2013 @07:24PM
(#5635540)
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.
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.