Betting on the Web – Why I Build PWAs(joreteg.com)
joreteg.com
Betting on the Web – Why I Build PWAs
https://joreteg.com/blog/betting-on-the-web
150 comments
Being able to use the 'app' offline is a pretty important feature tho. I almost always have web access, but most apps also almost never need it (for me to do what I want to do).
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
I feel like such an app could download the bus schedule and do this all offline (and let the user know it is simply an estimate)
In fact, I really wish Google Maps did this, but I guess the damage of getting it wrong once is far greater than getting it right 100 times.
Phones are pretty powerful with huge storage. If you can compute directions offline, why not buses? Saving a map or route is tiny compared to the 64, 128, or 256 GB storage on most people's devices, surely bus schedules can't be that big.
In fact, I really wish Google Maps did this, but I guess the damage of getting it wrong once is far greater than getting it right 100 times.
Phones are pretty powerful with huge storage. If you can compute directions offline, why not buses? Saving a map or route is tiny compared to the 64, 128, or 256 GB storage on most people's devices, surely bus schedules can't be that big.
I think you may misunderstand. The bus company provides live information. This is not a schedule, so cannot be downloaded ahead of time.
Many public transit agencies provide both static and real-time data.
- static data often is sharing using the "GTFS" specification, which includes stop locations, route geometries, scheduled trips, etc. See http://gtfs.org/
- real-time data is shared using a variety of specifications, and typically includes vehicle locations, service alerts, and other notifications from the agency
The static kind of data can certainly be cached for local use. Try browsing and downloading some from the Transitland open transit data platform and its API: https://transit.land
- static data often is sharing using the "GTFS" specification, which includes stop locations, route geometries, scheduled trips, etc. See http://gtfs.org/
- real-time data is shared using a variety of specifications, and typically includes vehicle locations, service alerts, and other notifications from the agency
The static kind of data can certainly be cached for local use. Try browsing and downloading some from the Transitland open transit data platform and its API: https://transit.land
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.
The online search takes into account all short term schedule modifications. Considering how many such changes occur on almost daily basis, you would be quickly complaining about data usage from all those schedule updates. Or you would frequently get wrong route.
Either way, a lot of complexity / resources spent on something trivially solved by the original solution (webpage).
Either way, a lot of complexity / resources spent on something trivially solved by the original solution (webpage).
Some buses don't have schedules, just an estimated frequency. Or some have schedules but don't stick to them with any reliability.
Not providing schedules because some buses don't have them seems like throwing the baby out with the bathwater.
The bus schedule is available on the bus company website. The only thing that app gives over that is what the schedule is now.
You clearly haven't ridden the buses in Boston.
There should be paper schedules available in the station.
the app is in leveraging the rider's actual experience ... each time the rider rides the bus, she records the time of arrival - eg takes a photo of the bus - and builds a record of actual arrival times. the app makes predictions about when the bus will come.
Even for this use case, an app (including offline-enabled PWA) should load faster than an online-only website if they're designed properly, because the app UI is pre-cached and it's just making a small JSON web request for the next bus.
> 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...
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...
It sounds like you're not a daily bus rider. The printed bus schedules are useless due to delays. I take transit into work everyday and you need to know when the next bus is coming or you risk waiting at a station for twenty minutes.
Yeah, they're majorly helpful for transit commuters - you can avoid extended wait times, know when you can take a walk to the convenience store or even know when there's another or a bigger bus coming so you can decide whether it's worth getting on the packed bus or waiting for the next one. It really does change the transit game a lot.
[deleted]
In Missoula, Montana, where I live, the Mountain Line app shows you where every individual bus on a given route is, and computes ETA to a selected bus stop.
I'm pretty sure that's common functionality.
(To be honest, the Mountain Line is very punctual, so I could likely do just fine with just a printed schedule.)
I'm pretty sure that's common functionality.
(To be honest, the Mountain Line is very punctual, so I could likely do just fine with just a printed schedule.)
Where I currently live, the bus app does the same, but the difference between scheduled time at each individual stop is typically 1-3 minutes. So it's not like off-line functionality would be useless, even if on-line can add value. But it obviously only adds value when you're on-line - and if off-line the app doesn't work at all...
Displaying the live AVL data for all Missoula busses is not too bad. In Seattle where I currently live, not so much. Thus, most of our apps here tend to give arrival times of busses with nearby stops.
Fun aside: my dad drove for the Mountain Line many years ago. I rescued one of his 1970s yellow shirts with the embroidered logo patch a while back.
Fun aside: my dad drove for the Mountain Line many years ago. I rescued one of his 1970s yellow shirts with the embroidered logo patch a while back.
You must not live in a city with over 100 bus schedules.. in my city, the offline app which uses your location data to tell you what bus stops are nearby and what the arrival times of each bus are, is immensely helpful.
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?
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?
> 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
This just isn't the case in the United States. There are large swaths of the country that straight up don't have high speed internet in any form.
This just isn't the case in the United States. There are large swaths of the country that straight up don't have high speed internet in any form.
But those large swaths apparently have a bustling public transit system? Sorry, rural America lacks both decent cell service AND decent busses.
Certainly, our rural public transit is a catastrophe in it's own right. That still supports the argument that there is a very real use case for offline bus schedule lookup.
edit: /apps/lookup
edit: /apps/lookup
Nah, you're wrong! [You're not totally wrong, tho you wrote in really broad absolutes.] Even your example would be a much better app with offline support. The app shouldn't stop working just because of a hiccup in the user's internet connectivity.
If I, the user, switch from the when-is-the-next-bus-coming app to another app and then switch back (within, say, a few minutes), it'd be really great if the app could default to showing me info based on the data it just downloaded instead of automatically resetting the UI and waiting to update it until it downloads the data again.
If I, the user, switch from the when-is-the-next-bus-coming app to another app and then switch back (within, say, a few minutes), it'd be really great if the app could default to showing me info based on the data it just downloaded instead of automatically resetting the UI and waiting to update it until it downloads the data again.
Correct me if I'm wrong, but PWA's support 'offline mode'. React's official tool, `create-react-app` comes with this boilerplate enabled by default.
[deleted]
PWAs can do offline.
I've always naively assumed that apps were given preference because they are better at gathering info about the user (can get location more easily for instance, can phone home whenever...) and better at displaying ads (no Adblock there), and therefore I'm surprised nobody evokes this. Don't you think it's at least partly true?
Surprised I didn't find this comment up higher. This is my first thought every time. Good observation!
> > You don't have to create a native app because PWAs now offer all the functionality of a native app.
I didn't think you could do arbitrary network or disk I/O. The sandbox is really, really nice for many applications, but PWAs aren't suitable for all native applications.
I didn't think you could do arbitrary network or disk I/O. The sandbox is really, really nice for many applications, but PWAs aren't suitable for all native applications.
My thoughts exactly, wondering why so many here are saying they are equivalent? PWA disk usage has tiny limits.
For the curious: https://developers.google.com/web/fundamentals/instant-and-o...
For the curious: https://developers.google.com/web/fundamentals/instant-and-o...
> I think it's going to be an uphill battle just to convince them that in many cases, you don't even need an app. You just need a mobile website.
but, isn't it a lot less expensive to build and maintain a mobile website than to build apps for both iOS and android? wouldn't that win the argument in a lot of cases?
but, isn't it a lot less expensive to build and maintain a mobile website than to build apps for both iOS and android? wouldn't that win the argument in a lot of cases?
What about sensors/stuff on the hardware that the browser may not be able to access?
Edit: I have seen some browser demos that could show your phone's orientation. In the past the camera trigger was not reliable that was in 2013-2014 if I recall dang time flies.
Edit: I have seen some browser demos that could show your phone's orientation. In the past the camera trigger was not reliable that was in 2013-2014 if I recall dang time flies.
The author also points out (correctly) that web apps are smaller than their equivalent native app. That's nice, but I'm not terribly constrained as far as storage goes on my phone. I am constrained by battery life and data consumption.
> The author also points out (correctly) that web apps are smaller than their equivalent native app.
Well, the author straw-mans that web apps are smaller. Yes, web apps are lighter than equivalent native apps. But not to anywhere near the degree described in the article.
There's no legitimate reason for the Starbucks app to be 100MB. None. A native Android app equivalent to the PWA in the article would come in at about about 2MB, for instance.
Starbucks app is huge because they stuffed it with something (same for Twitter, Facebook, etc). Starbucks new PWA is clean and light because it hasn't (yet) been stuffed with the equivalent junk. It's not a technology difference, it's a political/corporate one.
Well, the author straw-mans that web apps are smaller. Yes, web apps are lighter than equivalent native apps. But not to anywhere near the degree described in the article.
There's no legitimate reason for the Starbucks app to be 100MB. None. A native Android app equivalent to the PWA in the article would come in at about about 2MB, for instance.
Starbucks app is huge because they stuffed it with something (same for Twitter, Facebook, etc). Starbucks new PWA is clean and light because it hasn't (yet) been stuffed with the equivalent junk. It's not a technology difference, it's a political/corporate one.
Google will punish badly made web apps though, whereas the same apparently doesn't apply to native apps.
Even worse every time you go to Starbucks.com you might re-download all of the junk. If you use it multiple times a day, that's a lot of wasted bandwidth compared to a slim (unusual in these days) native app.
The value of PWAs with service worker support is that redownloads don't happen. That's also how they can have offline support (on Android at least, safari currently has a lest robust caching story)
I think one of the uphill battles you're going to have to fight with PWAs is end-user habit. If Joe consumer is looking for a great way to see a weather forecast he's going to look for an app. Jane wants to play podcasts - she's looking for an app. Ezra wants a Jewish calendar - app store.
99 times out of a hundred for the smartphone carrying crowd, the app store has become a replacement for google searches when it comes to tools/games/toys for their slab-o-glass...
99 times out of a hundred for the smartphone carrying crowd, the app store has become a replacement for google searches when it comes to tools/games/toys for their slab-o-glass...
You don't have to change users, you have to get Google and Apple to change. There's no technical reason they couldn't include web apps in their app stores. In the article the author speculates that both Google and Apple are working on this. I could see Google embracing web apps, but I'd be surprised if Apple does.
I would be seriously surprised if any smartphone company added PWA's to their app stores. Web apps inherently can't take advantage of many platform/model specific features. Even thing like UI elements, fonts, gestures etc. OS manufacturers want their feature sets used because it adds value to their ecosystem. As a consumer of smartphone apps, I tend to agree with them.
Microsoft announced at BUILD this year that PWAs would be ingested by the Bing crawler directly into the Windows Store, with tools for sites to opt out or further control their listings (including monetizing them).
The Windows Store has supported server-hosted web apps [1] for some time now, and provides a large subsection of the platform-specific libraries to hosted web apps. Hosted Web Apps are based on earlier drafts of PWA standards, but the expectation from BUILD and other Microsoft talks is that they will bring platform-specific libraries along for the ride as the converge to more recent PWA standards.
[1] https://developer.microsoft.com/en-us/windows/bridges/hosted...
The Windows Store has supported server-hosted web apps [1] for some time now, and provides a large subsection of the platform-specific libraries to hosted web apps. Hosted Web Apps are based on earlier drafts of PWA standards, but the expectation from BUILD and other Microsoft talks is that they will bring platform-specific libraries along for the ride as the converge to more recent PWA standards.
[1] https://developer.microsoft.com/en-us/windows/bridges/hosted...
Apple and Microsoft are actually dragging their feet to embrace PWA's until they can be regulated by their app stores and monetized. It's actually really annoying if you're interested in developing PWAs, because one of the nicest features is that it's a pseudo-native app that is cross compatible and doesn't have to be registered in any app stores.
You can already add PWA's to your home screen: https://developers.google.com/web/fundamentals/engage-and-re...
It's not that far of a leap to think they'll be added to the app store.
It's not that far of a leap to think they'll be added to the app store.
not only in the stores, widgets and general integration with the os (like actionable notifications etc.) are one of the things that make native apps a necesity. To appear in the widget screen in ios or make a homescreen widget in android you must have a native app.
Actionable notifications have been a feature of PWAs in Chrome for over a year now: https://developers.google.com/web/updates/2016/01/notificati...
That's progress, but that's not exactly a home screen widget. Eg, I can see "20C" and an icon showing it's rainy right on my phone's home screen. I don't think you can do that with the web yet, hopefully people are working on it.
I think you're wrong about the uphill battle part. Most users don't bother with new apps at all.
https://www.recode.net/2016/9/16/12933780/average-app-downlo...
Keep in mind this is in the US. People in developing countries, on older and slower devices with limited bandwidth, are even less likely to download new apps.
https://www.recode.net/2016/9/16/12933780/average-app-downlo...
Keep in mind this is in the US. People in developing countries, on older and slower devices with limited bandwidth, are even less likely to download new apps.
Oh they actually do. The thing is that people already have all the apps what they need, so there is no regular need to download other apps. But when such need arrives though, they head to the appstore.
The reality in developing countries is actually completely opposite. People in those countries love apps and use WiFi etc. to downlod them in coffee shops/schools/offices... so they can keep using the service only by downloading the minimalistic json instead of downloading whole service with UI/GFX etc. each time they need it.
I tried using some of those PWA now online and they do work better than traditional webapps, however they are still slightly laggish and have unfinished feeling when compared to native apps.
PWA is going to be almost certain flop. It's trying to do almost same what React Native has already done but with PWA you have to convince the users to switch from the secure, trusted, well working apps to "inferior and unsure webapps" and from just pressing the app icon back to the old school "open browser, select address bar, enter address, press enter"-hassle. Changing this mentality that people have build for almost 10 years now is probably going to be as easy as to make Trump change his opinion about the wall.
The reality in developing countries is actually completely opposite. People in those countries love apps and use WiFi etc. to downlod them in coffee shops/schools/offices... so they can keep using the service only by downloading the minimalistic json instead of downloading whole service with UI/GFX etc. each time they need it.
I tried using some of those PWA now online and they do work better than traditional webapps, however they are still slightly laggish and have unfinished feeling when compared to native apps.
PWA is going to be almost certain flop. It's trying to do almost same what React Native has already done but with PWA you have to convince the users to switch from the secure, trusted, well working apps to "inferior and unsure webapps" and from just pressing the app icon back to the old school "open browser, select address bar, enter address, press enter"-hassle. Changing this mentality that people have build for almost 10 years now is probably going to be as easy as to make Trump change his opinion about the wall.
You know that one of the major features PWAs offer is creating an app icon so you can launch it just like an app in a headless browser and use it offline, right?
I don't think that's what headless browser means...
Yeah, maybe I chose a bad word - I meant a browser with no controls.
It's surprising to me that everyone who is against PWAs doesn't even know what a PWA is.
How can be webapp less secure than native app?
Or maybe web apps are going to be good enough and cheap enough to develop that app stores will end up full of stale apps. If everything is on the web, that's where users will get their stuff.
For instance, how often do you try to get a desktop app for something instead of a Google search? Does anyone start by browsing the Mac App Store?
Related: http://www.kalzumeus.com/2009/09/05/desktop-aps-versus-web-a...
For instance, how often do you try to get a desktop app for something instead of a Google search? Does anyone start by browsing the Mac App Store?
Related: http://www.kalzumeus.com/2009/09/05/desktop-aps-versus-web-a...
I'm really sick and tired of going to a site on my phone, and getting inundated with popups and banners and crap telling me to install the app (Reddit, I'm looking at you).
I just want to view the same fricking website that I view on my desktop, but on my phone. You'd think that would be a simple and obvious way of working that would be supported by every single website in existence without any special effort on the part of web developers. And you'd be right, except web developers these days GO OUT OF THEIR WAY TO MAKE IT NOT WORK THAT WAY.
You'd think the simple and obvious fact, that phones these days generally have web browsers just as capable as desktop browsers, would have penetrated people's thick skulls by now. But for some reason everyone wants their own app, I darkly suspect so they can use the email, contacts, camera, microphone etc. for God knows what creepy spying and data harvesting purposes.
So if this guy's figured out that the way to convince The Powers That Be, who've already been convinced by someone else that You Need To Have An App Even If The App Is Literally The Same As Your Website, that it's actually okay to Not Have An App And Just Have People On Your Phones Go To Your Website, by simply re-naming your website from "a website" to "a Progressive Web Application," more power to him.
Me, I just want to look at websites, and occasionally look at them on my phone, and I'd like a web that allows me to have the experience I'm used to from my desktop, on my phone.
I just want to view the same fricking website that I view on my desktop, but on my phone. You'd think that would be a simple and obvious way of working that would be supported by every single website in existence without any special effort on the part of web developers. And you'd be right, except web developers these days GO OUT OF THEIR WAY TO MAKE IT NOT WORK THAT WAY.
You'd think the simple and obvious fact, that phones these days generally have web browsers just as capable as desktop browsers, would have penetrated people's thick skulls by now. But for some reason everyone wants their own app, I darkly suspect so they can use the email, contacts, camera, microphone etc. for God knows what creepy spying and data harvesting purposes.
So if this guy's figured out that the way to convince The Powers That Be, who've already been convinced by someone else that You Need To Have An App Even If The App Is Literally The Same As Your Website, that it's actually okay to Not Have An App And Just Have People On Your Phones Go To Your Website, by simply re-naming your website from "a website" to "a Progressive Web Application," more power to him.
Me, I just want to look at websites, and occasionally look at them on my phone, and I'd like a web that allows me to have the experience I'm used to from my desktop, on my phone.
I work at a small business, and our customers are constantly asking that we make an app. We have a fully functional website that is completely responsive, and we do more mobile sales than desktop. But they keep asking for an app. I have no idea why- I guess it feels more "legitimate" than a website. I try to politely explain that I'm our sole developer, and I'd have to support the website, AND an iphone app, AND an android app, and they pretend to understand, and say "yeah, but an app would be nice...".
I mean, do you want the app so you can have an app, or do you want the app so you can make a purchase? I don't understand.
I mean, do you want the app so you can have an app, or do you want the app so you can make a purchase? I don't understand.
Same here, except I had someone make native apps. They were bad and unmaintained for a long time (solo dev here as well, running a small business). But still, people used this Android app that didn't receive updates for 4 years(!) over a mobile website where I put a lot of effort into.
At some point, I gave up. If apps is what people want, I make apps. After a looong process of deciding between native and hybrid (build with Ionic), I finally settled on Ionic. The result is actually quite okay. People love it. I can maintain two platforms with a single code base and will probably rewrite parts of the web app with Node so that I can share core code between 3 platforms.
How all of this will turn out in the long run, I don't know. Maybe I'll outsource app development at some point again in the future, now that I have a working product that is exactly as I want it to be.
Seriously, consider releasing a Cordova-based app. Slap some functionality on top so that it won't be rejected by Apple (Website-only wrappers aren't allowed). Maybe an offline storage or whatnot. This shouldn't take too much effort and you might be surprised that new customers find their way to your business.
At some point, I gave up. If apps is what people want, I make apps. After a looong process of deciding between native and hybrid (build with Ionic), I finally settled on Ionic. The result is actually quite okay. People love it. I can maintain two platforms with a single code base and will probably rewrite parts of the web app with Node so that I can share core code between 3 platforms.
How all of this will turn out in the long run, I don't know. Maybe I'll outsource app development at some point again in the future, now that I have a working product that is exactly as I want it to be.
Seriously, consider releasing a Cordova-based app. Slap some functionality on top so that it won't be rejected by Apple (Website-only wrappers aren't allowed). Maybe an offline storage or whatnot. This shouldn't take too much effort and you might be surprised that new customers find their way to your business.
I suspect they want the app to have an easy access icon on their home screen. I don't think most people know you can save a shortcut as an icon from a given web page on their home screen.
Hybrid mobile app?
I was also skeptical of apps, but they do deliver a better more cohesive experience. I actually like the reddit app and it saves me a lot of time.
As for security, you don't have to grant permissions. All apps are also put through a scanning process.
For portability the browser wins. For quality well crafted apps prevail.
As for security, you don't have to grant permissions. All apps are also put through a scanning process.
For portability the browser wins. For quality well crafted apps prevail.
Just be aware that ionic3 is full of bugs.
You can use angular 4 which is absolutely ready now. Ionic is full of promises (literally and
figuratively), but it is not even ready as a beta.
- I spent days to make workaround for making it work. Even basic things like routers.
- I suffered a lot with its build process. Transpiling my typescript is a so much pain for my mac. That is even worse than when I compiled java years ago.
- The need to wait 2 minutes for the live reload (when it actually reloads the change like expected) is a big loss for the web development process.
Anyway for me the point is totally true. I was only on natives and now only what you call "PWA"
- I spent days to make workaround for making it work. Even basic things like routers.
- I suffered a lot with its build process. Transpiling my typescript is a so much pain for my mac. That is even worse than when I compiled java years ago.
- The need to wait 2 minutes for the live reload (when it actually reloads the change like expected) is a big loss for the web development process.
Anyway for me the point is totally true. I was only on natives and now only what you call "PWA"
Interesting that you had so many pain points. I like Ionic, don't love it but I find it to be very very easy to work with.
I don't mean to flame, I just want to provide a counter example as I was using Ionic on the day to day basis for about 5 months.
- I find the router to be very easy to use, requiring no work arounds, you call the nav controller and push / set a view, nothing crazy here.
- The build process, specifically for the TypeScript? Are you using the CLI? There's just about nothing you need to do
-I was able to start fresh on a mac and have everything up and running for both Android and iOS within 2 hours (this is mostly installing the Android SDKS).
- And the live reloading will reload your entire app within 20 seconds, and this was on a pretty large Banking application using most of the plugins that are available (Camera, fingerprint, maps, etc etc etc).
Note that this is all done through using the Ionic CLI, which really eases the development process. I personally wouldn't try it without the CLI.
I don't mean to flame, I just want to provide a counter example as I was using Ionic on the day to day basis for about 5 months.
- I find the router to be very easy to use, requiring no work arounds, you call the nav controller and push / set a view, nothing crazy here.
- The build process, specifically for the TypeScript? Are you using the CLI? There's just about nothing you need to do
-I was able to start fresh on a mac and have everything up and running for both Android and iOS within 2 hours (this is mostly installing the Android SDKS).
- And the live reloading will reload your entire app within 20 seconds, and this was on a pretty large Banking application using most of the plugins that are available (Camera, fingerprint, maps, etc etc etc).
Note that this is all done through using the Ionic CLI, which really eases the development process. I personally wouldn't try it without the CLI.
I use "ionic-app-scripts" (@ionic/app-scripts) for watching the change. It's what is used by ionic cli I think.
Since the recent update to webpack 3 things are better but I still loss my focus on each build :)
In fact I just checked and it's around 1 minute to finish the watch process, but many time consecutively, it become worse.
When I only update scss that is very quick indeed. The start process is very quick also.
For the router, things have became messy when I tried nested ion-nav. A method is deprecated (getRootNav) and the new is not even ready to use! (getRootNavById)
I post many issues on github. Still using ionic router (no other choices now, but by using tricks like events), and ionic cli for building, some buttons also, and I avoid anything else.
ion-menu was too buggy on ios, I had to make a menu by myself
The general quality on ios is very poor
Some plugins are great but I have bizarre issues... Keyboard plugin for exemple, I had to "ngZone" it to make it work.
Using the grid was too verbose and too buggy also. I design everything in flexbox now. It fells that ionic is trying to build a good WYSIWYGs editor with ionic creator but making developpers "beta-testing" their frameworks (sorry to complain after a open source project)
When I only update scss that is very quick indeed. The start process is very quick also.
For the router, things have became messy when I tried nested ion-nav. A method is deprecated (getRootNav) and the new is not even ready to use! (getRootNavById)
I post many issues on github. Still using ionic router (no other choices now, but by using tricks like events), and ionic cli for building, some buttons also, and I avoid anything else.
ion-menu was too buggy on ios, I had to make a menu by myself
The general quality on ios is very poor
Some plugins are great but I have bizarre issues... Keyboard plugin for exemple, I had to "ngZone" it to make it work.
Using the grid was too verbose and too buggy also. I design everything in flexbox now. It fells that ionic is trying to build a good WYSIWYGs editor with ionic creator but making developpers "beta-testing" their frameworks (sorry to complain after a open source project)
Hmm, definitely hop on the entire CLI, you won't regret it.
As far as live reload goes, it definitely is faster than 1 minute, are you connected via USB? For live reload I would stay connected via USB and then obviously you need to be on the same Wi-Fi, (For iOS, I've only used the simulator for development, but we test on a real iPhone all the time)
What kind of issues are you having with the menu? The only bugs that I've found had to do with animations, I had to use CSS animations as opposed to the Angular way of doing animations for iOS.
Other than that though, I've found the iOS to be the most stable version of the application, even though I developed it almost exclusively on Android (with some spurts on iOS to ensure everything worked).
As for the router, yeah I see what you're saying, our app is pretty straight forward as far as navigation goes.
The grid, I agree, it's annoying, it's like they threw bootstrap grid system and flexbox into one, and it's a bit strange.
As far as live reload goes, it definitely is faster than 1 minute, are you connected via USB? For live reload I would stay connected via USB and then obviously you need to be on the same Wi-Fi, (For iOS, I've only used the simulator for development, but we test on a real iPhone all the time)
What kind of issues are you having with the menu? The only bugs that I've found had to do with animations, I had to use CSS animations as opposed to the Angular way of doing animations for iOS.
Other than that though, I've found the iOS to be the most stable version of the application, even though I developed it almost exclusively on Android (with some spurts on iOS to ensure everything worked).
As for the router, yeah I see what you're saying, our app is pretty straight forward as far as navigation goes.
The grid, I agree, it's annoying, it's like they threw bootstrap grid system and flexbox into one, and it's a bit strange.
Which app were you developing? Is it actually in the app store? What kind of usage does it have?
I've always entertained the idea of using a hybrid framework--like Ionic--but I have never heard of a successful business betting the farm on one (especially a "Banking" one like you say).
I've always entertained the idea of using a hybrid framework--like Ionic--but I have never heard of a successful business betting the farm on one (especially a "Banking" one like you say).
Yessir, we have around 100 active users at any point. The app is butt ugly (I had no choice in the design).
https://play.google.com/store/apps/details?id=com.nexs.NexsC...
https://itunes.apple.com/us/app/nexscard/id1124098775?mt=8
https://play.google.com/store/apps/details?id=com.nexs.NexsC...
https://itunes.apple.com/us/app/nexscard/id1124098775?mt=8
I build an app with Ionic and didn't encounter a single problem you mentioned here.
- Router? What's wrong with it?
- Build process? `npm install` then `ionic serve`. I think that's it.
- Live reload and building my app became much faster during the last months. It takes probably 5-8 seconds today
- Router? What's wrong with it?
- Build process? `npm install` then `ionic serve`. I think that's it.
- Live reload and building my app became much faster during the last months. It takes probably 5-8 seconds today
Quasar framework for Vue is a breath of fresh air.
> It is now possible to build PWAs that are indistinguishable from their native counter parts
It's not now possible, but even if it were, it would only be because the native app does not in fact use native components.
The Starbucks app already doesn't feel native, with its custom casing, fonts, navigation and behaviors.
It's not now possible, but even if it were, it would only be because the native app does not in fact use native components.
The Starbucks app already doesn't feel native, with its custom casing, fonts, navigation and behaviors.
It's reasonably doable to get a PWA looking and feeling like a native Android app if you opt to use Material.io or Polymer's Paper Elements. Some behavior isn't 1:1 though, which can be frustrating.
What about iOS and others? Are we going to have to make multi versions of an app to make them look native?
For that matter, what does a native android app look like? I've never seen any consistency between apps at all, let alone the sort of consistency you can get with gnome, KDE or older windows.
For that matter, what does a native android app look like? I've never seen any consistency between apps at all, let alone the sort of consistency you can get with gnome, KDE or older windows.
PWA = progressive web app. Took me a while to figure out what that acronym was. https://pwa.rocks/
The author spends some time talking about platform stability as a big part of why web apps are great. But for web apps, is the platform actually stable?
I run some applications on my PC that are older than the iPhone and they work just fine. Will the Starbucks web app still work a decade from now? Is any non-trivial web app ever actually done?
I run some applications on my PC that are older than the iPhone and they work just fine. Will the Starbucks web app still work a decade from now? Is any non-trivial web app ever actually done?
20 year old PC apps only work by the good graces and Herculean efforts of Microsoft. Certainly any Mac app would have died many times over if unmaintained over that time, to say nothing of all the dead OSes. But web apps from that era still tend to work in modern browsers.
I ran a fairly niche website for a while, starting around 2006. It was pretty terribly designed (eg I learned sql and javascript from working on this project), used the whole kitchen sink of css/html/javascript circa 2006, and still, it never stopped working.
The site is actually older than that -- it started around 2004 I think.
So even poorly written web apps have longevity sometimes, even when you don't intentionally design for logevity.
So, the oldest code I wrote that's still running is a bunch of web stuff.
The site is actually older than that -- it started around 2004 I think.
So even poorly written web apps have longevity sometimes, even when you don't intentionally design for logevity.
So, the oldest code I wrote that's still running is a bunch of web stuff.
The platform has been stable for a while now. 20 year old web pages still render just fine. Its exceptionally backward compatible.
Web apps being "done/not-done" is a different question altogether, and it depends on the ever-changing goals of the app/business behind it.
Web apps being "done/not-done" is a different question altogether, and it depends on the ever-changing goals of the app/business behind it.
Unfortunately I don't have a Shockwave plugin, so no games for me.
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.
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.
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...
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...
I guess probably just fundamentally different experiences. We couldn’t have afforded to put any more time into optimizing for mobile, but most users I talked to didn’t even care to look at the mobile site before insisting they couldn’t use it unless it was an app. No need for push notifications, camera, anything like that—heck we even put in the iOS add to home screen stuff to try to get them to see it as more “app” like—but still, they just insisted an app straight from the App Store was necessary.
I've been experimenting with turning a work application into a PWA, but ran into a problem - all the stuff that would be great to cache was behind an authentication wall. None of the PWA examples covered this. Also, the service worker examples all had "Don't use this in production" warnings. :D
You can encrypt the cacheable content.
I had to CTRL+F through the article to learn that PWA == "Progressive Web App".
Am I missing a trend?
Am I missing a trend?
I had to do the same, looks like it was coined about a year ago.
https://en.wikipedia.org/w/index.php?title=Progressive_web_a...
This article gives a solid overview: https://alistapart.com/article/yes-that-web-project-should-b...
https://en.wikipedia.org/w/index.php?title=Progressive_web_a...
This article gives a solid overview: https://alistapart.com/article/yes-that-web-project-should-b...
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 functionality... years more along, the shoehorning continued with vigorous earnest, subverting every attempt by the W3C to prevent the web from turning into an application platform and remain a static document presentation system.
With so many hurdles to cross, so many things holding it back, why on earth did it win? Clearly not just because it was cross-platform, lots of things did that. Certainly not because it followed any even REMOTE sense of reasonable development. Remember when people used to talk about the utility of standard user interface widgets? I imagine all those people are dead now.
Personally I think it was the ability to search. That trumped absolutely every single other consideration across the board. What users wanted was to vaguely indicate what they wanted and be using that application moments later. There's no reason that HAS to be only how the web works, but it mostly is now. If something comes around that enables that elsewise... maybe consider putting a chip down on that as well.
With so many hurdles to cross, so many things holding it back, why on earth did it win? Clearly not just because it was cross-platform, lots of things did that. Certainly not because it followed any even REMOTE sense of reasonable development. Remember when people used to talk about the utility of standard user interface widgets? I imagine all those people are dead now.
Personally I think it was the ability to search. That trumped absolutely every single other consideration across the board. What users wanted was to vaguely indicate what they wanted and be using that application moments later. There's no reason that HAS to be only how the web works, but it mostly is now. If something comes around that enables that elsewise... maybe consider putting a chip down on that as well.
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 essential foundation of browsing the internet.
From a user perspective, being able to instantly download any "app" you need (i.e. visit a website) has been the logical conclusion of high speed mobile data. It's low investment, takes up a miniscule amount of ephemeral storage, and works on anything.
From a developer perspective, you can be assured that your single codebase will run on virtually any device, with minimal adaptations to it. You have enough performance to run mildly resource intensive 3D games, some basic concurrency, and an ecosystem that fixes all of the most important faults in the language (typescript is the biggest one IMO). You also increasingly have APIs that allow you to do everything that you could otherwise do with a proper desktop/mobile app.
Literally the ONLY reason webapps are not the first choice for most companies is because they're not as sticky (obnoxious). Users aren't forced to look at your icon and receive your notifications until they disable them. That's it.
From a user perspective, being able to instantly download any "app" you need (i.e. visit a website) has been the logical conclusion of high speed mobile data. It's low investment, takes up a miniscule amount of ephemeral storage, and works on anything.
From a developer perspective, you can be assured that your single codebase will run on virtually any device, with minimal adaptations to it. You have enough performance to run mildly resource intensive 3D games, some basic concurrency, and an ecosystem that fixes all of the most important faults in the language (typescript is the biggest one IMO). You also increasingly have APIs that allow you to do everything that you could otherwise do with a proper desktop/mobile app.
Literally the ONLY reason webapps are not the first choice for most companies is because they're not as sticky (obnoxious). Users aren't forced to look at your icon and receive your notifications until they disable them. That's it.
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.
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.
>There's no reason a similar system couldn't be built to deliver platform-native applications
I'm very into the idea of HTML/CSS/JS on the desktop (and by extension, things like react native), even if simply as a frontend to a heavier duty application running on localhost. I feel like the OSs should be shipping runtimes for it instead of having insane 120MB hello world electron apps.
Web apps also don't necessarily mean someone else has control over your data -- it is technically easier to determine whether they do. You can inspect web requests in your browser, you can't in most native apps. There are plenty of silly things like Dark Souls stat calculators that make so much more sense as a webapp, and are 100% client side.
I'm very into the idea of HTML/CSS/JS on the desktop (and by extension, things like react native), even if simply as a frontend to a heavier duty application running on localhost. I feel like the OSs should be shipping runtimes for it instead of having insane 120MB hello world electron apps.
Web apps also don't necessarily mean someone else has control over your data -- it is technically easier to determine whether they do. You can inspect web requests in your browser, you can't in most native apps. There are plenty of silly things like Dark Souls stat calculators that make so much more sense as a webapp, and are 100% client side.
> I'm very into the idea of HTML/CSS/JS on the desktop
Why? there are better languages, platforms and layout engines. HTML/CSS/JS was meant to be a document markup sharing platform, not a rich application one. Use the best tool for the job.
Why? there are better languages, platforms and layout engines. HTML/CSS/JS was meant to be a document markup sharing platform, not a rich application one. Use the best tool for the job.
Graphical frameworks -- GTK? QT?
These are intertwined with the language and GTK especially does not look attractive on macOS and Windows.
The appeal to HTML/CSS/JS is it's 100% agnostic to the platform, and can even be used as a front-end to a program written in a different language.
These are intertwined with the language and GTK especially does not look attractive on macOS and Windows.
The appeal to HTML/CSS/JS is it's 100% agnostic to the platform, and can even be used as a front-end to a program written in a different language.
Sure, but Java made that claim as a platform in 1995, and it was free and open source.
> I feel like the OSs should be shipping runtimes for it
Well, Windows does come with the MSHTML control. Sadly for some reason they decided to version lock it at IE6 instead of keeping it up to date for applications to use.
Well, Windows does come with the MSHTML control. Sadly for some reason they decided to version lock it at IE6 instead of keeping it up to date for applications to use.
Windows 8+ added the HTML/JS native application stack in the WinRT/UWP modern application world. That stack is a lot nicer to work within than bad old days trying to script MSHTML to do what you need, if you give it the chance.
You can do that already. It's windows only though.
https://msdn.microsoft.com/en-us/magazine/jj891058.aspx
https://msdn.microsoft.com/en-us/magazine/jj891058.aspx
This is something I feel quite strongly about, and I too favour PWAs. I think native apps have their place for now, as a few key APIs are not fully exposed via browsers yet, but the API landscape continues to improve. Apple has even started dev on service workers for Safari, and their IndexedDB implementation is not as buggy as it used to be.
If I'm honest, apps never really made sense to me; they seem to be part of an intrinsically closed eco-system, which feels completely at odds with the initial premise of the internet, and dare I say, computing in general. If you have an Apple product, you must go to the App Store, if you have an Android product, then it's the Play Store etc. The feeling of openness that I became accustomed to (probably from a time before "apps") seems to have taken a step backward with mobile apps, and replaced with an endless need for vendor lock in. It's great for business, but as a user, it feels really restrictive. As a developer, it's not great either.
I believe that as browsers become more standardised (i.e. you don't need rubbish like if(IS_IOS) { ... } else { ... } in your JavaScript), and they start to expose more and more functionality via well-defined APIs, developers will favour the browser as a deployment platform, simply because it'll be more ubuquitous, will be easier to deploy and manage, and will have a lower barrier to entry. Till then, native apps will maintain their position, as they will be the more polished product.
A personal anecdote: I gave my latest app (a PWA - https://usebx.com) to a few small business owners in my home town to use for free. I pointed them to the website, and the first question they asked me was "why can't I find it on the app/play store?". I told them that they needn't go to the app store - just add the webpage to your homescreen, and you're good to go! They much preferred that method, as compared to "faffing around on t'app store" (imagine that said in a Yorkshire accent)! They even loved the app, and as far as I'm aware, found it on par with a native app. My point is, even the fairly long winded process of searching the app store to find an app, then waiting for it to install, was the first thing that came to mind for these non-techy guys. Once they knew about "Add to homescreen", they liked it. I think much of the transition to PWAs will be like this - people struggling free from their habitual need to use vendor specific app stores and eventually embracing the simpler, more open, web-based app paradigm.
If I'm honest, apps never really made sense to me; they seem to be part of an intrinsically closed eco-system, which feels completely at odds with the initial premise of the internet, and dare I say, computing in general. If you have an Apple product, you must go to the App Store, if you have an Android product, then it's the Play Store etc. The feeling of openness that I became accustomed to (probably from a time before "apps") seems to have taken a step backward with mobile apps, and replaced with an endless need for vendor lock in. It's great for business, but as a user, it feels really restrictive. As a developer, it's not great either.
I believe that as browsers become more standardised (i.e. you don't need rubbish like if(IS_IOS) { ... } else { ... } in your JavaScript), and they start to expose more and more functionality via well-defined APIs, developers will favour the browser as a deployment platform, simply because it'll be more ubuquitous, will be easier to deploy and manage, and will have a lower barrier to entry. Till then, native apps will maintain their position, as they will be the more polished product.
A personal anecdote: I gave my latest app (a PWA - https://usebx.com) to a few small business owners in my home town to use for free. I pointed them to the website, and the first question they asked me was "why can't I find it on the app/play store?". I told them that they needn't go to the app store - just add the webpage to your homescreen, and you're good to go! They much preferred that method, as compared to "faffing around on t'app store" (imagine that said in a Yorkshire accent)! They even loved the app, and as far as I'm aware, found it on par with a native app. My point is, even the fairly long winded process of searching the app store to find an app, then waiting for it to install, was the first thing that came to mind for these non-techy guys. Once they knew about "Add to homescreen", they liked it. I think much of the transition to PWAs will be like this - people struggling free from their habitual need to use vendor specific app stores and eventually embracing the simpler, more open, web-based app paradigm.
> ... seems to have taken a step backward with mobile apps, and replaced with an endless need for vendor lock in. It's great for business, but as a user, it feels really restrictive. As a developer, it's not great either.
But isn't using a web app that stores its data to a remote server and handles upgrades a method of vendor (in this case developer) lock in? As a user you are 100% reliant on the developer, both for your data but also in their mercy when it comes to upgrades (imagine developers changing how their UI works to a way you dislike - my aunt every now and then calls me because something went wrong but what really went wrong was Google making slight changes to Gmail or the Google home page that confused her - or, even worse, starting to require more resources than your computer can handle but you cannot do something as simple - with native apps - as to just keep using the older version).
But isn't using a web app that stores its data to a remote server and handles upgrades a method of vendor (in this case developer) lock in? As a user you are 100% reliant on the developer, both for your data but also in their mercy when it comes to upgrades (imagine developers changing how their UI works to a way you dislike - my aunt every now and then calls me because something went wrong but what really went wrong was Google making slight changes to Gmail or the Google home page that confused her - or, even worse, starting to require more resources than your computer can handle but you cannot do something as simple - with native apps - as to just keep using the older version).
I don't disagree with what you're saying, but the issue I have is with the monopolistic aspect of an app store... Basically, it's one or two monolithic companies that control everything and determine the rules because they make the base operating systems. With regards to updates etc, I think similar issues apply to native apps - e.g. devs can change the backend, which can break older front ends. I'm sure you can eventually have the concept of a versioned web app as well, much like versioned APIs, and users can decide if they wish to upgrade.
TBH i was mainly thinking about desktop applications where app stores are not really a thing (beyond Steam) and - at least in Windows - you can still use applications written a couple of decades ago while the companies that made them have long dissolved.
I agree about the gatekeeperness aspect of app stores too :-). At least with Android there is the ability to install APK files, though it isn't very user friendly.
I agree about the gatekeeperness aspect of app stores too :-). At least with Android there is the ability to install APK files, though it isn't very user friendly.
This is a really beautiful designed PWA - congratulations!
Do you mind sharing some tech details (Framework used, Charts)
I pretty much rolled my own! Everything from the view rendering to the charts were done in house, as I wanted to keep it lightweight. If I end up making a bit of money on this, I will definitely open source the charts and view rendering engines :)
Awesome and great work! I would happily pay for both :-)
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?"
I want PWAs to succeed, because I would love to publish close-to-native apps without an app store. I think PWAs are a great thing for the open web. However, hyping PWAs with unrealistic expectations doesn't do any good. The Ionic team talks in the same vein. I like Ionic, I don't like hype. Here are a few reasons why PWAs aren't there yet and probably won't replace most apps in the near future:
- No native APIs. Yeah sure, you can order a coffee at Starbucks, but the underyling hardware isn't exposed to JS. You won't be able to make a camera app with PWAs.
- Input controls suck. Same as with every mobile browser and every Cordova-based app: You cannot control how the keyboard behaves and I suspect that it's not even in Apple's interest to make Mobile Safari super-great. Sure, they're working on PWAs, but that doesn't mean anything. Just see how bad Mobile Safari's <select> looks like. Or bugs in multi-selects that have been there forever.
- They still run in a browser. It shows an address bar and whatever else your browser is always showing. Try Twitter's PWA right now: https://lite.twitter.com It's way too easy to accidentally swipe back. And then, Twitter being a shitty Single-Page-App, the browser loses its scroll position.
- PWAs suffer from the same problems like all SPAs [1]
And finally:
- A PWA is just a proxy to download and cache responses from a server. It enables offline support (kinda) for single-page apps. It's not a magical something. The problem is that most users go to the App or Play Store first (like djrogers pointed out here: https://news.ycombinator.com/item?id=15219682). They COULD be using PWAs – or at least good mobile webistes – right now, but they aren't.
I think PWAs will find their places and I'm betting on them, too, to a certain extend. But over-hyping PWAs without addressing these issues is just naive.
[1]: Great read on this topic: https://adamsilver.io/articles/the-disadvantages-of-single-p...
- No native APIs. Yeah sure, you can order a coffee at Starbucks, but the underyling hardware isn't exposed to JS. You won't be able to make a camera app with PWAs.
- Input controls suck. Same as with every mobile browser and every Cordova-based app: You cannot control how the keyboard behaves and I suspect that it's not even in Apple's interest to make Mobile Safari super-great. Sure, they're working on PWAs, but that doesn't mean anything. Just see how bad Mobile Safari's <select> looks like. Or bugs in multi-selects that have been there forever.
- They still run in a browser. It shows an address bar and whatever else your browser is always showing. Try Twitter's PWA right now: https://lite.twitter.com It's way too easy to accidentally swipe back. And then, Twitter being a shitty Single-Page-App, the browser loses its scroll position.
- PWAs suffer from the same problems like all SPAs [1]
And finally:
- A PWA is just a proxy to download and cache responses from a server. It enables offline support (kinda) for single-page apps. It's not a magical something. The problem is that most users go to the App or Play Store first (like djrogers pointed out here: https://news.ycombinator.com/item?id=15219682). They COULD be using PWAs – or at least good mobile webistes – right now, but they aren't.
I think PWAs will find their places and I'm betting on them, too, to a certain extend. But over-hyping PWAs without addressing these issues is just naive.
[1]: Great read on this topic: https://adamsilver.io/articles/the-disadvantages-of-single-p...
> - They still run in a browser. It shows an address bar and whatever else your browser is always showing. Try Twitter's PWA right now: https://lite.twitter.com It's way too easy to accidentally swipe back. And then, Twitter being a shitty Single-Page-App, the browser loses its scroll position.
Android doesn't show the address bar. I don't have iOS but it seems like Safari support for PWA isn't as far along as Chrome.
Android doesn't show the address bar. I don't have iOS but it seems like Safari support for PWA isn't as far along as Chrome.
One mobile safari bug that really irritates me is not being able to move the cursor on a text input element. Basically, if the text in there is longer than the element, you won't be able to move the cursor left or right. You can only work with the visible part of the input element. Try it - it's really quite terrible!
I know. Same with textareas, especially if they're wrapped in some kind of scrollable container. It is a mess. I don't know why it's not being fixed.
The only reason I can think of is that Apple intentionally keeps the mobile experience slightly crappy so that people perceive native apps having higher quality.
Of all companies, Apple should be the one with the best usability in a browser, no? But hardly so.
The only reason I can think of is that Apple intentionally keeps the mobile experience slightly crappy so that people perceive native apps having higher quality.
Of all companies, Apple should be the one with the best usability in a browser, no? But hardly so.
You can move the cursor by long pressing on the words to bring up the magnifying glass.
"4. PWAs everywhere"
Yeah, yeah, I read that many times while I researched about it. But everywhere seams to mean today, everywhere except for the old-school Desktop (!)
I mean I understand, that the implementation and development of a new standard takes time and since mobile is hip, everyone focus there first. Makes sense. But I feel a bit ridicouled(and annoyed) with all the PWA, don't worry about plattform talk - and then there are no signs at all, that the traditional desktop is a target in the near future, if it is at all. At least I could not find further informations.
https://developer.mozilla.org/en-US/docs/Web/Manifest
And I am building a webapp, which does a bit more than turning on a lightbulb, so I also like it to run on a real PC. To work with it. With a screen and keyboard - and yes, whenever I want, easily switch to mobile and still be able to work with it, ... this is what would make me excited. True plattform-independence, where I don't have to worry about clumsy plattform details. What I have to worry about is adjusting to the screensize, etc. and if there is a keyboard, mouse, gps, device orientation, battery maybe(so the app knows to save urgent data, before, the power goes off), pressure sensitive pen, multitouch, etc. etc.
I'd like to have all this information and then present the user the best UI I can master with the given conditions and don't worry what happens behind the scene.
I just target the WebAPI's.
And they get more and more powerful. Mozilla tried to build and market their OS around them, which failed comercially, but helped the basic idea a lot. And this basic idea I like because of the simplicity. So I am excited and looking forward for further improvements ... but please don't forget the desktop as a plattform!
Yeah, yeah, I read that many times while I researched about it. But everywhere seams to mean today, everywhere except for the old-school Desktop (!)
I mean I understand, that the implementation and development of a new standard takes time and since mobile is hip, everyone focus there first. Makes sense. But I feel a bit ridicouled(and annoyed) with all the PWA, don't worry about plattform talk - and then there are no signs at all, that the traditional desktop is a target in the near future, if it is at all. At least I could not find further informations.
https://developer.mozilla.org/en-US/docs/Web/Manifest
And I am building a webapp, which does a bit more than turning on a lightbulb, so I also like it to run on a real PC. To work with it. With a screen and keyboard - and yes, whenever I want, easily switch to mobile and still be able to work with it, ... this is what would make me excited. True plattform-independence, where I don't have to worry about clumsy plattform details. What I have to worry about is adjusting to the screensize, etc. and if there is a keyboard, mouse, gps, device orientation, battery maybe(so the app knows to save urgent data, before, the power goes off), pressure sensitive pen, multitouch, etc. etc.
I'd like to have all this information and then present the user the best UI I can master with the given conditions and don't worry what happens behind the scene.
I just target the WebAPI's.
And they get more and more powerful. Mozilla tried to build and market their OS around them, which failed comercially, but helped the basic idea a lot. And this basic idea I like because of the simplicity. So I am excited and looking forward for further improvements ... but please don't forget the desktop as a plattform!
I think buildings sites as PWAs is a good idea but it'll take some time for them to actually replace apps. As other commenters have said, user habits go straight to apps. And until Apple decides to support service worker in iOS Safari, it won't have the same functionality as on Android.
Worth noting that Apple (WebKit) set Service Workers from 'Under discussion' to 'in development'
"With the original iPhone, there was no App Store, and no third party apps. At least not at first..."
https://www.imore.com/history-app-store-year-zero
I think this section sums it up well why there became a demand for apps, and the points are still valid today.
"But back then, the limitations of web apps, their lack of access to core functionality, their relatively poor performance compared to native apps, and the difficulties involved in charging for them proved to be insurmountable problems.
As a solution, web apps were more sour than sweet."
https://www.imore.com/history-app-store-year-zero
I think this section sums it up well why there became a demand for apps, and the points are still valid today.
"But back then, the limitations of web apps, their lack of access to core functionality, their relatively poor performance compared to native apps, and the difficulties involved in charging for them proved to be insurmountable problems.
As a solution, web apps were more sour than sweet."
the author doesn't seem to discuss Android's "instant app" feature
https://developer.android.com/topic/instant-apps/index.html
Android Instant Apps allows Android users to run your apps instantly, without installation
Android Instant Apps allows Android users to run your apps instantly, without installation
This is pretty cool and was actually my reasoning behind creating my side project as a PWA.
It's a gym workout logging app and you can try the UI without needing an account -> https://ewol.fitness
It's a gym workout logging app and you can try the UI without needing an account -> https://ewol.fitness
I sure hope history will repeat itself. Just like Desktop, web apps are taking over. Hopefully, PWAs will do the same in mobile.
No one wants to install/update apps anymore. They are not exciting. They are chore.
No one wants to install/update apps anymore. They are not exciting. They are chore.
PWA = Progressive Web Apps
It's possible to sell a PWA like sell a $5 app on the App Store/Play Store? The author doesn't address this topic and it's important to make a transition imho.
Well, since the trend goes towards In-App-Purchaes, you could simply paywall some functionality and slap Stripe or PayPal on your website. That should give users a relatively similar experience. Don't even have to share 30% that way. It's up to you.
This is the most congruent argument advocating web apps and indirectly the most clear career advice that I've read for a long time.
A sincere thank you.
A sincere thank you.
I don't think writing a web extension thingy on Safari/Chrome mobile can be achieved with a PWA. Would love to be corrected.
Thank you SO MUCH!!
Speaking of BlackBerry, I now have a functional Starbucks app on my BlackBerry10 phone (and not a laggy Android sideload).
You rock.
Speaking of BlackBerry, I now have a functional Starbucks app on my BlackBerry10 phone (and not a laggy Android sideload).
You rock.
I'd not heard of PWA before. After reading the OP I did an additional search on Google. Found a course on udemy that claims to be on sale.
https://www.udemy.com/progressive-web-app-pwa-the-complete-g...
I've seen three of the videos in it so far. Seems like an ok course for the ~25 USD I paid for it.
https://www.udemy.com/progressive-web-app-pwa-the-complete-g...
I've seen three of the videos in it so far. Seems like an ok course for the ~25 USD I paid for it.
[deleted]
> You don't have to create a native app because PWAs now offer all the functionality of a native app
This is a blatant lie
> Starbucks PWA: ~600KB
2.1 MB just the initial page, with no cards. The preview.js file is 751 K
I do agree, however, that it's much smaller than an iOS app.
This is a blatant lie
> Starbucks PWA: ~600KB
2.1 MB just the initial page, with no cards. The preview.js file is 751 K
I do agree, however, that it's much smaller than an iOS app.
> 2.1 MB just the initial page, with no cards
650 KB for me: https://i.imgur.com/eVoZtWQ.png
650 KB for me: https://i.imgur.com/eVoZtWQ.png
preview.js 752 KB
vendor.js 614 KB
https://dmitriid.com/i/gm2tmobrgeydcnbt.png
vendor.js 614 KB
https://dmitriid.com/i/gm2tmobrgeydcnbt.png
600KB gzipped?
Android's answer to this guy's "app for this right now" thing:
https://www.theregister.co.uk/AMP/2017/01/25/google_testing_...
https://www.theregister.co.uk/AMP/2017/01/25/google_testing_...
So, a PWA is a massively bloated web page? Yeah, that is exactly the kind of thing I want to run on a browser in my phone.
Sure, a decade with Moore and it might actually become usable - but do we really want to set the bar that low?
Installing an app is cumbersome, but when going to his example I'm forced to create an account just to see what it is.
Sure, a decade with Moore and it might actually become usable - but do we really want to set the bar that low?
Installing an app is cumbersome, but when going to his example I'm forced to create an account just to see what it is.
> You don't have to create a native app because PWAs now offer all the functionality of a native app.
That's cool. But _this_ has been true for a while:
> You don't have to create a native app because a mobile-friendly website offers all the functionality you need.
I use (reluctantly) a bunch of apps that really should be just websites. They don't make use of my phone's camera or microphone or do anything fancy to my phone's user experience. They don't need any special permissions, aside from web access. They're really just websites in disguise.
And yet, for some reason, they're apps.
Some were even built as websites (e.g. using PhoneGap) and then compiled into native apps.
So before we convince people that PWAs are the answer for all of their fancy, highly integrated apps that previously could only be achieved as native apps, I think it's going to be an uphill battle just to convince them that in many cases, you don't even need an app. You just need a mobile website.