Moving from Native Apps to Progressive Web Apps • Hacker News Board

Re: Moving from Native Apps to Progressive Web Apps

#11

Post by victorhooi » Sun, Nov 13, 2016, 7:09 AM UTC

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…

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.

Re: Moving from Native Apps to Progressive Web Apps

#12

Post by dfabulich » Sun, Nov 13, 2016, 7:20 AM UTC

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

Re: Moving from Native Apps to Progressive Web Apps

#13

Post by inimino » Sun, Nov 13, 2016, 7:29 AM UTC

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…

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.

Re: Moving from Native Apps to Progressive Web Apps

#14

Post by pedalpete » Sun, Nov 13, 2016, 7:44 AM UTC

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?

Re: Moving from Native Apps to Progressive Web Apps

#15

Post by bsder » Sun, Nov 13, 2016, 8:01 AM UTC

victorhooi wrote: post #11

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…

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.

Re: Moving from Native Apps to Progressive Web Apps

#16

Post by josephg » Sun, Nov 13, 2016, 8:07 AM UTC

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?

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.

Re: Moving from Native Apps to Progressive Web Apps

#17

Post by sssilver » Sun, Nov 13, 2016, 8:16 AM UTC

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.

Re: Moving from Native Apps to Progressive Web Apps

#18

Post by Animats » Sun, Nov 13, 2016, 8:18 AM UTC

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.

Re: Moving from Native Apps to Progressive Web Apps

#19

Post by [deleted] » Sun, Nov 13, 2016, 8:19 AM UTC

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…

[deleted]

Re: Moving from Native Apps to Progressive Web Apps

#20

Post by josephg » Sun, Nov 13, 2016, 8:22 AM UTC

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…

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.