9 ms·

Moving from Native Apps to Progressive Web Apps

124 points by solarengineer 10y ago

symlinkk 10y ago
push notifications from web apps isn't even supported yet on iOS
- kyriakos 10y ago
  And probably won't. They're not in apple's interests to make web apps feel native.
- grzm 10y ago
  Personally, I'm thankful for that. I can see how some might find them useful. I personally disable them whenever the browser presents me with the request dialog. I'm glad I'm presented with the option.
  - petepete 10y ago
    It was useful on Facebook until they decided to try and strongarm everyone into using Messenger.
millstone 10y ago
> From now on, I won’t be building any more native apps It looks like the author blogs exclusively about JavaScript. What native apps has this author built?
- on_and_off 10y ago
  Well, at least it won't be too difficult for him to commit to this. More seriously, this kind of comment seems to almost entirely come from javascript devs.
  - sotojuan 10y ago
    The article is by probably the worst blogger in the JS community. Full of hyperbole, biased if any research, always trying to sell his courses, and strange sources (dude quotes himself fairly often).
    - ericelliott 10y ago
      If everybody likes you, you're not being honest enough.
- ericelliott 10y ago
  I admit, I don't do a lot of native mobile development, but of course I have participated in the production of many mobile apps, mostly servicing middle and back-end tiers using JavaScript and Node (because I specialize in JavaScript). For instance, I wrote a bunch of the code the powers mobile notifications for mobile apps connected to the Adobe Creative Cloud. One of the biggest problems I saw with maintaining separate apps was that we struggled to keep feature parity across the products, and that would frustrate our users when they switched back and forth between the web app and the mobile apps. Features they depended on in the web app didn't exist in the native app or vice verse. Yet another compelling reason to choose the universal web platform technology.
lkrubner 10y ago
Native apps are helped by the weakness of HTTP/HTML. For some reason, the tech industry has been slow to admit what seems obvious -- that a technology designed in 1989 to let academics trade documents is a terrible solution for doing modern apps. At least for now, the tech industry has chosen a strategy of incremental improvement (of HTTP/HTML) rather than radical overhaul, but there does come a point when the pain is too much, and a radical overhaul begins to seem like an easier solution. Consider React, and also Om, and Om Next. These strike me as proto-types for the technology that will eventually replace HTTP/HTML. If you'd like to build a great GUI for an app that has to constantly interact with outside events/data, then you might expect to have these 4 elements: 1.) inbox 2.) outbox 3.) meta 4.) display Both React and Om Next have moved somewhat in this direction. But both still struggle with the limitations imposed by HTTP/HTML. A particular limitation is the old notion of a "markup language", with its roots in SGML. Markup languages are great when academics exchange documents. But markup languages are terrible for GUIs for apps. Also worth noting, of the 4 items I listed above, consider how much they map to what Joe Armstrong wrote about modules in Erlang, and consider how much thought and research, over the course of decades, has suggested that these 4 ideas, bound together, are important for building resilient systems. At some point the tech industry is going to get rid of HTTP/HTML, and something like React or Om Next is going to become the dominant paradigm for building a GUI for TCP, that is a GUI for an app that interacts with events over the network. Until that happens, native apps will continue to thrive, at least because they are built with tools that give sane options for the GUI.
- inimino 10y ago
  Two questions: 1. What's wrong with HTTP that hasn't already been addressed? I think we can agree on HTML having some limitations. 2. What do your four elements represent? I haven't seen this exact breakdown before.
- godDLL 10y ago
  Could you please define more specifically, or explain by example how an app (say a todo list) can be decomposed into the four elements you call inbox, outbox, meta and display?
