8 ms·

IMO the bigger reason to lament the loss of competition here is the app model: Firefox OS was pushing for "apps" to be web apps. That seemed a lot more open to

IMO the bigger reason to lament the loss of competition here is the app model: Firefox OS was pushing for "apps" to be web apps. That seemed a lot more open to me than pushing for apps to be proprietary (Android, iOS, Windows, etc.). As great as mobile devices are, their walled gardens stifle creativity, privacy, and choice.

Sanddancer 11y ago
Apple was pushing for "apps" to be web apps when they first released the iPhone as well [1], with Steve Jobs going as far as to say that native apps would potentially "damage the phone system". It wasn't until after the iphone was jailbroken, and people kept insisting on more powerful development choices that they started on their app store. People have been saying that webapps are the future for a decade now. At this point, I have to say it's never going to happen. [1] http://www.apple.com/pr/library/2007/06/11iPhone-to-Support-Third-Party-Web-2-0-Applications.html http://www.apple.com/pr/library/2007/06/11iPhone-to-Support-...
- Spooky23 11y ago
  Don't forget Facebook's HTML5 focus.
- benlower 11y ago
  Fair points. I think it's more nuanced. Native apps are great and necessary for many scenarios. However, there are a ton of native apps that could be just as functional as a responsive web site. Sure there were issues with discoverability which the app stores helped with in the beginning (now I think it's just as hard to get noticed in the store as it is on the open web). I don't think "web apps are the future of mobile". But I do think there is a better separation of native apps and mobile/responsive web apps.
  - wwweston 11y ago
    What's more -- a significant number of apps ARE a wrapper around a UIWebView or something like it.
    - adamdoupe 11y ago
      We've studied this and found that ~85% of the free apps on the Google Play store use a WebView (I like the term "mobile web app"): http://adamdoupe.com/publications/large-scale-study-of-mobile-web-app-security-most2015.pdf http://adamdoupe.com/publications/large-scale-study-of-mobil...
      - nodamage 11y ago
        There's a big difference between an app that 'uses a WebView' to render specific pieces of content or clicked links, and an app that is basically a thin wrapper around a WebView. Can you clarify whether your ~85% number is referring to the former or the latter?
        adamdoupe 11y ago
        Sure! The short version is that I don't know. We were looking for instances of insecure WebView usage, so from a security perspective small piece vs. entire app doesn't matter too much (and is difficult to measure, especially when looking at 1.1M apps). However, some of the other numbers from our analysis can be useful to draw a picture of WebView usage. We statically looked for uses of WebView, and 85% of the 1.1M apps used a WebView. Of those 998,286 apps: - 97% enable JavaScript (which is off by default) - 36% use the JavaScript Bridge Interface (which is a fairly good indicator of heavy WebView usage) - 94% implement a shouldOverrideUrlLoading method of the WebView (another good indicator that the developer is using the WebView for something non-trivial) - 27% implement an onReceivedSslError method of the WebView (indication that the developer is using the WebView for something non-trivial). (Sadly, 29% of the apps that implement onReceivedSslError intentionally IGNORE all SSL errors.) So I guess the takeaway is that 85% is an upper bound, the real number of WebView-only apps is absolutely lower, however it's clear that WebViews are significantly used in mobile apps.
        ori_b 11y ago
        As far as I'm aware, mobile doubleclick ads need a WebView with Javascript and shouldOverrideUrlLoading(). I'm not sure about others. How do you account for apps that only use the WebView for showing ads with the various ad toolkits out there?
  - wvenable 11y ago
    > there are a ton of native apps that could be just as functional as a responsive web site That is probably true but most would require 10x the development effort at least and be obsoleted much sooner. And then users don't want generic lowest common denominator applications; users want software to make the best use of the platform.
    - denniskane 11y ago
      If we turn the web itself into an actual developer (and user) friendly platform, then we could probably start making better use of it as an application delivery vehicle. To enable this, I've been furiously working on this OS-in-a-browser concept for the past 3+ years: https://linuxontheweb.appspot.com https://linuxontheweb.appspot.com
      - wvenable 11y ago
        "This site relies upon cutting-edge web technologies that only Chromium-based browsers have implemented." This might as well be Java.
        efes 11y ago
        > This might as well be Java. Chromium specific certainly isn't as good as open standards, but it isn't as bad as Java. Once chromium is ported to something it doesn't face legal uncertainty.
        pjmlp 11y ago
        Everyone that follows the Java license never had any issues. Only the two companies that tried to screw Sun had any issues with it.
        efes 11y ago
        If you write a free application that runs on Java on the raspberry Pi you (probably) owe Oracle nothing. If anyone builds a console around that raspberry Pi, Oracle probably is owed money because the device is no longer a general machine. That is very different than chromium or anything else that is license compatible with your typical Linux distribution. Whether or not someone owed damages is immaterial to the problem of trying to get everyone an appropriate license who might want to run your software in contexts you haven't imagined yet.
