4 ms·

Native will never die, and this is because there is a fundamental problem with webapps -- they lay on a wrong abstraction, a document delivery system. To this e

by mbq 14y ago

Native will never die, and this is because there is a fundamental problem with webapps -- they lay on a wrong abstraction, a document delivery system. To this end, they will always require huge amount of hacks to overcome its restrictions (security issues, browser overhead and bugs) and to emulate stuff native apps gather for free from OS, like file systems, cross-process communication, i18n, networking, device access, compositing, UI look&feel and so on. About breaking cross-platform apps... there is simply a better solution -- open, solid protocols. If a protocol solves some problem, it will get great apps on all platforms and will be supported for years, outliving dozens of closed solutions (think of e-mail, jpeg, ssh, pdf, ftp, csv or BibTeX).

anon1385 14y ago
The web has totally changed compared to just a few years ago. The things you mention were once issues, but are solved now :) >security issues web apps run in a secure sandbox. Native code is insecure by comparison. Users don't trust native apps. >browser overhead irrelevant in the age of multi GHz CPUs in your phone > bugs native platforms have bugs too >file systems most people don't need a file system at all when they have the cloud, but it's there if you need it http://www.html5rocks.com/en/tutorials/file/filesystem/ http://www.html5rocks.com/en/tutorials/file/filesystem/ >cross-process communication http://dev.w3.org/html5/websockets/ http://dev.w3.org/html5/websockets/ >i18n libraries for that will come >networking Websockets, WebRTC etc >device access anything common or mainstream is already available (cameras, microphones, gps, accelerometers etc) > compositing https://www.khronos.org/webgl/ https://www.khronos.org/webgl/ >UI look&feel The freedom to create your own UI without being constrained by platform conventions is going to open up many new and exciting UI paradigms now that we finally get a true open and free market in interface ideas. >About breaking cross-platform apps... there is simply a better solution -- open, solid protocols protocols and file standards won't save your app from breaking when the OS vendor kills the framework you are using
- gngeal 14y ago
  "web apps run in a secure sandbox. Native code is insecure by comparison." Of course it is safe. You have at least two options: software sandboxing (NaCl, Vx32, OS-based sandboxing...) or proof-carrying typed assembly. Of course, the first option is complicated by the horrible state of the most prevalent hardware architecture available today, but that's something to be fixed in the future anyway. "irrelevant in the age of multi GHz CPUs in your phone" Oh, thank you very much. You're perpetuating the trend of "What Andy giveth, Bill taketh away" with this kind of thinking. "native platforms have bugs too" And studies confirm that the amount of bugs is largely proportional to the LOCs. The web-based approach, however adds a few million lines of code to something that would have, say, tens of thousands at most on its own.
- mbq 14y ago
  Browser sandboxes are regularly escaped, both between same-origins and surroundings of the browser. Native apps are usually verified cryptographically, mobile almost never. Webapps shamelessly reveal many information about your usage patterns and put even your cached data at risk of being revealed to third parties. Relevance of overhead depends on what you do. Not all people restrict themselves to decoding cat videos. Browser and web-app server are additional SPOFs; and browser is unauditably complex piece of software. Cloud has storage limits, low speed, great latency and zero privacy. Moreover FSes are all about interoperability; this WebKit-only API has nothing to do with that, it only gives an access to a restricted lease of space. Websockets only allow your app to talk with its mothership and its friends, not other apps working locally. Sure. They won't allow me to connect two computers behind a NAT with SSH. Nope, only certain fraction of their output. There is no option to configure them, and sharing policies do not exist. I was thinking about a way to squeeze few things on one screen; most webapps are designed to work full-screen, at most giving you a chance to open a tab. BTW WebGL is a giant security hole because for years of GPU development no-one imagined that low-level access can be given to an untrusted code. Great, but 95 in 100 of such innovations are total failures, 99 in 100 break keyboard navigation and accessibility, finally 999 in 1000 have zero personalisation options. That's not the point; they give me a chance to switch to other, working app and continue using the service/data.

by mbq 14y ago

anon1385 14y ago

The web has totally changed compared to just a few years ago. The things you mention were once issues, but are solved now :) >security issues web apps run in a secure sandbox. Native code is insecure by comparison. Users don't trust native apps. >browser overhead irrelevant in the age of multi GHz CPUs in your phone > bugs native platforms have bugs too >file systems most people don't need a file system at all when they have the cloud, but it's there if you need it http://www.html5rocks.com/en/tutorials/file/filesystem/ http://www.html5rocks.com/en/tutorials/file/filesystem/ >cross-process communication http://dev.w3.org/html5/websockets/ http://dev.w3.org/html5/websockets/ >i18n libraries for that will come >networking Websockets, WebRTC etc >device access anything common or mainstream is already available (cameras, microphones, gps, accelerometers etc) > compositing https://www.khronos.org/webgl/ https://www.khronos.org/webgl/ >UI look&feel The freedom to create your own UI without being constrained by platform conventions is going to open up many new and exciting UI paradigms now that we finally get a true open and free market in interface ideas. >About breaking cross-platform apps... there is simply a better solution -- open, solid protocols protocols and file standards won't save your app from breaking when the OS vendor kills the framework you are using

gngeal 14y ago
"web apps run in a secure sandbox. Native code is insecure by comparison." Of course it is safe. You have at least two options: software sandboxing (NaCl, Vx32, OS-based sandboxing...) or proof-carrying typed assembly. Of course, the first option is complicated by the horrible state of the most prevalent hardware architecture available today, but that's something to be fixed in the future anyway. "irrelevant in the age of multi GHz CPUs in your phone" Oh, thank you very much. You're perpetuating the trend of "What Andy giveth, Bill taketh away" with this kind of thinking. "native platforms have bugs too" And studies confirm that the amount of bugs is largely proportional to the LOCs. The web-based approach, however adds a few million lines of code to something that would have, say, tens of thousands at most on its own.
mbq 14y ago
Browser sandboxes are regularly escaped, both between same-origins and surroundings of the browser. Native apps are usually verified cryptographically, mobile almost never. Webapps shamelessly reveal many information about your usage patterns and put even your cached data at risk of being revealed to third parties. Relevance of overhead depends on what you do. Not all people restrict themselves to decoding cat videos. Browser and web-app server are additional SPOFs; and browser is unauditably complex piece of software. Cloud has storage limits, low speed, great latency and zero privacy. Moreover FSes are all about interoperability; this WebKit-only API has nothing to do with that, it only gives an access to a restricted lease of space. Websockets only allow your app to talk with its mothership and its friends, not other apps working locally. Sure. They won't allow me to connect two computers behind a NAT with SSH. Nope, only certain fraction of their output. There is no option to configure them, and sharing policies do not exist. I was thinking about a way to squeeze few things on one screen; most webapps are designed to work full-screen, at most giving you a chance to open a tab. BTW WebGL is a giant security hole because for years of GPU development no-one imagined that low-level access can be given to an untrusted code. Great, but 95 in 100 of such innovations are total failures, 99 in 100 break keyboard navigation and accessibility, finally 999 in 1000 have zero personalisation options. That's not the point; they give me a chance to switch to other, working app and continue using the service/data.