Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The web apps that will eat mobile

kruschecompany.com

Post reply on HN
Print view View original

91–100 of 105 posts

Re: The web apps that will eat mobile

#91

Post by jasonkostempski »

tjoff wrote: post #68
zwieback wrote: post #36

Earlier quoted context omitted.

Depends on the user, I might be an outlier but my "ingrained behavior" is to not download an app unless I absolutely have to.

So the solution is to automatically download and execute anything and everything? The 90s called and want ActiveX back.

As long as I can use a browser with uBlock Origin and API access (location, file system, camera, etc.) remains sane, I would very much prefer a web app. I don't want to: waste time installing; use up limited storage space; allow who knows what kind of access to other stuff on my device (e.g. LinkedIn and Facebook style abuse of native APIs); and have no way to combat ads. Especially for something I'm going to use maybe just once a month or less.

Re: The web apps that will eat mobile

#92

Post by judah »

millstone wrote: post #90
judah wrote: post #78

Earlier quoted context omitted.

>> The $99/year/active developer is a nominal amount Is it really? There are 2 million apps in the iOS App Store[0]. At $99/year to be listed in the store, that's $198,000,000/year for Apple. On top of that, you have 30% price of an app. 12% of those apps are paid[1], that's 240,000 paid apps. Suppose the average price of a paid app is $5, and suppose each app is purchased 2000 times. (I have no idea what the average…

It's not $99 a year to list an app in the store. We don't have to guess: Apple reports these numbers. They earned $11.5 billion in revenue from the app store in 2017. I'm not sure what you're expecting here. Apple clearly views their role as protecting users from the hostile aspects of the web: see content blockers, reader mode, anti-tracking features in iOS 12. Of course Apple is not going to jump on unrestricted JS…

Wow, even larger than my napkin calculations. So my assertion that the app store business is significant is correct.

The problem with Apple, or any other big corporation, "protecting" users is that censorship is a two-edged sword. It's great that the iOS App Store doesn't suffer from, say, malware. It's not great that Apple has the final say over published content; Apple (or hostile governments forcing Apple) can block content for any reason; political, religious, or even vindictive. This is not merely theoretical[0].

[0]: https://en.wikipedia.org/wiki/Censorship_by_Apple

Re: The web apps that will eat mobile

#93

Post by zwieback »

jasonkostempski wrote: post #91
tjoff wrote: post #68

Earlier quoted context omitted.

So the solution is to automatically download and execute anything and everything? The 90s called and want ActiveX back.

As long as I can use a browser with uBlock Origin and API access (location, file system, camera, etc.) remains sane, I would very much prefer a web app. I don't want to: waste time installing; use up limited storage space; allow who knows what kind of access to other stuff on my device (e.g. LinkedIn and Facebook style abuse of native APIs); and have no way to combat ads. Especially for something I'm going to use may…

Add "10 apps need your approval to update" to the list

Re: The web apps that will eat mobile

#94

Post by blub »

oneshot908 wrote: post #57

How many years have we been hearing this tale? And yet almost every major web site continues to bend over backwards to persuade us to install their battery-killing surveillance system oops I mean mobile app. So the solution now is even more battery-killing HTML + Javascript + Secret Sauce? Hell no... PS Just say no to push like the Hulk says no to Banner. All IMO of course but these days, I use my phone for Yelp, Goo…

We've been hearing this tale for more than a decade and native apps are still better at pretty much everything. :)

Web devs are a very optimistic bunch.

Re: The web apps that will eat mobile

#95

Post by oneshot908 »

blub wrote: post #94
oneshot908 wrote: post #57

How many years have we been hearing this tale? And yet almost every major web site continues to bend over backwards to persuade us to install their battery-killing surveillance system oops I mean mobile app. So the solution now is even more battery-killing HTML + Javascript + Secret Sauce? Hell no... PS Just say no to push like the Hulk says no to Banner. All IMO of course but these days, I use my phone for Yelp, Goo…

We've been hearing this tale for more than a decade and native apps are still better at pretty much everything. :) Web devs are a very optimistic bunch.

And why wouldn't they be? the fewer abstraction layers between the app and the hardware, the more efficient it will usually be, no?

Re: The web apps that will eat mobile

#96

Post by epmaybe »

bsbechtel wrote: post #30

Unpopular opinion here, but I just don't see PWAs living up to the hype. Yes, there are lots of technical advantages, they're catching up to native apps in capabilities, and there is reduced friction by bypassing app stores. However, the ingrained user behavior of downloading apps from the app store, trust of knowing what you're downloading by doing so (yes, even on Android), and browsability on mobile falling behind…

> trust of knowing what you're downloading by doing so

Are you saying that some websites may not offer as much trust as an app-store approved app? Maybe when discovering new web-apps, I agree, but for standard websites that you know the url for, maybe not so much? I can't imagine someone not trusting "pandora.com", for example.

Re: The web apps that will eat mobile

#97

Post by dfansteel »

I’ve read this exact same article every year for ten years and in that time the web has become increasingly slower and more personally invasive while apps have become more capable and faster.

Pardon me if I take this all with a grain of salt.

Re: The web apps that will eat mobile

#98

Post by deftturtle »

jaegerpicker wrote: post #33
bsbechtel wrote: post #30

Unpopular opinion here, but I just don't see PWAs living up to the hype. Yes, there are lots of technical advantages, they're catching up to native apps in capabilities, and there is reduced friction by bypassing app stores. However, the ingrained user behavior of downloading apps from the app store, trust of knowing what you're downloading by doing so (yes, even on Android), and browsability on mobile falling behind…

I very much agree, we evaluated PWA vs native recently and found PWA(on iOS) to be a really poor decisions. We likely build one for Android as the experience is better there but it's very poor on iOS and unlikely to get better anytime soon(next 1-2 years).

Apple doesn't fully support PWAs. If they embraced it enthusiastically, I think then we'd have a great experience.

Re: The web apps that will eat mobile

#99

Post by lazerpants »

ams6110 wrote: post #64
lazerpants wrote: post #51

Earlier quoted context omitted.

Indeed. Somehow people even manage to forget that he died of a typically curable cancer because of his hubris.

Pancreatic cancer is serious business. It's not "typically curable" by any stretch. The 5-year survival rate is 1% - 15% depending on how early it's detected. That said, his holistic approach to treatment didn't help him at all.

He had a neuroendocrine islet tumor, not pancreatic adenocarcinoma. It has a much higher survival rate... as long as you don't try to treat it with acupuncture.

https://www.forbes.com/sites/alicegwalton/2011/10/24/steve-j...

Re: The web apps that will eat mobile

#100

Post by oblio »

pjmlp wrote: post #81
oblio wrote: post #74

Earlier quoted context omitted.

I don't consider an universal bytecode as native.

So according to you IBM and Unisys mainframes, the Xerox PARC computers, watchOS apps don't run native code.

Do the CPUs of their respective systems directly understand the instructions? In my opinion, if they don't, that's not native code. Of course, for strategic reasons such as portability the manufacturer might not provide any kind of access. At which point that's the closest to "native" you're going to get...
Post reply on HN