4 ms·

I disagree. The problem is more nuanced. A well implemented (native) app is always better than a well implemented web site. The problem is poorly implemented

I disagree. The problem is more nuanced. 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.

adastra22 2y ago
> at Rogue Engine, we’re committed to being the go-to game engine for Three.js and the web and there you go, author has a vested interest in you making web apps.
- polotics 2y ago
  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?
  - egypturnash 2y ago
    https://rogueengine.io/GetStarted https://rogueengine.io/GetStarted says: Plus $ 20 $ 10 / month / seat Billed Annually $ 120 Pro $ 50 $ 25 / month / seat Billed Annually $ 300 Enterprise $ 90 $ 45 / month / seat Billed Annually $ 540 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. ----
  - adastra22 2y ago
    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.
- deleted 2y ago
  [deleted]
ndr42 2y ago
From the article: "[…] web apps have caught up. They’re faster […]" Especially how can this be true? Maybe this doesn't matter because it's already fast enough but the difference in look and feel will be noticeable.
- oneeyedpigeon 2y ago
  The writer probably meant "faster [than they used to be]" rather than "faster [than native apps]".
hombre_fatal 2y ago
> A well implemented (native) app is always better than a well implemented web site. Dunno, native app doesn't have URLs nor deep links. I can't link you to a page in my native app that you can click on. In my iOS HN app I'd have to click "Copy website link" to share a submission. If there were no website, I couldn't share it at all. Same with Reddit. For most apps, that's a lot to give up when you app is basically just a website without a url bar.
- oneeyedpigeon 2y ago
  Same native apps don't even relayout when you change window size, let you change the font size, or let you copy text.
  - manmal 2y ago
    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.
- sltkr 2y ago
  Android apps absolutely support deep links: https://developer.android.com/training/app-links https://developer.android.com/training/app-links (surely iOS supports this too?) 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.
- victorbjorklund 2y ago
  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)
  - jcotton42 2y ago
    Android and Windows do too.
backspace_ 2y ago
On a side not, I like how we have electron apps that are 100s of mega that just access a website. Just as much of a waste.
amelius 2y ago
> A well implemented (native) app is always better than a well implemented web site. No, because it fails to support the feature of running virtually anywhere. For many people this is the #1 feature. Everything else is just icing on the cake. Who cares about an app that is 2x faster but doesn't run?
- flkiwi 2y ago
  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.
- mjmsmith 2y ago
  > For many people this is the #1 feature. Everything else is just icing on the cake. I hear this sentiment from developers much more than non-developers. I wonder what percentage of developers do all their work within a browser.
  - amelius 2y ago
    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.
syndicatedjelly 2y ago
> 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.
wiseowise 2y ago
> A well implemented (native) app is always better than a well implemented web site. No, not always. I don’t care how well implemented or optimized your “app” if it’s something that could’ve been a static web page. > They don't work offline, they use way more resources than anything native and they leak data like a sieve generally False, false and false.
throwitaway1123 2y ago
> They don't work offline 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 https://hono.dev/docs/getting-started/service-worker
- Spivak 2y ago
  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.
  - throwitaway1123 2y ago
    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. You can of course use the CacheStorage API directly as well (you're not obligated to use a mock server): https://developer.mozilla.org/en-US/docs/Web/API/CacheStorage#examples https://developer.mozilla.org/en-US/docs/Web/API/CacheStorag... I've certainly seen crazier things though. People routinely include entire copies of Ubuntu LTS in their Docker images to ship tiny HTTP servers.

adastra22 2y ago

> at Rogue Engine, we’re committed to being the go-to game engine for Three.js and the web and there you go, author has a vested interest in you making web apps.

polotics 2y ago
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?
- egypturnash 2y ago
  https://rogueengine.io/GetStarted https://rogueengine.io/GetStarted says: Plus $ 20 $ 10 / month / seat Billed Annually $ 120 Pro $ 50 $ 25 / month / seat Billed Annually $ 300 Enterprise $ 90 $ 45 / month / seat Billed Annually $ 540 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. ----
- adastra22 2y ago
  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.
deleted 2y ago
[deleted]

ndr42 2y ago

From the article: "[…] web apps have caught up. They’re faster […]" Especially how can this be true? Maybe this doesn't matter because it's already fast enough but the difference in look and feel will be noticeable.

oneeyedpigeon 2y ago
The writer probably meant "faster [than they used to be]" rather than "faster [than native apps]".

hombre_fatal 2y ago

> A well implemented (native) app is always better than a well implemented web site. Dunno, native app doesn't have URLs nor deep links. I can't link you to a page in my native app that you can click on. In my iOS HN app I'd have to click "Copy website link" to share a submission. If there were no website, I couldn't share it at all. Same with Reddit. For most apps, that's a lot to give up when you app is basically just a website without a url bar.

oneeyedpigeon 2y ago
Same native apps don't even relayout when you change window size, let you change the font size, or let you copy text.
- manmal 2y ago
  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.
sltkr 2y ago
Android apps absolutely support deep links: https://developer.android.com/training/app-links https://developer.android.com/training/app-links (surely iOS supports this too?) 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.
victorbjorklund 2y ago
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)
- jcotton42 2y ago
  Android and Windows do too.

backspace_ 2y ago

On a side not, I like how we have electron apps that are 100s of mega that just access a website. Just as much of a waste.

amelius 2y ago

> A well implemented (native) app is always better than a well implemented web site. No, because it fails to support the feature of running virtually anywhere. For many people this is the #1 feature. Everything else is just icing on the cake. Who cares about an app that is 2x faster but doesn't run?

flkiwi 2y ago
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.
mjmsmith 2y ago
> For many people this is the #1 feature. Everything else is just icing on the cake. I hear this sentiment from developers much more than non-developers. I wonder what percentage of developers do all their work within a browser.
- amelius 2y ago
  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.

syndicatedjelly 2y ago

> 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.

wiseowise 2y ago

> A well implemented (native) app is always better than a well implemented web site. No, not always. I don’t care how well implemented or optimized your “app” if it’s something that could’ve been a static web page. > They don't work offline, they use way more resources than anything native and they leak data like a sieve generally False, false and false.

throwitaway1123 2y ago

> They don't work offline 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 https://hono.dev/docs/getting-started/service-worker

Spivak 2y ago
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.
- throwitaway1123 2y ago
  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. You can of course use the CacheStorage API directly as well (you're not obligated to use a mock server): https://developer.mozilla.org/en-US/docs/Web/API/CacheStorage#examples https://developer.mozilla.org/en-US/docs/Web/API/CacheStorag... I've certainly seen crazier things though. People routinely include entire copies of Ubuntu LTS in their Docker images to ship tiny HTTP servers.