5 ms·

- "better performance, better battery use" - this is not true at all. What makes you think so? - "better integration, better look and feel" - it depends a lot

- "better performance, better battery use" - this is not true at all. What makes you think so? - "better integration, better look and feel" - it depends a lot on available web standards, which are constantly improving. You forgot about disadvantages: Developers need to develop several versions of their app (they could spend that time on improving one version). They need several devices for testing (luckily, there are Unity and Xamarin). Authors have to pay fees for having their product in various "stores". Big corporations (such as Google, Apple, Microsoft, Steam) can throw you away anytime for any reason, accuse you of various violations. But noone can prevent you from going to a website.

je42 8y ago
even for PWA. you still need to test your app. on several devices.
coldtea 8y ago
>- "better performance, better battery use" - this is not true at all. What makes you think so? How is that even remotely controversial? With native you run direct native code, in C/C++/Obj-C/Swift/etc and optimized native UI libraries. With a PWA you run a browser engine, a DOM rendering pipeline, and on top of it you run Javascript, and on top you run one today's frameworks. Guess what uses less battery? Ever did a comparison of native vs Electron apps on the desktop, where it's easy to compare? (To preempt a facile counter-argument: yes, a native app can be coded very silly, do busy wait or whatever, and eat all the cpu/battery/memory. We're interested about baselines and what happens "everything else being equal"). >- "better integration, better look and feel" - it depends a lot on available web standards, which are constantly improving. Doesn't matter how much they improve, they will always not be 1:1 with the access to the smartphone OS's SDK libs a native app has. Nor would be the exact same look/feel as the platform (which native gives you), ever compare to someone's ad-hoc UI or re-implementation of the native L&F. >You forgot about disadvantages: Developers need to develop several versions of their app That's a disadvantage of the developer, not the user. Why would I as a user care? So that I can get more worse apps more easily? Besides, WPA still need testing -- especially if they use the "available web standards, which are constantly improving". >Authors have to pay fees for having their product in various "stores" Still good in my book. Puts a somewhat higher barrier for crap.
- untog 8y ago
  On the UI front, I'd be interested to see what's possible. For instance, <input type="date"/> creates a native date input. Why not the same for navigation components etc? After all, the vast majority of native apps don't need the processing power of native, they just need the UI.
- pjmlp 8y ago
  As answered on another thread, PWAs are native apps on some OSes, like ChromeOS and Windows.
  - coldtea 8y ago
    The OS, like ChromeOS, having "first class support" for web technologies doesn't make those apps native. ChromeOS still runs a Linux underneath, and could run apps without a web layer, DOM, etc, if allowed. When most of us call for "native apps" we don't mean "first class OS support" we mean "as little BS layered crap as possible on top of the CPU" -- so AOT or even a low level VM fits that, a web rendering engine, the DOM, and JS, does not.
    - pjmlp 8y ago
      ChromeOS native apps are web apps, like it or not,that is what we get, even Android and the alternative Linux environment run inside VMs. As for the second part, that is exactly what Chakra within UWP does on Windows.
      - coldtea 8y ago
        >ChromeOS native apps are web apps, like it or not,that is what we get Again, I explained what I mean by native apps (which is what everybody means). What "we get" and whether we "like it or not" has no bearing as to whether they're native. When iOS at first had no public Obj-C SDK and only allowed web apps, those web apps weren't magically "native" just because that was what Apple encouraged/allowed. "The only type of apps that are encouraged/supported by the vendor" is not the same as them being native apps.
moreira 8y ago
> Developers need to develop several versions of their app (they could spend that time on improving one version). I hear this line so much you'd think the web app world is full of the most amazing light and high-performance web apps out there, that show the best of what we can do with our web browsers. But no, it's just full of bloated ever-growing ever-more-resource-hungry framework-heavy web apps wrapped in Electron. It's just cost-cutting, let's not pretend it's anything but. Slack is a great example of this. A text chat app that could be done natively and isn't. And the reality is it saves them money and it's acceptable to have it just as a web app. It is not, however, in any single way better than a native app could be.
JumpCrisscross 8y ago
> Developers need to develop several versions of their app Because there are, in almost all cases, different market segments. iOS users generally want a different app from Android users. For most companies, they’ll constitute different demographics, support profiles and needs. Smearing then together for cost cutting reduces product-market fit. (This reduction may be worth the cost reductions at low scales or low population differentiations.) The freedom point is valid. But that makes PWAs a good back-up, not primary choice, for apps.

je42 8y ago

even for PWA. you still need to test your app. on several devices.

coldtea 8y ago

>- "better performance, better battery use" - this is not true at all. What makes you think so? How is that even remotely controversial? With native you run direct native code, in C/C++/Obj-C/Swift/etc and optimized native UI libraries. With a PWA you run a browser engine, a DOM rendering pipeline, and on top of it you run Javascript, and on top you run one today's frameworks. Guess what uses less battery? Ever did a comparison of native vs Electron apps on the desktop, where it's easy to compare? (To preempt a facile counter-argument: yes, a native app can be coded very silly, do busy wait or whatever, and eat all the cpu/battery/memory. We're interested about baselines and what happens "everything else being equal"). >- "better integration, better look and feel" - it depends a lot on available web standards, which are constantly improving. Doesn't matter how much they improve, they will always not be 1:1 with the access to the smartphone OS's SDK libs a native app has. Nor would be the exact same look/feel as the platform (which native gives you), ever compare to someone's ad-hoc UI or re-implementation of the native L&F. >You forgot about disadvantages: Developers need to develop several versions of their app That's a disadvantage of the developer, not the user. Why would I as a user care? So that I can get more worse apps more easily? Besides, WPA still need testing -- especially if they use the "available web standards, which are constantly improving". >Authors have to pay fees for having their product in various "stores" Still good in my book. Puts a somewhat higher barrier for crap.

untog 8y ago
On the UI front, I'd be interested to see what's possible. For instance, <input type="date"/> creates a native date input. Why not the same for navigation components etc? After all, the vast majority of native apps don't need the processing power of native, they just need the UI.
pjmlp 8y ago
As answered on another thread, PWAs are native apps on some OSes, like ChromeOS and Windows.
- coldtea 8y ago
  The OS, like ChromeOS, having "first class support" for web technologies doesn't make those apps native. ChromeOS still runs a Linux underneath, and could run apps without a web layer, DOM, etc, if allowed. When most of us call for "native apps" we don't mean "first class OS support" we mean "as little BS layered crap as possible on top of the CPU" -- so AOT or even a low level VM fits that, a web rendering engine, the DOM, and JS, does not.
  - pjmlp 8y ago
    ChromeOS native apps are web apps, like it or not,that is what we get, even Android and the alternative Linux environment run inside VMs. As for the second part, that is exactly what Chakra within UWP does on Windows.
    - coldtea 8y ago
      >ChromeOS native apps are web apps, like it or not,that is what we get Again, I explained what I mean by native apps (which is what everybody means). What "we get" and whether we "like it or not" has no bearing as to whether they're native. When iOS at first had no public Obj-C SDK and only allowed web apps, those web apps weren't magically "native" just because that was what Apple encouraged/allowed. "The only type of apps that are encouraged/supported by the vendor" is not the same as them being native apps.

moreira 8y ago

> Developers need to develop several versions of their app (they could spend that time on improving one version). I hear this line so much you'd think the web app world is full of the most amazing light and high-performance web apps out there, that show the best of what we can do with our web browsers. But no, it's just full of bloated ever-growing ever-more-resource-hungry framework-heavy web apps wrapped in Electron. It's just cost-cutting, let's not pretend it's anything but. Slack is a great example of this. A text chat app that could be done natively and isn't. And the reality is it saves them money and it's acceptable to have it just as a web app. It is not, however, in any single way better than a native app could be.

JumpCrisscross 8y ago

> Developers need to develop several versions of their app Because there are, in almost all cases, different market segments. iOS users generally want a different app from Android users. For most companies, they’ll constitute different demographics, support profiles and needs. Smearing then together for cost cutting reduces product-market fit. (This reduction may be worth the cost reductions at low scales or low population differentiations.) The freedom point is valid. But that makes PWAs a good back-up, not primary choice, for apps.