Live data from Hacker News

Betting on the Web – Why I Build PWAs

joreteg.com

91–100 of 151 posts

Re: Betting on the Web – Why I Build PWAs

#91
I'm not sure I understand the motive behind progressive web apps. Some apps I can see being web-only. But apps that require extensive storage, low latency, and much more traditional computing resources isn't going to work in the mold of a PWA. A calendar, a chat room, or some games I can see fitting the PWA mold automatically. But like I said, PWA to me isn't a universal replacement for good native app development. It fits many lightweight problems but anything else that better fits native should stay native. I really wish web developers would acknowledge this much and stop trying to say "why can't you make that a web app?"

Re: Betting on the Web – Why I Build PWAs

#92

Earlier quoted context omitted.

I think you may misunderstand. The bus company provides live information. This is not a schedule, so cannot be downloaded ahead of time.

What if I just want the schedule though? It's not unusual that I'm underground (perhaps getting off a subway train) and don't have connection.

Then download the schedule from the web site?

Re: Betting on the Web – Why I Build PWAs

#93

Deciding to bet on the web is fine, but shouldn't the immediate next thought be like 'wait, why did the web win?' I think that's a far more interesting topic. It would be hard to argue that it didn't win, and it certainly wouldn't have been easy to see it coming. Someone designed a system for static hyperlinked document presentation... then years later others start shoehorning in broken bits of application-like funct…

To add on to this, the centralization factor of your webapp being a google search away is just one token of the overarching theme of "write once, run anywhere" -- this translates to value for the user. Web apps are quite literally the only thing that can be run on essentially any device that is or can be connected to the internet. Nothing else achieved this because nothing else had an interpreter which was the most e…

Well there's also some other factors I would think... as soon as you want that fancy web app of yours to convert a 10GB video file you're going to be sad. Or if you want to have control of your data. Or if you don't want someone ELSE to have control of your data. Or if you don't want them listening to everything you say, profiling everything you do, and lacing everything with advertising... Much is done remotely which has absolutely no need to be. Voice recognition is the perfect example now. Sure you need a gigantic corpus and a datacenter full of GPUs to train the recognizer... but once its trained, you could use it on a raspberry pi without a problem. But the company wouldn't get the data that way.

There's no reason a similar system couldn't be built to deliver platform-native applications that run with full access to data you control and which call out to corporate servers only for situations where those corporations are going to provide actual VALUE that couldn't be had locally couldn't be made. It just hasn't been.

Re: Betting on the Web – Why I Build PWAs

#94

Earlier quoted context omitted.

What if I just want the schedule though? It's not unusual that I'm underground (perhaps getting off a subway train) and don't have connection.

Then download the schedule from the web site?

So... like a PWA?

Re: Betting on the Web – Why I Build PWAs

#95
Here's what I've realized lately. Our product is for teachers (K-6 mostly) who tend to not be very techy. They use phones, tablets, etc. to the extent that they need to. We spent TONS of time optimizing our website for mobile. At one point it was a PWA that was very optimized and had like a 95 lighthouse score (not anymore because of finicky SW behavior). They didn't care one bit. Like, not even one little bit. To them, it was annoying that it wasn't "an app".

I don't think this battle is one of "build good enough mobile web experiences", it's more "convince non-techy users that a good mobile web experience is good enough for you in x% of cases." For us who read HN, we're jaded on apps, installs, 100mb of storage wasted. For the less techy world, they don't feel the pain we do, and that will continue to be a problem.

Re: Betting on the Web – Why I Build PWAs

#98
post #33

Earlier quoted context omitted.

This really depends on what the app is . A few of my friends use apps to look up when the next bus is coming. I use the official website. There's zero need for their apps to be available offline, they only thing they're for is looking up the next bus, which requires an internet connection. The app in this case gives absolutely no advantage to the website. I find that's the case for a lot of phone apps

> look up when the next bus is coming That's ridiculous argument against offline use - bus schedules are small enough data that we print them out and carry them in our pockets. Sure, if the bus company socks, it might be nice to know about changes due to roadwork, real-time updates (ie look up the next bus via it's gps location and speed) - but doing off-line route planning would be a great feature...

Can you elaborate why offline use is something that matters for bus schedules?

I mean, I get the usefulness of wilderness-related apps (e.g. ocean fishing) or various things that could be useful in an emergency like the aftermath of a hurricane, and for these offline functionality matters, but for buses, if you're within a few miles of a bus stop and the buses are running at all, then you're guaranteed to have high-speed cellular internet access and offline features don't matter.

I can imagine being in the middle of some national park where the closest bus is unimaginably far away but I still have mobile internet access, but I really can't imagine a situation where I'd care about buses but don't have internet. Or are USA data plans so small that it's worth thinking about the data usage (as opposed to just latency) of downloading a webpage with timetables?

Re: Betting on the Web – Why I Build PWAs

#99

Here's what I've realized lately. Our product is for teachers (K-6 mostly) who tend to not be very techy. They use phones, tablets, etc. to the extent that they need to. We spent TONS of time optimizing our website for mobile. At one point it was a PWA that was very optimized and had like a 95 lighthouse score (not anymore because of finicky SW behavior). They didn't care one bit. Like, not even one little bit. To th…

This doesn't match my experience. I've recently built an "intranet" website for some consukting agency. They had an IOS app already, but no android app. I built them a SPA based on create-react-app with a material design look and feel, making sure it worked fine both on desktops and on phones (which also means changing how certain things are presented, not just scaling the same screens). I told them to try the "add to start screen" link on chrome mobile (or the equivalent in IOS safari)... they ended up ditching the IOS app altogether.

All in all, it depends hugely on the functionalities your app/web provides, and whether you can build an experience that is app-like enough or not...

Post reply on HN