I think that is a very pessimistic view of what you actually can achieve in a browser! With web assembly a lot of those things actually are very possible today.
But it's not always about if it's possible. I think we can even take a step back here and not look at performance critical apps to begin with, there are a whole host of successful native iOS apps on the App Store, making money that could be replicated as web apps with todays tech and added to the home screen, even on iOS Safari, yet these native apps keep getting built and sold. Why is that?
Sure that is true, but it is fast enough for many apps already and will be even faster in the future or do you really argue that most native apps on Apple Store couldn't be done as a web app?
Yes, you're right. actually not most, but more close to 95% of them apps could be done as web instead. Yet, on mission critical apps while they can be done as web apps, the decision to make them native it's not a choice, is a must.
If SpaceX can have a web app for their astronauts, I think so can you even if it's "mission critical". I just don't see any argument why a web app cannot be mission critical and work just as fine as a native app would.
Ok if you make an AAA-game title with extreme need of performance or if you make a database engine or something. This is however a very tiny minority of apps with extreme performance needs but again probably 99% of the apps on the appstore doesn't have those requirements and could be done as a web app.
I understand why you don't want code running medical equipment be dependant on some garbage collection or whatever, but no one is saying that we should use javascript for your heart monitoring equipment, unless it can fail and it won't kill you or hurt you physically.
OK then, let me tell you an example, since you can't see any argument.
I have this client, it's an Arkansas truck company that is hauling cargo all over US. So a few years ago they decided to ease the way, and also double check on their drivers, of how cargo is delivered. To optimize routes (fuel economy), to make it easier for drivers to enter/use data in the system, stuff like that. So they decided to give them drivers work smartphones, GPS enabled always with location reported through Google services. And a custom app that would use them features to run on said smartphone which would connect back to their server and interact with the central DB there. Server on AWS, back-end there, client app on smartphone - classic programming job, OK? So they hire a developer who was just like you "if it can be a web app then should be a web app" that caught their eyes with "look how nice works on any device or any operating system since is a web app" kind of argument. Job done, and they started to use the new system. In the beginning everything went fine, then client wanted more features. Add reports, add logging errors, add more contracts in the system that drivers show/sign with their cargo clients, notification if a nearby new customer pop-ed up in the system so the truck driver takes a little detour - stuff like that. And of course the aforementioned web developer delivered. Implemented all them features over the course of next couple years.
And then problems started to creep-up. More and more features, means more and more power was drawn from the phone battery. Have you ever seen a company that seek to reduce their operating costs give expensive with long battery life smartphones to their employees? Because I never seen one. So them phones had to be plugged into charges more often, battery cycle was shorter, also plenty of batteries don't like to be charged on short many cycles throughout the day or otherwise they start to swell, best case scenario, or to even explode (worst case scenario). So the company started to experience problems with smartphones, their drivers complained a lot about how when the smartphone was hot after charging the app was sometime unresponsive so they had to wait for the phone 5 minutes to coll off, time which added to their operational costs. Tell me, how do you think truck drivers are? University graduates who have a lot of tech understanding or simple folks trying to make a buck for their family and are tech illiterate? Because in my experience they are 99% of the time the latter rather than former.
What was "mission critical" (as you like to mock it)? Get an app running on an inexpensive phone, used by tech illiterate humans that definitely will use it wrong, to lower the company costs without hiccups!! Did the web app achieved that? Absolutely not, made it worse actually.
My solution? Get rid of GPS crap from smartphone, move that as a microservice running on a Raspberry Pi, which also had attached a LoRa module, phone would connect to RPi's access point only. RPi would also have a GSM dongle to connect to internet and always stay in the truck's cabin plugged in. Let's see running costs. RPi is 15 USD, LoRa is 5 USD, GSM dongle another 10 USD. Total cost for the rest of their life a grand total of 30 USD. Do you know how much is a battery replacement? Average of 40 USD, if you manage to find the battery model, otherwise you need to replace the entire phone. So which one is better? 40 USD every 6 months or 30 USD one time payment? Now multiply that with 300 trucks.
I made all of them native apps as native apps are also draining less battery, turned off all Google location services, GPS, notifications services and implemented my notification service instead, pushed from RPi's local server to phone's app. Back to charge the phone only once per day.
Funny thing. As a side effect of my implementation they made a bunch of their clients happy. See some of them are mining operations, and sometime the boss of the mining operation was inside the mine. Before they had to exit the mine to check stuff on the truck driver phone and make the do paperwork. Now LoRa module allowed the phone to have signal even inside if they parked their truck at the mine's mouth. Before that the phone would lose internet connectivity 20 feet inside the mine.
The main thing to note here is that the moment you offloaded some of the work off of the phone, the comparison stopped being apples-to-oranges. It'd be interesting to see how PWA vs native app would compare against each other (both performing the same work).
My job as a freelancer is to view the bigger picture of the client. Then discuss things and see what's the best course of action. Hardware, software, operating systems - all these are irrelevant. You advice your client to his needs, not to your " I like web apps so this has to be a web app". So in this particular case the phone had to be unloaded and that's exactly what I did.
> So they hire a developer who was just like you "if it can be a web app then should be a web app"
I can see arguments and I am not like that, you're portraying your predisposed view about me onto me.
This argument you have is not really saying a lot to me actually since you could use Rpis with a web app as well? Tbh I don't think you save that much battery on just making it native. You complain about battery, but fail to mention that Android phones needs to be switched to be able to use the newest api:s in android development. So if you want to use new shit, your client needs to update their phones, something they would not have to do if it were a web app. But in your case, I would probably also have made a native app but that app you built don't really describe how most apps are. You are talking about an exception to the rule IMO.
I can give you a pretty similar counter example:
I worked for a client once that made a newspaper. This client has a list with all shops, kiosks etc that sell their newspaper in a database. To save fuel and to be efficient, they used an old Java Swing application that would every day calculate the most efficient route for each driver. It did a lot of other stuff as well, but that isn't important for the story. The app was fine, it was just a pain to develop and release. Because it was still actively developed. In every release, a jar file had to be distributed to each user of the app since there was no good way of auto updating the app since it was so old. Any way, the users of the java swing application would run the calculation functionality and it would give a result that was printed out and given to the drivers.
What happened later was that the app was remade and presented in a web page. Each driver didn't have to wait for a paper printout of the result of the java swing app, they could simply open their phone, visit a specific url and see their route for that day. There was nothing to install for each driver, since drivers was often changed, no need to wait for some guy that had to print out a paper for them and everything was basically automated.
The benefit here of a web app was great, since as you say truck drivers aren't the most tech literate people in the world, managing a native app here would be a great pain.
So what can we learn from our examples? That the needs are different. I get that. I never said every app should be a web app. But if you can make it a web app, you probably should at least consider it. The benefits usually outweighs any negatives. My entire point was never to not make native apps, it was to avoid them if possible.
Let's agree to disagree. And frankly I love people with love for hypes and technologies that bullshit their clients into adopting that. It means I get to do this type of work, which I call "cleanup jobs" that bring me the big bucks.
Since when is doing stuff for an open standard that will have backwards compability for likely decades following a hype? The hype technologies is imo android and ios apps. They will only work for a few years and soon enough their UI will look so ugly because of the hundred times Google or Apple has revamped their entire UX so they deprecate all apps that don't update SDK version.
Then, the clients have to replace their devices because otherwise they can't run the new app versions. This is literally a hype.
I on the other hand dont use any big frameworks, I just do web apps after the open standard that everyone agreed upon. You're a slave for whatever platform you develop for.
In 10 years when people run iPhone 50 my apps will still work as they do today or probably better due to better hardware. Can you really say the same of yours, given no updates are made?
