Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

App Should Have Been a Website (and Probably Your Game Too)

rogueengine.io

Post reply on HN
Print view View original

301–310 of 384 posts

Re: App Should Have Been a Website (and Probably Your Game Too)

#301

Post by p2detar »

nox101 wrote: post #272
thot_experiment wrote: post #159

I man don't get me wrong, I love the idea of PWAs but this dude is out to lunch. It's so painful making anything complex work cross browser/cross platform. On iOS iirc they don't even support adding PWAs to the homescreen? You definitely can't Bluetooth outside of Chrome (probably only on Android and Windows too because nothing fun is ever allowed on Macs). Multiplayer games you kind of need UDP. You cannot UDP in th…

Do you need UDP? I see lots of multiplayer browser games. Here's a few https://browsergames.gg/ Google shows me a bunch of RPGs https://www.google.com/search?q=browser+based+rpg FPSes here https://poki.com/en/shooting or maybe better a video showing some https://www.youtube.com/watch?v=9ad5jcXPbNw I know none of them are Edlin Ring, Skyrim, or Call of Duty. One issue with Web games is users's expect them to start qui…

https://nightpoint.io has been around for a long time, it's a fast-paced 2D shooter, uses web sockets and it does quite good actually.

I think the same dev created https://battledudes.io later on, again based on web sockets. It has/had (haven't played recently) a pretty big player community.

Re: App Should Have Been a Website (and Probably Your Game Too)

#302

Post by theK »

thot_experiment wrote: post #159

I man don't get me wrong, I love the idea of PWAs but this dude is out to lunch. It's so painful making anything complex work cross browser/cross platform. On iOS iirc they don't even support adding PWAs to the homescreen? You definitely can't Bluetooth outside of Chrome (probably only on Android and Windows too because nothing fun is ever allowed on Macs). Multiplayer games you kind of need UDP. You cannot UDP in th…

Agreed. But I would like to add that there are also numerous UX pitfalls that apps fall into that are trivially solvable on the web.

Broadly:

- deeplinking (while technically doable it is still a pita to set up cross platform and require just way too much engineering in the long run)

- branching out UX (it is interesting how many seemingly straightforward processes turn out to be better if you can branch out into something like a tab)

Re: App Should Have Been a Website (and Probably Your Game Too)

#303

Post by throwitaway1123 »

Spivak wrote: post #300
throwitaway1123 wrote: post #294

Earlier quoted context omitted.

> 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

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.

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

Re: App Should Have Been a Website (and Probably Your Game Too)

#304

Post by Intermernet »

nox101 wrote: post #272
thot_experiment wrote: post #159

I man don't get me wrong, I love the idea of PWAs but this dude is out to lunch. It's so painful making anything complex work cross browser/cross platform. On iOS iirc they don't even support adding PWAs to the homescreen? You definitely can't Bluetooth outside of Chrome (probably only on Android and Windows too because nothing fun is ever allowed on Macs). Multiplayer games you kind of need UDP. You cannot UDP in th…

Do you need UDP? I see lots of multiplayer browser games. Here's a few https://browsergames.gg/ Google shows me a bunch of RPGs https://www.google.com/search?q=browser+based+rpg FPSes here https://poki.com/en/shooting or maybe better a video showing some https://www.youtube.com/watch?v=9ad5jcXPbNw I know none of them are Edlin Ring, Skyrim, or Call of Duty. One issue with Web games is users's expect them to start qui…

I know it was a typo, but I want to play edlin ring. The most frustrating text mode adventure ever.

Re: App Should Have Been a Website (and Probably Your Game Too)

#305

Post by [deleted] »

reaperducer wrote: post #299
madeofpalk wrote: post #282

Earlier quoted context omitted.

> Originally all third-party software was going to be installed this way. It's off topic, but I don't think this was true once the HTML Weather and Stocks 'widgets' failed on iOS. Anything Apple said publicly was just saving face until their SDK was ready for public consumption.

It was true. I developed iPhone OS web apps during that time.

[deleted]

Re: App Should Have Been a Website (and Probably Your Game Too)

#306

Post by liontwist »

