
Moving from Native Apps to Progressive Web Apps - solarengineer
https://medium.com/javascript-scene/native-apps-are-doomed-ac397148a2c0#.p4aazx6vn
======
josephg
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.

~~~
SkyMarshal
Regarding #2 I feel like Oracle is dropping the ball here with Java for the
desktop. They need to provide a lightweight JVM tailored specifically for
desktop apps and for bundling into a self-contained install package, so that
the app doesn't have to confuse users by downloading the JVM separately. Just
pack it all into a single .msi/.dmg/.dpkg/etc, download one file, install it,
and you're good to go. The JVM should be local to that app only, not global to
the whole OS.

The filesize may be a little bigger than native apps, and redundant if you
install more than one of such apps, but in this day and age of high bandwidth
and storage that's an acceptable tradeoff. I spent 2015 working on a
Win/Mac/Linux app where this would have been the preferred solution, it was
annoying that in 2016 it still doesn't exist and as a result we're getting
janky Node.js-based platforms like Electron
([http://electron.atom.io/](http://electron.atom.io/)) instead.

Qt and GTK are the only mature enough x-platform non-web-based options it
seems, but Qt is not open source and GTK's look is dated.

~~~
pjmlp
I imagine you are out of touch with Java efforts.

Since Java 8, the JDK offers tooling to package applications, making it
standard the way many third party bundlers used to work.

In Java 9 there is a linker, which will allow for an application personalised
JRE, coupled with the startup code.

The biggest problem was that using Swing properly required a mix of
programming and designer skills, which most didn't bother to learn.

At least on enterprise space of our customer base, we are still on Java and
.NET for native applications, no Electron on sight.

~~~
mateuszf
> The biggest problem was that using Swing properly required a mix of
> programming and designer skills, which most didn't bother to learn.

What about JavaFX 1/2? Do you have any information about its popularity and
usefulness?

~~~
pjmlp
Sadly yes.

It is the Java version of XAML, and it is quite nice to use, but the uptake
has been on the slow side. There were quite a few sessions at JavaONE 2016:

[https://oracle.rainfocus.com/scripts/catalog/oow16.jsp?event...](https://oracle.rainfocus.com/scripts/catalog/oow16.jsp?event=javaone&search=JavaFX&search.event=javaone)

Probably the place where it has seen more uptake has been in car infotainment
systems, like by Volkswagen.

[https://static.rainfocus.com/oracle/oow16/sess/1462531766187...](https://static.rainfocus.com/oracle/oow16/sess/1462531766187001prJx/ppt/CON2609%20-%20Prototyping%20Automotive%20Apps%20with%20JavaFX.pdf)

However our Java desktop native projects are still mostly Swing based, or make
use of either Eclipse or Netbeans as desktop framework.

And of course there is the Android Java fork, which doesn't offer any JavaFX
compatibility (some guys on the community are porting it though).

------
lkrubner
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
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.

------
millstone
> 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
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
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
If everybody likes you, you're not being honest enough.

------
chetanahuja
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
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
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
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.

~~~
pjmlp
Well, the last three years I have gotten lots of nice projects coding
greenfield native applications.

Outside the HN bubble not everyone is sold on web.

------
sssilver
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.

~~~
GeneralTspoon
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
I hope Apple does something similar and we can all move towards this
direction, which seems to be the best approach, in my opinion.

------
helthanatos
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.

------
HiroP55
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
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-d...](https://www.tune.com/blog/no-the-average-
american-does-not-download-0-apps-each-month/)

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.

------
elsigh
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

------
SCdF
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
> 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
This is the correct solution to this problem in web apps.

------
anuraj
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.

------
Animats
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.

------
pepijndevos
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
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.

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

~~~
grzm
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
It was useful on Facebook until they decided to try and strongarm everyone
into using Messenger.

------
qwtel
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.

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

~~~
ericelliott
See this comment:
[https://news.ycombinator.com/item?id=12943936](https://news.ycombinator.com/item?id=12943936)

------
dep_b
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
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
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.

------
z3t4
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!

------
unclebucknasty
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.

