7 ms·

Sorry to say but from my perspective you seem to live in a bubble as well, to use your words. What apps do is add eas of install (app store), and usability (ca

Sorry to say but from my perspective you seem to live in a bubble as well, to use your words. What apps do is add eas of install (app store), and usability (cache, use device sensors, do some offline tasks) For a webapp the installation is "Add to homescreen" on a webpage. It then behaves like a native app, no address bar. Usability is tackled by modern browsers that allow webapps started like this to: - cache the entire webapp, and some/all data it requests. - run webworkers in background, (get push notifications, etc) - provide sensor access via APIs, (camera, etc) And to conclude, todays webapps respond FAST. They do everything the same way a native app does. Ofcourse if your webapp does video transcoding or uses some specific OS feature it might profit from being native. But even then, its unbelievable easy to wrap your webapp in a shell that adds these functionality. How do you think FB and other popular content consuming apps work nowadays? You are basically looking at webapps rendered in a shell that provides the few APIs a browser doesnt yet have, like share button and contact/calendar integration, to get/set data specific to/on your device.

nikanj 8y ago
Is there a _convenient_ way to bill the user for microtransactions and subsriptions, after you have added the page to the home screen? As far as I know, the web alternatives are miles behind the convenience of ”click the side button twice to confirm this payment” that an app provides.
- oarsinsync 8y ago
  On iOS devices that support Apple Pay, yes, this is available to the browser for transactions. Not sure what mechanism exactly, I’m just an end user using Apple Pay to pay on websites in Safari on my iPhone without any issues.
coldcode 8y ago
FB was at one time a web app, today it is a monstrous objective-c nightmare (someone a couple year ago measured 18,000 classes in the codebase). They never could get the web app to work. Building iOS apps is what I do for a living, its really not that hard.
- kyriakos 8y ago
  Of course they would, in fact they already do, it's the Facebook website itself.
- Terretta 8y ago
  That app, or rather its descendent, still works, and is arguably preferable for privacy and battery.
TeMPOraL 8y ago
I agree with GP's reasons, but not the conclusion. Native apps are going away, which is a shame, because web apps are bad. > For a webapp the installation is "Add to homescreen" on a webpage. It then behaves like a native app, no address bar. Only as long as you have an open Internet connection. Maybe a properly made web app will cache itself somehow, but that process is relatively obscure and (from the user's POV) pretty unreliable. Whereas a native app is an executable on the phone, it will run whether or not you're on a network. > They do everything the same way a native app does. Only slower and worse. Between basic UI functions being (poorly) reimplemented one abstraction layer and extra VM level higher, and random 404 screens because oops, you briefly lost connectivity, it takes lots of extra work to get a web app to native level of quality - at which point one might want to consider why they didn't write it native in the first place? > How do you think FB and other popular content consuming apps work nowadays? You are basically looking at webapps rendered in a shell that provides the few APIs a browser doesnt yet have, like share button and contact/calendar integration, to get/set data specific to/on your device. Yes, I can tell, by the frequency with which it breaks in unexpected ways, and shows its internals - by e.g. giving you a web error page instead of the app-specific one, or just giving you a blank screen. Webapps are just "worse is better" in action. Gross.
jaegerpicker 8y ago
Almost nothing you said here is true. Add to homescreen is a horrid broken mess on iOS, caching is broken/bugging as hell on chrome and safari, webworkers are really horrid battery drains and again don’t work on iOS. Wrapping a native HTML5 mixed with native code results in a buggy, spaghetti code mess of an app. Also literally NONE of the biggest most popular apps are HTML5/native. FB, Twitter, Uber, etc... are all native apps.
- fabrice_d 8y ago
  Yes, Apple is good at keeping their web stack good enough for "regular" web browsing but not feature full enough to compete with their native toolkits. And of course, doesn't allow alternative implementations of the web stack on their platform...
  - JumpCrisscross 8y ago
    Isn’t there a security argument for limiting native APIs to apps from the App Store?
    - kyriakos 8y ago
      True but for web apps you use the same way to give permissions to use your device sensors you would use for a native app. The only difference is that it doesn't pass through the app store review process and apple gets no cut for it.
      - JumpCrisscross 8y ago
        > for web apps you use the same way to give permissions to use your device sensors you would use for a native app Which would mean any malicious site a user got tricked into visiting can access the native API. (Downloading an app is more deliberate than visiting a site and instinctively clicking to make the pop-up go away.) All I'm saying is there are non-financial reasons why an OS designer might sandbox websites from the native API.
  - 8y ago
