Live data from Hacker News

Your 'app' could have been a webpage (so I fixed it for you)

danq.me

531–540 of 571 posts

Re: Your 'app' could have been a webpage (so I fixed it for you)

#531
post #526
post #509

Earlier quoted context omitted.

> Most 'native' apps are just electron wrappers Desktop apps tend to be ElectronJS, because somehow Desktop failed. But because ElectronJS sucks doesn't mean that it's impossible to have good desktop apps. I have high hopes that Kotlin multiplatform and Compose multiplatform will make desktop apps cool again. Then mobile apps are a completely different story: a good mobile app is a lot better than a webapp. At one en…

Everything you have said here is pretty much incorrect. Are you a coder and do you know how native and webapps work? If not I would do some research rather than assuming, because things you are saying about how webapps work are just not true.

You may start by elaborating on why everything I said is incorrect. I can't really engage on "it's wrong, trust me bro".

> Are you a coder and do you know how native and webapps work?

I am, and I do. I am thinking that we may disagree on what a "webapp" is. I meant webapp as "a dynamic webpage that behaves like an app, but in the browser". Not "web tech used to write a desktop app" like ElectronJS. With ElectronJS you ship a desktop app built with web tech. You may also ship a mobile app built with web tech. But that's orthogonal to my point.

My point is that what you load in your browser is not installed. It's fetched at runtime.

Re: Your 'app' could have been a webpage (so I fixed it for you)

#532
post #510

Earlier quoted context omitted.

This is wrong. The most important reasons why I prefer mobile apps are the same as why I prefer desktop programs. - I can download it once and then use it. - I can see when it gets updated (versus a website that gets updated every time I load it). For security reasons it's better, I can even verify my app with other people online and make sure we run the same thing. - End-to-end encryption doesn't make much sense in…

> - I can see when it gets updated (versus a website that gets updated every time I load it). For security reasons it's better, I can even verify my app with other people online and make sure we run the same thing. in many cases this is no longer the case. Discord, for example, has introduced capabilities to update parts of the app without goung through the play store on android, same with youtube. Which they obvious…

I understand your point, but I am not sure how relevant it is to use bad practice as a criticism of the technology itself.

Like I can write a modern C++ program that will be orders of magnitudes slower than an interpreted Java program from the 90s. But that does not mean that C++ is slower than interpreted Java: just that I can't write software, right?

If I care about security, then I choose apps that I believe are built correctly. I do happen to believe that ProtonMail is built correctly, and Signal as well. But it remains that because of how the technology works, the end-to-end encryption happening in ProtonMail requires me to trust the server, which defeats the point of end-to-end encryption in the first place [1].

[1]: to be fair, it does not defeat the purpose of ProtonMail entirely. It helps me trust that ProtonMail doesn't massively store data of all the users. But it is weaker because Proton can easily target me personally, and Signal cannot.

Re: Your 'app' could have been a webpage (so I fixed it for you)

#533
post #443

Earlier quoted context omitted.

There are actually apps which will "appify" webpages/websites for Android, or were the last time I needed one. They've been aroubd a long time. I assume they still exist.

The functionality is literally built into both Android and iOS. For example, I've got some of my self-hosted services linked on my home screen. On Firefox for Android you just browse to the site, click the 3 dots, and then under more its "Add to Home screen", Chrome works similarly.

Ah no, I meant there are apps which will create an APK file. I think they use node.js or something.

Re: Your 'app' could have been a webpage (so I fixed it for you)

#534
How you distribute software is a consequence of the user’s relationship with it. If I “take a number” online for the License Office before driving in, that most certainly shouldn’t be an app. Installing is harder than “taking a number.”

Apps are great for tools which the user needs to depend on regularly. A consequence of this is that apps shouldn’t change their UI too frequently.

Re: Your 'app' could have been a webpage (so I fixed it for you)

#535
post #489
post #411

Earlier quoted context omitted.

