3 ms·

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 mis

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.

unnouinceput 6y ago
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.
- ecmascript 6y ago
  > 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.
  - unnouinceput 6y ago

unnouinceput 6y ago

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.

ecmascript 6y ago
> 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.
- unnouinceput 6y ago