Live data from Hacker News

App Should Have Been a Website (and Probably Your Game Too)

rogueengine.io

261–270 of 384 posts

Re: App Should Have Been a Website (and Probably Your Game Too)

#261

Earlier quoted context omitted.

> The need to remove the capability was informed by the complex security and privacy concerns associated with web apps to support alternative browser engines that would require building a new integration architecture that does not currently exist in iOS and iPadOS. This rationalization makes zero sense, it's just opening a standalone browser window from a convenient icon shortcut. They could even ignore the manifest.…

Shows why guessing and gut feel are bad basis for opinions. In fact, Apple’s problem was that the PWA serviceworker runs as root, a bad decision made years ago. Enabling Chrome-hosted PWAs means Google gets root on those peoples’ phones. We can still lambast Apple and go all ad hom, but let’s stay factual?

Ok running something like that as root by design is enough of a self own from Apple that I really don't need to say anything more, hahaha

Re: App Should Have Been a Website (and Probably Your Game Too)

#262

Earlier quoted context omitted.

Developing apps on it still seems really, really primitive. HTML alone is not sufficient for a decent looking UI. Tailwind directives gunk it up rapidly. Component frameworks help some but still don’t seem quite as nice as something like SwiftUI. Server side functionality still requires a lot of manual serialization/deserialization (unless you use the newer crop of frameworks that have figured out this is pure noise)…

>HTML alone is not sufficient for a decent looking UI Well that's some nonsense. HTML can absolutely achieve 1:1 on any UI you care to mention. It isn't even difficult if you have any skill at all. >And then there’s JS. And then there's another person who didn't take the time to learn JS and just hates it for reasons . >Rails, htmx, and a few others seem like the only ones who really get that a simple web app should…

I have learned JS & used it extensively in many projects. Including modern SPAs. And I absolutely despise it & wish I could use something like recently trendy GO or RUST.

JS has absolutely no rhyme or reason, single threaded nature makes it gunk up browsers crazy quickly & the insane bloat of "frameworks", which attempt to completely replace already great APIs, while working on top of them... IS CRAZY!

Re: App Should Have Been a Website (and Probably Your Game Too)

#263
post #211

Earlier quoted context omitted.

> On the other hand, there is absolutely no reason that Uber or Waymo needs to have an "app". Here’s one: I don’t give websites my location or the ability to interrupt me with notifications. Ever. I’ve blocked the browser from doing this entirely. I have Uber and Lyft apps installed and granted those permissions though.

You could give only them location access then they wouldn't be able to see what apps are installed, contacts and family photos or listen on the mic. You are afraid of a browser so you give system access?

What you describe hasn't been the case for almost a decade. On iOS and Android apps need to explicitly request and be granted one-by-one permission for all those items.

Which is exactly the problem I'm encountering for web apps--typically the browser is granted all those privileges and then there is a per-site restriction in place. (1) I don't trust this sub-level restriction as much as I do the native per-app restrictions, and (2) it's often more difficult to configure and stay on top of (e.g. iOS will nag me if an app has been using my location in the background, the browser will not).

For these reasons, I restrict my browser to NOT be allowed access to bluetooth, location information, etc. Nobody gets to track me through the browser. If a site I use needs those capabilities, I install their app.

Re: App Should Have Been a Website (and Probably Your Game Too)

#264

Earlier quoted context omitted.

> you can archive and sideload old APKs Only as long as external dependencies (like APIs) are satisfied.

Very true, but you can also keep around an old Android phone, or even emulate an old AOSP distribution if your really need to. Obviously this is not ideal, but if you're trusting your hobby or business to an app, it is in your best interest to make sure that it doesn't poof out of existence randomly before you can upgrade.

I was thinking more about backend APIs managed by the company providing the app.

Re: App Should Have Been a Website (and Probably Your Game Too)

#265
post #260

Earlier quoted context omitted.

> On the other hand, there is absolutely no reason that Uber or Waymo needs to have an "app". Here’s one: I don’t give websites my location or the ability to interrupt me with notifications. Ever. I’ve blocked the browser from doing this entirely. I have Uber and Lyft apps installed and granted those permissions though.