- kitsunesoba 11y ago
  I think that one day, web apps by default could work, but before that can happen the web must see sweeping change. The lackluster performance and high resource usage associated with web apps is a direct consequence of the complex patchwork nature of each component involved. Quite simply, the web was not designed to be used the way we’re using it, and evolving standards have made browser rendering engines horrifically complex (and in some cases convoluted). What’s needed is a fundamental reimagining of HTML, CSS, and the DOM at minimum with little to no regard for legacy. In the 90s, we didn’t know what we needed but now the picture is crystal clear. Should we use this knowledge to design a new web, I’m positive that the result would be just as open as the web is now while performing tens or hundreds of times better — it’d likely be good enough to make web apps competitive with native apps under a far wider set of circumstances.
  - pcwalton 11y ago
    You'll have to explain why in details, not at a high level. In particular the fact that a replacement could perform "tens or hundreds of times better" is an extraordinary claim. CSS has tons of problems, but almost every replacement for CSS that I've seen proposed would almost certainly have worse performance characteristics than CSS, optimally implemented, would. Most of them kill parallelism and kill opportunities for optimal GPU usage—they're proposed cures that are worse than the disease. The problem is mostly that browsers don't implement CSS as well as they could due to legacy, not that the technologies are fundamentally flawed (though this is not to say that they're not improvable, far from it). To create a better architecture, you first need to have an in-depth understanding of what the problems in CSS actually are. Otherwise, you'll just trade one set of mistakes for another. (In particular, a CSS replacement that optimizes for Web developer productivity will not necessarily have acceptable performance characteristics—too often, people assume that "easy to develop in" implies "runs fast", which in fact these concerns are often in direct opposition.)
    - ben0x539 11y ago
      can't wait for servo "strict mode" css!!
  - 11y ago
- bad_user 11y ago
  I've seen this anecdote given as rationale, but you can't say that the "web app" model on iPhones failed when Safari doesn't give you the needed functionality to make web apps. For example iPhone Safari does not do push notifications, an essential ingredient if you want web apps, whereas Chrome on Android does. With Chrome on Android you can do Facebook's Messenger without installing anything. And while iPhone Safari led the way with some useful additions, like the possibility of specifying higher resolution icons for "Add to Homescreen", they dropped the ball on such improvements since iPhone 3G. In fact iPhone Safari is behind in implementing web standards. Apple also rejected Adobe's Flash and I concede that was for good reasons, but that left a huge void in how media, like video and games, could be delivered. You know, things like HTML5 Video and WebGL came after that. You also have to take into account that the first two models (iPhone 1 and iPhone 3G) had poor resolution, poor hardware and poor battery life by today's standards. So you know, if Safari on iPhone 1 is the anchor by which you judge native apps, well of course native apps are better. You also make it sound like "the people" forced Apple to open their SDK. Oh come on, you can't be that gullible. An SDK was inevitable. What's the point of building your own OS if you can't lock people into its APIs? That's a lesson Microsoft taught us. The only reason for its delay was them taking the time to figure out how to control it. Do you remember when Google Voice along with other apps where rejected because they "duplicated existing functionality"? You may not see it, but web apps have been winning for some time and there's no end in sight. When Google Voice was rejected by Apple, Google still delivered its functionality by means of a web app. When the Google Maps integration app was replaced by Apple with their own, which I might say it is inferior and unusable in my city, for a while iPhone users used Google Maps on the web, as it's very much usable. All it takes for web apps on mobile phones to be more common is for the browser makers to implement the needed functionality. Right now the front-running in implementing web standards relevant for mobile phones is Google's Chrome and sadly not Firefox (though I hope that will change). And I must say it works well.
AnthonyMouse 11y ago
How is it that web apps are supposed to be open and apps are supposed to be proprietary, as though Microsoft OneDrive is "open" and IPFS is "proprietary"?
- benlower 11y ago
  Is IPFS proprietary? Have they even gotten far enough along yet to really know? OneDrive having a web client doesn't make it open. If you think about OD as just a way to access and share files then it's probably open since the web client will run in any modern browser. However if you think of OD as a platform of sorts then I wouldn't consider it open since, to my knowledge, MSFT controls everything about it and it's not standardized.
orangecat 11y ago
Firefox OS was pushing for "apps" to be web apps. That seemed a lot more open to me than pushing for apps to be proprietary This argument is made frequently, and I don't get it. With a typical web app, you have no idea what the backend is doing, and your data is stored on servers owned by third parties. At any time they can revoke your access, go out of business, share your data with others, or change the app in user-unfriendly ways. An open source Android app that runs and stores data locally (perhaps with an option for cloud storage) seems much more "open" than that.
- m52go 11y ago
  Yeah, but with a mobile app you have all those downsides...and you have to deal with the whims of a walled-garden gatekeeper like Google or Apple. That is, I can't just create an app and throw it up on a server like I can with a website. It needs to be "approved" first. That's a HUGE barrier to openness that the web never had, and hopefully never will have in the future. And, even though mobile apps run natively, I don't think one can be very confident that they're any more private than a typical website...analytics & the drive for data is there regardless of medium.
  - soylentcola 11y ago
    Not to nitpick, but people create native apps all the time and throw them up on servers for download and installation. In fact I have a handful on my phone right now. It's one of the main reasons I've gravitated toward Android on mobile and away from the more mixed iOS/Android devices I used to buy. My first smartphones running PalmOS and Windows Mobile allowed me to download and install apps from trusted developers and I disliked the dodgy hurdles I had to jump in order to do the same on iOS. I agree completely about the privacy thing though. I guess it's a bit easier to see when a native app is sending data over the network with the right tools but in general, there's just as much room for abuse with either model.
- petecox 11y ago
  'typical web app' is NOT the default deployment model for Firefox OS. Apps on the Marketplace are deployed to a device and run locally, offline - complete with an intricate permissions model. The only 'web' aspect is being written in HTML/JS/CSS and the extent to which they integrate with the cloud. No less open than the github hosted, Android app scenario you mention. Maybe Firefox OS does need an f-droid equivalent for a free app catalogue though, if and when Mozilla pull the Marketplace servers down. So be aware of the distinction between mobile web 'apps' and mobile web sites.
pjmlp 11y ago
Nokia was probably the first vendor to try out web apps with Web Widgets on Symbian. Web is never going to be as feature rich as native, until the browser becomes nothing more than yet another JavaScript VM.
DyslexicAtheist 11y ago
I too think that losing the possibility for an open model to distribute apps is the biggest loss. I did a very enthusiastic article when the news broke about FirefoxOS aiming to become a more open alternative. It's both funny and sad now reading my enthusiasm from back then http://blog.valbonne-consulting.com/2013/07/19/steve-jobs-is-dead-is-the-app-store-next/ http://blog.valbonne-consulting.com/2013/07/19/steve-jobs-is... time to move on I guess

Sanddancer 11y ago

Apple was pushing for "apps" to be web apps when they first released the iPhone as well [1], with Steve Jobs going as far as to say that native apps would potentially "damage the phone system". It wasn't until after the iphone was jailbroken, and people kept insisting on more powerful development choices that they started on their app store. People have been saying that webapps are the future for a decade now. At this point, I have to say it's never going to happen. [1] http://www.apple.com/pr/library/2007/06/11iPhone-to-Support-Third-Party-Web-2-0-Applications.html http://www.apple.com/pr/library/2007/06/11iPhone-to-Support-...

Spooky23 11y ago
Don't forget Facebook's HTML5 focus.
benlower 11y ago
Fair points. I think it's more nuanced. Native apps are great and necessary for many scenarios. However, there are a ton of native apps that could be just as functional as a responsive web site. Sure there were issues with discoverability which the app stores helped with in the beginning (now I think it's just as hard to get noticed in the store as it is on the open web). I don't think "web apps are the future of mobile". But I do think there is a better separation of native apps and mobile/responsive web apps.
- wwweston 11y ago
  What's more -- a significant number of apps ARE a wrapper around a UIWebView or something like it.
  - adamdoupe 11y ago
    We've studied this and found that ~85% of the free apps on the Google Play store use a WebView (I like the term "mobile web app"): http://adamdoupe.com/publications/large-scale-study-of-mobile-web-app-security-most2015.pdf http://adamdoupe.com/publications/large-scale-study-of-mobil...
    - nodamage 11y ago
      There's a big difference between an app that 'uses a WebView' to render specific pieces of content or clicked links, and an app that is basically a thin wrapper around a WebView. Can you clarify whether your ~85% number is referring to the former or the latter?
      - adamdoupe 11y ago
        Sure! The short version is that I don't know. We were looking for instances of insecure WebView usage, so from a security perspective small piece vs. entire app doesn't matter too much (and is difficult to measure, especially when looking at 1.1M apps). However, some of the other numbers from our analysis can be useful to draw a picture of WebView usage. We statically looked for uses of WebView, and 85% of the 1.1M apps used a WebView. Of those 998,286 apps: - 97% enable JavaScript (which is off by default) - 36% use the JavaScript Bridge Interface (which is a fairly good indicator of heavy WebView usage) - 94% implement a shouldOverrideUrlLoading method of the WebView (another good indicator that the developer is using the WebView for something non-trivial) - 27% implement an onReceivedSslError method of the WebView (indication that the developer is using the WebView for something non-trivial). (Sadly, 29% of the apps that implement onReceivedSslError intentionally IGNORE all SSL errors.) So I guess the takeaway is that 85% is an upper bound, the real number of WebView-only apps is absolutely lower, however it's clear that WebViews are significantly used in mobile apps.
        ori_b 11y ago
        As far as I'm aware, mobile doubleclick ads need a WebView with Javascript and shouldOverrideUrlLoading(). I'm not sure about others. How do you account for apps that only use the WebView for showing ads with the various ad toolkits out there?
