I man don't get me wrong, I love the idea of PWAs but this dude is out to lunch. It's so painful making anything complex work cross browser/cross platform. On iOS iirc they don't even support adding PWAs to the homescreen? You definitely can't Bluetooth outside of Chrome (probably only on Android and Windows too because nothing fun is ever allowed on Macs).
Multiplayer games you kind of need UDP. You cannot UDP in 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.
WebTransport is now supported in most common browsers (just missing safari support) and provides a nice API for sending/receiving messages via UDP. https://developer.mozilla.org/en-US/docs/Web/API/WebTranspor...
Thanks for pointing this out! I wasn't aware this had more or less landed. (though I think my broader point about cross platform support unfortunately still stands, I personally don't care about supporting iOS on my side projects and I'm excited to mess with this)
Support is getting there on the browsers' side, but you need a backend that supports HTTP3+WebTransport - barely any out there
Yup, as I have found out over the last 5 hours. I managed to get a handshake but it's nowhere near the convenience of something like WebSockets. The security circus you have to go through to get even a handshake working is absolutely absurd, all sorts of extremely poorly documented certificate requirements and you'll be lucky to get an error message that helps you in any way. I'm getting ready to give up for the day, I will definitely make a top level HN post if I get a solution working and documented.
Meanwhile https://github.com/achingbrain/webtransport-echo-server this is the best we have for a minimal working node example.
Surprisingly, socket.io supports WebTransport: https://socket.io/get-started/webtransport
The guys at Colyseus (a JS library for multiplayer games netcode) also added support, in a preview version for now.
I wasn't aware this had more or less landed.
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.
> 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
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.
Comments have too low credibility on average. If a new thing is worth learning about, it hits frontpage eventually with an exploratory post.
I disagree at least a little bit, the fact that there's support on the browser side is much much more important than support on the server. I can write a server of arbitrary complexity given enough time, the scope of the problem is now one that I can fix.
I also found the following in my research yesterday, which looks like a very promising set of abstractions for WebRTC data channels.
> On iOS iirc they don't even support adding PWAs to the homescreen?
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.
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
> The need to remove the capability was informed by the complex security and privacy concerns associated with web apps to support alternative browser engines that would require building a new integration architecture that does not currently exist in iOS and iPadOS.
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.
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?
Sounds like something very fixable though. Why is it so difficult for apple to fix the "engineering mistake" and move the PWA process to a less privileged user or even a jail?
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
Ok running something like that as root by design is enough of a self own from Apple that I really don't need to say anything more, hahaha
Factual ad hom indeed.
Not doubting you but care to share some links to back this up? I’d be interested to read more.
It is really quite complicated to do. Since you get some interesting functionality I had considered it but writing the page how to add the website to the home screen I couldn't imagine users doing this.
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.
One big missing piece is the inability for me to put an "Install" button like I can on android. I don't want to have to teach old people how to add to desktop
Yes, even Windows (Edge) prompts to install the PWA on the desktop. The "Add to Home Screen" process works well, but is obscure.
In fact, home-screen web apps on iPhone OS predate third-party apps on the platform. Originally all third-party software was going to be installed this way.
> Originally all third-party software was going to be installed this way.
It's off topic, but I don't think this was true once the HTML Weather and Stocks 'widgets' failed on iOS. Anything Apple said publicly was just saving face until their SDK was ready for public consumption.
It was true. I developed iPhone OS web apps during that time.
Point the author is trying to make is that there are certain usecases you really don't need to deliver it via app, it is cheaper and better to serve via web. For eg. The Itaki app mentioned in the article.
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.
iPhones support PWAs on homescreen. However, there's no way to trigger the "install the PWA?" prompt. The user has to do it, which very few know about, and maybe that's what you were thinking of.
I haven't looked at this lately and so don't have a specific recommendation, but there are small libraries for helping iOS learn how to add PWAs using the standard Share → Add to Home Screen mechanism.
https://github.com/khmyznikov/pwa-install (Try on device: https://khmyznikov.com/pwa-install/)
I've seen guides like this before. Would be nice if they showed what the share button looks like, cause that's not obvious to some people. Or, some file sharing websites show an arrow pointing to the downloads button in desktop Safari.
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.
Only if they’re designed that way. Many aren’t.
Ready to use (or buy/download) controls in appdev usually pack some ui wisdom into themselves for free, borrowing most of it from the base system.
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”.
I can't say about gaming, but a huge chunk of popular apps out there are PWAs with a native wrapper. If built well people aren't even going to notice.
oh i notice. But im a picky user. You’re probably right that _well designed_ apps are indistinguishable to most users.
Apple is currently being sued by the DOJ for a variety of abusive business practices, including forcing all web browser apps on iOS to use the Safari browser engine, which limits the usefuleness of all web browsers on iOS, so that developers are forced to develop an app which Apple can then take a 30% cut of all revenue generated by the app. It's a pure money-grab by Apple, and they deserve this legal action against them.
Is the only alternative still Google? Yeah I’m good with Apple, thanks.
That’s all the more reason good regulation is essential. If there were a dozen viable competitors then you could just step back and let the market decide.
Point taken about preferring Apple over Google. I buy Pixel phones and immediately install GrapheneOS, which does a pretty good job of keeping Google at arms' length. So I guess the answer to your question is that there is another alternative.
buy android
Agreed. But I would like to add that there are also numerous UX pitfalls that apps fall into that are trivially solvable on the web.
Broadly:
- deeplinking (while technically doable it is still a pita to set up cross platform and require just way too much engineering in the long run)
- branching out UX (it is interesting how many seemingly straightforward processes turn out to be better if you can branch out into something like a tab)
In my defense, I always skip lunch.
> On iOS iirc they don't even support adding PWAs to the homescreen?
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 don’t think parent means the same or maybe he does. On chrome and edge on macOS one can choose to install the PWA as a native app. It gets an app icon and everything. It’s similar to a web bookmark on the HomeScreen. But it’s a sandboxed app. Don’t know if this is the exact same behavior though. PWAs are also a bit different to normal websites. They have a manifest and what not to describe the app in a standardized way.
PWAs on iOS get their own local storage, for example. And deleting the PWA from your Home Screen will delete its data, just like deleting an app would delete the data of the app.
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.
Do you need UDP? I see lots of multiplayer browser games. Here's a few
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 know it was a typo, but I want to play edlin ring. The most frustrating text mode adventure ever.
And its sequel, Vimborne.
Yes and no. UDP objectively performs better because it prioritizes sending relevant (in the context of real time application) data rather than retrying no longer relevant data (and all the overhead that entails).
https://nightpoint.io has been around for a long time, it's a fast-paced 2D shooter, uses web sockets and it does quite good actually.
I think the same dev created https://battledudes.io later on, again based on web sockets. It has/had (haven't played recently) a pretty big player community.
No you don't need UDP to make a game, but for the sorts of games that I enjoy playing you need UDP.
I have several PWAs on my home screen on a iPhone that open in a window that doesn’t appear as a browser.
Most of the time a PWA isn't needed at all, a mobile Web friendly website suffices.
For offline use?
Depends on the application, naturally.
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.
A website can work offline, too. Service workers are a feature that any website (installed or not) can use to (pre)cache assets, etc. On iOS, that data will get evicted if the user doesn't visit the site at least every 7 days, though. Other platforms keep the data for a lot longer, but will evict at some point, too.
You can add PWAs to the Home Screen on iOS; Share, Add to Home Screen. This is how I build apps to scratch my own itches.
Edit: Err, sorry to pile on. I see others have already mentioned this.
Author needs to show not tell.
Theory falls down hard.
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.
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!)
You forgot constant 100MB updates, which are just one page refresh on web.
And that one page refresh is probably also 100MB these days.
Uncompressed - maybe.
Obsidian is an Electron app (I don't know if it belongs to the Block editor category). It loads just as fast as your app. I tried copying and pasting the text file War and Peace (66035 lines) from Notepad into both apps and, interestingly, Obsidian is slightly faster. Also, scrolling through this large chunk of text is slightly faster on Obsidian, too. Obsidian memory consumption (4 processes) is 172 MB and Daino Notes consumption (1 process) is 352.7 MB. Tested on Windows 11 PC.
Obsidian is not a block editor. Can you put a Kanban or any other complex block in the middle of a document? From my understanding, you can't. Here's how to think of it: a block editor is a basically a virtualized list with dynamic loading, so it can load any arbitrary component *while* allowing the user to interact with the list as it was a singular piece of document - so you get text selection between these discrete blocks, editing, etc like you would in a regular text editor.
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).
Here is the screenshot showing memory consumption of Obsidian (I did wait 30 seconds for memory to settle down after initial spike which was 240 MB): https://pasteboard.co/uW2lPNSbL7f7.png
[EDIT] Here is memory consumption of Daino Notes: https://pasteboard.co/z5pciLoh99i6.png
This is what I get with an *empty* vault: https://pasteboard.co/N3IdNUKUUNKq.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.
> pasting the text file War and Peace (66035 lines)
Funny, but how about a log of one Jenkins run weighting at - checking... - 630 MB? Or two of them so someone can compare them?
Obsidian is the only Electron app I don’t despise.
VSCode is close to counting… but it absolutely sucks on RAM usage, so I try to avoid it when I can.
RAM is cheap, my time is not. VSCode is the best game in town (for me), and my 32GB computer has no problem with its RAM requirements. Even 8GB would be enough for VSCode depending on what else your toolchain requires.
> 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, "hnthrowaway2376".
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.
> 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 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.
> but let's not forget that just being an employed SWE in the US easily places you in the top 1% globally.
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.
Not everybody can upgrade RAM due to warranty seal/lack of slot or simply doesn't know how to do it. Software should use as little resources as it could.
Not when it is soldered on a mobile phone, tablet or laptop, and getting more implies throwing away an otherwise perfectly working device.
[dead]
Unfortunately no one is making apps for poor people.
This app looks exactly like one I had used in the past. Took me a while to find it: https://www.notes-foss.com/
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?
I was wondering about that too. This is in the article linked to https://rubymamistvalove.com/block-editor
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
Hi there! Yes, I will switch to a more distinctive icon in the future once I can afford to hire a new designer.
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.
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.
> 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.
The problem with that mentality is that you start seeing inefficiencies spring everywhere (why loading Discord takes so long? Slack? etc, etc).
Inefficiency also compounds. If you're sending too much data over an unreliable connection using a bloated protocol (say), you have three multipliers. Now start daisy-chaining these things together, host them on bloated images on pods in underpacked nodes in k8s (not a potshot at k8s, which I like quite a bit, just... another plausible source of inefficiency). Write all the servers in Python (or worse, some Ruby on Rails backed by MySQL or something comically underperformant).
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")
The old metaphor of shipping bananas by packing the entire jungle surrounding the ape that’s holding the banana does very well to illustrate the truly egregious level of inefficiency at play here, especially when one considers how there’s tens or hundreds of thousands of these jungles involved in any given product…
It’s a third world mindset where we end up with the software equivalent of public defecation, living in squalor and filth.
How is Discord not loading fast enough the result of a “third world mindset”? Is this one of those “this software is bad because it was made in China / India / outsourced to one of those countries” arguments (which I don’t even think applies to this topic???)
I’ve routinely needed to open a 5GB text file on my computer before (previous job), and only some “apps” can do it. If we even call them apps lol. It’s just bloated web browser junk packaged to look like a native app.
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.
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?
I don’t know that I completely agree. It depends on the functionality offered, right? Like vim, for example, can struggle with very large files if you ask it to do syntax highlighting all the way from the beginning (or, it can give you syntax highlighting that is just wrong if you don’t). I don’t think vim is very inefficient (could be wrong there, though), and I don’t see any way to generally do syntax highlighting without looking at the whole file (although, of course, in practice there are often shortcuts for specific languages…)
I am not sure if it's worth it though.
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.
Hi there! Indeed, QML is very buggy. But there's also a large discrepancy between Chromium's budget (Google) and The Qt Company. Also The Qt Company tend to prioritize advancement in the embedded world (where it probably gets most of its cash) rather than regular applications. So, many bugs get fixed through open-source contributors (KDE, individuals, etc) And that might be a big reason why non-critical bugs don't get prioritize enough.
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.
> But there's also a large discrepancy between Chromium's budget (Google) and The Qt Company. Also The Qt Company tend to prioritize advancement in the embedded world (where it probably gets most of its cash) rather than regular applications
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?
> 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).
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
I am so happy that you made this, legit. I’m absolutely going to try it whenever I get a chance.
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 ^-^
Very cool! I hope my blog post could be of help. Let me know if you need any help my socials are in my HN profile. And let me know what you think of my app, would love to hear any feedback.
It's funny that part of the reason computer hardware has gotten faster and more efficient is because heavy usage work flows, even things like web apps.
So while you think web apps are going "backwards", they've likely helped contributed to modern computing hardware speeding up your native programs!
Is that true, or the reverse? That web apps became a feasible thing only after consumer hardware, esp phones, became performant enough to handle loads like that (which lead to less and less offloading to servers)?
I'd say that web apps became a thing because Google really wanted them to be. They first tried with their browser plugin. That worked, but adoption wasn't good enough. So they ditched Google Gears and started developing a browser with sufficient performance for web- native apps. They succeeded quite well.
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).
No. The motivation to make existing flows faster and do more of those at once is constant. It wasn’t initiated by bloated web apps
Native apps also give users a type of control that web apps can’t, by way of existing as fully independent executables on storage in possession of the user.
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).
Yes, but native Apps have adds, which at least I don't know how to block. On Firefox mobile I can just use ublock origin to watch YouTube Videos without ads, as one example...
That applies mostly to online-service apps, which are in a bit of different category as their usefulness without a connection is extremely restricted. Most apps don’t need to fall into the bucket.
Let’s normalize offline web apps, then. Your examples at the end go back to needing technical chops, and in the end, everything gets bitrot.
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.
Offline web apps are better but still not great because unless their dev has gone out of their way to wrap it in Electron, they don’t come in nice self-contained units like native apps do… for instance, if you’re upgrading your computer and want to copy over a previously installed but now defunct offline PWA, where do you go looking? The wrapper binary built by your browser doesn’t actually contain it, all the inner workings are squirreled away in some obscure directory with an inscrutable name.
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'd give anything to move our apps to the web. We're in the medical field (our apps connect to medical devices over Bluetooth), so publishing on Google Play is like a Kafkaesque fever dream. Two days ago they tell us our app fits into categories like:
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.
The Google Play update emails kill me with the level of irrelevant noise.
“This is an important tax update for [country you didn’t think existed anymore].” etc.
Good lord this is so true.
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.
We’ve wandered off topic, but there should be a safe harbor provision if your app has <500 installs or something.
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
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.
I feel your pain, though I blame the websites more than the browsers. I can run full firefox on my OG pinephone as long as the sites I visit aren't running a pile of JS lunacy.
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.
Oh yes, I think the web standards orgs are culpable (especially W3C) for not making it fast and simple to implement the features PHBs demand. This is surely in spite of the good people working on their behalf, and more a sad molochian consequence of regulatory capture big big adtech.
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.
True, and regrettable; on the other hand, mobile compute is getting so much cheaper all the time. This is the driving force behind all that bloat.
> 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.
The older browsers that would run on these devices have known exploitable security issues. The newer browsers are very heavy because they support navy features and expect that the hardware is newer.
The problems begin accruing before the user even types in your URL.
Developing apps on it still seems really, really primitive. HTML alone is not sufficient for a decent looking UI. Tailwind directives gunk it up rapidly. Component frameworks help some but still don’t seem quite as nice as something like SwiftUI. Server side functionality still requires a lot of manual serialization/deserialization (unless you use the newer crop of frameworks that have figured out this is pure noise).
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.
>HTML alone is not sufficient for a decent looking UI
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.
> It isn't even difficult if you have any skill at all.
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.
>There's no pit of success, just lots of div-wrapping and tweaking until things fall into place.
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.
I have learned JS & used it extensively in many projects. Including modern SPAs. And I absolutely despise it & wish I could use something like recently trendy GO or RUST.
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!
>JS has absolutely no rhyme or reason
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.
> about a billion blog posts on medium.com.
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.
I started the project with create-react-app a long time ago. I've since updated it to latest versions of webpack and switched from React to Preact. It's not using any hooks or any modern React conventions, but I don't really need it. I've kept it simple, the only two libraries I include are preact-easy-state and preact-router. Everything else is components I wrote. All images used are SVG, I'm using LESS to compile to CSS, and everything is bundled into a single HTML file that gets gzipped down to about 48KB. I've tweaked the default Webpack configs to get exactly the payload I want. This gets compiled into my ESP32 firmware and served directly from flash. The web app handles all devices configs as well as wifi access point config, and it controls all kinds of device functions using custom sliders and buttons, etc.
"Tailwind directives gunk it up rapidly"
CSS classes are all of the rage these days.
True except the part about "works on every device" is dependent on what part of the device you're trying to use, as the parent says about Bluetooth.
Their devices should probably just include a different interface, such as one based on a secure internet connection. Or use bridging hardware.
I'm a bit curious about what's wrong with Bluetooth on the web. Is it just because Safari and Firefox don't support it yet?
It’s important to note that it’s not a matter of effort for Firefox. They’ve decided that the it’s not something they want to implement[1]. The reasoning is that they think it allows low enough level access to potentially mess with devices who weren’t made to be resilient to malicious input, and didn’t like that the proposed method of allowing web Bluetooth is based on a default allow policy with a blocklist, which means as new Bluetooth device vulnerabilities are discovered, this blocklist has to be maintained.
[1]: https://mozilla.github.io/standards-positions/#web-bluetooth
Wouldn't the correct time to raise those concerns be during the web bluetooth design process? The idea that a browser decides "nah" about a web standard because they're mad about it seems like the road to ruin
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)
Funnily Mozilla had implemented Web Bluetooth API for Firefox OS long ago: https://wiki.mozilla.org/B2G/Bluetooth
Not just Safari and Firefox, on iOS all browsers are forced to use Safari's web view, because Apple wants to force developers to write apps so they can make 30% revenue from the app should any money exchange hands. They can't force developers to write apps if web browsers on iOS are allowed to access bluetooth and other modern browser APIs.
Isn't some of what you're describing a critique of walled garden platforms rather than web vs native? e.g. When I self-publish a native desktop app, I can pick the DRM, code updater, and payment processor I use.
Looks like at least chromium has web Bluetooth. Could that work?
As a consumer, I understand the need of a native app for something that is performance intensive or that requires a level of OS access that the website doesn’t provide.
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.
I don't think it has anything to do with performance. Apps make it far easier to advertise to users.
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.
> Apps make it far easier to advertise to users.
And to obstruct users e.g. from screenshotting content such as my bank transaction data.
Also, the majority of users are going to search Google for the website they want, rather than enter a url directly. An app avoids exposing the user to competitor's ads.
Both major app stores have similar ads. I don't see the difference. Maybe they could provide a URL and QR code and go straight to the site without depending on third parties.
This reminds me of aggressive technicians trying to convince me to install their bloatware on my computer in order to complete setting up internet connectivity 20+ years ago. One was completely baffled by my insistence that he was not going to be touching my computer, makes me laugh now.
> aggressive technicians trying to convince me to install their bloatware on my computer
I still remember the look on the tech's face back around 2002 when he saw a text login prompt on my FreeBSD box.
Definitely not necessary for internet service alone. You also don't need their modem. Just buy your own. Cheaper in the long run and a bit more control over the device. Never had a tech push me into installing anything either.
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.
It has been crazy since before apps were 'apps.' It is a simple flow chart to me: do I need to interact more than once a month? No? Should probably be a website. The only time I want an app is for things I check more than 50 or so times a day, but that is because the UI for phones is awful and it is more convenient to context switch. Needless to say I find messaging apps to be the only ones that qualify.
Android app? Then install amd64 Lineage OS in virtualbox, push app there, then restore a snapshot.
> 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 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".
> Is it a deliberate attempt by Google to force people to Chrome?
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.
> And changing the user agent fixed it!
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...
This is really annoying when it happens. Next time it starts, I'll definitely try the user agent thing. When loading youtube, when this is happening, (and sometimes it doesn't) the whole page locks up for a few seconds half-way through loading/rendering/hydrating. After that, it seems to do a CSS recalc/reflow. While waiting, it's impossible to do anything.
> On the other hand, there is absolutely no reason that Uber or Waymo needs to have an "app".
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.
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 literally website wrappers that I use once a year.
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.
You could give only them location access then they wouldn't be able to see what apps are installed, contacts and family photos or listen on the mic.
You are afraid of a browser so you give system access?
What you describe hasn't been the case for almost a decade. On iOS and Android apps need to explicitly request and be granted one-by-one permission for all those items.
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.
Here’s an example of how large companies abuse their power to push back against these privacy guards.
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 kind of phone are you running and how old is it? Apps don’t get any of that other information either unless you specifically approve it. If you want to give Uber just notifications and just location, you can do that.
And even then, it only gets location access while it's running (if that's the access that's set). And doesn't get to run in the background either (if you say it's not allowed to).
"When it's running" also means when it runs in the background, and apps can wake themselves up any time they want when you allow them to send you notifications.
Running location triggers an icon in the UI which puts it in a list of apps that have run location recently. An app abusing this in the background will eventually cause the operating system to ask you “hey, are you okay with this?” alongside a map of your current location as your phone sees it.
Funny, I blocked notifications from the Uber and Lyft apps because they kept spamming me. And the notifications aren’t all that useful, since I’m actively checking the app whenever something time sensitive is happening anyway.
Location is super useful here, of course.
I was referring to lock-screen notifications (time-sensitive notifications on iOS?), which are quite useful in this context. It was a feature basically designed for apps like Uber, and I do t think it’s available for web apps.
Is there a reason why you think location access is OK for the Uber app but not ok for the uber.com website?
That's not what I was saying. Granting the permission to uber.com requires granting the permission first to the browser, then configuring and trusting the browser's own internal per-site restrictions. I don't trust this as much as the more fine grained and configurable OS-level restrictions.
Uber are the worst for abusing this kind of stuff and for dark UX patterns to get you to subscribe to Uber One. I’m repeatedly asked SEVERAL TIMES EVERY TIME I USE THE APP. and there is no way to pause or opt out from this nagging. They even abuse the push notifications to try and sell me stuff as well.
> I’m repeatedly asked SEVERAL TIMES EVERY TIME I USE THE APP.
You know what doesn't do that? The local cab company when I call them to ask for a pick up.
I feel like I have much more control over "when" I share my location, if permission is granted to "uber app" not "uber domain".
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.
> Anyone know what went wrong in there?
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...
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.
>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.
Yes, Google has adopted lots of dark patterns.
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.
If you’re in the Apple ecosystem, I highly recommend the Vinegar extension which replaces the awful custom player with a standard HTML5 <video> element
I disagree. The problem is more nuanced.
A well implemented (native) app is always better than a well implemented web site.
The problem is poorly implemented apps which are just UI wrappers hitting dumb APIs or embedding entire web stacks which hit dumb APIs. A well implemented web app isn't much better than that. They don't work offline, they use way more resources than anything native and they leak data like a sieve generally.
> at Rogue Engine, we’re committed to being the go-to game engine for Three.js and the web
and there you go, author has a vested interest in you making web apps.
well the article is well reasoned enough. what I gave up on was finding actual pricing information for this engine. all it say is free if you earn less than 80k... so what's the price please?
https://rogueengine.io/GetStarted says:
Plus $ 20 $ 10 / month / seat Billed Annually $ 120
Pro $ 50 $ 25 / month / seat Billed Annually $ 300
Enterprise $ 90 $ 45 / month / seat Billed Annually $ 540
Each of those tiers has a different "free if you earn less than $xxx" level that I'm not gonna cut and paste. There's a chart with the differences between what those tiers gets you too.
Also:
Can I publish anything I want to Rogue Play?
You're allowed to publish content that is neither sexual in nature or illegal under either UK law and the laws of your country of residence.
What happens to my files if I cancel my subscription?
When you cancel your subscription your files will be locked and you won’t have access to them until you buy a new license. They will be scheduled for deletion in 30 days.
What happens to my files if I downgrade my subscription?
It's your responsibility to free the necessary space before downgrading. Your files will be deleted after 24hs unless you take action.
----
I don’t think the article was well sourced. WebGL technologies might be adequate for casual games… maybe. But it will be a very long time before they approach AAA gaming performance. And there is still a ton of funkyness about input (gamepad? multitouch?) and latency that is hard to address on a web stack.
He just asserts that the underlying technology has come along. It hasn’t.
> A well implemented (native) app is always better than a well implemented web site.
Dunno, native app doesn't have URLs nor deep links. I can't link you to a page in my native app that you can click on.
In my iOS HN app I'd have to click "Copy website link" to share a submission. If there were no website, I couldn't share it at all. Same with Reddit.
For most apps, that's a lot to give up when you app is basically just a website without a url bar.
Android apps absolutely support deep links: https://developer.android.com/training/app-links (surely iOS supports this too?)
It's also widely implemented in practice. For example, Instagram allows copying links to posts, and if you can view an Instragram link in the browser, it opens in the app.
ios and mac got url schemes. Sure not all developers implement it correctly. But not all sites implement a good url structure either (keeping state etc in url for sharing)
Android and Windows do too.
iOS apps absolutely do support deep links and URLs. Custom URL schemes are the older of the two and let iOS launch the app when someone taps on a URL that begins with its protocol (e.g. "bugmunch://orders?id=xxxxxxx"); the newer is Universal Links, which lets you set your web site up to launch your app from the web page if it's installed on your device.
Same native apps don't even relayout when you change window size, let you change the font size, or let you copy text.
Native apps made with SwiftUI or Jetpack Compose adjust their font size according to user preference in system settings out of the box. They also relayout automatically. Copying text on press is a one-liner in both frameworks, just need to think of it.
From the article: "[…] web apps have caught up. They’re faster […]" Especially how can this be true?
Maybe this doesn't matter because it's already fast enough but the difference in look and feel will be noticeable.
The writer probably meant "faster [than they used to be]" rather than "faster [than native apps]".
> A well implemented (native) app is always better than a well implemented web site.
No, because it fails to support the feature of running virtually anywhere.
For many people this is the #1 feature. Everything else is just icing on the cake.
Who cares about an app that is 2x faster but doesn't run?
> For many people this is the #1 feature. Everything else is just icing on the cake.
I hear this sentiment from developers much more than non-developers. I wonder what percentage of developers do all their work within a browser.
Non developers typically don't think about these things. They just suffer them subconsciously or accept the situation as something they can never change anyway and go on with their lives. You have to ask them to find out.
And I also hear developers complain more about performance issues than non developers.
I've watched Logseq (note app) go from a perfect little browser-based app that did exactly what I wanted--block-based markdown notes synced through git--to an app with dozens of features that are pure bloat for me that I can't use in half the places I need it because I cannot install apps.
It was an interesting process to watch start, because people were like "finally an app!" and "moving on from 'just' a website!" but without any real justification for it. The app itself was the accomplishment.
And I should note the Logseq app is a good piece of work. In absolute terms it's great. It is, however, not what it used to be and not really what I want. I'd like to fork Logseq, deprecate the app, and have a self-hosted browser interface with storage on the server, synced to a git repository for backup.
On a side not, I like how we have electron apps that are 100s of mega that just access a website. Just as much of a waste.
> A well implemented (native) app is always better than a well implemented web site.
Given that the entire article argues pretty strongly against this, you need to at minimum argue against the points posed, or present your arguments for why "well-implemented native apps are always better". It's not enough to make a straw man of the worst possible scenario and claim that it holds true for the general case as well.
> They don't work offline
This isn't true. Offline functionality is the raison d'être for Service Workers. You can run an entire HTTP request router on the client to respond to requests while offline: https://hono.dev/docs/getting-started/service-worker
Are you guys okay? Don't get me wrong it's clever, but it's also insane.
If I pitched the idea of having SMB shares work online by shipping a driver that could intercept low level SMB calls and reroute them to a mock SMB server that holds the cache they would have assumed I'd lost it.
Surely the browser could help you a bit more to implement offline sites in a more integrated fashion.
It's ultimately just a little event listener function that accepts a Request object and returns a Response object. I bundled the service worker by running a quick `npx esbuild --minify --bundle --outfile=sw.js sw.ts` command, and it produced an 18.6kb JS file in 10 milliseconds. That's not even half the size of libraries like HTMX, Alpine, and jQuery.
You can of course use the CacheStorage API directly as well (you're not obligated to use a mock server): https://developer.mozilla.org/en-US/docs/Web/API/CacheStorag...
I've certainly seen crazier things though. People routinely include entire copies of Ubuntu LTS in their Docker images to ship tiny HTTP servers.
> A well implemented (native) app is always better than a well implemented web site.
No, not always. I don’t care how well implemented or optimized your “app” if it’s something that could’ve been a static web page.
> They don't work offline, they use way more resources than anything native and they leak data like a sieve generally
False, false and false.
As the solo founder of a couple of 'popular' websites I get asked regularly if I want to create an app. When I ask them what they want the app to do what a website can't, they can't name a single USP, especially now notifications work on all devices.
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.
> 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?
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
> I'm a solo dev for a startup and this is something I always hammer home to my non-technical co-founder.
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.
> 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 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.
>> 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.
How well does that work on Android, Linux and Windows desktop, ChromeOS?
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.
One major one for anything with a text input it the inability to know when the keyboard is open and closed and how large it is.
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.
Contacts API; Not all sensors are supported
Contacts Picker API: https://developer.mozilla.org/en-US/docs/Web/API/Contact_Pic...
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).
There are other platforms than iOS.
> Developers pay hefty app store fees
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...
Then why did you switch (honest question, not intended to be snarky)?
Customer pressures. Don't want to pay for iPhones ('too costly'), and then for long very hard to optimize for Android ('why too slow?') (even native... wait if native why slow? Because they buy the worst, cheapest androids ever, then later buy androids that cost similar to iPhones, so it was a big switch cost for nothing at the end)
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.
> Browsers can't access all the APIs in iOS.
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?
> Browsers can't access all the APIs in iOS
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.
Apps fingerprint you much, much better, and can access more data (despite what apple marketing says), your argument is moot.
What data can apps access without your explicit permission?
install tiktok (if you do not have it) and disable everything, no mic/camera/photos/contacts/… nothing. then ask you partner/friend/… to send you some text messages about purchasing an ebike for instance. open safari and do some searches for ebikes (https://blue.bike perhaps and others)… the head on over to tiktok and scroll a bit and see if any ebikes start showing up…
a) There is no evidence that Apple is sharing messages with third parties.
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.
there is no evidence for a whole lot of things… /s
You do realize that it was the “open safari and do some searches for ebikes” step that causes you to get the ads in TikTok, right?
So you think there a conspiracy and that TikTok for iOS has been able to break out of its sandbox and read your text messages?
This would have made news if so.
What? No. Apps are guaranteed to be sandboxed and can’t access anything you don’t let them.
> Every time I hear the PWA argument it's always what is in the best interest of developers not users.
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.
Fingerprinting isn't going anywhere without legislation. New browser APIs or PWAs won't change the underlying problem. It's the same status quo.
Meetings should be emails
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.
I actually don’t think it’s always financial.
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.
I look at these things as essentially aesthetic preferences. There's certainly cases where a certain medium is the objectively right one for a task, but there's many others where it really just a matter of taste.
I actually think of them as more than just an aesthetic preference. It is fundamentally about proof of work. Something that will become more and more important as we move into a post AI world.
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.
What web game is as good as Stardew Valley and deserves to be just as remembered? Most web games are crap.
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
That's a interesting way of thinking of it, but a little limited. For most, the proof of work aspect becomes just another part of the the status competition. I think I'm a little more optimistic about the future.
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 monopoly problem. Text retains quality, because it's more democratic, and AI can democratize visual art.
How does AI democratize visual art? Anyone can pick up a pen and draw. Affording all the expensive hardware to train AI, on the other hand, is limited to a much smaller group of people, unless there's something I'm missing?
Web gaming might be a decent incremental revenue source (< 10%) for big developers or the main distribution channel for small studios that will never make it big.
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.
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.
Just played around with a PWA on iOS and added it to Home Screen. Works really really nicely and so it seems pwa have come along a lot since I last looked into them! Thanks for the prompt to update my understanding.
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 not sure about the specifics of UE/Unity/Godot but I was under the impression that a Hello World in any of those for the web would be about 20MB where as the Three.js game I'm working on will be at most 1MB when done (not counting game music soundtrack).
Sure, but so will be the native app.
While I'm sure it wouldn't be easy, it sounds like an opportunity for disruption.
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.
> I showed him how to add a website to his home screen
Some sites prevent rhis, diverting you to install their app.
One comment that I haven't seen yet and that puts PWA for Games in jeopardy: the maximum caching allowed for Safari PWA's (thus the whole iOS ecossystem) is only 50mb. Most mid-core / hardcore mobile games are bigger than that after downloading remote assets when the app loads for the first time, and this means a player of a mid-core PWA game would have to redownload a good chunk of the assets everytime the game loads.
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.
The 50mb limit no longer exists, it's much higher now https://bugs.webkit.org/show_bug.cgi?id=198133#c15
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.
If the app is added to the home screen, then it is exempted from having it's data wiped after 7 days without usage.
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
That's nice, thanks for correcting me! Although it's quite a nuisance that most PWA info I looked for before posting had the old 50mb (mis)information.
Safari has always hampered PWAs, and probably for the reason that they want you to use the appstore instead ($$$).
It came out in the Epic trial that 90% of App Store revenue comes from games. Those aren’t going to be web apps anyway for monetization reasons.
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?
Is Android dramatically better for PWAs?
There are fewer walls, yes.
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.
It’s a bit better but I’ve still not found any PWAs that I’d want to use over a native Android app, if only because they’re near-universally rough, quirky, and generally unpleasant in ways that modern Jetpack Compose apps aren’t.
Agreed but on mobile, the native app still has a marginally nicer UX. For apps I use heavily, I appreciate that. (Funnily enough, I use the inverse as a means of controlling my screen time. Too much YouTube? Delete the app and suffer through using it on Safari.)
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.
The problem with web games is monetization. If you look at Poki, for example, the most popular games are those that simply drag the user into a sort of low level loop where they are not ever going to actually fail but also never really succeed, as the aim is just to keep them there long enough to show more and more ads.
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.
Strongly disagree that Facebook games were the peak. To me that was classic flash games like nitrome.com
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.
One aspect I find fascinating and under estimated is how Apple makes the browser kind of secondary to apps. The browser is basically a navigator, a renderer of websites.
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.“
Are you trying to tell me there are people without a million tabs open?
There's a clear agenda with this article. I'm all for website wrapping apps being websites again. But I'm definitely sick of websites that should be apps. And I'd use a native app any day over a bloated website masquerading as an app, especially on desktop.
Hard agree on all that.
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.
Kind of off-topic, but I always wonder why Chase bank's tech is so good. I seldom use the app, preferring instead to use the website, but no matter which way I interact with Chase, they seems to know what they are doing.
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.
One of my kids recently started playing travel basketball and being a nerdy, into stats tech dad I wanted to take stats on the game.
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 don't understand what this has to do with the topic.
The general topic was web apps vs phone apps.
I was pointing out that this applies to apps that you can build yourself.
This is about apps being easily simple enough to make into a web page.
No one is saying a table with javascript can't be done in a web page, people have been doing it for 30 years.
Whilst I agree with most of the points, author is making here I cannot help but make a small snarky remark that we, as a dev community, have been talking and dreaming about those talking points since the advent of html5 which is roughly 15ys.
Marketing and availability, i.e. is it within reach when a customer thinks about it, are core problems needing to be solved.
Who is this unified hivemind dev community you speak of?
Maybe 2025 will be the year of PWAs? /s
I sympathise, but talking to my sister I've come to appreciate a different point of view. I have an "app", a PWA, that she says she cannot find because it's not in the App Store. Despite telling her it's available as a website, this seems too much... she just doesn't use — or is comfortable using — Safari.
This was because every ad agency on the planet wanted to be in apps when the App Store took off, so they rebranded websites to apps to confuse people.
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 dislike apps and avoid installing them in general terms. They're bloated and frankly I have better things to store on my phone (mostly music, but also photos, conversation histories etc). I do not need an "app" for submitting a form. Looking at a website. etc etc
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.
The world seems to be reversed in my mind. On my phone everything wants to be an app, and everything on my computer wants to be a webapp. I want the opposite. Native apps on the computer and the phone can just be webapps, because I don't really care, nor do I need to repeatably use the same app on my phone.
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.
Same. I have only a few apps installed that my phone didn't come with. No games. No social media apps. Even email I access via Safari. If I absolutely must use an app for something, I typically install it, do what I need, and then delete it.
If you're on Android, you may enjoy the new "Archive" functionality, which uninstalls the app but retains its local data directory so when you tap the icon it re-downloads the apk on top of its existing data directory, so no more first-user experience https://support.google.com/googleplay/answer/15523443?hl=en
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
> My favourite thing about using a website? It can't send me attention grabbing notifications. It can't harass me for perms.
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.
I'm right there with you. There are probably dozens of us!
Never call a PWA an app, people will get confused.
But the "A" stands for "app"! Is there anything you could call it that would be less confusing (because "PWA" or "Progressive Web App" sure ain't it)?
Until some massive marketing campaign explains to all users of the internet what PWA's are (which is never going to happen), there's nothing wrong with calling your PWA a website if it prevents a lot of confusion.
Further to that, there are plenty of people who can't really articulate what a web browser actually is or how a website differs from an app. It's not clear to me whether these users would be more accepting of a PWA or if they would be even further confused by them, particularly if they have to be left to find the app on the web first in order to "install" it, even more so if they've never bothered to look at what all those buttons in their web browser actually do.
Sure, but I also think there's nothing wrong with calling it an "app" if that's the buzzword that will tip some people from dismissing it towards trying it out.
If it's clear that people expect 'apps' to be in the app store, how can you think "there's nothing wrong" with calling PWA's 'apps'?
OK, "there's nothing wrong with calling a PWA an 'app' in most contexts, unless the person listening to you is likely to try to search for the PWA in an app store".
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.
I never understood why anyone bothered with native apps. It defies reason why consumers would prefer to download some clunky app instead of just using it in their mobile browser with no strings attached. The main excuse I keep hearing are UI/UX differences but web UI/UX is excellent these days, it really doesn't offset the huge negative hurdle of having to download an untrusted app which takes up your time and uses up space on your phone before you can use it. How do consumers even know they will like the app before they tried it? Why would they download an app they don't know? It makes no sense to me. WTF! The user will only ever download the native app if they've been conditioned to believe that it's worth their time and disk space. But how do you get that conditioning effect going when you're just starting out? Massive chicken-and-egg problem.
I think it's probably a remnant of a very successful corporate PsyOp. I can see why big tech wants to be able to covertly access people's cameras, microphones and location data. In most cases, there is literally nothing positive for the consumer. It's a story of leveraging user apathy to manufacture consent. Most people fell for it. Personally, I hate being forced to download native apps when the web version of the app already works perfectly.
Sometimes I feel like the push against web tech is partly the product of a spiteful group of developers who hate JavaScript because they had a bad experience with it back in 2010 and they've stubbornly refused to re-evaluate their position in spite of the language showing extreme resilience and adaptability.
The HTML + CSS + JavaScript combo is a marvel of software engineering. The ECMAScript standard is surely one of the most impressive accomplishment that bureaucracy has ever produced. It has progressed with both speed and quality, picking the best parts of many different languages.
I currently have 4 parking apps, and 2 ev charging apps on my phone. None of those have a Web version when you can clearly see that most of their ui is webview based. They could have been bookmarks indeed.
100% agree. Except it would be nice to have a notification, reminding you that the meter is running. And on iOS, you need to install a web app before it can send notifications, defeating the point of not having to install anything.
https://webventures.rejh.nl/blog/2023/ios-web-push-requires-...
I'll take a native app over a web app every time.
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
Apps also:
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
> More powerful
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.
When HTTP was designed, there also weren't any images, CSS, or Javascript.
There was no support for images in the two pre-1.0 versions of HTTP.
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.
> a decent solution in Java applets
Uh!
The web is for hypertext. Simultaneously, lots of apps should be App Clips or whatever the Android fragment equivalent is called.
For my game, I do have a web version, but I also have native apps, because the web monetization path is just not as smooth as native.
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.
I would if there aren't silly restrictions like rotation lock and fullscreen in safari. You can't even make a app that stay at one direction properly. And fullscreen is limited to video (without any ui control).
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"
One thing I haven't seen addressed in the post or comments (sorry if it's there and I just missed it) is for apps and websites that sell non-digital goods to customers.
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.
If the website is a PWA, it can be installed to the home screen and look and behave just like a native app. You just tap the icon on the home screen. It will remember your login.
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).
It is not about tooling, but distribution.
Android lets you list PWAs in the app store, so we're halfway there...
This should be auto posted as first comment on every post about a new technology / platform
This reasoning is why I'm keen to try out RomM[0], a ROM library manager that has EmulatorJS[1] built in. Rather than having to setup emulation on each device where I want to play a simple game, I can instead use this combination to do it from any web browser on my local network.
I'm playing https://www.twilightwars.com it's a turn based game. You get a notification once it's your turn. If you don't click on the notification but just open the browser, the browser thinks you don't want the notifications and stops them. There is no way of whitelisting the notifications.
WebOS had quietly solved this years ahead of its time.
All apps and the OS are JavaScript based.
The timing of the hardware missed or maybe it could have stuck more.
This argument has existed since native apps were first introduced. One of the problems I see now is how horrible and frankly broken browsing the web can feel, especially on a mobile device. With all of the cookie confirmations due to GDPA and other ways mobile websites try to engage you (such as popups to subscribe to a newsletter or for discounts off your first order), some websites become almost unusable on a mobile device. If that's the future where native apps don't exist, count me out.
There is no difference regarding GDPR/newsletter/discount popups between website and application. It's up to the owner if they want to nag users, and on which platforms.
(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 disagree. Native apps usually don't have annoying popups especially to the extent that the web does. Saying there's "no" difference isn't being genuine.
> WebGPU and web games are said to be catching up to native-level performance, and some argue they’re already there.
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 working on a little niche puzzle game in Love2D. Well, I'm done, I just need to ship it. I currently have web, iOS, and Windows builds. I strongly prefer playing the native version.
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.)
I completely agree with the sentiment of the article but the general user behavior is changing. Young people are always asking for an app. It's what they're used to. My nephew never even opens his web browser on his phone.
Hey, author here. Thanks thunderbong for sharing. I underestimated how much people cared about this. I'm so happy to see everyone sharing their arguments.
There are definitely apps, which could be websites, e.g., using the coinmarkecap app doesn't make any sense in comparison to the website.
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.
The web tries to do a lot of things, even some of the stuff you named. There's a Bluetooth API in Chrome, server-sent notifications via service workers, and some attempts at VR support.
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.
> Yet businesses still push native apps as if it’s 2010, and we’re left downloading apps for things that should just work on the web.
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.
> If it were just a website, you wouldn't have a little picture of their logo on your phone
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: )
> 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 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.
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.
That's a good thing for the customers though.
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.
For many businesses an app also has a web version for those users who refuse to install the app. I'm thinking my local supermarket, or kmart, they want me to install their app for some reason. I suppose it's so they can send me advertising as notifications? Many business that aren't "app only" have to have both web app and mobiles apps. App development studios love them.
there's even a worse option that his article doesnt include. and thats apps that have limited functionality compared to the web app. My bank is one of them. Heres your account and here's your most recent bank statement. You want to see more bank statements or add/remove a auto bill or change your password, you need to go to the website for that. What the f** why do you even have an app?
Cool, but web apps still can’t do location tracking in the background. So please do tell me how my fitness app should be a web app instead?
Does your app still function if the user disables location sharing?
Regardless of the answer, it's very common for people to wish to share their workouts, locations included.
Just to add another perspective:
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.
I generally agree, but not for any critical workflow. You can't easily archive copies of web software. One day any website you rely on could introduce user-hostile regressions or simply disappear. Apps in the mobile ecosystem also have this problem, but at least you can archive and sideload old APKs on Android (for now).
> you can archive and sideload old APKs
Only as long as external dependencies (like APIs) are satisfied.
Very true, but you can also keep around an old Android phone, or even emulate an old AOSP distribution if your really need to. Obviously this is not ideal, but if you're trusting your hobby or business to an app, it is in your best interest to make sure that it doesn't poof out of existence randomly before you can upgrade.
I was thinking more about backend APIs managed by the company providing the app.
And here I am making unportable C projects. Actually, I'm quite happy being away from the web, its a pain
This was the original plan for the iPhone. The web just needed to catch up. But now that everything is app based, it's hard for companies to want to give up space on a user's home screen. Web apps can be added to the home screen, but it's not the default state, like an app is.
There’s a dichotomy between web and native apps. I don’t feel like I’m leaving my OS when using an app that’s parked on my dock. For subscriptions and pricing web is great but even the notifications are sub-par to native, I need user retention not another tab in my browser.
I'm also curious about apps vs native. Here on HN it seems people often hate on the web "you're the product, not the customer" vs native. But, half the websites I visit say "download the app!!!!". If all the spying on the web is so great for them but they're pushing you to an app, that to me suggests they get more spying on the app. Even if the app is just a webview, they get to set the policy so no blocking the 950+ companies they're letting spy on you. And, even better, the app will require you to login in so they can magically get even better data.
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)
The modern web sucks, with all the tracking, etc.
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).
Yeah so native apps have some unique abilities to track you that websites do not.
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...
Oh wow, I had no idea about the in-app browser tracking
meanwhile, huge shout out to FiiO for their web based eq control and firmware updater (via WebHID)
For multiple reasons outside of devs' control, PWAs basically don't fly on iPhones. They don't go to all that extra effort of packing a webapp into a "native" app just for fun.
while i understand the sentiment and having an app for everything is annoying, there’s a reason ppl prefer app: most web developers are either incompetent as hell or don’t care and write horrible websites, and forcing ppl to make a native app at least ensures some basic level of saneness and performance
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
Love this:
> 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.
Please stop making web apps, the web is for documents, not to be hijacked by Google in their attempt to wrestle personal computing from Microsoft.
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" ?).
Yep. And it gets worse.
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.
Mobile operating systems have really good security models, and native apps are even more isolated compared to the websites.
I really wish that we would have similar isolation options on desktop/laptop OSes.
It would be horrible if we lost desktop computing to a scenario where we need permission from one of the tech giants before running code.
Those who sacrifice freedom for security deserve neither.
I'm afraid it's the other way around. Browsers are (generally) better at sandboxing than OSs. Browsers are paranoid by default. They have to be, because visiting a website is just a click away (compared to multiple clicks/taps to install a native app).
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)
You can use Qubes OS (a linux that relies heavily on virtualization) if you want that.
The browser is an operating system. This might be unsettling to this crowd but we can’t just cover our eyes and hope it turns into the browser from 20 years ago.
> Please stop making web apps
No.
> the web is for documents
No it isn’t.
I think you're about 25 years late to the conclusion of the first war, and 10 years late to the second
Do individual consumer web apps get many sales when compared to smartphone apps in a store?
Referring to everything as "web" when they mean JavaScript has been such a feat of marketing.
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.
Plenty of flash games got archived in time as .swf files! And many can still be played with either Ruffle or the last build of the standalone Flash Player Projector (which is still available on Internet Archive).
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.
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.
email me when y'all are upset enough to actually do something about this => e.g., create a newsgroup like app-store across iOS and Android using the new api's exposed by apple and google
maceip@sina.com
Users should educate themselves about when to use web apps and native apps.
> To create an Audio Asset, you need to import your audio file (mp3, wav, ogg, mkv) into your project.
Seriously? You can't have audio except precomputed in a file?
Lol no thanks, not everyone hates beautiful native design
Nope.. HTML should’ve been just that, hyperlinked text.
Friend should’ve been forms.
Applications should’ve been apps.
The thing is that html/http is such a great distribution model
When an app rots you're left completely helpless. When a website rots at least you can try with multiple browsers until one of them works.
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.
[dead]
[flagged]
> A Unity like environment to create web apps
Spell check needed.
No. Websites are more laggy, cookie disclaimers, weird dimensions, needless UX, choppy. Apps are almost always way smoother.
The app can be installed only by tapping, but the web app requires typing in the url or into a search.
I feel this is difficult for many more people with less motor skills, or that can’t read.
Do you not have to search for the app on the app stores? How else is the app found?
Save bookmark to home screen.
> it’s time to get back to what the web was always meant to be: a universal platform for everyone
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.
That ship appears to have sailed. The more realistic proposal would be the converse: a stripped down browser that acts only to retrieve and display web pages that are documents, not apps.
I actually agree. I think that's the best way to achieve what I'm talking about. Compatibility with current browsers must be maintained for many years. But we split the web into two much simpler platforms. One for documents that includes HTML and a tiny subset of CSS, and the other that's basically WebAssembly + WebGPU and other APIs for networking etc.
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.
