1116
Rule
(files.catbox.moe)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 14 Aug 2024
1116 points (100.0% liked)
196
16714 readers
2070 users here now
Be sure to follow the rule before you head out.
Rule: You must post before you leave.
founded 2 years ago
MODERATORS
Of course a good website can beat a shit app. But there's no way that you can build a website that's faster than a good app.
First of all, because your website has to run on an actual app, called a web browser. Additionally, you can't magically remove the initial load time to fetch resources from the server. Those resources are already on your phone on the app so it's instantaneous.
You...realize that when you visit a website more than once the resources are also available on your phone right? Even the most bloated JS monstrosity will have most of its data cached after the first visit and the initial load time will be as good as an installed app after the first visit. You're not fetching all 200mb of its JavaScript every time you visit the site. Of course, if the site updates its code, you'll have to re-fetch it, but the same goes for app updates.
Obviously if your app is designed to work offline, a website probably is going to be worse. But that's a scenario that actually does warrant a standalone app, which does not go for the majority of apps.
Most apps just do CRUD and act as a thin client to fetch data from a server (this includes pretty much all social media apps). There is not going to be a real difference in speed between loading the site in a web browser with cached resources or a fully-fledged app you install, except the app can harvest data from you in ways that can be prevented by a good browser. Actually, a site can be faster in many cases since it leverages libraries and capabilities already built into and loaded by a browser while an app might have to load its own standalone resources. And being able to access the app offline in these instances is worthless because if your connection isn't good enough to serve the website, it's not good enough to use the app either.
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.