Hacker News new | comments | ask | show | jobs | submit login
Moving from Native Apps to Progressive Web Apps (medium.com)
124 points by solarengineer on Nov 13, 2016 | hide | past | web | favorite | 85 comments



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.


In addition to the benefits you mention, web sites can be created/updated without anyone's approval, and web browsers make URLs prominent (which makes it easy to share content via any textual format).

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


The unilateral updates and URLs pointing to remote content also have downsides.

* 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


My point is that the technical problems have been solved. That is to say, there aren't any new, difficult CS problems we have to figure out before we can bring the desktop up to par.

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.


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/) 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.


> Qt is not open source

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.

https://www.qt.io/licensing/

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


He's probably referring to QT5. If you're a for-profit business and using QT, most likely your software is closed-sourced which requires a commercial license.

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.


Open source doesn't always mean that one can do whatever they want with it, nor does it mean gratis.

Still, LGPL libraries can be used for commercial software, this is a rather common use case.


Yes, we looked at Qt 1.5yrs ago, and we were a for-profit startup creating an MIT-licensed open source desktop software that we needed to add a UI to, for which we were considering Qt5 for specific features. It was a weird, edge case mix.


Have you looked at "Self-Contained Application Packaging"?

https://docs.oracle.com/javase/8/docs/technotes/guides/deplo...

(Disclaimer: I work for Oracle but I don't speak for them)


Thank you! Is this supported/automated well in any IDEs?


NetBeans supports it - https://netbeans.org/kb/docs/java/native_pkg.html

(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):

https://bugs.eclipse.org/bugs/show_bug.cgi?id=441274

https://wiki.eclipse.org/JDT_UI/Java_Packager


Thanks!


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.


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


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

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


I am a bit out of touch, last looked at this stuff in spring of 2015, thanks for the update, good to see!


Why would you want to solve the problems of native apps rather than solve the problem (there is only one) of web apps, which is the performance issue.

Customers don't install apps for the most part. Why try to solve for that?


Why? Because building hack on top of hack is convenient, but terrible craftsmanship. The web today is a red hot mess of overlapping standards and inconsistent APIs. Google chrome is up to ~20M lines of code now, which makes it bigger than the linux kernel (with every device driver). Its basically a small virtualised operating system at this point.

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 reason native apps have avoided that fate is because they are not cross-platform, they are entirely controlled by a single vendor. Of course you also have cross-platform GUI toolkits like Java and Qt, but they suck because they don't have true vendor support.

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.


The irony in all this push towards web apps is that browsers will become more and more bloated, out of the user's control and insecure.

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


> The stack is a mess, and I don't see any direction it can possibly go but fatter, bigger and uglier than ever before.

Yes, the stack is a mess! I am hopeful that Web Assembly will make things better.


The problem of the browser environment is that it is yet another, less-powerful abstraction level on top of the operating system.

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.


This. And performance is actually very easy to solve, it is already solved by the sites like hn, wikipedia, etc: focus on content and drop all the useless "beautiful" stuff.


> Performance of modern web apps is simply awful compared to their native counterparts by any measure

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.


The app is said to have over 18,000 classes: http://quellish.tumblr.com/post/126712999812/how-on-earth-th...

I'm guessing that link will crash on mobile, it slows down chrome on a desktop.


The native app tracks you harder, better but alas, not faster.

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.


I am also voting along josephg.

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.


You are following that guy on twitter, you will he is a avid javascript guy. So you can take his words with a grain of salt.

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.


Interesting that you mention #2. This is what Instant apps want to solve. tbh I wonder if it is that much of an issue but we are probably going to test it at some point.

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.


Web apps do not need to be slow, they are slow because they are badly written or more usually rely on the network far too often. There is no reason

    <Button android:id="@+id/button"
is faster than

    <button>


> Web apps do not need to be slow

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.


Rendering engines are capable of turning html into on screen drawn pixels more than fast enough for the user to perceive and are capable of maintaining 60fps drawing.

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


> we built an OS and application suite that on low end hardware compared often favorably than the equivalent on Android

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?


Most of the code and metrics are now outdated but https://wiki.mozilla.org/Firefox_OS/Performance will have some historical perspective, http://eideticker.mozilla.org/#/android/lg-g2x/mozilla-centr... was our test for comparison between android and fxos.

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


I think the problem is that web apps is new and we are still experimenting, but new developers, and there are a lot of them, now start with learning a framework, that compiles to another framework that compiles to a framework that complies to JavaScript and HTML. I think we need to take some steps back, and try writing plain old HTML, CSS and JavaScript and also teach new developers how to do so.


That's a lot of do this/do that. With native apps you get all that for free with no effort and there is always a lot of room for optimization. The web on the other hand is hostile to apps.


The first one is also precompiled for quick parsing at compile time and doesn't burn battery/CPU every time a user accesses the app.


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://www.youtube.com/watch?v=__KvYxcIIm8

and they used quite a few clever tricks to tweak performance.


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


The desktop is (slowly) making inroads on that front through app sandboxing, backported from mobile operating systems like ios and android. I really look forward to being able to run native apps on my desktop without worrying about the network & filesystem access they have.


That is the whole point.

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.


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.


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.


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?


I'm sure there was plenty wrong with 1960s printing presses and the engineers working on them were looking forward to a radical overhaul of the technology, instead of supporting a cruft of legacy technology that was holding them back from designing fancier machines and fancier papers.

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.


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


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.


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


If everybody likes you, you're not being honest enough.


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.


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.


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


"They weren't wrong, but how many bare metal software do you see today?"

Umm... This discussion is about mobile devices right? Almost all my usage of my phone is on native apps.


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.


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.


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.


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.


Google are starting to do some work on this front with Android 'Instant Apps': https://developer.android.com/topic/instant-apps/index.html


I hope Apple does something similar and we can all move towards this direction, which seems to be the best approach, in my opinion.


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.


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?


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

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.


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


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.


> 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


This is the correct solution to this problem in web apps.


Navigation is usually the first way I discover than an app is web based and disappoints me.

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.


>you want the button to go "up" rather than back...you'd expect hitting back at this point would take you to the contact list.

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?


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.


Well, the idea is useful, but the examples at "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.


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.


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.


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


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.


It was useful on Facebook until they decided to try and strongarm everyone into using Messenger.


And probably won't. They're not in apple's interests to make web apps feel native.


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.


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



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.


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.


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.


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!


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.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: