Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Moving from Native Apps to Progressive Web Apps

medium.com

Post reply on HN
Print view View original

21–30 of 87 posts

Re: Moving from Native Apps to Progressive Web Apps

#21

Post by josephg »

bsder wrote: post #15
victorhooi wrote: post #11

Earlier quoted context omitted.

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/ ): h…

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

Re: Moving from Native Apps to Progressive Web Apps

#22

Post by the8472 »

pedalpete wrote: post #14
josephg wrote: post #9

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 ove…

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?

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.

Re: Moving from Native Apps to Progressive Web Apps

#23

Post by dasil003 »

josephg wrote: post #16
pedalpete wrote: post #14

Earlier quoted context omitted.

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…

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.

Re: Moving from Native Apps to Progressive Web Apps

#24

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

Re: Moving from Native Apps to Progressive Web Apps

#25

Post by the8472 »

dfabulich wrote: post #12
josephg wrote: post #9

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 ove…

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 ju…

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

Re: Moving from Native Apps to Progressive Web Apps

#26

Post by godDLL »

lkrubner wrote: post #6

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 i…

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?

Re: Moving from Native Apps to Progressive Web Apps

#27

Post by GeneralTspoon »

sssilver wrote: post #17

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 accom…

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

Re: Moving from Native Apps to Progressive Web Apps

#29

Post by SkyMarshal »

josephg wrote: post #9

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 ove…

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.

Re: Moving from Native Apps to Progressive Web Apps

#30

Post by icebraining »

chetanahuja wrote: post #10

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 Open…

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

Post reply on HN