me551ah 8y ago
>How do you think FB and other popular content consuming apps work nowadays? Majority of the content on these apps is native and not html/js. They have a small amount of content on the settings screens in html/js but all of the main view code is native. For an app with complex layouts and content like facebook, html/js scroll performance would be far too slow. You can easily verify this by running the application with UIAutomator turned on which will show you the widgets being used on screen. Native is faster because it's not layout and control agnostic. So you get controls like recyclerview which recycle view elements while scrolling large lists to keep animations smoooth. Sure, you can implement that in javascript too, but the javascript can't beat a native c++ implementation which is also GPU accelerated. This is also the reason why frameworks like React Native and Flutter were born. They use javascript/dart but render all UI content natively which allows them to maintain smooth 60fps animations. To be honest, I wouldn't like mobile going the html/js way at all. Html/js has moved to desktop with electron and the results aren't that great. They take up huge amounts of memory ( gmail web on chrome takes up 500mb of ram on my machine, also slack is a noteworthy mention). Native desktop apps take up a fraction of that memory. For the sake of accessibility we have significantly sacrificed performance. I can't wait for webassembly to be widely adopted so that the browser can move away from html/js. Google has a nifty tool called ArcWelder which allows android apps to run in chrome. Apple has already announced support for running iOS apps on Mac. Would people really want to use html/js apps if they have native and more performant apps available on their platform?
ken 8y ago
> For a webapp the installation is "Add to homescreen" on a webpage. It then behaves like a native app, no address bar. Usability is tackled by modern browsers that allow webapps started like this to ... Does this finally work? I remember first reading about this many years ago. I tried to make a simplest-possible webpage that I could "add to homescreen" and have it work like a native app. Unfortunately, there were too many critical features that were missing, broken, or unreliable. Every couple years I've tried again, and every time I've failed. Does it finally work? Is there any example of a webpage which can successfully pretend it's a phone app?
steve1977 8y ago
> For a webapp the installation is "Add to homescreen" on a webpage. It then behaves like a native app No, it doesn't, I'm sorry. It's often a far cry from how a native app would be behave, both in terms of usability and performance.

nikanj 8y ago

Is there a _convenient_ way to bill the user for microtransactions and subsriptions, after you have added the page to the home screen? As far as I know, the web alternatives are miles behind the convenience of ”click the side button twice to confirm this payment” that an app provides.

oarsinsync 8y ago
On iOS devices that support Apple Pay, yes, this is available to the browser for transactions. Not sure what mechanism exactly, I’m just an end user using Apple Pay to pay on websites in Safari on my iPhone without any issues.

coldcode 8y ago

FB was at one time a web app, today it is a monstrous objective-c nightmare (someone a couple year ago measured 18,000 classes in the codebase). They never could get the web app to work. Building iOS apps is what I do for a living, its really not that hard.

kyriakos 8y ago
Of course they would, in fact they already do, it's the Facebook website itself.
Terretta 8y ago
That app, or rather its descendent, still works, and is arguably preferable for privacy and battery.

TeMPOraL 8y ago

