Moving from Native Apps to Progressive Web Apps
medium.com
medium.com
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.
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://www.youtube.com/watch?v=__KvYxcIIm8
and they used quite a few clever tricks to tweak performance.
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.
Native apps are fast and enjoy every feature the OS has to offer.
Web apps are a pile of hacks that require conferences sharing clever tricks, usually browser specific, to make them usable at all.
> Performance of modern web apps is simply awful compared to their native counterparts
> There aren't any hard technical problems there - we obviously manage it on the web, so its easily possible
"easily?" Didn't you just say we're managing it badly on the web?
It turns out that it's quite difficult to develop an app-like experience that loads from scratch on a cellular connection and is ready for the user to interact in just seconds. The app folks will have it just as bad, if not worse, because they've got no practice.
Instead solving this problem will 'just' require tons of work. We need to improve our compilation toolchains to allow native apps to load progressively. We'll need better ways to monitor and analyse application size & performance. We'll need new libraries and we'll need buy in from vendors. And as thats going on we need to convince developers to actually care about this stuff. Again, all these problems have been solved for the web. We 'just' need to backport all that stuff to native apps.
No question there's lots of work to do. But its all (obviously) solvable with code.
* it assumes you're online
* features can be removed at any time even if the user relies on them
* link rot
* totally unsuited for sensitive data
Customers don't install apps for the most part. Why try to solve for that?
How many more lines of code do you think it'll take for chrome to feel fast and light again? Is it possible to achieve that by adding code, forever? And then to work around all the cruft in browsers we have frameworks like react - conceptually beautiful but which do layout by diffing thousands of DOM elements through javascript.
The stack is a mess, and I don't see any direction it can possibly go but fatter, bigger and uglier than ever before. Forever. Surprisingly, this is a fate native apps have avoided. And in avoiding that fate new laptops have amazing battery life and work great. Well, until you open chrome or slack that is.
> Customers don't install apps for the most part. Why try to solve for that?
I don't write code for customers. I do it because as a kid I fell in love with the craft. I just... didn't fall in love with programming for this. Nope nope nope I want off the train before I throw up.
The web has solved these things: it's an open standard which any serious device maker must support to be taken seriously. It can load applications in a relatively safe sandbox on demand. And it does all this with tremendous backwards compatibility that even 90s Microsoft would be envious of.
You're absolutely right Chrome is a virtualized operating system, but that's what it takes to be open and cross platform. Designing a better platform is the easy part; getting it to cross the chasm where it has first class device vendor support on a majority of platforms is the practically insurmountable part. I'm not saying it can't happen, but I don't think any organized group of humans has the power to do it intentionally.
Chrome is not a virtualized OS, it has become a mega-plugin similar to Java or Flash, except with better but still insufficient security. As more of the platform services are exposed to the internet, we'll start seeing new and interesting exploits, such as tracking users based on battery status and attacks on the local network (https://news.ycombinator.com/item?id=12406310).
Yes, the stack is a mess! I am hopeful that Web Assembly will make things better.
And the worst thing is that it is a hermetically sealed abstraction. There is no escape hatch to access the underlying primitives in those cases where you need them. Even virtual machines offer device passthrough these days for those cases where the virtualization overhead is too expensive and you need exclusive, direct access to some hardware. You could even assign the device to a container inside the VM.
Browsers offer no such way to punch through all the abstraction layers.
They don't even speak berkeley sockets.
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/) 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.
Not only is Qt open source, it is also free software according to FSF. Core Qt and most modules are released under the LGPL, the rest under the GPL.
Qt even has a binding poison-pill promise that will make the code BSD-licensed should Qt (the company) stop releasing it. See https://www.kde.org/community/whatiskde/Software_License_Agr... and https://www.kde.org/community/whatiskde/kdefreeqtfoundation....
I've worked with a team who develops a windows app which still uses QT4. They cannot migrate to QT5 since it requires a commercial license.
Still, LGPL libraries can be used for commercial software, this is a rather common use case.
https://docs.oracle.com/javase/8/docs/technotes/guides/deplo...
(Disclaimer: I work for Oracle but I don't speak for them)
(I can't comment on whether it is supported well since I've never used that part of NetBeans.)
Eclipse was apparently working on support for it at one point, but it looks to me like the work has stalled (just my impression from their bug database, I don't really know):
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.
What about JavaFX 1/2? Do you have any information about its popularity and usefulness?
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...
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...
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).
For what is worth I can now only access FB from my phone using the browser (the web-app, so to speak), the native FB app has become ridiculously slow for quite some time. I use the native app only for uploading photos, once every 3 or 4 months. I'm using an iPhone 4 of which I'm still pretty happy, don't feel the need to drop 600+ euros on a New phone just yet if this one still does its job.
I'm guessing that link will crash on mobile, it slows down chrome on a desktop.
This will be fixed once web apps get more capabilities, don't worry, the entire web development community (except the josephg fellow above) is praying for it.
Since I returned back to native apps development, couldn't be happier, instead of having to deal daily with the crap and hacks on top of hacks, to make a stack designed for interactive documents work as a virtual machine.
<Button android:id="@+id/button"
<button>They are slow because HTML rendering engines are slow, they are slow because Javascript engines aren't that fast compared to Java, C or Swift. Native frameworks don't need to deal with the complexity of an HTML layout and CSS. And native applications can be optimized to use way less memory than web apps. There is very little room for performance tuning in a web app, since it depends on the browser engine. Something good for a browser can degrade performances in another browser.
> <Button android:id="@+id/button">
Isn't dynamic, it is inflated once and turned in a class instance.
> <button>
Is highly dynamic as it can be replaced by anything at any time in an HTML page.
JavaScript can certainly deal with handling user input faster than the user can perceive, rendering engines can 'inflate' html (cache the layer tree) of dom that hasnt been invalidated.
While a commercial failure I worked on Firefox OS and we built an OS and application suite that on low end hardware compared often favorably than the equivalent on Android. The web does not need to be slower than native applications it just needs to be built better
I haven't heard this before. I assumed firefox os failed because the web stack proved to be too crufty for the low end hardware. Are you aware of any resources that go into more detail?
When we started it was an open question whether we could build a fast enough platform to compete with native applications, thats no longer a question I think about.
People think the web is slow because opening facebook.com takes >200 requests loading >4MB over the network of which a large chunk blocks any rendering (and all of which interferes with it). Build a web application which loads its UI from disk, caches application data, only touches the network for updates, does not block rendering waiting on bundles of JavaScript and uses proper practices for JS / dom manipulation (use transforms over animating top/left, dont attach process heavy scroll handlers) and your web app will be as fast as a native app
About #1. I am not that convinced that they are easier to build. Well they are, but building them in a way that fits each platform and performs well looks harder than making 2 apps.
I should mention that I work in a 30 devs teams (half iOS, half Android) working on the same in-house app.
I do believe that there is some potential to reduce duplicated work with something like j2objc. It is probably not the definitive expression of this concept, but it seems to me that it should be possible to share a lot of the business logic and this is what this tool aims to do. Some of the data objects should be shareable as well.
All the rest : UI, integrating with the Home screen, notifications, services, et cetera is just very specific to the platform and IMO should be written specifically for each platform.
I am still waiting for the perfect kotlin-to-swift library allowing that.
I never see any web app one mobile feel good. But you never know.
also, with kotlin and swift doing native app is not that complicated. Learning a new API on top of native API I don't think is safe.
Also, google, apple they can change the rules and parts of the apps don't work anymore for x reason.
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.
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.
As we know, there indeed was a major overhaul in the way publishing works, just not in a way those engineers hoped for.
I think the same is true for the web. It's not an engineer's paradise, but it does a good enough job for the people who are using it, it gets gradually better, and it will probably experience a radical overhauled at some point -- just not in a way any of us hoped for or could even imagine at this point.
It looks like the author blogs exclusively about JavaScript. What native apps has this author built?
More seriously, this kind of comment seems to almost entirely come from javascript devs.
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.
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.
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".
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.
Outside the HN bubble not everyone is sold on web.
Umm... This discussion is about mobile devices right? Almost all my usage of my phone is on native apps.
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.
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.
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.
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
For example Steam is just the worst app that I use often. Pages take ages to load, and navigation is simply broken. scrolling through a page, clicking on an element then hitting back makes often (they have started solving this in some pages) me lose my scroll in the previous page. Other times, the back action is just absent. As a result, window shopping is just awful in a shopping app. I ended up using the webpage for buying games, just ridiculous.
Can this be handled by your app's design? For instance, could you have the toggle between edit and save take place on the same page (i.e. on the same URL) like a SPA, while the list is a different URL?
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.
More than monetization, the app store provides stronger discover-ability than web apps.
A better title would have been: A collection of highly useful resources for getting started with progressive web apps.
But there are a lot of apps that don't need those features at all, and those apps are a great fit for PWAs.
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.