- qwtel 10y ago
helthanatos 10y ago
Native apps will die to hybrid apps but probably not to full web apps. There are some functions for apps that are much better done natively than through support wrappers and such that overly complicate the whole scenario. Hybrid apps are great for providing a UI that can be drastically overhauled with relative ease. They provide ways to make web feel native. Any app that is installed should feel like a native app. Hybrid apps are the way forward for small developer teams but large app devs should stick to native for the power and performance.
elsigh 10y ago
I'm a web developer, and excited about progressive web apps. But until we have access to sensors and video streaming that isn't subpar, and sweet/easy camera APIs - this idea is good but simply not great- and that's a big difference when it comes to making an amazing UX on your crappy little phone. At least today: * service workers only on chrome * the install prompt is totally not a native browser feature * mobile web browsers are straight up slower at rendering
josephg 10y ago
As a web developer, I honestly hope the author of this post is wrong. Performance of modern web apps is simply awful compared to their native counterparts by any measure. They load slowly and consistently feel sluggish in comparison to proper native apps. Slack takes seconds to load and it'll happily sit on over a gig of ram while in use. (And remember, its a glorified IRC client.) Web apps only have two benefits over native apps: 1. They're easier to build in a cross-platform way, because you just have to make the app once 2. Users don't need to install anything I hope in the long run we solve both of those problems for native apps and move back to writing applications which don't depend on a DOM implementation to run. React-native is a great step toward solving (1). I hope that in time we can have modern (reactish), good looking cross-platform toolkit for native app development. But the biggest hurdle is (2), which very few people are attacking. App stores have helped a lot, but we need to be able to run native apps without installing anything. It should be as easy as it is on the web. Unfortunately native app authors usually assume all their assets are bundled. Nobody even thinks about how long it takes from the point when a user decides to install an app to when they see the first content. On the web we count that time in milliseconds and on native apps we count minutes. There aren't any hard technical problems there - we obviously manage it on the web, so its easily possible. We need native apps to catch up if they are ever going to be able to compete as a platform.
- victorhooi 10y ago
  Is this a given though? What is stopping a progressive web-app from performing as well, or nearly as well (to be impercetible). I would have assumed that most of the time waiting is on network events - so using things like service workers to handle things asynchronously, and also handle caching would reduce things. I watched a presentation on how Google made the IO 2016 webapp (https://events.google.com/io2016/ https://events.google.com/io2016/): https://www.youtube.com/watch?v=__KvYxcIIm8 https://www.youtube.com/watch?v=__KvYxcIIm8 and they used quite a few clever tricks to tweak performance.
  - bsder 10y ago
    > What is stopping a progressive web-app from performing as well, or nearly as well (to be impercetible). Direct access to graphics, direct access to network, and direct access to storage. The problem is that direct access to network and storage are ALSO security hazards.
chetanahuja 10y ago
Reading that post feels like sincere but wishful thinking. Both major mobile platforms provide the developer with sandboxed access to a more or less complete unix machine. This means complete access to things like underlying network interfaces (via sockets), Full File API access to local storage (inside the sandbox), threads, memory management (via JVM/ObjC or at a lower level in Native C), Graphics hardware via OpenGL just to name a few. Just because there's now the web standard has some half-hearted attempt at notifications doesn't change the fact that the HTML/javascript based machine available in web applications is a severely crippled platform for app development and always will be.
- icebraining 10y ago
  Yes, the web platform has more limitations, but it's a bit like when people wrote software for DOS (or bare metal) because Windows didn't give them direct access to all hardware features. They weren't wrong, but how many bare metal software do you see today? Eventually the platform provides support to the needs of 99%+ of software, and more unrestricted access becomes a special case, not the default. All of the things you've pointed out are either mostly available (File API, WebGL, ServiceWorkers, memory management using Typed Arrays like asm.js does) or will be soonish, and when all you can point to is stuff like CUDA, native apps will become the new "bare metal".
  - pjmlp 10y ago
    I see it everywhere. On my computers the only web based software is related to online travel agencies, discussion forums not based on email and news sources. When there is a native alternative, it gets installed.
    - icebraining 10y ago
      Sure, and I use Debian on all my machines, and read my email with Alpine over ssh. But I don't think that tells me much regarding the overall tendencies of software development and use.
sssilver 10y ago
This is something I've been thinking about for a while, why not make apps not require to be installed, and put them behind URLs? Something similar to the way Blizzard does their games with the Battle.net client, e.g. you click "Install", and the game is playable after only a few megabytes, and then as you play things progressively load. That could really disrupt the mobile scene, and Apple is well positioned to accomplish that.
- deleted 10y ago
  [deleted]
- GeneralTspoon 10y ago
  Google are starting to do some work on this front with Android 'Instant Apps': https://developer.android.com/topic/instant-apps/index.html https://developer.android.com/topic/instant-apps/index.html
  - dcarmo 10y ago
    I hope Apple does something similar and we can all move towards this direction, which seems to be the best approach, in my opinion.
Animats 10y ago
Well, the idea is useful, but the examples at "https://pwa.rocks/" https://pwa.rocks/" don't work too well on desktop. They run in Firefox 49, and a service worker is created, but the browser console is full of error messages. There seems to be a tendency to write these "apps" like webcrap pages, with lots of ignored errors. The Washington Post app loads "js/offline-analytics.js", some Google code which apparently snoops on you're doing while not connected and periodically sends the reports to the mothership. "Inbox Attack" works fine.
SCdF 10y ago
I am building native webapps using PWAs at the moment. They are not there yet. He touches on navigation, but misses talking about the Android hardware back button, which in PWAs hooks up to the same mechanism as it does in the browser: it goes back. This quickly stops making sense when you're making an application, as you want that button to go "up" rather than back. Imagine you are viewing a list of contacts and you: tap on a contact, tap edit to get the editable version, make some edits, tap save to get the change read-only version. In an Android app, you'd expect hitting back at this point would take you to the contact list. Here, it will take you back to edit mode for that contact. There is also little to no support for apps that want to use large or arbitrary amounts of storage (imagine spotify with offline support as a PWA), or a framework to allow users to deal with that. With a native application I can store as much data as I want, and the user can see what data I'm using in the app list, and clear my data to remove it, or simply uninstall my app. With a PWA you're limited to some confusing arbitrary amount that is unpredictable to the application, the user cannot see this amount anywhere, let along aloneside normal apps where it should be, nor can they reasonably clear the data. We are currently solving both problems, ironically, by wrapping our app in a native android app: solving the former by overriding where the hardware back button navigates to, and the solving the latter by (no joke) shipping a patched version of chromium with the obtuse quotas patched out.
- mrighele 10y ago
  > This quickly stops making sense when you're making an application, as you want that button to go "up" rather than back. Did you try to use the history API [1] for this ? Not straightforward but with either replaceState or the onpopstate event maybe you could achieve with JS what you are looking for. [1] https://developer.mozilla.org/en-US/docs/Web/API/History_API https://developer.mozilla.org/en-US/docs/Web/API/History_API
  - ericelliott 10y ago
    This is the correct solution to this problem in web apps.
- on_and_off 10y ago
pepijndevos 10y ago
One thing the article does not touch on is monetization options for web apps. This is where the App Store makes everything orders of magnitude easier.
- exodust 10y ago
  Except that these days it's more common to offer the app for free and then the user chooses or not to get premium content via in-app purchase. A web app or website can quite easily offer an upgrade to premium content if the user is already using that service. More than monetization, the app store provides stronger discover-ability than web apps.
Etheryte 10y ago
Hard to take this article seriously when it practically ignores performance topics.
- ericelliott 10y ago
  See this comment: https://news.ycombinator.com/item?id=12943936 https://news.ycombinator.com/item?id=12943936
unclebucknasty 10y ago
I prefer the "Native Apps Are Doomed" title the HN link originally had. Yeah, it's a little click-baity, but it matches the article and better tells me what it's about. Everyone knows what a native app is, but I would have never inferred by name that a Progressive Web App had any relationship to native development.
anuraj 10y ago
Native Apps Vs Web Apps is settled and Native Apps won. Web Apps offer compromised UI and performance and shall always remain a security threat - Cross Scripting, Link baiting, CORS my... . We are going to app less economy now - and contextual interactive interfaces that route to/from headless services based on advanced intelligence is the future.Apps are dying, long live the apps.
HiroP55 10y ago
Is it really that hard to build native mobile apps? No it is not. It does require learning something new. I don't hear any of my non technical friends complaining that this app isn't a web page or that I had to install a new app. I mostly hear developers who want to utilize their web development skills make the argument that native apps are bad. Is the native vs web argument actually just laziness?
- ericelliott 10y ago
  They don't complain. They just don't ever install or use the app. The average user installs less than 3 new apps per month. https://www.tune.com/blog/no-the-average-american-does-not-download-0-apps-each-month/ https://www.tune.com/blog/no-the-average-american-does-not-d... App install friction is much higher than website visit friction, and with PWA's, coming back is enough to prompt the user to install the app to their home screen with a single click. Learning something new is not the big obstacle. The big obstacle is investment vs return on investment. If you have to write the same app 3 times, that is a significantly larger investment, and potentially much smaller return if what you end up with turns away most of your users. Each click in the install process reduces the number of successful installs by 20%. So, start with 1,000 interested users. If the user has to click six times to install the app, you end up with only only 262 installs. And then you have to activate them to keep them using the app. Data shows you'll lose an average of 80% of your users after install if you fail to activate. That means you end up with 52 out of 1,000 potential users. VS PWA. Once click means you start out with 800 instead of 252, so then you just need to activate them, which gives you 160 activated users. 3x the users for 1/3rd the investment. I don't know about you, but these are pretty compelling numbers for me.
dep_b 10y ago
You can't do push notifications on iOS from a web app. But apart from that there's a category of apps for websites that never should have been made, if that's the kind of apps you have been building in the past 5 years it's OK you realise it's time to stop making apps nobody uses. I've built some of those apps in my time but the majority of my apps couldn't be done without sacrificing or completely preventing functionality as a web app.
- ericelliott 10y ago
  You can with Cordova. I've worked on several hybrid apps in recent years that took advantage of native features through a thin native wrapper. But there are a lot of apps that don't need those features at all, and those apps are a great fit for PWAs.
  - dep_b 10y ago
    Yeah but that's not what the author is talking about. Cordova applications still go through the very Apple specific tooling pipeline before end users can use it.
qwtel 10y ago
The author seems to really struggle with reconciling the click-baity title with the rather dull conclusion that native apps aren't that doomed just yet (if at all), within the last couple of paragraphs. A better title would have been: A collection of highly useful resources for getting started with progressive web apps.
z3t4 10y ago
Hey! This is more then a rant, it's a guide on how to make your web app usable without a Internet connection. This has been possible for a decade using application cache, but service workers will give more granular control and allow stuff like push notifications!

124 points by solarengineer 10y ago

symlinkk 10y ago

push notifications from web apps isn't even supported yet on iOS

kyriakos 10y ago
And probably won't. They're not in apple's interests to make web apps feel native.
grzm 10y ago
Personally, I'm thankful for that. I can see how some might find them useful. I personally disable them whenever the browser presents me with the request dialog. I'm glad I'm presented with the option.
- petepete 10y ago
  It was useful on Facebook until they decided to try and strongarm everyone into using Messenger.

millstone 10y ago

> From now on, I won’t be building any more native apps It looks like the author blogs exclusively about JavaScript. What native apps has this author built?

on_and_off 10y ago
Well, at least it won't be too difficult for him to commit to this. More seriously, this kind of comment seems to almost entirely come from javascript devs.
- sotojuan 10y ago
  The article is by probably the worst blogger in the JS community. Full of hyperbole, biased if any research, always trying to sell his courses, and strange sources (dude quotes himself fairly often).
  - ericelliott 10y ago
    If everybody likes you, you're not being honest enough.
ericelliott 10y ago
I admit, I don't do a lot of native mobile development, but of course I have participated in the production of many mobile apps, mostly servicing middle and back-end tiers using JavaScript and Node (because I specialize in JavaScript). For instance, I wrote a bunch of the code the powers mobile notifications for mobile apps connected to the Adobe Creative Cloud. One of the biggest problems I saw with maintaining separate apps was that we struggled to keep feature parity across the products, and that would frustrate our users when they switched back and forth between the web app and the mobile apps. Features they depended on in the web app didn't exist in the native app or vice verse. Yet another compelling reason to choose the universal web platform technology.

lkrubner 10y ago

Native apps are helped by the weakness of HTTP/HTML. For some reason, the tech industry has been slow to admit what seems obvious -- that a technology designed in 1989 to let academics trade documents is a terrible solution for doing modern apps. At least for now, the tech industry has chosen a strategy of incremental improvement (of HTTP/HTML) rather than radical overhaul, but there does come a point when the pain is too much, and a radical overhaul begins to seem like an easier solution. Consider React, and also Om, and Om Next. These strike me as proto-types for the technology that will eventually replace HTTP/HTML. If you'd like to build a great GUI for an app that has to constantly interact with outside events/data, then you might expect to have these 4 elements: 1.) inbox 2.) outbox 3.) meta 4.) display Both React and Om Next have moved somewhat in this direction. But both still struggle with the limitations imposed by HTTP/HTML. A particular limitation is the old notion of a "markup language", with its roots in SGML. Markup languages are great when academics exchange documents. But markup languages are terrible for GUIs for apps. Also worth noting, of the 4 items I listed above, consider how much they map to what Joe Armstrong wrote about modules in Erlang, and consider how much thought and research, over the course of decades, has suggested that these 4 ideas, bound together, are important for building resilient systems. At some point the tech industry is going to get rid of HTTP/HTML, and something like React or Om Next is going to become the dominant paradigm for building a GUI for TCP, that is a GUI for an app that interacts with events over the network. Until that happens, native apps will continue to thrive, at least because they are built with tools that give sane options for the GUI.

inimino 10y ago
Two questions: 1. What's wrong with HTTP that hasn't already been addressed? I think we can agree on HTML having some limitations. 2. What do your four elements represent? I haven't seen this exact breakdown before.
godDLL 10y ago
Could you please define more specifically, or explain by example how an app (say a todo list) can be decomposed into the four elements you call inbox, outbox, meta and display?
qwtel 10y ago

helthanatos 10y ago

Native apps will die to hybrid apps but probably not to full web apps. There are some functions for apps that are much better done natively than through support wrappers and such that overly complicate the whole scenario. Hybrid apps are great for providing a UI that can be drastically overhauled with relative ease. They provide ways to make web feel native. Any app that is installed should feel like a native app. Hybrid apps are the way forward for small developer teams but large app devs should stick to native for the power and performance.

elsigh 10y ago

I'm a web developer, and excited about progressive web apps. But until we have access to sensors and video streaming that isn't subpar, and sweet/easy camera APIs - this idea is good but simply not great- and that's a big difference when it comes to making an amazing UX on your crappy little phone. At least today: * service workers only on chrome * the install prompt is totally not a native browser feature * mobile web browsers are straight up slower at rendering

josephg 10y ago

As a web developer, I honestly hope the author of this post is wrong. Performance of modern web apps is simply awful compared to their native counterparts by any measure. They load slowly and consistently feel sluggish in comparison to proper native apps. Slack takes seconds to load and it'll happily sit on over a gig of ram while in use. (And remember, its a glorified IRC client.) Web apps only have two benefits over native apps: 1. They're easier to build in a cross-platform way, because you just have to make the app once 2. Users don't need to install anything I hope in the long run we solve both of those problems for native apps and move back to writing applications which don't depend on a DOM implementation to run. React-native is a great step toward solving (1). I hope that in time we can have modern (reactish), good looking cross-platform toolkit for native app development. But the biggest hurdle is (2), which very few people are attacking. App stores have helped a lot, but we need to be able to run native apps without installing anything. It should be as easy as it is on the web. Unfortunately native app authors usually assume all their assets are bundled. Nobody even thinks about how long it takes from the point when a user decides to install an app to when they see the first content. On the web we count that time in milliseconds and on native apps we count minutes. There aren't any hard technical problems there - we obviously manage it on the web, so its easily possible. We need native apps to catch up if they are ever going to be able to compete as a platform.

victorhooi 10y ago
Is this a given though? What is stopping a progressive web-app from performing as well, or nearly as well (to be impercetible). I would have assumed that most of the time waiting is on network events - so using things like service workers to handle things asynchronously, and also handle caching would reduce things. I watched a presentation on how Google made the IO 2016 webapp (https://events.google.com/io2016/ https://events.google.com/io2016/): https://www.youtube.com/watch?v=__KvYxcIIm8 https://www.youtube.com/watch?v=__KvYxcIIm8 and they used quite a few clever tricks to tweak performance.
- bsder 10y ago
  > What is stopping a progressive web-app from performing as well, or nearly as well (to be impercetible). Direct access to graphics, direct access to network, and direct access to storage. The problem is that direct access to network and storage are ALSO security hazards.

chetanahuja 10y ago

Reading that post feels like sincere but wishful thinking. Both major mobile platforms provide the developer with sandboxed access to a more or less complete unix machine. This means complete access to things like underlying network interfaces (via sockets), Full File API access to local storage (inside the sandbox), threads, memory management (via JVM/ObjC or at a lower level in Native C), Graphics hardware via OpenGL just to name a few. Just because there's now the web standard has some half-hearted attempt at notifications doesn't change the fact that the HTML/javascript based machine available in web applications is a severely crippled platform for app development and always will be.

icebraining 10y ago
Yes, the web platform has more limitations, but it's a bit like when people wrote software for DOS (or bare metal) because Windows didn't give them direct access to all hardware features. They weren't wrong, but how many bare metal software do you see today? Eventually the platform provides support to the needs of 99%+ of software, and more unrestricted access becomes a special case, not the default. All of the things you've pointed out are either mostly available (File API, WebGL, ServiceWorkers, memory management using Typed Arrays like asm.js does) or will be soonish, and when all you can point to is stuff like CUDA, native apps will become the new "bare metal".
- pjmlp 10y ago
  I see it everywhere. On my computers the only web based software is related to online travel agencies, discussion forums not based on email and news sources. When there is a native alternative, it gets installed.
  - icebraining 10y ago
    Sure, and I use Debian on all my machines, and read my email with Alpine over ssh. But I don't think that tells me much regarding the overall tendencies of software development and use.

sssilver 10y ago

This is something I've been thinking about for a while, why not make apps not require to be installed, and put them behind URLs? Something similar to the way Blizzard does their games with the Battle.net client, e.g. you click "Install", and the game is playable after only a few megabytes, and then as you play things progressively load. That could really disrupt the mobile scene, and Apple is well positioned to accomplish that.

deleted 10y ago
[deleted]
GeneralTspoon 10y ago
Google are starting to do some work on this front with Android 'Instant Apps': https://developer.android.com/topic/instant-apps/index.html https://developer.android.com/topic/instant-apps/index.html
- dcarmo 10y ago
  I hope Apple does something similar and we can all move towards this direction, which seems to be the best approach, in my opinion.

Animats 10y ago

Well, the idea is useful, but the examples at "https://pwa.rocks/" https://pwa.rocks/" don't work too well on desktop. They run in Firefox 49, and a service worker is created, but the browser console is full of error messages. There seems to be a tendency to write these "apps" like webcrap pages, with lots of ignored errors. The Washington Post app loads "js/offline-analytics.js", some Google code which apparently snoops on you're doing while not connected and periodically sends the reports to the mothership. "Inbox Attack" works fine.

SCdF 10y ago

I am building native webapps using PWAs at the moment. They are not there yet. He touches on navigation, but misses talking about the Android hardware back button, which in PWAs hooks up to the same mechanism as it does in the browser: it goes back. This quickly stops making sense when you're making an application, as you want that button to go "up" rather than back. Imagine you are viewing a list of contacts and you: tap on a contact, tap edit to get the editable version, make some edits, tap save to get the change read-only version. In an Android app, you'd expect hitting back at this point would take you to the contact list. Here, it will take you back to edit mode for that contact. There is also little to no support for apps that want to use large or arbitrary amounts of storage (imagine spotify with offline support as a PWA), or a framework to allow users to deal with that. With a native application I can store as much data as I want, and the user can see what data I'm using in the app list, and clear my data to remove it, or simply uninstall my app. With a PWA you're limited to some confusing arbitrary amount that is unpredictable to the application, the user cannot see this amount anywhere, let along aloneside normal apps where it should be, nor can they reasonably clear the data. We are currently solving both problems, ironically, by wrapping our app in a native android app: solving the former by overriding where the hardware back button navigates to, and the solving the latter by (no joke) shipping a patched version of chromium with the obtuse quotas patched out.

mrighele 10y ago
> This quickly stops making sense when you're making an application, as you want that button to go "up" rather than back. Did you try to use the history API [1] for this ? Not straightforward but with either replaceState or the onpopstate event maybe you could achieve with JS what you are looking for. [1] https://developer.mozilla.org/en-US/docs/Web/API/History_API https://developer.mozilla.org/en-US/docs/Web/API/History_API
- ericelliott 10y ago
  This is the correct solution to this problem in web apps.
on_and_off 10y ago

pepijndevos 10y ago

One thing the article does not touch on is monetization options for web apps. This is where the App Store makes everything orders of magnitude easier.

exodust 10y ago
Except that these days it's more common to offer the app for free and then the user chooses or not to get premium content via in-app purchase. A web app or website can quite easily offer an upgrade to premium content if the user is already using that service. More than monetization, the app store provides stronger discover-ability than web apps.

Etheryte 10y ago

Hard to take this article seriously when it practically ignores performance topics.

ericelliott 10y ago
See this comment: https://news.ycombinator.com/item?id=12943936 https://news.ycombinator.com/item?id=12943936

unclebucknasty 10y ago

I prefer the "Native Apps Are Doomed" title the HN link originally had. Yeah, it's a little click-baity, but it matches the article and better tells me what it's about. Everyone knows what a native app is, but I would have never inferred by name that a Progressive Web App had any relationship to native development.

anuraj 10y ago

Native Apps Vs Web Apps is settled and Native Apps won. Web Apps offer compromised UI and performance and shall always remain a security threat - Cross Scripting, Link baiting, CORS my... . We are going to app less economy now - and contextual interactive interfaces that route to/from headless services based on advanced intelligence is the future.Apps are dying, long live the apps.

HiroP55 10y ago

Is it really that hard to build native mobile apps? No it is not. It does require learning something new. I don't hear any of my non technical friends complaining that this app isn't a web page or that I had to install a new app. I mostly hear developers who want to utilize their web development skills make the argument that native apps are bad. Is the native vs web argument actually just laziness?

ericelliott 10y ago
They don't complain. They just don't ever install or use the app. The average user installs less than 3 new apps per month. https://www.tune.com/blog/no-the-average-american-does-not-download-0-apps-each-month/ https://www.tune.com/blog/no-the-average-american-does-not-d... App install friction is much higher than website visit friction, and with PWA's, coming back is enough to prompt the user to install the app to their home screen with a single click. Learning something new is not the big obstacle. The big obstacle is investment vs return on investment. If you have to write the same app 3 times, that is a significantly larger investment, and potentially much smaller return if what you end up with turns away most of your users. Each click in the install process reduces the number of successful installs by 20%. So, start with 1,000 interested users. If the user has to click six times to install the app, you end up with only only 262 installs. And then you have to activate them to keep them using the app. Data shows you'll lose an average of 80% of your users after install if you fail to activate. That means you end up with 52 out of 1,000 potential users. VS PWA. Once click means you start out with 800 instead of 252, so then you just need to activate them, which gives you 160 activated users. 3x the users for 1/3rd the investment. I don't know about you, but these are pretty compelling numbers for me.

dep_b 10y ago

You can't do push notifications on iOS from a web app. But apart from that there's a category of apps for websites that never should have been made, if that's the kind of apps you have been building in the past 5 years it's OK you realise it's time to stop making apps nobody uses. I've built some of those apps in my time but the majority of my apps couldn't be done without sacrificing or completely preventing functionality as a web app.

ericelliott 10y ago
You can with Cordova. I've worked on several hybrid apps in recent years that took advantage of native features through a thin native wrapper. But there are a lot of apps that don't need those features at all, and those apps are a great fit for PWAs.
- dep_b 10y ago
  Yeah but that's not what the author is talking about. Cordova applications still go through the very Apple specific tooling pipeline before end users can use it.

qwtel 10y ago

The author seems to really struggle with reconciling the click-baity title with the rather dull conclusion that native apps aren't that doomed just yet (if at all), within the last couple of paragraphs. A better title would have been: A collection of highly useful resources for getting started with progressive web apps.

z3t4 10y ago

Hey! This is more then a rant, it's a guide on how to make your web app usable without a Internet connection. This has been possible for a decade using application cache, but service workers will give more granular control and allow stuff like push notifications!