If it’s a CRUD app and slower than the network, it is a dogshit app. Both the app and the webpage should be exactly as fast, since it should be waiting for the network for most of the time.
The cache is not magic though. It doesn’t work for the first visit, and it doesn’t last forever. Some clients might not even use a cache. I don’t know if this is the case, but if the cache is validated to be recent (an HTTP HEAD request or whatever) that’s still a round trip to the server.
Well yeah. You have to download the assets on first load to cache them, just like you have to download an app first to use it. And an ideally designed app should perform as well as a website since it has access to all the low level optimization and performance an app entails. The point of the post is that most services don’t actually warrant the benefits you get with an app: namely, easy offline access, higher performance, and native feel/integration with the system. If your whole service is online anyways and every time I open the app it takes a moment to fetch data, it isn’t a considerable improvement over a web experience (with cached assets) and you still can’t use it offline. Like, why do I need an entire app to use your shitty CRUD service (sometimes it’s not even CRUD, just R). If I use it so infrequently that my cache gets invalidated, I could care less about a couple seconds initial load time.
Obviously if you use something everyday a slick app is a nicer experience than a website. There’s nothing wrong with lemmy clients, even though the web client is gonna work fine on mobile and run fairly fast. The issue is when companies release shitty apps that don’t provide any more value as an app as they would as a plain old website, purely so they can get a persistent spot on a user device and mine more data, and then push a ton of annoying banners and feature blocks to mobile web users to get them to download the app.