Is there a reason why you think location access is OK for the Uber app but not ok for the uber.com website?

That's not what I was saying. Granting the permission to uber.com requires granting the permission first to the browser, then configuring and trusting the browser's own internal per-site restrictions. I don't trust this as much as the more fine grained and configurable OS-level restrictions.

Re: App Should Have Been a Website (and Probably Your Game Too)

#266

I man don't get me wrong, I love the idea of PWAs but this dude is out to lunch. It's so painful making anything complex work cross browser/cross platform. On iOS iirc they don't even support adding PWAs to the homescreen? You definitely can't Bluetooth outside of Chrome (probably only on Android and Windows too because nothing fun is ever allowed on Macs). Multiplayer games you kind of need UDP. You cannot UDP in th…

Point the author is trying to make is that there are certain usecases you really don't need to deliver it via app, it is cheaper and better to serve via web. For eg. The Itaki app mentioned in the article.

Of course there are use cases that you mentioned are better served via native app. For eg. Apps that need compute or location. That's not the argument author is making.

The downside of delivering everything via app is your device ends up with app sprawl that eats up the resources.

Re: App Should Have Been a Website (and Probably Your Game Too)

#267

I man don't get me wrong, I love the idea of PWAs but this dude is out to lunch. It's so painful making anything complex work cross browser/cross platform. On iOS iirc they don't even support adding PWAs to the homescreen? You definitely can't Bluetooth outside of Chrome (probably only on Android and Windows too because nothing fun is ever allowed on Macs). Multiplayer games you kind of need UDP. You cannot UDP in th…

> On iOS iirc they don't even support adding PWAs to the homescreen?

They literally supported this since iPhone OS 1.0 (it wasn’t even called iOS yet). In fact, it was supposed to be the only way to add apps to the iPhone until people complained and started jailbreaking to install their own apps. Apple didn’t release the App Store and the iOS SDK until iPhone OS 2.0

Re: App Should Have Been a Website (and Probably Your Game Too)

#268
post #260

Earlier quoted context omitted.

> On the other hand, there is absolutely no reason that Uber or Waymo needs to have an "app". Here’s one: I don’t give websites my location or the ability to interrupt me with notifications. Ever. I’ve blocked the browser from doing this entirely. I have Uber and Lyft apps installed and granted those permissions though.

Is there a reason why you think location access is OK for the Uber app but not ok for the uber.com website?

I feel like I have much more control over "when" I share my location, if permission is granted to "uber app" not "uber domain".

All the reasons I come up with, can be easily argued "you can do the same thing in a browser". But still, it is not the same.

Re: App Should Have Been a Website (and Probably Your Game Too)

#269

I man don't get me wrong, I love the idea of PWAs but this dude is out to lunch. It's so painful making anything complex work cross browser/cross platform. On iOS iirc they don't even support adding PWAs to the homescreen? You definitely can't Bluetooth outside of Chrome (probably only on Android and Windows too because nothing fun is ever allowed on Macs). Multiplayer games you kind of need UDP. You cannot UDP in th…

> On iOS iirc they don't even support adding PWAs to the homescreen? They literally supported this since iPhone OS 1.0 (it wasn’t even called iOS yet). In fact, it was supposed to be the only way to add apps to the iPhone until people complained and started jailbreaking to install their own apps. Apple didn’t release the App Store and the iOS SDK until iPhone OS 2.0

I don’t think parent means the same or maybe he does. On chrome and edge on macOS one can choose to install the PWA as a native app. It gets an app icon and everything. It’s similar to a web bookmark on the HomeScreen. But it’s a sandboxed app. Don’t know if this is the exact same behavior though. PWAs are also a bit different to normal websites. They have a manifest and what not to describe the app in a standardized way.

Re: App Should Have Been a Website (and Probably Your Game Too)

#270
post #190

Earlier quoted context omitted.

Most of the time a PWA isn't needed at all, a mobile Web friendly website suffices.

For offline use?

Depends on the application, naturally.

Most of them, even if native don't really work without the API based backend.

If we take out the garbage apps, copycats, and games without DLCs, most stuff is some variation of form over data.

And those that are really special, needing native APIs, working offline by default, can probably be reduced to about 10% of apps.

Post reply on HN