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

351–360 of 384 posts

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

#351

Post by lurking_swe »

TeamDman wrote: post #230
oneeyedpigeon wrote: post #36

Earlier quoted context omitted.

> Any text editor that struggles to load a large text file... Define "large". If it's bigger than the biggest text file I'll ever open, then I don't care. My point is that "efficient" code isn't absolutely necessary in many, many cases.

I've recently been summarizing entire directories into a single chunk of text for use with Gemini, the other day I overshot and ended up pasting 28 million characters into vscode. It handled it pretty well.

that’s like a 28MB file, no? That’s not exactly impressive to me on a modern computer in 2024. Maybe i’m crazy haha.

I’d consider 28MB to be a medium sized file. Maybe 100MB+ would be large?

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

#352

Post by lurking_swe »

bloppe wrote: post #259
sgustard wrote: post #222

Earlier quoted context omitted.

Uber is almost the canonical example of something that should be an app! I need to do a frequent task, I punch up the app, I'm always logged in with my location pinpointed, I get a little live-updating widget on my phone with my ride location, plus notifications and Apple Pay and so on. When my ride's over I'm done with the app. Much more useful than say the "Hilton Honors" or "Ann Arbor News" apps which are literall…

literally each of those things is also totally possible and easy with a PWA, except maybe the widget.

which approach would use less battery though? rendering a web view is always more expensive than native rendering.

What about older smartphones that may not work well with bloated web frontend frameworks?

I agree that most of it is possible but in this case I agree with parent, uber makes more sense as a native app.

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

#353

Post by 0dayz »

This really depends on the scope of the project or the philosophy of the project.

Personally I have pretty much sworn off webapps because of the amount of separate concerns:

* the web stack (html+css+ts)

* framework quirks

* dom vs vdom

* nodejs quirks

* hosting platform quirks (if you use serverless)

While some of these can be overcome, personally it was too damn much work.

Compared to say flutter it's dart + flutter quirks, I was surprised how fast I got a working prototype ready without having to dread the all extra crap.

And it seems it's mostly the bullshit Apple and Google does since both solutions have technical issues, all the web apps that only support Chrome for instance.

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

#354

Post by perilunar »

dotancohen wrote: post #158
FredPret wrote: post #145

Earlier quoted context omitted.

The web is just a beautiful publishing platform. - no permission needed (mostly) - built-in discoverability - you get to figure out whatever payment processing you want - works on every device - update code in seconds - no copy protection needed

> works on every device Assuming that the device has an up-to-date browser available for it. And today, that usually requires having a multi-MHz multi-core processor and GiBs of memory. No matter how lean your actual application/website is. I have a stack of E-Ink readers, all in terrific condition. My favorite is the B&N Nook Glowlight 3. When it was new just about five years ago, I could install a web browser on it…

> Assuming that the device has an up-to-date browser available for it.

Not necessarily. You can target older devices with old browsers if you want, by carefully choosing JS/CSS versions and features, or just by making sure your code degrades gracefully.

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

#355

Post by xyzsparetimexyz »

pjmlp wrote: post #188
Animats wrote: post #186

> Thanks to HTML5, WebGL, and WebAssembly, browser games are catching up to native ones in ways we couldn’t have imagined just a few years ago. Meta’s Oculus browser already delivers web games that rival native apps in performance. And once WebGPU becomes standard, the differences will be practically invisible. If only. Have you tried Google Earth on Firefox lately? You can't even zoom in and out any more without wai…

Also, after a decade, browser vendors still don't provide any usable 3D developer tooling better than SpectorJS.

Yeah, your best bet is targeting both desktop and web with something like the rust wgpu library and using renderdoc for debugging/profiling. Which works well until the code stops working in the browser for whatever reason.

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

#356

Post by xyzsparetimexyz »

Animats wrote: post #186

> Thanks to HTML5, WebGL, and WebAssembly, browser games are catching up to native ones in ways we couldn’t have imagined just a few years ago. Meta’s Oculus browser already delivers web games that rival native apps in performance. And once WebGPU becomes standard, the differences will be practically invisible. If only. Have you tried Google Earth on Firefox lately? You can't even zoom in and out any more without wai…

>It's a subset of Vulkan - one command queue, and no bindless mode. Google proposes to fix that around December 2026.

Yeah, WebGPU would be a good, modern API... If it was 2015 and not 2025. But now the differences between it and the desktop are widening and at a certain point, people will just break compatibility for the sake of convenience. I mean, theres not even an equivalent of vkCmdFillBuffer ffs! If you want to reset e.g. a indirect dispatch buffer in a command list, tour best bet is to have a buffer that contains uint32_t 1s and do copies.

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

#357

Post by smart_tech »

leptons wrote: post #253
hnthrowaway2376 wrote: post #223

Earlier quoted context omitted.

> RAM is cheap RAM is cheap for you. It's always silly when people bring up their top-of-the-line computer into discussions about performance. Software shouldn't be just for the top 1%.

Apple RAM is expensive. Every other kind of RAM is pretty cheap. 32GB DDR4 can be had for under $30, and 16GB DDR4 can be had for about $25. I'm not sure who you think has a computer, is developing software, and can't afford that. Maybe someone in India, I guess. Too bad if that's you, but "top 1%" is a laughable claim when RAM is so cheap. 16GB of RAM is nowhere near "top of the line". You're just trolling here, "hn…

[dead]

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

#358

Post by spiderfarmer »

jay_kyburz wrote: post #220
spiderfarmer wrote: post #59

Earlier quoted context omitted.

Ask any random person where they would go to install an app and you'll stop belittling this problem.

I don't know why you wouldn't just call them "web apps". Why the P and why the acronym.

If you define a web app as ‘an app that is actually a website’, just call it a website.

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

#359

Post by rejhgadellaa »

rejhgadellaa wrote: post #328
brookst wrote: post #255

Earlier quoted context omitted.

Shows why guessing and gut feel are bad basis for opinions. In fact, Apple’s problem was that the PWA serviceworker runs as root, a bad decision made years ago. Enabling Chrome-hosted PWAs means Google gets root on those peoples’ phones. We can still lambast Apple and go all ad hom, but let’s stay factual?

Service Workers do not require an installed PWA. Every regular website can have a PWA. I'm not sure who came up with this explanation for Apple trying to kill PWAs in Europe, but it makes zero sense.

I meant to say "Every regular website can have a service worker", but can't edit anymore

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

#360

Post by rejhgadellaa »

brookst wrote: post #257
segfaltnh wrote: post #247

Earlier quoted context omitted.

I think the part where he calls out airline apps is spot on though. They don't need any of that tech.

As a frequent user of both web and phone airline apps, the phone apps are just nicer . UI idioms that are appropriate for the platform, etc.

Part of the problem is that the websites need to "share" budget with the teams that build 2 separate native apps (or maybe they use something like React Native, but that still costs money that could've been used for a better mobile website).

Also, if a company has a mobile app, a bad mobile website is less of a problem. Take Takeaway.com. Their mobile site is terrible. But they have a pretty good mobile app, so why would they need to pour money into making the site any better?

But yes, (mobile) web also just needs to do better.

Post reply on HN