- wvenable 11y ago
  > there are a ton of native apps that could be just as functional as a responsive web site That is probably true but most would require 10x the development effort at least and be obsoleted much sooner. And then users don't want generic lowest common denominator applications; users want software to make the best use of the platform.
  - denniskane 11y ago
    If we turn the web itself into an actual developer (and user) friendly platform, then we could probably start making better use of it as an application delivery vehicle. To enable this, I've been furiously working on this OS-in-a-browser concept for the past 3+ years: https://linuxontheweb.appspot.com https://linuxontheweb.appspot.com
    - wvenable 11y ago
      "This site relies upon cutting-edge web technologies that only Chromium-based browsers have implemented." This might as well be Java.
      - efes 11y ago
        > This might as well be Java. Chromium specific certainly isn't as good as open standards, but it isn't as bad as Java. Once chromium is ported to something it doesn't face legal uncertainty.
        pjmlp 11y ago
        Everyone that follows the Java license never had any issues. Only the two companies that tried to screw Sun had any issues with it.
        efes 11y ago
        If you write a free application that runs on Java on the raspberry Pi you (probably) owe Oracle nothing. If anyone builds a console around that raspberry Pi, Oracle probably is owed money because the device is no longer a general machine. That is very different than chromium or anything else that is license compatible with your typical Linux distribution. Whether or not someone owed damages is immaterial to the problem of trying to get everyone an appropriate license who might want to run your software in contexts you haven't imagined yet.