darknavi wrote: post #68
rubymamis wrote: post #22

While the web platform is catching up due to the continuous supply of abstractions by modern browsers, once you must deviate from those abstractions, you quickly find yourself needing to implement something yourself that is much less efficient than a native implementation. I wrote about developing my own block editor from scratch[1] using C++ and QML after finding that Notion (and so many other web apps) are extremel…

It's funny that part of the reason computer hardware has gotten faster and more efficient is because heavy usage work flows, even things like web apps. So while you think web apps are going "backwards", they've likely helped contributed to modern computing hardware speeding up your native programs!

No. The motivation to make existing flows faster and do more of those at once is constant. It wasn’t initiated by bloated web apps

Re: App Should Have Been a Website (and Probably Your Game Too)

#307

Post by kristianp »

For many businesses an app also has a web version for those users who refuse to install the app. I'm thinking my local supermarket, or kmart, they want me to install their app for some reason. I suppose it's so they can send me advertising as notifications? Many business that aren't "app only" have to have both web app and mobiles apps. App development studios love them.

Re: App Should Have Been a Website (and Probably Your Game Too)

#308

Post by jongjong »

I never understood why anyone bothered with native apps. It defies reason why consumers would prefer to download some clunky app instead of just using it in their mobile browser with no strings attached. The main excuse I keep hearing are UI/UX differences but web UI/UX is excellent these days, it really doesn't offset the huge negative hurdle of having to download an untrusted app which takes up your time and uses up space on your phone before you can use it. How do consumers even know they will like the app before they tried it? Why would they download an app they don't know? It makes no sense to me. WTF! The user will only ever download the native app if they've been conditioned to believe that it's worth their time and disk space. But how do you get that conditioning effect going when you're just starting out? Massive chicken-and-egg problem.

I think it's probably a remnant of a very successful corporate PsyOp. I can see why big tech wants to be able to covertly access people's cameras, microphones and location data. In most cases, there is literally nothing positive for the consumer. It's a story of leveraging user apathy to manufacture consent. Most people fell for it. Personally, I hate being forced to download native apps when the web version of the app already works perfectly.

Sometimes I feel like the push against web tech is partly the product of a spiteful group of developers who hate JavaScript because they had a bad experience with it back in 2010 and they've stubbornly refused to re-evaluate their position in spite of the language showing extreme resilience and adaptability.

The HTML + CSS + JavaScript combo is a marvel of software engineering. The ECMAScript standard is surely one of the most impressive accomplishment that bureaucracy has ever produced. It has progressed with both speed and quality, picking the best parts of many different languages.

Re: App Should Have Been a Website (and Probably Your Game Too)

#309

Post by aeldidi »

Ajedi32 wrote: post #156
frereubu wrote: post #152

Earlier quoted context omitted.

True except the part about "works on every device" is dependent on what part of the device you're trying to use, as the parent says about Bluetooth.

I'm a bit curious about what's wrong with Bluetooth on the web. Is it just because Safari and Firefox don't support it yet?

It’s important to note that it’s not a matter of effort for Firefox. They’ve decided that the it’s not something they want to implement[1]. The reasoning is that they think it allows low enough level access to potentially mess with devices who weren’t made to be resilient to malicious input, and didn’t like that the proposed method of allowing web Bluetooth is based on a default allow policy with a blocklist, which means as new Bluetooth device vulnerabilities are discovered, this blocklist has to be maintained.

[1]: https://mozilla.github.io/standards-positions/#web-bluetooth

Re: App Should Have Been a Website (and Probably Your Game Too)

#310

Post by what »

wiseowise wrote: post #279
nmstoker wrote: post #28

Earlier quoted context omitted.

First the needs of the user-base should trump those of the dev. And secondly the kinds of apps that are referred to here are not the type that need massive efficiency or some complex feature - when inconvenienced by yet another single-use car park payment app, I've never once thought how marvellous it was that the text downloaded so much faster than the many web sites I regularly use: mainly because that responsivene…

You forgot constant 100MB updates, which are just one page refresh on web.

And that one page refresh is probably also 100MB these days.
Post reply on HN