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

21–30 of 384 posts

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

#21

Post by noam_compsci »

oneeyedpigeon wrote: post #10

> Platforms like Poki and CrazyGames, with a combined 95 million players a month, are leading the charge in, what I like to call, the Browser Games Renaissance. I'm probably not the target market, but my first impression of Poki is that it's absolute trash; it looks like a shopfront for the lowest quality mobile games I can imagine. The first thing I tried was a block-puzzler that involved drag-and-drop to move piece…

Agreed I’d rather spend more time on itch. But from a dev perspective poki has a chance to monetise while itch monetisation is near zero at the moment.

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

#22

Post by rubymamis »

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 extremely slow and inefficient - in terms of CPU/RAM/battery life.

I detailed a comparison between native and web block editors, and the difference is huge. The fastest web app (MarkText) is 60x slower at loading texts and uses 3x more RAM than my native app. Also, all web apps couldn't handle loading a very large text file (they were all hanging).

Modern computers are blazing fast and efficient, there's no reason a text editor couldn't load large files. This is why, in my view, web apps aren't really the progress people make them to be. We're going backward, not forward, with web apps. This need to change.

[1] https://rubymamistvalove.com/block-editor

[2] https://rubymamistvalove.com/block-editor#8-performance

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

#23

Post by oneeyedpigeon »

mertbio wrote: post #16

> But fast-forward to today, and browsers can do all that. Browsers can't access all the APIs in iOS. > Developers pay hefty app store fees You pay 99$ per year and 15% for each sale. Apple handles VAT, refunds, distribution and so on. > They’re faster, more flexible, and work seamlessly across devices. Native apps? Not so much. Enabling iCloud sync for your app is just a single click on Xcode. > Why Web Apps Are the…

Your first quote is very misleading because it followed this:

> apps had unique features like notifications and offline access.

Browsers can do those things. If you're going to offer "Browsers can't access all the APIs in iOS" then, at the very list, provide one or two examples of what you're referring to.

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

#24

Post by oneeyedpigeon »

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…

A web app that cannot handle a text file bigger than X bytes doesn't become useless, in the same way that a native app isn't useless even though it, too, has a limit on the maximum file size it can handle.

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

#25

Post by jampekka »

noam_compsci wrote: post #17

Web gaming might be a decent incremental revenue source ( But it will never be more than that. 1. Game ops is too entrenched in mobile. The entire stack (user acquisition, analytics, monetisation) is tried and tested on mobile. These are difficult problems that seem easy to port to web games, but “devils in the detail”. Eg When you’re waiting on appsflyer to ship an update to properly attribute reinstalls for 6 month…

I'm sure there are problems with web games, but some of your arguments seem stem from ignorance about the modern web tech[1].

> 2. Consumers don’t want web games. The UI just isn’t there yet. You misclick out of a tab and lose progress or get distracted / start browsing another tab. Also to do with the ephemeral nature of a browser tab.

Fullscreen mode mostly solves the misclick problem. PWAs solve it entirely. Do consumers care at all about what the underlying technology is.

> 3. Unity’s dev network effects are too large. People who know how to make games use unity. People who want to make games therefore learn unity. It’s a flywheel.

There's Unity web. And people who really know how to make games can also use e.g. Unreal, which as compiled for web for ages.

> 4. Something psychological about downloading an app and seeing it on your Home Screen leads to retention.

PWAs can install to Home Screen.

[1] There is admittedly one company unable to implement modern web tech.

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

#26

Post by PaulRobinson »

A couple of weeks ago I was with a friend who was looking at a website for unusual holiday properties and he bemoaned the lack of an app. I asked him why bookmarks didn't work for him, and he explained it all just got lost - he wanted this to be in the "hotels and holidays" section of his phone's home screen. So I showed him how to add a website to his home screen (well, sort of, I've been iOS since ~2009 and he uses Android, so we had to do a little of collaboration to make it work). Mind blown. Effusive thanks. He now has a way to bookmark sites that works for him.

I'm a big fan of the PWA phenomenon, and got very annoyed with my CEO when I was CTO'ing a new platform about 10 years ago, because he wanted to move to native apps just so that a loading screen looked a little nicer. Ended up using a native shell, did the loading screen the way he wanted and then fell back to a WebUI view for core functions.

However, there are some areas where I think native wins out, primarily the developer experience - I'll take SwiftUI + Swift over almost any other UI based developer workflow out there.

WebASM should mean we see a nice little bit of innovation in the web app dev experience in the near future, and I keep meaning to find time to try Elm out, but at the moment the next app I'm thinking about (which has some tricky low latency UI needs), I'm eyeing up native a lot.

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

#27

Post by rubymamis »

oneeyedpigeon wrote: post #24
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…

A web app that cannot handle a text file bigger than X bytes doesn't become useless, in the same way that a native app isn't useless even though it, too, has a limit on the maximum file size it can handle.

Any text editor that struggles to load a large text file on a modern computer is, simply put, inefficient. If 20 years ago they managed to write programs that could handle such cases and today many (web) apps fail at this task means we're going backward.

My point is that it's much harder to write efficient code in the web ecosystem because you're bound to specific abstractions from the browser. Once deviating from said abstractions, it's not trivial to write efficient code.

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

#28

Post by nmstoker »

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…

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 responsiveness is blown away by the need to faff about installing the app (not to mention the effort needed to avoid giving unnecessary phone access out!)

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

#29

Post by i_love_retros »

Apps get access to the device advertising id, can slurp up more valuable data from users who don't know better than to install it, and are harder to block ads in (average Joe isn't going to set up DNS level ad blocking)

It's all about advertising, always, everywhere.

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

#30

Post by newusertoday »

Webapps do not have access to public url's outside their domain(CORS). Webapps don't have access to gpu in 2024(there is webgpu in chrome but not yet enabled in firefox) Webapps don't have access video/audio codecs.(There is webcodecs api but its partly enabled and there is no api for muxing/demuxing which makes accessing them difficult.) Webapps don't have access to other hardware features that are required for ML.

So while i am rooting for webapps it is still long way to go.

Post reply on HN