Rich widgets on the Home Screen are valuable too. As a web developer, I wish I were able to make widgets for people to put on their Home Screen to perform certain actions in less clicks, or have information from my (web) apps easily viewable at a glance. Which I know they would want. Right now, as far as I’m aware, for me to do that in iOS (and possibly Android) is to build those in native land.

Use this to test it out, https://whatpwacando.today/

Wait wait. How does PWA when I click "install to home screen" actually show me that rich preview screen, with instructions? That's crazy!

Edit: I have been truly wowed today https://web.dev/learn/pwa/installation-prompt

Re: Your 'app' could have been a webpage (so I fixed it for you)

#536
post #516
post #362

Earlier quoted context omitted.

> We take tech literacy for granted, because it's like a dozen levels down fundamental to our entire field. But the tech illiterati exist, and they love apps. They "love apps" because apple and android have spent billions to break their mental models and convince them that "you use apps to do things on your phone". Literally. That's the extent of most people's understanding. So, sure, they "want" apps in the same sen…

webapps are inefficient, clunky, slow substitutes to actual native apps. I think decades of marketing and billions spent by Google trying to convince people that webapps are better is what makes many tech people think they are. Literally. People "want" webapps to be what users "wanted" bc it pays their salary...

That's clever rhetoric, but for most use cases it's just not true, and that's the point of the original article. There are legitimate use cases for native apps, but many of them could be converted to an instantly loading, 50-100KB web page without losing any functionality. As opposed to a 50-300MB native app, which you need a fast connection to install, and starts up more slowly than the web page every time you use it.

Re: Your 'app' could have been a webpage (so I fixed it for you)

#537
post #278

I once read that app users are seven times more profitable than web users. That easily answers the author's question about why a company would bother make an app when a web page is the natural fit for the use case. I don't remember the source or methodology for that number, but I have no trouble believing it. An app gives the developer a foothold on the user's device. It can more easily send notifications, track the…

> I once read that app users are seven times more profitable than web users

Drug sales are often profitable.

Re: Your 'app' could have been a webpage (so I fixed it for you)

#539
post #510

Earlier quoted context omitted.

There are many reasons to prefer an app, most of which are ways OS makers have crippled web apps for reasons that TOTALLY HAVE NOTHING TO DO with the fact that they get a 30% cut if the user chooses the native app.

This is wrong. The most important reasons why I prefer mobile apps are the same as why I prefer desktop programs. - I can download it once and then use it. - I can see when it gets updated (versus a website that gets updated every time I load it). For security reasons it's better, I can even verify my app with other people online and make sure we run the same thing. - End-to-end encryption doesn't make much sense in…

1. You can download & install PWAs for offline use too.

2. This isn't true for apps anymore. Server driven ui is a thing.

3. JS runs locally. You can inspect the network traffic more easily than you can with an app.

4. You can audit OSS websites too.

5. Your personal preferences have nothing to do with the fact that Apple makes tons of money from apps but not websites.

Re: Your 'app' could have been a webpage (so I fixed it for you)

#540
post #380

Earlier quoted context omitted.

When I say I want an app that implies a few things: - this isn't a one-off use, I don't want an app to pay parking meter once and never use it again. - it's an app and not a WebView pretending to be native - it's native and not react-wanna-be-native - you know how to make an app I have to use this app to open a parcel locker and every time I launch it I have to wait for "downloading bundle". It's probably the easiest…

But take parents example. What is it you want the app version to do that a decent website can’t do?

Well, for starters, UIKit apps are faster and better on battery than web apps. Then we add a bunch of APIs that are just not available to a web app:

- Core Bluetooth

- Core NFC

- Periodic synchronization

- Background upload/download

- Background location tracking (in some cases, it's a plus, though)

- Nearby Interaction

- Anything USB

- No widgets

- No HomeKit integration

- No share extension

- No Live Activities or Dynamic Island content

The list is honestly too long.

To be clear, I do wish that Apple was less hostile towards PWAs and developers were better at making PWAs. Until recently, you couldn't even send a push notification from PWA.

Post reply on HN