App Should Have Been a Website (and Probably Your Game Too)
rogueengine.io
rogueengine.io
Multiplayer games you kind of need UDP. You cannot UDP in the browser (WebRTC data channels technically use UDP but that stack is an abomination wrapped in SCTP and DTLS)
This is by no means an exhaustive list, just issues I've dealt with recently. It's better than it was with WebGPU and WASM, some of the gap between a native app and a website is surmountable, but unless you're doing something extremely boring surmounting the gap is hard fucking work.
You've been able to add websites to the home screen going back at least to the iPhone 5 in 2012. Is it the "PWA" part you're questioning? iOS definitely does have PWA support, although with a few notable limitations that may be deal-breakers for certain apps. Oh, and apparently Apple recently disabled PWAs entirely in the EU.
Apple reversed that decision back in March [0] (expand "Why don't users in the EU have access to Home Screen web apps?")
[0] https://developer.apple.com/support/dma-and-apps-in-the-eu
This rationalization makes zero sense, it's just opening a standalone browser window from a convenient icon shortcut. They could even ignore the manifest.json entirely like Android does half the time anyway cause the implementation is buggy as all hell.
I think the real reason was some kind of retaliation worthy of a baby insanity wolf meme because they were forced to stop reskinning Safari for all other browsers on iOS which was absolutely ridiculous in the first place.
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?
My least favorite dark pattern is that you first have to change the share menu and add the option. That way it seems less inconvenient to people who've done it before.
To share a fun perspective: Desktop desktops and phone home screens are really revolutionary compared to the browser bookmark menus and app stores are really web directories that are both glamorous and horrible at the same time.
There is sabotage along the way but we are clearly moving forwards.
Imagine an AI starting a thread or a sub forum for each application it can find online. Then have it gather articles about the application and post them as replies or topics. Divide everything neatly over categories (like a web directory) and have it gather usable icons/logos for navigation. By default it only displays software for the users platform or browser but a few check boxes in advanced search settings can change the selection.
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.
Meanwhile https://github.com/achingbrain/webtransport-echo-server this is the best we have for a minimal working node example.
The guys at Colyseus (a JS library for multiplayer games netcode) also added support, in a preview version for now.
That’s usually a sign nobody uses it because it has at least one large issue. Personally I stopped falling for “there’s now X” advices long ago because if it worked, it would already be mainstream very much heard of by everyone. Sorry for your five hours.
I also found the following in my research yesterday, which looks like a very promising set of abstractions for WebRTC data channels.
So you just never use anything new, always stuck with what has been? Because everything starts with just one person using it, then two, then four and so on, things can't just be popular from day 0.
I'd agree with that chasing the latest fads (no matter the popularity) is a fools errand, and you need to look beyond vanity metrics to evaluate if something is useful or not. Sometimes that means trying things and sometimes even making a hard bet on something that hasn't been demonstrated "right" yet.
Most of them, even if native don't really work without the API based backend.
If we take out the garbage apps, copycats, and games without DLCs, most stuff is some variation of form over data.
And those that are really special, needing native APIs, working offline by default, can probably be reduced to about 10% of apps.
Edit: Err, sorry to pile on. I see others have already mentioned this.
https://github.com/khmyznikov/pwa-install (Try on device: https://khmyznikov.com/pwa-install/)
Webdev is constant reinvention of a wheel in all sorts of wrong ways, with “components” on the same level of ui quality.
Many apps are just electron apps or vb-like (x,y,w,h) forms slapped together by someone barely familiar with a platform IDE. But the rest is absolutely superior to the “web”.
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.
Of course there are use cases that you mentioned are better served via native app. For eg. Apps that need compute or location. That's not the argument author is making.
The downside of delivering everything via app is your device ends up with app sprawl that eats up the resources.
They literally supported this since iPhone OS 1.0 (it wasn’t even called iOS yet). In fact, it was supposed to be the only way to add apps to the iPhone until people complained and started jailbreaking to install their own apps. Apple didn’t release the App Store and the iOS SDK until iPhone OS 2.0
I got a basic offline-capable TODO list (the hello world of web apps) working as a PWA for my iPhone. Almost all of it handed to me by ChatGPT.
If I exit the PWA, turn off WiFi and open the PWA again, the PWA still works.
The only annoying thing is that the way you add a PWA to your Home Screen on iOS is too convoluted to realistically get most people to do it, if you were to make a PWA that you actually wanted people to “install”. Although the JS solution that someone else posted ITT with a small pop-over that explains the steps is pretty near to ok. Certainly helps the situation a bit at least.
Google shows me a bunch of RPGs
https://www.google.com/search?q=browser+based+rpg
FPSes here
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 quickly so no downloading 80gig of assets like 102gig for CoD Black Ops 6
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.
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)
Theory falls down hard.
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.
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.
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.
We could keep going, but it maths out to mind-blowing amounts of waste just copying bytes around between buffers with no value add.
(Old man editorializing at clouds: "and all so we can employ people who don't know how computers work to satisfy corporate product pipelines by shoveling digital shit onto people that they neither want nor need")
I’d consider 28MB to be a medium sized file. Maybe 100MB+ would be large?
notepad++ solved this problem 20+ years ago.
I agree it’s an uncommon use case but it’s kind of sad when an app struggles to open a file like that on a modern machine in 2024. Just sad.
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!)
Again, from my understanding, Obsidian is not that. If I remember correctly it is based on CodeMirror which is designed to only handle (EDIT: rich) text.
Edit (addendum): BTW, I'm not sure your Obsidian RAM reading is correct, an empty instance of Obsidian with one note uses 285MB (all 4 processes together) on my machine (M1).
[EDIT] Here is memory consumption of Daino Notes: https://pasteboard.co/z5pciLoh99i6.png
EDIT: Btw, I do have plans to cut RAM usage significantly in Daino Notes (I focused more on load time and responsiveness). But getting back to my point - I can do these optimizations because those RAM inefficiencies are a result of my code, not some abstractions I can't change.
Funny, but how about a log of one Jenkins run weighting at - checking... - 630 MB? Or two of them so someone can compare them?
VSCode is close to counting… but it absolutely sucks on RAM usage, so I try to avoid it when I can.
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%.
Let's say I spent $50 on 32GB of RAM. Over the lifetime of the computer that upgrade would cost ~$0.02 per day. Two pennies a day. And that's US prices, it can be less expensive elsewhere.
I've used VSCode on a computer with 2GB of RAM, and it worked. I expected everything to run slower - and it did run slower, but it ran. And I developed, and contributed to the project I was working on while away from my workstation. This was a cheap $70 Windows 10 tablet. YMMV.
I'm sure that's pretty cheap for you, yes. Taxes and other fees tend to increase those prices outside the US, by the way.
> I'm not sure who you think has a computer, is developing software, and can't afford that.
There is a market for lightweight code editors, isn't there?
> Too bad if that's you, but "top 1%" is a laughable claim when RAM is so cheap.
That was a bit of hyperbole on my part, but let's not forget that just being an employed SWE in the US easily places you in the top 1% globally.
> I've used VSCode on a computer with 2GB of RAM, and it worked. I expected everything to run slower - and it did run slower, but it ran. And I developed, and contributed to the project I was working on while away from my workstation. This was a cheap $70 Windows 10 tablet. YMMV.
Fair enough. VSCode is hardly the worst offender though - it actually runs quite well for an Electron app.
And not being able to afford $30 as a developer for a decent amount of RAM puts you in the bottom 1% of developers globally. Yes, I made that up just as you are making up your own numbers. But as I explained, you don't need 128GB of RAM, you don't need 64GB of RAM, you don't even need 8GB of RAM, you can still develop with VSCode with 2GB of RAM. Nobody is handing out free RAM, so if you need more, save your rupees, or pennies, or euros, or whatever. The daily cost of it spread over time is miniscule for anyone on the planet, and you will get back the investment in saved time.
So while you think web apps are going "backwards", they've likely helped contributed to modern computing hardware speeding up your native programs!
So in my view, browsers became capable, but then plenty of "heavy" web apps appeared, which required more beef in the machine.
That's also the typical way it goes: current hardware being okayish but not great is one of the strongest drivers for better hardware. Whether it is gaming (PCs), camera (smartphones), the web bloating (both).
Web apps can just up and disappear, spontaneously grow paywalls, or slowly enshittify over time, and unless both the user is technically savvy and the web app is fully open source, there’s nothing the user can do about it.
In contrast, when a new release of a native app is worse or its company goes under, the user retains a useful product (old binary) that can be run bordeline indefinitely one way or another (hacks, emulation, etc).
The biggest problem is with apps that show you content. Web sites give the user more control over what content to save, better exposure to scrapers and APIs, standard navigation to every other web site.
Websites can give more control but that’s hardly a rule these days and depends on how the site/webapp in question was built. Something built with a canvas-based UI (as is sometimes necessary for displaying high volumes of information without performance degradation) for example isn’t going to give the user any better control than a native app would, and in some cases less.
I’ve wanted to do the same thing you did but with coding notebooks (e. Jupyter) for a while now. It frustrates me to no end that the only native software for notebooks is JetBrains IDEA (and even that’s only an “I think it’s naive” lol). Hopefully I can take what you learned and documented and apply it to my app ^-^
Even the logo is almost identical.
Is this the same project? Looks like two separate GitHub repos by the same author. Why two similar projects/websites?
7. The previous version of Daino Notes, called Notes is FOSS (free and open-source software) available at https://www.notes-foss.com/ and the source code is available at https://github.com/nuttyartist/notes. I decided to make Daino Notes closed source due to difficulties in monetizing FOSS. In order to comply with Notes' MPL license, all common files between Notes and Daino Notes are published in https://github.com/nuttyartist/daino-notes-public
Multiplayer was quoting the correct reason. I also exeplained more about the timeline here: https://github.com/nuttyartist/notes/issues/690#issuecomment...
Tldr: The FOSS version earned a stable revenue through Google Ads placed on the website, since the website ranked high on Google searches. Two years ago, that changed since the website got de-ranked, so I created a different, proprietary version of the app based on the FOSS version but with a totally revamped block editor that I wrote from scratch - that I worked on full-time for a whole 1 year.
As you have pointed out, QML is buggy. Chromium's rendering engine is probably the most stable and polished GUI toolkit there is, not to mention a cross-platform one too. Throughout the last 10 years I only had to deal with 2 Chromium bugs and they were very minor. Well-written JavaScript is fast and the machines are getting faster every year. It does not take much real time computation to provide a UI for a desktop app, it's not a video game. And many of the those things that are real time, like the caret in the text editor or hover states are implemented in native code by the web browser, with no JS interaction. I agree though that a block editor is a little more real time than the average UI.
The key word is well-written JavaScript. What is the most popular state management framework? Redux, possibly. What is the most inefficient state management framework? Also Redux. With Redux, if you have an app that displays a timer that updates every second, every subscription to any piece of the state throughout the entire app will trigger. I'm not sure if the app used Redux, but I used to use a time tracker app that would use 30% of my CPU when idle (I since moved to a CLI C++ solution and it is so much faster, but that does not mean a decent time tracker could not be built with web technologies). So if Redux is the most popular framework, you can see just how little the average web dev cares about writing apps that are not slow resource hogs.
> Also, all web apps couldn't handle loading a very large text file (they were all hanging).
Could it be that QT has some optimisation technique to not render all those lines out of view? I.e. if you have a huge file that can still be loaded to RAM, C++ won't sweat it, but is it actually getting all rendered at the same time in a savvy implementation, whether at the level of the app or the framework? Probably not. On the other hand, the textarea element or a contentEditable div just was not made for something like this. It could still be developed by implementing a custom element / component that loads the text dynamically while scrolling. If it's too much for JS to hold, it could use WASM or another process and pass it with IPC. It is definitely possible to write an Electron-based text editor that can open a 1 GB text file efficiently, it's just not out of the box experience and most people do not think there's a need for such a use case.
Like with anything, we're dealing with abstractions. Qt and QML are also abstractions. But I'd argue they are better abstractions than the web for dynamic semi-complex to complex applications (for static sites/simple applications, the web is fine). The reason Qt and QML are a great abstractions are mainly:
1. Native modules/APIs - you can always plug in native modules into your app as needed. For example, I use native Objective-C APIs to draw the window on macOS for my app. It just looks better than what you get with just Qt.
2. Performance - Almost all QML-based components (called Qt Quick), are written in fast, compiled language C++, and if needed, you can create your own components in C++ and expose them via QML.
3. There are many more reasons, one of them is that I think QML is the best declarative UI language I've seen, and it plays very nicely with Qt style of C++ (signal and slots etc.).
> Could it be that QT has some optimisation technique to not render all those lines out of view?
Well, I detailed in my blog post my technique - it's not really novel - you can build virtualized lists in many languages, including JavaScript. You can look into the source code of many web apps that have done the same type of block editor that I implemented. MarkText[1] seems to be the most efficient one from my testings. My point is that building upon the abstractions of the web makes it very hard to write truly efficient code that is well-optimized for your computer resources. You might be an amazing programmer, but you're limited by a certain upper bound of performance, by the mercy of the web standards council and web browser engines implementation of those standards.
Yep. That's precisely the point, you get all this stuff from a billion dollar project for free.
I really would not mind writing some C++ instead, even if it was more difficult. If anything, it would only be better because of higher moat of the project as well as my own skills. I agree 100% on the principles that native is better, faster and JS is an unnecessary layer of abstraction slowing things down.
However, if I can compare 2 timelines, one where I am using QML for a project, another one where I am using Electron and think about the time spent working around bugs, reporting bugs and the users of the app complain about crashes in the former, or not have any of that at the trade off of having something slightly slower, to me it's a no brainer.
In the context of what you wrote in the article:
> One of the most frustrating aspects of developing a Qt application is the slew of Qt bugs you encounter along the way. During ten months of development, I reported seven bugs, three of which were assigned 'critical' priority—two of which resulted in crashes. I also came across many bugs already reported by others that remain unfixed.
I would rather have an app that is slightly slower than one that can crash unexpectedly. Even if they are quick to fix bugs, new bugs may be introduced in new releases. Your intent was to promote QT in your blog post, but unfortunately it has only affirmed to me that it's not something production-ready (QML on desktop).
That's just the unfortunate state of industry where we are at. Hopefully it changes one day. Maybe Chromium could be forked into a C++ GUI toolkit where DOM could be manipulated directly by C++. Has anyone ever considered that?
Haha, that's interesting. But to be honest, it's really not that bad as it seems. Again, crash reports tend to be highly prioritized and most of the time you can find your way around them until they get fixed. It's indeed a frustrating experience when non-crash related bugs aren't being prioritized, but then again, like I explain in the blog, I could use a different library, probably an open source solution like I described using QBasicHtmlExporter[1] since QTextDocument toHtml uses weird inline HTML (and has some other bugs).
The thing is, with experience I kinda start to have my own boilerplate of battle-tested components/tools/libraries. I made the following client for Ollama[2][3] while not working on it full-time (still WIP) in around a month. It already is better than many web apps I tried who kept hanging while the model was generating a response. Also, try to copy text from a code block in web apps while a model is still generating a response -> it's almost always impossible since most web apps keep re-rendering everything on each completion, while I (like the native macOS chatGPT app) do incremental parsing which is much more efficient. The binary is 28MB (and can be even smaller), the app is fast and can handle very large amount of data. So I can build QML apps really, really fast these days due to the experience I gained and still gaining. I'm also wondering if I should open source my components as AGPL and then have some commercial licensing for it... Not to mention, I rarely use my own heap allocations myself - I try to put as much as I can either on the stack or in QML - so Qt handles all the heap allocation itself. While I'm relying on Qt to do an appropriate job, it seems to be very, very stable for now.
[1] https://github.com/Open-App-Library/QBasicHtmlExporter
Activity and Fitness
Nutrition and Weight Management
Sleep Management
Medical Device Apps
So we gotta update our policies, but today they said something like: "Actually, jk, you don't qualify as a Medical Device App anymore - app update rejected."
Meanwhile, Apple (who used to be the actual nightmare) has somehow turned into the reasonable one. They approve apps in minutes now. MINUTES.
It's like Google saw Apple's approval process from 10 years ago and thought, "Let's do that, but make it a circus." At this point, I dream of ditching native apps entirely. Too bad Bluetooth on the web is still a bit... fragile.
“This is an important tax update for [country you didn’t think existed anymore].” etc.
I somehow got my personal email associated with the classroom Google Play account from back when I was at university, so every app uploaded by all students for each new semester I get emails for still. Every few months I get a batch of 30+ emails telling my that my app is not in compliance and it's at risk of being removed.
- 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
[1]: https://mozilla.github.io/standards-positions/#web-bluetooth
Then again, almost every time a Firefox thread appears here it gets filled with comments pointing out how low its adoption is so I guess "well, yeah" sums it up (he said, commenting from Firefox)
> works on every device
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 via ADB and it would work reasonably well. Today, all the browsers are bloated beyond installable and usable.
My Onyx Boox runs Firefox happily too, but for that and the pinephone I'd recommend trying out a Gemini browser (there are several on fdroid). It's lacking plenty, but has an old-web feel, no sites are slow, and you can handily use it on old devices.
> I feel your pain, though I blame the websites more than the browsers.
I love the Boox devices as well. My Note Air 2 Plus is almost two years old, it is a terrific machine. I'd love to know what your use cases are. I mostly use it for taking notes and reading - including on the web - but I'm rather unhappy with most browsers on it including Firefox. For one thing, Firefox on Android has almost no keyboard support.
My Boox Color 7 was originally bought for terminal work and I connect it to my bluetooth keyboard and use tailscale and termux to make it a nice e-ink "dumb terminal". It's also nice for reading books on, and downloading said books (though I miss Kindle's email transfer method). I did try watching a YouTube video on it once, the result was almost watchable and far better than expected.
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.
The problems begin accruing before the user even types in your URL.
And then there’s JS.
Rails, htmx, and a few others seem like the only ones who really get that a simple web app should be 50-100loc.
Well that's some nonsense. HTML can absolutely achieve 1:1 on any UI you care to mention. It isn't even difficult if you have any skill at all.
>And then there’s JS.
And then there's another person who didn't take the time to learn JS and just hates it for reasons.
>Rails, htmx, and a few others seem like the only ones who really get that a simple web app should be 50-100loc
Show me a native app with a polished UI and any useful functionality in only 50-100loc.
JS has absolutely no rhyme or reason, single threaded nature makes it gunk up browsers crazy quickly & the insane bloat of "frameworks", which attempt to completely replace already great APIs, while working on top of them... IS CRAZY!
That's really false. The type coercion matrix does make sense for the job it is supposed to accomplish, even if you personally don't agree with it for whatever your reasons are.
https://media.geeksforgeeks.org/wp-content/uploads/advanced-...
If you haven't seen the info presented like this before, then I can understand why Javascript might seem "CRAZY" after reading so many blog posts by people who like to complain for clicks. If you think this chart doesn't have any "rhyme or reason", then please explain why.
>single threaded nature makes it gunk up browsers crazy quickly
That's one way to look at it. Another way is to learn how to work with the system you have, not the system you want. Improvements to the system can be slow, and can't be breaking changes. This is true about every system humans have ever devised.
Webworkers are great, you can absolutely do multi-threaded Javascript, I've done it, it was easy. If that solves the problem in a reasonable amount of time, great, if not then I'll probably do it in C and run it from Javascript since it's so easy to write the rest of the application with Javascript.
Not everything needs maximum performance. For some embedded systems I usually write 100% assembly language because every byte and clock cycle matters. But I know all of this really well, so maybe it seems easy for me. When I started with Javascript in Netscape in the early 90's, it wasn't as well documented and well supported as it is today. That version of Javascript was a bit rough around the edges. But today? Naaa. It's easy, it's got a huge support system, a lot of progressive enhancements, thousands of videos, millions of developers and about a billion blog posts on medium.com.
I switch back and forth from C to Javascript and it's a great combination. Less context switching, the syntax close to 1:1 as far as I'm concerned. But C is a pain in the ass in comparison to Javascript, and I know both languages extremely well. I've been writing software almost 50 years.
>the insane bloat of "frameworks"
I'm using Preact for my embedded IoT front-end and the complex web app it compiles is less than 50KB total gzipped. Bloat is a choice, not a requirement.
I have complex front-ends running "at web scale" based on jQuery (for business reasons). We decide every byte that gets included, and manage to score 100% on all page speed tests. No bloat.
>which attempt to completely replace already great APIs,
Citation needed.
> IS CRAZY!
People have been using Javascript successfully for decades. Sorry Javascript isn't your favorite language, but it's not as you describe it either.
Are you trying to sell JS or not? :)
> When I started with Javascript in Netscape in the early 90's, it wasn't as well documented and well supported as it is today. That version of Javascript was a bit rough around the edges
Best bug I saw there was how it would sometimes just...give up on running JS if you held it wrong (probably a Netscape thing) and you had to figure out why.
> I'm using Preact for my embedded IoT front-end and the complex web app it compiles is less than 50KB total gzipped. Bloat is a choice, not a requirement.
50KB sent to the client in total? What UI libraries do you use? Happy to try out things; I'm currently a fan of Svelte but haven't tried Preact yet.
Very constructive, thank you.
I'm talking about the defaults of HTML. There's no pit of success, just lots of div-wrapping and tweaking until things fall into place. Compare with SwiftUI, where you plop two controls and they're spaced sensibly from one another without you doing anything. This was also the case in VB6.
> And then there's another person who didn't take the time to learn JS and just hates it for reasons.
I've been writing TS for awhile now, it's mostly fine. Should've expanded further: npm is a bit of a madhouse, and JS culture basically consists of "we shove JS everywhere we can and say it is good because it is JS."
> Show me a native app with a polished UI and any useful functionality in only 50-100loc.
I'll concede that. At 50-100loc, you can have a decent looking native app for a simple task. Presentation layer for a webapp blows through that immediately. Some of that is accepting the medium as is and learning to work with it. Some of it is also the fundamental impedance mismatch of the web writ documents/apps.
If you don't know what you're doing and plan things out, sure that is what you might expect - but that's a choice. And that's the same in any language or framework or platform. It's possible to write bloated unmaintainable UIs outside of JS/HTML.
>npm is a bit of a madhouse, and JS culture basically consists of "we shove JS everywhere we can and say it is good because it is JS."
Every package manager for every language is a bit of a "madhouse". It's the nature of free software. I'm not sure why you would expect JS programmers to not want to use JS packages, I'm not quite sure how you arrived at this sentiment.
>At 50-100loc, you can have a decent looking native app for a simple task.
Same with Javascript. You might be surprised what can be achieved in a few bytes of Javascript. Ever visit dwitter.net ? I think you're also leaving CSS out of the equation, which has very powerful styling capabilities. 10 or 20 lines of CSS can achieve a lot of UI styling for a simple app. The HTML/CSS/JS combination is very expressive, extremely powerful and easy to use. Not sure how you think it's somehow incapable of UI similar to native applications, without bloat, and easy to implement. I suppose it depends on your skill level with these tools, because I find it extremely easy to do. YMMV.
CSS classes are all of the rage these days.
OTOH, in tired of everyone pushing apps that could easily be a website.
I had an xfinity technician aggressively pushing me to install their xfi app when they came to install the service. They told me it was the only good way to configure the WiFi (!) and that they had to check a task in their technician to do list that they “walked the consumer through installing the app”.
Horrible consumer experience. Between the borderline lies and the nefarious push for the app, if I had had any other choice I would have rejected the installation on the spot. But alas xfinity was literally the only provider that could offer service with any decent speed.
But, I guess if you're paying for one for one of their all-in-one packages where the service is managing voip/streaming/tv/internet I guess I can see their equipment and management tool might be necessary. Wouldn't know, have avoided all that. Try to keep them just as an ISP.
You can send the users a notification even when they aren't using the app
It's much harder or impossible for users to block in-app advertising
It's easier to track users via apps, and your tracking data will be richer, more accurate and therefore more valuable.
Until this changes, we'll get stupid apps that should have been websites.
And to obstruct users e.g. from screenshotting content such as my bank transaction data.
I still remember the look on the tech's face back around 2002 when he saw a text login prompt on my FreeBSD box.
If only. Have you tried Google Earth on Firefox lately? You can't even zoom in and out any more without waiting many seconds. It's CPU bound, not I/O or graphics bound. Anyone know what went wrong in there? Is it a deliberate attempt by Google to force people to Chrome?
As for games, the browser environment is still rather limited. WebGPU is (mostly) single thread. (You can share memory between processes, which is something else.) It's a subset of Vulkan - one command queue, and no bindless mode. Google proposes to fix that around December 2026.
On the other hand, there is absolutely no reason that Uber or Waymo needs to have an "app".
For the last several months, the YouTube player takes me several seconds to load on Firefox and freezes on me for a couple of seconds every other time I press play/pause...
And changing the user agent fixed it! So I say yes. But I found the extensions to do so quite clunky so I gave up.
Send a note about that to the legal team at the Department of Justice managing the Google antitrust lawsuit.[1]
[1] https://apnews.com/article/google-search-antitrust-case-5911...
Here’s one: I don’t give websites my location or the ability to interrupt me with notifications. Ever. I’ve blocked the browser from doing this entirely.
I have Uber and Lyft apps installed and granted those permissions though.
You are afraid of a browser so you give system access?
Which is exactly the problem I'm encountering for web apps--typically the browser is granted all those privileges and then there is a per-site restriction in place. (1) I don't trust this sub-level restriction as much as I do the native per-app restrictions, and (2) it's often more difficult to configure and stay on top of (e.g. iOS will nag me if an app has been using my location in the background, the browser will not).
For these reasons, I restrict my browser to NOT be allowed access to bluetooth, location information, etc. Nobody gets to track me through the browser. If a site I use needs those capabilities, I install their app.
iOS has the ability to share your photos with an app in a special “picker” where you select the pics you want to share and then they’re sent to the app. The app can’t see the picker so it only has access to the photos you explicitly share.
WhatsApp deliberately ignores this integration path and gives you a choice of either manually choosing more photos to share each time, then selecting them a second time. Or sharing all photos forever, which most users will eventually choose because the friction of the first one is so massive. It’s done cynically and deliberately so they can have access to all your photographs. I shudder to think for what purpose.
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.
You know what doesn't do that? The local cab company when I call them to ask for a pick up.
All the reasons I come up with, can be easily argued "you can do the same thing in a browser". But still, it is not the same.
Location is super useful here, of course.
Knowing, I don’t know, could be related though…
Google Earth uses Flutter on web, too, which is in my opinion, the platform where Flutter is giving its users the worst experience.
Though the root cause of the bug could also be non-Flutter related, because in Google Earth’s case, Flutter mainly just wraps the interesting bits (maps stuff in c++???) with a unified UI skin.
And does Google break Firefox all the time on purpose? Good question…
https://medium.com/flutter/extreme-ui-adaptability-in-flutte...
I use YouTube via browser (Safari or Brave) on mobile and it's clear they don't care about the mobile web experience at all - to the point it seems like they are deliberately trying to force you to use the app.
I assume it's because they know the browsers support adblocking and limitations on tracking and notifications.
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.
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.
and there you go, author has a vested interest in you making web apps.
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.
----
He just asserts that the underlying technology has come along. It hasn’t.
Maybe this doesn't matter because it's already fast enough but the difference in look and feel will be noticeable.
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.
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.
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?
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.
I hear this sentiment from developers much more than non-developers. I wonder what percentage of developers do all their work within a browser.
And I also hear developers complain more about performance issues than non developers.
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.
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.
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
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.
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.
And really, who has the time to maintain a website and two apps? Or rebuild a decade old platform in a janky cross compiling solution like Flutter that is always on the brink of being sunsetted?
Not me. I'll spend that time on improving my websites, thanks. I'll let my competitors go bankrupt on trying to monetise an expensive app that should have been a website.
I'm a solo dev for a startup and this is something I always hammer home to my non-technical co-founder. I tell him that spinning up an app that would have parity with our current app will not only take close to a year for a single person to develop, but from there on out every feature will come out slower since we need to have mobile parity as well. Out current plan is to slowly make all the pages on our website mobile friendly and even that is a big lift for a complex business app
He is just trying to piggyback an another distribution channel to get more visibility and another place to be found. It has nothing to do with UX.
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 Future
On a national TV program in Germany, they talked about an app related to trees in Hamburg. That same day, my app on the App Store experienced a significant spike in downloads. When I looked into it, I discovered that the app they mentioned on the news was actually a PWA! :)
I feel like the author doesn't have any idea about native app development.
> 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.
Hardware APIs: There is of course a good reason why websites don't get unlimited access to those APIs (and why they can't access them in the background). But Bluetooth and USB are both available on Chromium browsers on every platform except iOS (because Chrome on iOS is Safari).
Example: When Google closed down Stadia, they offered a way to unlock the Stadia controller so you could connect it via BT to any computer and use it as a regular controller. You just went to their website, hooked up the controller via USB, and the site would update the firmware on the USB device.
But sure, there are many use-cases for native apps. Also, there are many native apps that should just be a website (you shouldn't even need to install it if you only need to use it once or twice).
I was not denying that not every app needs to be native -- I was replying to a comment asking for what is not supported.
It’s very common for something like a comment box to keep the text pinned above the virtual keyboard. This is impossible on the web. If you have ever seen an implementation of this on the web (for iOS) please point me in that direction as I would love to copy the implementation.
Notifications just came recently, but weren’t available for a decade after availability to native apps.
The final hurdle is discovery. It’s not possible for a site or app to act as a one click installer of a PWA (add to homescreen) and sites can’t prompt to be added.
And nor should they.
Every single API that gets added to a browser increases the likelihood that you will be accurately fingerprinted and tracked across the web. This data is then packaged and sold to third parties whom you will never know about.
Every time I hear the PWA argument it's always what is in the best interest of developers not users.
b) You are simply confirming my point which is that when you visit a website it is able to tie you to an consistent identifier through the APIs your browser supports.
This would have made news if so.
I can control a web app through customizations to my browser in ways I can't with a native app. It's about user choice.
So, hosting doesn't cost?
Too many app-but-websites should be local, but because are web requires hosting and likely a database (that must be 'web-scale' so it survives bots).
My web app cost far more than my older native one. And is far harder to maintain...
Eventually, it became nice because it worked to give the app a wider reach. Then I added an e-commerce front, so it made sense. But is it less costly than native? Not.
> Enabling iCloud sync for your app is just a single click on Xcode.
How well does that work on Android, Linux and Windows desktop, ChromeOS?
Always laugh at the argument. Surely this matters for yet-another-mobile-crud #3553333.
> You pay 99$ per year and 15% for each sale. Apple handles VAT, refunds, distribution and so on.
15% until 1 mil, isn’t it? And even without that, 15% is ridiculous price.
> Enabling iCloud sync for your app is just a single click on Xcode.
How many Xcode clicks to port iOS app to Windows, Mac, Android and Web?
Youtube content should be a blog
React websites should be static with sprinkles of vanilla JS
etc
These are all ideas that in many cases are true, though sometimes they aren't, but if you ask the right questions, usually those holding the line have a financial incentive.
Every single piece of art, music, game or any other creative piece, has three things to it. One, the actual artifact itself of the music, the art and the game. Second is who is making it. And the third is how much have they put into it.
This last point I think matters a lot. As producing things gets easier and easier, just because almost all of creative art is a popularity contest, things will move towards who has put in most of their hearts / effort into it.
And that is why still I think we will always remember a desktop game such as Stardew Valley but never a web game, no matter how good it is. I mean Roblox has been around for a while and maybe I can tell you one or two games in their entire history, which I even remember.
The same with movies from Netflix which are becoming this data oriented, aesthetically pleasing, easy to watch things, but none of them are worth remembering. Will Netflix and these platforms keep growing and having more and more users? Sure.
But therein lies the conundrum. We will have a lot of everything. We will own none of it and our lives will grow more and more shallow and meaningless.
Also, there's definitely web games (paperclips, kittens) and art in every media that are memorable and excellent to someone. That's kind of the point that I was making; the medium is part of the message, but many things can be presented in different ways, and mostly this doesn't detract from anyone else.
Fundamentally, I reject your model of art; I personally think the actual artifact should be the most important part. Anything else shouldn't even be considered as far as we're able, even though we are mostly status seeking monkeys who pay very close attention to every other monkey's status so as to increase our status.
That's just an argument about quality though. In the end it's quality that matters more than the amount of effort expended (which isn't something you can easily quantify or confirm). Technology promises to make things easier allowing for quality that wouldn't have been practical otherwise.
Even when the quality is identical there are times when I can appreciate the effort that went into something just because the creator choose to make something in the most inefficient and painful way possible. That's kind of fun in its own way, but it's the exception, not the norm.
As games, music, and other forms of art get easier to produce and distribute thanks to technology we'll have more to choose from. Having choice will always mean you have a lot of sifting through garbage to find things you like, but technology can make that easier too. I'd rather have an overabundance of options than be forced to select from only a few options because creation/distribution is reserved for a select few due to cost/difficultly
I understand better now that by forcing a more complex medium you will inherently attract a consumer who has greater commitment to your content.
A person getting an email isn’t as locked in as a person who is attending a zoom meeting. And a person in a zoom meeting isn’t as locked in as a person forced to physically attend a meeting.
You could make your YouTube channel a blog but now you’ll mostly attract an audience that has a greater chance of getting their attention consumed by something shinier, like another YouTube channel.
Therefore, you will always want to deliver a message through the most complicated medium that still lets you attract a suitable audience. It creates more hooks for people to latch onto.
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 months and end up wasting 25% of your UA budget during that time.
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.
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.
4. Something psychological about downloading an app and seeing it on your Home Screen leads to retention.
Source: 7 years game dev and each studio I’ve worked in has been paid multiple tens of thousand dollars to port a game to web. Metrics were never anywhere near as good.
> 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.
I do disagree in the developer point though. Those who know unity really do not translate well to unreal. Totally different languages and ecosystems. Also unity web has always really really sucked for anything other than gimmick games.
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.
Some sites prevent rhis, diverting you to install their app.
I could be mistaken though, but I tried looking for how PWA's work with caching and it is a whole layer of uncertainties that depends on which browser/OS/ecosystem you are in, and if the user clears it's browser cache. In the end, it seems like PWA will only work reliably when the PWA is super light, and doesn't need a lot of caching, so for gaming that would mean only lightweight, casual and hypercasual games.
Safari will delete your cached data if your app goes unused for a little while though. Native apps may do the same thing though... at least on Android I get notifications about it deleting cached data for native apps I haven't used recently.
https://webkit.org/tracking-prevention/#intelligent-tracking...
And good docs on storage quotas on different browsers.
https://developer.mozilla.org/en-US/docs/Web/API/Storage_API...
I think there's also benefits of using persistent storage
Push notifications from PWAs are another area that is unnecessarily limited on iOS. They only work if the user has added your PWA to their home screen and Safari doesn't support the install prompts available in Chrome and similar.
So your users will need to go out of their way to add the PWA to their home screen and then they can receive silent push notifications because Apple says sound and vibrations are only allowed for native apps.
If PWAs are so bad on iOS and great on Android, why do companies bother with writing Android apps, web apps for computers and iOS apps instead of just telling Android users to use the web apps?
This is exactly why I’m such a huge fan of Strada. I’m not married to Strada as the “best” solution, but it was early on trending towards the (seemingly) obvious solution.
This makes casino games look almost virtuous because in those the possibility that you win and walk away actually exists.
On reflection, since I also experimented and contributed to this mess, the whole Facebook game era of web games was the peak, because at least those games enabled strengthening connections between real people.
It's all about advertising, always, everywhere.
People don’t think of the web as a platform for apps. For them, it’s like a bunch of pages you get to via Google. They have very poor notions of how to navigate or make workflows with it. How many people do you know who just have a million tabs open? Who have no notion of what web apps to use and mainly use Gmail / Slack / Google?
This is why Apple pushes apps so much. A dedicated little place for a use case.
PWAs are a good in between for sure. But for a lot of humans, having a logo of a brand they recognize is going to be the main thing.
“I want a button that says Music, it’s Apple Music, I pay it 10 bucks, I get all the music.“
And to be honest, none of these things solve the actual issue which is tons of these apps are software that is built by companies who do not build good software, and no framework or methodology is going to overcome that fact.
My banking app, Chase, is terrific. It is either native or such a well optimized web wrapped one that I can't tell the difference, which would be a first-of-kind. It has quirks but for every daily driver task I need, it's great. In fact the app being so good was actually part of why I decided to pull the trigger on changing banks, because my last was anything but.
That said, other apps I use (and websites, for that matter) are TRASH on mobile. Slow to load, slow to respond, and make my damn phone hot in my hand while I try and use them. And like, maybe they'd be better running native code, from a technical perspective at least, but that doesn't change that the usability is still awful, which is not a technical problem: it's a design problem, that probably originated far above the heads of any of the developers actually building them.
This is all the more surprising considering how other other banks, let alone other large companies, seem to blunder all the time with their services, especially online banking.
I returned to my country Ghana from the US a few years back, and more time passes, the more I realize just how valuable my account with them is. Never have I felt I needed to visit a physical branch for anything. Everything just works. In my view, they are arguably the best bank in the world.
Marketing and availability, i.e. is it within reach when a customer thinks about it, are core problems needing to be solved.
Instead of downloading an existing app, I decided to see if I could write my own web app with the following constraints:
- no frameworks
- just basic javascript
- track multiple stats
- be able to enter stats via phone and only using one hand
- while also holding a 4 year old in my other arm
It was a fun exercise and I actually got it working! It can track multiple players, multiple stats and even saves the data to a server for later viewing or more analysis.
"You can just build things" also includes fully functional web apps using old school technologies to solve your own needs/constraints.
I was pointing out that this applies to apps that you can build yourself.
No one is saying a table with javascript can't be done in a web page, people have been doing it for 30 years.
My favourite thing about using a website? It can't send me attention grabbing notifications. It can't harass me for perms.
I'm 100% an outlier. My friends don't blink twice to install all manor of loyalty, news, social media, lifestyle, games etc etc and rarely clean up. It's all just choices and preferences - the world does not suit me.
On my computer I have a few programs installed, which I just constantly. On the phone I need each app only a few times a month, if that, yet they all insist on being actual apps.
I believe it's primary use case is storage efficiency but it works perfectly fine in your use case of preventing the code from running while you're not actively using it
But it works the same as for apps. You get prompted once on iOS at least. You either opt in for notifications or you don’t. There’s no difference.
Chrome, being a division of a huge ad company that makes money from these agencies, not merely played along but took a leading role in sowing the confusion.
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.
https://webventures.rejh.nl/blog/2023/ios-web-push-requires-...
HTTP was not designed for apps, it was designed for serving HTML. We had a decent solution in Java applets and the tech giants could play nice so we couldn't have nice things.
The work around has been a huge kludge of crap frameworks of the day trying to reinvent the OS and associated API in the browser. It sucks all the way down.
Apps are:
More powerful
More efficient
Have better tooling
Have stable APIs
Are easier to debug
Uh!
The two versions written by one man as experiments and used by (by reasonable interpretation) absolutely nobody.
HTTP 1.0, the first "real" HTTP did indeed include support for images at some point prior to being finalized as RFC 1945.
Require devs pay a tithe to the app store owner
Are less able to be customized, reverse-engineered, and controlled by the user
Are subject to arbitrary, vague, constantly shifting, opaque app store approval rules
Require constant updates just to continue existing, since the platforms they target don't care for backwards compatibility, and are constantly releasing updates
Are hostile to open source projects that have limited resources, as those represent a drain on the system, since they generate no revenue
What does it even mean?
> More efficient
Debatable. Depends on implementation.
> Have better tooling
Absolutely no. I’m yet to see any native toolkit that has even feature parity and nice DX compared to web development.
> Have stable APIs
Ask Android developers about stable APIs. Also, which web APIs do you find unstable?
> Are easier to debug
Debatable.
I chose Flutter because I like Dart far more than TypeScript/JavaScript. AdMob doesn't support web. Of course there is a Google Web ads solution, but Google's "significant content" evaluator doesn't see any Flutter content, so you have to add a bunch of useless text to use web ads. In-app purchases are fairly easy compared to getting Stripe set up, and for the user far more usable.
I'd LOVE to stop dealing with app stores and the 15% tax, and iOS entirely, but it's not a good user experience.
Of course, I could choose not to monetize at all, but I would like to get something for my efforts, at least enough to support its own running costs.
Even worse that it limit memory to damn 1gb. So any slightly complex operations will CRASH and restart the whole page.
These basically work in any browser except safari (Not even ie crash and restart your page so often)
These aren't really fancy features only a few people used. It's the bare minimum for anything that is considered "properly working"
For returning customers, a customer with an app installed is simply going to have a lot less friction to open the installed app and place an order than a customer who has to open their browser, log in again, and then place the order.
That alone is worth the investment for many companies in making an app, even if a minority of customers actually choose to install the app and keep it installed.
And the upside is that you only have to develop one website (instead of a website and 2 separate native apps for iOS and Android).
All apps and the OS are JavaScript based.
The timing of the hardware missed or maybe it could have stuck more.
(as for the GDPR, consent must explicitly be given in app as on the website, if they are doing tracking and sharing the data with 3rd parties)
I can’t agree with that, sorry. I’m developing 3D games for the web, and the limitations are asset size, memory size, and CPU/GPU constraints feel like developing games with 2001-era resources. The web isn’t there yet, and I’m not sure it will be anytime soon. There are some impressive apps leveraging the web’s fast distribution, but 3D games are harder in that regard. You can create content-rich, visually appealing 3D games, but then you severely limit your audience. I’m considering moving to native game development because the web’s limitations are daunting.
I'm not sure what I'm going to do about this. I think people will have a better experience with the native versions, but won't discover that if the web version exists. However there are also probably people who would play the web version who wouldn't install an app.
Probably most of the attention I can drive to it will come from other daily web puzzle games I run. I suppose if that weren't the case, I wouldn't bother with the web version (unless I get rejected by app stores - which looks somewhat likely at the moment.)
But there are many things which cannot be done sufficiently on the web, e.g., augmented reality, tracking gps in the background, accessing a users calendar or phonebook, Bluetooth, scheduled notifications, etc...
In general there is something called app fatigue. Convincing somebody to install an app is difficult these days, even if it's free... Let's see what the future brings for app development.
So while i am rooting for webapps it is still long way to go.
The app icon acts as free marketing. If it were just a website, you wouldn't have a little picture of their logo on your phone to be reminded that they exist every now and then. They know that it could just be a website (usually it IS just a website, packed inside an "app"), but they don't want that for a reason.
You can install web apps on the home screen since iOS 1.0. The fact that you (and many, many others) don't seem to know this is a thing, says a lot about how effective Apple is at hiding that feature... :(
(Chromium browsers support an API where a website can show an install button if certain conditions are met, making it a one-click experience. But alas, for some reason Apple doesn't allow browser engines except the one they control :thinking: )
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 pieces, but the drag didn't track the mouse cursor properly.
If someone asked me "which site is leading the charge in the Browser Games Renaissance?", I would say itch.io, hands down.
When the original article is talking about escaping the tyranny of the app store it sounds to me like they don't want to share the loot box revenue with Apple/Google, like our chinese friends at Epic.
Unfortunately for them, there are still pay once real games. Some of the good indies are on itch.io indeed.
Stop calling lootbox dispensers "games" please. I prefer paying for a game in advance instead of being monetized.
Native apps are sticky. As an example a Webshop has no reason to have a native app (likely it is a browser wrapper anyway).
However, being installed puts you right in front of the users noses everytime the unlock the phone. Just look at the discounts that are offered for installing Native apps or shops that are app only to begin with.
Only as long as external dependencies (like APIs) are satisfied.
It feels like we (the HN crowd?) should be pushing for more web (the one place where you can inject more control like ad blockers, etc), than native apps (where you have no control)
But it's still a lot better than apps, which give the developer more control without (in most cases) any tangible UX benefit. Just as an example, Reddit doesn't need to have an app, all they do is display text and images, along with some interaction, and they especially don't need to lock some content behind the app (I recently got a popup when trying to view a post saying that "unreviewed content" is only available in the app, despite the post clearly loading for a split second before the popup).
On top of that, platforms like Reddit and Facebook tend to prefer native apps because it's easier to keep you within the app. Even if you click a link to an external website, for example, Facebook will open that link in an in-app browser (unless you find the opt-out). A few years ago, a researcher found out that these apps often inject their own javascript into that in-app browser. In theory, that means FB can track you even on external sites, even if you do not accept cookies for that website. You just brought your own tracker. Facebook then decided they should ship their own entire browser engine, giving them even more control.
https://webventures.rejh.nl/blog/2022/in-app-browsers-are-tr...
i think there’s maybe two or three popular websites that work well on my phone, everything else is unuseable, while apps still work okay
> Important!! the Windows version might show a false warning, if it does, hit More Info and then Run Anyway.
because recognising a false warning is impossible.
This issue becomes even worse if you try to make software that can both be used with keyboard & mouse and on a small touchscreen. With very few exceptions, you end up with something that works poorly with both interfaces, instead of working great on one of them. Trying to do that in a browser rather than the OS only makes the issue worse (what happens when you press "Alt" ?).
Websites are at least supposedly sandboxed so they are not as much of a risk as running native binaries. But this is getting worse and worse as browsers expose more and more of their host operating system's functionality. The benefits of using a website instead of a native app are quickly disappearing while the drawbacks have only been somewhat mitigated. We're getting to the point where browsers are worthy of the decades old criticism Emacs has received. They have eventually become an OS with many fine features - simply lacking a good web browser.
The browser, and the web, has been destroyed by the insane security model of modern OS-Browsers: running every executable they're sent from anyone with not a care in the world as if it is normal. This one thing has made it so browsers cannot be in control of the user, made it so that CA TLS is pretty much required and so that browser devs write entirely for the security use cases of the insane corporate web applications instead of writing for human people looking at website documents.
And this same security model makes it so that web apps basically cannot communicate with each other at all, unlike real applications where piping between small applications is the entire idea.
I really wish that we would have similar isolation options on desktop/laptop OSes.
Those who sacrifice freedom for security deserve neither.
For example, Chromium was able to mitigate Meltdown/Spectre within days, even if the OS was still vulnerable. (Chrome already had site isolation ready to ship, a feature that completely isolates websites into their own process). Even better, Chromium browsers tend to update themselves (or via Google Play) automatically.
Meanwhile, OS vendors were scrambling to ship an OS update.
(Also, worth mentioning that iOS users were vulnerable until Apple shipped an OS update, because every browser on iOS has to use Apple's WebKit)
> Please stop making web apps
No.
> the web is for documents
No it isn’t.
I'd rather not have stuff I pay for be websites, thanks. I have games from 2005 I can still play today. The flash games from back then on the other hand are gone forever.
Games nowadays however have so many online-only features and content that it's getting much harder to keep them working no matter the platform.
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.
maceip@sina.com
Seriously? You can't have audio except precomputed in a file?
Friend should’ve been forms.
Applications should’ve been apps.
The thing is that html/http is such a great distribution model
In 2015 Robin Hutcheson partnered with a vendor, ParkSLC, to deploy an iOS and Android app that is the only possible way to pay for street parking in many areas of downtown SLC. She seemed awfully proud of herself in this announcement, bragging about how it hasn't really fallen over much in the first few months in the field:
https://archive.org/details/Press_Conference_-_ParkSLC_Mobil...
But that's not the bar. For public infrastructure it needs to continue to function for the life of the system. So let's fast-forward to Kubecon 2024 in SLC. I'm staying with a friend further south, so I had to rent a car. I pull up to a restaurant where I'm meeting some business partners and park right here:
https://www.google.com/maps/@40.7647761,-111.8938564,3a,75y,...
In a past life there would be a parking meter right there at the stall where I could drop in some coins and be on my way. Now let's talk about how Robin's fancy new parking system is going now that we're in the app-infested future.
It's November in the early evening, so it's not exactly warm and cozy. The first problem is that the little blue post you see in the Google Streetview back in Oct 2022 isn't there now. So I have no idea what the stall number is. Fortunately the blue post for the spot behind it is there, and I determine it's counting up going north. I guess the stall number is one higher than the one behind it, and that's all I have to go with.
I walk up to the super-advanced new fancy kiosk and hit the button to turn on the screen. Icons on the screen invite me to start tapping away to register. No response. The touchscreen functionality is completely broken.
There's a sticker with a QR code and a website, parkslc.com. Okay, maybe I'm not being phished here. Better do a quick web search to make sure. Yup, ParkSLC appears to be The Thing. So I go to parkslc.com to get the link to the app and discover that it's only distributed via Google Play. But I'm running GrapheneOS because I don't want Google spying on me. So it looks like the only way I can park on W Temple in downtown Salt Lake City is to allow Google to spy on me?
Great. Well, I do have another dummy account on the phone with a sandboxed install of Google Play with a temporary account I created just for that user on that phone, so I was able to attempt to install the app. It still "phones home" to Google but maybe without enough information for Google to determine who I am. But at that point I'm greeted with an error like, "This app was designed for an older version of Android. Go pound sand."
Great. So this app isn't even being updated, I guess. I wonder if other people with newer Android devices are getting this same error. Regardless, by then it's been about 7 minutes while I've been sitting on a concrete bench in the cold trying to pay to park so I can go to my business meeting. So far both the kiosk and the app have been dead ends.
My last option, it seems, is to browse to parkslc.com and see if there's a way to pay via Firefox. After scrolling around more than I should have had to I finally find a "Pay Online" link and follow it. It asks me for a phone number, so I punch that in. I get an SMS. I have to create a pin. It asks me for a "Zone Number." I punch in what I guess it's supposed to me. Then it prompts me for my credit card. I start punching that in, but when I get to the drop-down menu to select the year of expiration... nothing. No response to my taps. No ability to just type in the year.
Great. So the website doesn't work with Firefox. Another 3 or 4 minutes wasted on another dead end. Okay, so I launch Vanadium and restart the whole process again. This time around the drop-down menu worked, and I was finally able to complete the process, after futzing around with a broken kiosk, a broken app, and a broken website for 12-13 minutes out in the cold night air of Salt Lake City.
As the app-based system she deployed in SLC fell into ruin behind her, Robin has since flown on to be the administrator of the Federal Motor Carrier Safety Administration. Good for her! I'm sure there's blame to be passed around here, as it's in the current transportation administration in SLC to maintain the system in working order. I just wonder how many spare kiosk touchscreens they have lying around from a system built in 2015. And I wonder if anyone still has the source code for the app that doesn't work with newer versions of Android. Or if there's anyone around who can even push an update any more. Obviously Robin didn't seem to do enough to ensure the system she deployed would end up being robust and reliable public infrastructure just 10 short years down the road.
And not to pick on Robin too much, this is endemic in our institutions everywhere. As an industry we need to do much, much better. One lesson from my anecdote is that there should always be a website, and it should be as simple and compatible as possible, especially if it serves as public infrastructure.
Spell check needed.
I feel this is difficult for many more people with less motor skills, or that can’t read.
That is not what the web was always meant to be. The web is a document distribution platform. In its purest form, that should mean no bloat, no tracking, no JavaScript period. Browsers should be tiny, extremely secure programs.
There's nothing wrong with having a universal app platform that embraces important lessons from the web like URIs, the security model, WebAssembly, etc, but it should be a separate program.
90% of the web can be documents. If you're actually building an app use the app platform. People using legacy browsers don't need to know the difference, but over time they'll want to switch because of the benefits.