I agree with GP's reasons, but not the conclusion. Native apps are going away, which is a shame, because web apps are bad. > For a webapp the installation is "Add to homescreen" on a webpage. It then behaves like a native app, no address bar. Only as long as you have an open Internet connection. Maybe a properly made web app will cache itself somehow, but that process is relatively obscure and (from the user's POV) pretty unreliable. Whereas a native app is an executable on the phone, it will run whether or not you're on a network. > They do everything the same way a native app does. Only slower and worse. Between basic UI functions being (poorly) reimplemented one abstraction layer and extra VM level higher, and random 404 screens because oops, you briefly lost connectivity, it takes lots of extra work to get a web app to native level of quality - at which point one might want to consider why they didn't write it native in the first place? > How do you think FB and other popular content consuming apps work nowadays? You are basically looking at webapps rendered in a shell that provides the few APIs a browser doesnt yet have, like share button and contact/calendar integration, to get/set data specific to/on your device. Yes, I can tell, by the frequency with which it breaks in unexpected ways, and shows its internals - by e.g. giving you a web error page instead of the app-specific one, or just giving you a blank screen. Webapps are just "worse is better" in action. Gross.

jaegerpicker 8y ago

Almost nothing you said here is true. Add to homescreen is a horrid broken mess on iOS, caching is broken/bugging as hell on chrome and safari, webworkers are really horrid battery drains and again don’t work on iOS. Wrapping a native HTML5 mixed with native code results in a buggy, spaghetti code mess of an app. Also literally NONE of the biggest most popular apps are HTML5/native. FB, Twitter, Uber, etc... are all native apps.

fabrice_d 8y ago
Yes, Apple is good at keeping their web stack good enough for "regular" web browsing but not feature full enough to compete with their native toolkits. And of course, doesn't allow alternative implementations of the web stack on their platform...
- JumpCrisscross 8y ago
  Isn’t there a security argument for limiting native APIs to apps from the App Store?
  - kyriakos 8y ago
    True but for web apps you use the same way to give permissions to use your device sensors you would use for a native app. The only difference is that it doesn't pass through the app store review process and apple gets no cut for it.
    - JumpCrisscross 8y ago
      > for web apps you use the same way to give permissions to use your device sensors you would use for a native app Which would mean any malicious site a user got tricked into visiting can access the native API. (Downloading an app is more deliberate than visiting a site and instinctively clicking to make the pop-up go away.) All I'm saying is there are non-financial reasons why an OS designer might sandbox websites from the native API.
- 8y ago

me551ah 8y ago

>How do you think FB and other popular content consuming apps work nowadays? Majority of the content on these apps is native and not html/js. They have a small amount of content on the settings screens in html/js but all of the main view code is native. For an app with complex layouts and content like facebook, html/js scroll performance would be far too slow. You can easily verify this by running the application with UIAutomator turned on which will show you the widgets being used on screen. Native is faster because it's not layout and control agnostic. So you get controls like recyclerview which recycle view elements while scrolling large lists to keep animations smoooth. Sure, you can implement that in javascript too, but the javascript can't beat a native c++ implementation which is also GPU accelerated. This is also the reason why frameworks like React Native and Flutter were born. They use javascript/dart but render all UI content natively which allows them to maintain smooth 60fps animations. To be honest, I wouldn't like mobile going the html/js way at all. Html/js has moved to desktop with electron and the results aren't that great. They take up huge amounts of memory ( gmail web on chrome takes up 500mb of ram on my machine, also slack is a noteworthy mention). Native desktop apps take up a fraction of that memory. For the sake of accessibility we have significantly sacrificed performance. I can't wait for webassembly to be widely adopted so that the browser can move away from html/js. Google has a nifty tool called ArcWelder which allows android apps to run in chrome. Apple has already announced support for running iOS apps on Mac. Would people really want to use html/js apps if they have native and more performant apps available on their platform?

ken 8y ago

> For a webapp the installation is "Add to homescreen" on a webpage. It then behaves like a native app, no address bar. Usability is tackled by modern browsers that allow webapps started like this to ... Does this finally work? I remember first reading about this many years ago. I tried to make a simplest-possible webpage that I could "add to homescreen" and have it work like a native app. Unfortunately, there were too many critical features that were missing, broken, or unreliable. Every couple years I've tried again, and every time I've failed. Does it finally work? Is there any example of a webpage which can successfully pretend it's a phone app?

steve1977 8y ago

> For a webapp the installation is "Add to homescreen" on a webpage. It then behaves like a native app No, it doesn't, I'm sorry. It's often a far cry from how a native app would be behave, both in terms of usability and performance.