A well implemented (native) app is always better than a well implemented web site.
The problem is poorly implemented apps which are just UI wrappers hitting dumb APIs or embedding entire web stacks which hit dumb APIs. A well implemented web app isn't much better than that. They don't work offline, they use way more resources than anything native and they leak data like a sieve generally.
well the article is well reasoned enough. what I gave up on was finding actual pricing information for this engine. all it say is free if you earn less than 80k... so what's the price please?
Each of those tiers has a different "free if you earn less than $xxx" level that I'm not gonna cut and paste. There's a chart with the differences between what those tiers gets you too.
Also:
Can I publish anything I want to Rogue Play?
You're allowed to publish content that is neither sexual in nature or illegal under either UK law and the laws of your country of residence.
What happens to my files if I cancel my subscription?
When you cancel your subscription your files will be locked and you won’t have access to them until you buy a new license. They will be scheduled for deletion in 30 days.
What happens to my files if I downgrade my subscription?
It's your responsibility to free the necessary space before downgrading. Your files will be deleted after 24hs unless you take action.
I don’t think the article was well sourced. WebGL technologies might be adequate for casual games… maybe. But it will be a very long time before they approach AAA gaming performance. And there is still a ton of funkyness about input (gamepad? multitouch?) and latency that is hard to address on a web stack.
He just asserts that the underlying technology has come along. It hasn’t.
It's also widely implemented in practice. For example, Instagram allows copying links to posts, and if you can view an Instragram link in the browser, it opens in the app.
ios and mac got url schemes. Sure not all developers implement it correctly. But not all sites implement a good url structure either (keeping state etc in url for sharing)
iOS apps absolutely do support deep links and URLs. Custom URL schemes are the older of the two and let iOS launch the app when someone taps on a URL that begins with its protocol (e.g. "bugmunch://orders?id=xxxxxxx"); the newer is Universal Links, which lets you set your web site up to launch your app from the web page if it's installed on your device.
Native apps made with SwiftUI or Jetpack Compose adjust their font size according to user preference in system settings out of the box. They also relayout automatically. Copying text on press is a one-liner in both frameworks, just need to think of it.
Non developers typically don't think about these things. They just suffer them subconsciously or accept the situation as something they can never change anyway and go on with their lives. You have to ask them to find out.
And I also hear developers complain more about performance issues than non developers.
I've watched Logseq (note app) go from a perfect little browser-based app that did exactly what I wanted--block-based markdown notes synced through git--to an app with dozens of features that are pure bloat for me that I can't use in half the places I need it because I cannot install apps.
It was an interesting process to watch start, because people were like "finally an app!" and "moving on from 'just' a website!" but without any real justification for it. The app itself was the accomplishment.
And I should note the Logseq app is a good piece of work. In absolute terms it's great. It is, however, not what it used to be and not really what I want. I'd like to fork Logseq, deprecate the app, and have a self-hosted browser interface with storage on the server, synced to a git repository for backup.
> A well implemented (native) app is always better than a well implemented web site.
Given that the entire article argues pretty strongly against this, you need to at minimum argue against the points posed, or present your arguments for why "well-implemented native apps are always better". It's not enough to make a straw man of the worst possible scenario and claim that it holds true for the general case as well.
This isn't true. Offline functionality is the raison d'être for Service Workers. You can run an entire HTTP request router on the client to respond to requests while offline: https://hono.dev/docs/getting-started/service-worker
Are you guys okay? Don't get me wrong it's clever, but it's also insane.
If I pitched the idea of having SMB shares work online by shipping a driver that could intercept low level SMB calls and reroute them to a mock SMB server that holds the cache they would have assumed I'd lost it.
Surely the browser could help you a bit more to implement offline sites in a more integrated fashion.
It's ultimately just a little event listener function that accepts a Request object and returns a Response object. I bundled the service worker by running a quick `npx esbuild --minify --bundle --outfile=sw.js sw.ts` command, and it produced an 18.6kb JS file in 10 milliseconds. That's not even half the size of libraries like HTMX, Alpine, and jQuery.
A well implemented (native) app is always better than a well implemented web site.
The problem is poorly implemented apps which are just UI wrappers hitting dumb APIs or embedding entire web stacks which hit dumb APIs. A well implemented web app isn't much better than that. They don't work offline, they use way more resources than anything native and they leak data like a sieve generally.