4 ms·

Also there is no app store on the web, no 30% fee. So no incentive for mobile platform owners to make it first class citizen.

by forty 5y ago

Retric 5y ago
The web isn’t a first class citizen on desktop as you can’t run new AAA games in one. The real difference is the web is a more limited UI that breaks down when your also forced to use the more limited interface of mobile. For example on desktop the top 10% or so of the screen is taken up by the browsers UI and tabs which is normally fine. On a tablet in keyboard mode your left with ~40% of the screen being useable. Native applications sidestep this by not needing the browsers UI.
- quonn 5y ago
  This is a very important point. Mobile web apps primarily don‘t feel right because of the browser UI and also because the interaction with scrolling/tapping is never quite as perfect.
- wffurr 5y ago
  AAA games are a weird example. It's one of the few app categories that really needs full native performance, although a lot of them can also scale nicely to run on older hardware. WebGPU and WebAssembly are getting close to matching the speed and capabilities of older hardware. Tab UI is possible to hide, and has been for some time. You can "app-ify" a web site into a dedicated window with no browser UI. ISTR apps that we doing this >10 years ago. I think the real differences break down to economics. Can't charge an app store fee for web sites or force sites to use your advertising network.
  - Retric 5y ago
    > Tab UI is possible to hide That’s not a solution to the issue though. An independent application is managed by the OS, but websites are generally managed by the browser which has multiple tabs. Users don’t want every tab to be treated like it’s own app, which means websites need to play nice with the browsers UI even if the OS did give them full control. Now, mobile OS have mechanisms to treat websites as native apps but your still stuck with web baggage. From a users perspective installing this website as a native app is simply worse than installing native app. Basically when you start improving the websites as app enough, such as gracefully handling network outages, you just end up with a native application. From the other direction anything that would be fine as a website is already fine. You don’t get websites killing huge numbers of native apps because in that case there weren’t any native apps built to be killed.
  - Zarel 5y ago
    For me, the big thing I can't do with a web app is work around the keyboard. If I try to write a chat app, the keyboard will often cover the text box, and there's often no way to prevent this. There's no APIs for "tell me where the on-screen keyboard is so I can move the app UI out of the way" or even "automatically resize the window to exclude the keyboard". The options for showing a numpad are also very limited. <input type="number"> exists, but it doesn't work for things that aren't numbers, like codes starting with 0.
- deleted 5y ago
  [deleted]
dijit 5y ago
Going to point out the irony of Steve Jobs not wanting an App Store at all and preferring a rich web experience. And devs getting mad at that.
- jeroenhd 5y ago
  I think the anger was justified at the time. The rich web experience back in those days was extremely limited (as it still sometimes is, on iOS). There was no way anyone was going to write a music player that could compete with the built-in one using just the "rich web experience". Connection speeds in the original iPhone era were low, as was processing power. Spotify wouldn't have been able to provide you with the service it can provide over the web now. The focus on the web was also a complete break from existing smartphones, where installing applications had been the norm for years. iPhones weren't exactly the first to feature apps, or even app stores, and delivering an iPhone experience that was as smooth as a Windows Mobile or Blackberry experience was going to be difficult without native code. At the same time, everyone already knew that upper and middle management (and all the other departments to convince when introducing new software) were going to buy iPhones because new, shiny Apple stuff often scores well as a status symbol. At the time, it made complete sense to be mad. It's not that people didn't want to create websites, it's that websites were simply not equivalent to the real deal. A lot has changed since then.
  - mumblemumble 5y ago
    As I recall, the "rich web experience" that Jobs was pushing for didn't mean it would be mobile Web for everything. Wasn't his idea that apps could be installed locally, but would be written in JavaScript and use a Web stack for the UI? Given the popularity of tools like Cordova and React Native, and the absolute dominance of Electron on desktop, I'd say he wasn't exactly wrong.
    - squarefoot 5y ago
      > Wasn't his idea that apps could be installed locally, but would be written in JavaScript and use a Web stack for the UI? That would essentially have been Firefox OS, minus HTML5 that wasn't yet ready back then.