kitsunesoba 11y ago
I think that one day, web apps by default could work, but before that can happen the web must see sweeping change. The lackluster performance and high resource usage associated with web apps is a direct consequence of the complex patchwork nature of each component involved. Quite simply, the web was not designed to be used the way we’re using it, and evolving standards have made browser rendering engines horrifically complex (and in some cases convoluted). What’s needed is a fundamental reimagining of HTML, CSS, and the DOM at minimum with little to no regard for legacy. In the 90s, we didn’t know what we needed but now the picture is crystal clear. Should we use this knowledge to design a new web, I’m positive that the result would be just as open as the web is now while performing tens or hundreds of times better — it’d likely be good enough to make web apps competitive with native apps under a far wider set of circumstances.
- pcwalton 11y ago
  You'll have to explain why in details, not at a high level. In particular the fact that a replacement could perform "tens or hundreds of times better" is an extraordinary claim. CSS has tons of problems, but almost every replacement for CSS that I've seen proposed would almost certainly have worse performance characteristics than CSS, optimally implemented, would. Most of them kill parallelism and kill opportunities for optimal GPU usage—they're proposed cures that are worse than the disease. The problem is mostly that browsers don't implement CSS as well as they could due to legacy, not that the technologies are fundamentally flawed (though this is not to say that they're not improvable, far from it). To create a better architecture, you first need to have an in-depth understanding of what the problems in CSS actually are. Otherwise, you'll just trade one set of mistakes for another. (In particular, a CSS replacement that optimizes for Web developer productivity will not necessarily have acceptable performance characteristics—too often, people assume that "easy to develop in" implies "runs fast", which in fact these concerns are often in direct opposition.)
  - ben0x539 11y ago
    can't wait for servo "strict mode" css!!
- 11y ago
bad_user 11y ago
I've seen this anecdote given as rationale, but you can't say that the "web app" model on iPhones failed when Safari doesn't give you the needed functionality to make web apps. For example iPhone Safari does not do push notifications, an essential ingredient if you want web apps, whereas Chrome on Android does. With Chrome on Android you can do Facebook's Messenger without installing anything. And while iPhone Safari led the way with some useful additions, like the possibility of specifying higher resolution icons for "Add to Homescreen", they dropped the ball on such improvements since iPhone 3G. In fact iPhone Safari is behind in implementing web standards. Apple also rejected Adobe's Flash and I concede that was for good reasons, but that left a huge void in how media, like video and games, could be delivered. You know, things like HTML5 Video and WebGL came after that. You also have to take into account that the first two models (iPhone 1 and iPhone 3G) had poor resolution, poor hardware and poor battery life by today's standards. So you know, if Safari on iPhone 1 is the anchor by which you judge native apps, well of course native apps are better. You also make it sound like "the people" forced Apple to open their SDK. Oh come on, you can't be that gullible. An SDK was inevitable. What's the point of building your own OS if you can't lock people into its APIs? That's a lesson Microsoft taught us. The only reason for its delay was them taking the time to figure out how to control it. Do you remember when Google Voice along with other apps where rejected because they "duplicated existing functionality"? You may not see it, but web apps have been winning for some time and there's no end in sight. When Google Voice was rejected by Apple, Google still delivered its functionality by means of a web app. When the Google Maps integration app was replaced by Apple with their own, which I might say it is inferior and unusable in my city, for a while iPhone users used Google Maps on the web, as it's very much usable. All it takes for web apps on mobile phones to be more common is for the browser makers to implement the needed functionality. Right now the front-running in implementing web standards relevant for mobile phones is Google's Chrome and sadly not Firefox (though I hope that will change). And I must say it works well.

AnthonyMouse 11y ago

How is it that web apps are supposed to be open and apps are supposed to be proprietary, as though Microsoft OneDrive is "open" and IPFS is "proprietary"?

benlower 11y ago
Is IPFS proprietary? Have they even gotten far enough along yet to really know? OneDrive having a web client doesn't make it open. If you think about OD as just a way to access and share files then it's probably open since the web client will run in any modern browser. However if you think of OD as a platform of sorts then I wouldn't consider it open since, to my knowledge, MSFT controls everything about it and it's not standardized.

orangecat 11y ago

Firefox OS was pushing for "apps" to be web apps. That seemed a lot more open to me than pushing for apps to be proprietary This argument is made frequently, and I don't get it. With a typical web app, you have no idea what the backend is doing, and your data is stored on servers owned by third parties. At any time they can revoke your access, go out of business, share your data with others, or change the app in user-unfriendly ways. An open source Android app that runs and stores data locally (perhaps with an option for cloud storage) seems much more "open" than that.

m52go 11y ago
Yeah, but with a mobile app you have all those downsides...and you have to deal with the whims of a walled-garden gatekeeper like Google or Apple. That is, I can't just create an app and throw it up on a server like I can with a website. It needs to be "approved" first. That's a HUGE barrier to openness that the web never had, and hopefully never will have in the future. And, even though mobile apps run natively, I don't think one can be very confident that they're any more private than a typical website...analytics & the drive for data is there regardless of medium.
- soylentcola 11y ago
  Not to nitpick, but people create native apps all the time and throw them up on servers for download and installation. In fact I have a handful on my phone right now. It's one of the main reasons I've gravitated toward Android on mobile and away from the more mixed iOS/Android devices I used to buy. My first smartphones running PalmOS and Windows Mobile allowed me to download and install apps from trusted developers and I disliked the dodgy hurdles I had to jump in order to do the same on iOS. I agree completely about the privacy thing though. I guess it's a bit easier to see when a native app is sending data over the network with the right tools but in general, there's just as much room for abuse with either model.
petecox 11y ago
'typical web app' is NOT the default deployment model for Firefox OS. Apps on the Marketplace are deployed to a device and run locally, offline - complete with an intricate permissions model. The only 'web' aspect is being written in HTML/JS/CSS and the extent to which they integrate with the cloud. No less open than the github hosted, Android app scenario you mention. Maybe Firefox OS does need an f-droid equivalent for a free app catalogue though, if and when Mozilla pull the Marketplace servers down. So be aware of the distinction between mobile web 'apps' and mobile web sites.

pjmlp 11y ago

Nokia was probably the first vendor to try out web apps with Web Widgets on Symbian. Web is never going to be as feature rich as native, until the browser becomes nothing more than yet another JavaScript VM.

DyslexicAtheist 11y ago

I too think that losing the possibility for an open model to distribute apps is the biggest loss. I did a very enthusiastic article when the news broke about FirefoxOS aiming to become a more open alternative. It's both funny and sad now reading my enthusiasm from back then http://blog.valbonne-consulting.com/2013/07/19/steve-jobs-is-dead-is-the-app-store-next/ http://blog.valbonne-consulting.com/2013/07/19/steve-jobs-is... time to move on I guess