Also there is no app store on the web, no 30% fee. So no incentive for mobile platform owners to make it first class citizen.

by forty 5y ago

Also there is no app store on the web, no 30% fee. So no incentive for mobile platform owners to make it first class citizen.

Retric 5y ago

The web isn’t a first class citizen on desktop as you can’t run new AAA games in one. The real difference is the web is a more limited UI that breaks down when your also forced to use the more limited interface of mobile. For example on desktop the top 10% or so of the screen is taken up by the browsers UI and tabs which is normally fine. On a tablet in keyboard mode your left with ~40% of the screen being useable. Native applications sidestep this by not needing the browsers UI.

quonn 5y ago
This is a very important point. Mobile web apps primarily don‘t feel right because of the browser UI and also because the interaction with scrolling/tapping is never quite as perfect.
wffurr 5y ago
AAA games are a weird example. It's one of the few app categories that really needs full native performance, although a lot of them can also scale nicely to run on older hardware. WebGPU and WebAssembly are getting close to matching the speed and capabilities of older hardware. Tab UI is possible to hide, and has been for some time. You can "app-ify" a web site into a dedicated window with no browser UI. ISTR apps that we doing this >10 years ago. I think the real differences break down to economics. Can't charge an app store fee for web sites or force sites to use your advertising network.
- Retric 5y ago
  > Tab UI is possible to hide That’s not a solution to the issue though. An independent application is managed by the OS, but websites are generally managed by the browser which has multiple tabs. Users don’t want every tab to be treated like it’s own app, which means websites need to play nice with the browsers UI even if the OS did give them full control. Now, mobile OS have mechanisms to treat websites as native apps but your still stuck with web baggage. From a users perspective installing this website as a native app is simply worse than installing native app. Basically when you start improving the websites as app enough, such as gracefully handling network outages, you just end up with a native application. From the other direction anything that would be fine as a website is already fine. You don’t get websites killing huge numbers of native apps because in that case there weren’t any native apps built to be killed.
- Zarel 5y ago
  For me, the big thing I can't do with a web app is work around the keyboard. If I try to write a chat app, the keyboard will often cover the text box, and there's often no way to prevent this. There's no APIs for "tell me where the on-screen keyboard is so I can move the app UI out of the way" or even "automatically resize the window to exclude the keyboard". The options for showing a numpad are also very limited. <input type="number"> exists, but it doesn't work for things that aren't numbers, like codes starting with 0.
deleted 5y ago
[deleted]

dijit 5y ago

Going to point out the irony of Steve Jobs not wanting an App Store at all and preferring a rich web experience. And devs getting mad at that.

jeroenhd 5y ago
I think the anger was justified at the time. The rich web experience back in those days was extremely limited (as it still sometimes is, on iOS). There was no way anyone was going to write a music player that could compete with the built-in one using just the "rich web experience". Connection speeds in the original iPhone era were low, as was processing power. Spotify wouldn't have been able to provide you with the service it can provide over the web now. The focus on the web was also a complete break from existing smartphones, where installing applications had been the norm for years. iPhones weren't exactly the first to feature apps, or even app stores, and delivering an iPhone experience that was as smooth as a Windows Mobile or Blackberry experience was going to be difficult without native code. At the same time, everyone already knew that upper and middle management (and all the other departments to convince when introducing new software) were going to buy iPhones because new, shiny Apple stuff often scores well as a status symbol. At the time, it made complete sense to be mad. It's not that people didn't want to create websites, it's that websites were simply not equivalent to the real deal. A lot has changed since then.
- mumblemumble 5y ago
  As I recall, the "rich web experience" that Jobs was pushing for didn't mean it would be mobile Web for everything. Wasn't his idea that apps could be installed locally, but would be written in JavaScript and use a Web stack for the UI? Given the popularity of tools like Cordova and React Native, and the absolute dominance of Electron on desktop, I'd say he wasn't exactly wrong.
  - squarefoot 5y ago
    > Wasn't his idea that apps could be installed locally, but would be written in JavaScript and use a Web stack for the UI? That would essentially have been Firefox OS, minus HTML5 that wasn't yet ready back then.