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.
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?
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.
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.
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)
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.
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.
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.
> 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.
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.
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.
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.
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.
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".
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.
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
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.
> 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.
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.
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.
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
> 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.
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.
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).
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.
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.
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.
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.
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).
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.
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.
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???)
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…
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.
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 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…)
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!)
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: 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.
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.
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.
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).
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 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.
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
Tldr: The FOSS version earned a stable revenue through Google Ads placed on the website, since the website ranked high on Google searches. Two years ago, that changed since the website got de-ranked, so I created a different, proprietary version of the app based on the FOSS version but with a totally revamped block editor that I wrote from scratch - that I worked on full-time for a whole 1 year.
As you have pointed out, QML is buggy. Chromium's rendering engine is probably the most stable and polished GUI toolkit there is, not to mention a cross-platform one too. Throughout the last 10 years I only had to deal with 2 Chromium bugs and they were very minor. Well-written JavaScript is fast and the machines are getting faster every year. It does not take much real time computation to provide a UI for a desktop app, it's not a video game. And many of the those things that are real time, like the caret in the text editor or hover states are implemented in native code by the web browser, with no JS interaction. I agree though that a block editor is a little more real time than the average UI.
The key word is well-written JavaScript. What is the most popular state management framework? Redux, possibly. What is the most inefficient state management framework? Also Redux. With Redux, if you have an app that displays a timer that updates every second, every subscription to any piece of the state throughout the entire app will trigger. I'm not sure if the app used Redux, but I used to use a time tracker app that would use 30% of my CPU when idle (I since moved to a CLI C++ solution and it is so much faster, but that does not mean a decent time tracker could not be built with web technologies). So if Redux is the most popular framework, you can see just how little the average web dev cares about writing apps that are not slow resource hogs.
> Also, all web apps couldn't handle loading a very large text file (they were all hanging).
Could it be that QT has some optimisation technique to not render all those lines out of view? I.e. if you have a huge file that can still be loaded to RAM, C++ won't sweat it, but is it actually getting all rendered at the same time in a savvy implementation, whether at the level of the app or the framework? Probably not. On the other hand, the textarea element or a contentEditable div just was not made for something like this. It could still be developed by implementing a custom element / component that loads the text dynamically while scrolling. If it's too much for JS to hold, it could use WASM or another process and pass it with IPC. It is definitely possible to write an Electron-based text editor that can open a 1 GB text file efficiently, it's just not out of the box experience and most people do not think there's a need for such a use case.
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.
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.
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)
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.
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.“
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
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" ?).
Websites are at least supposedly sandboxed so they are not as much of a risk as running native binaries. But this is getting worse and worse as browsers expose more and more of their host operating system's functionality. The benefits of using a website instead of a native app are quickly disappearing while the drawbacks have only been somewhat mitigated. We're getting to the point where browsers are worthy of the decades old criticism Emacs has received. They have eventually become an OS with many fine features - simply lacking a good web browser.
The browser, and the web, has been destroyed by the insane security model of modern OS-Browsers: running every executable they're sent from anyone with not a care in the world as if it is normal. This one thing has made it so browsers cannot be in control of the user, made it so that CA TLS is pretty much required and so that browser devs write entirely for the security use cases of the insane corporate web applications instead of writing for human people looking at website documents.
And this same security model makes it so that web apps basically cannot communicate with each other at all, unlike real applications where piping between small applications is the entire idea.
I'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)
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.
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 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.
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.
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.
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.
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.
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).
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.
383 comments
[ 43.9 ms ] story [ 4913 ms ] threadA well implemented (native) app is always better than a well implemented web site.
The problem is poorly implemented apps which are just UI wrappers hitting dumb APIs or embedding entire web stacks which hit dumb APIs. A well implemented web app isn't much better than that. They don't work offline, they use way more resources than anything native and they leak data like a sieve generally.
and there you go, author has a vested interest in you making web apps.
Plus $ 20 $ 10 / month / seat Billed Annually $ 120
Pro $ 50 $ 25 / month / seat Billed Annually $ 300
Enterprise $ 90 $ 45 / month / seat Billed Annually $ 540
Each of those tiers has a different "free if you earn less than $xxx" level that I'm not gonna cut and paste. There's a chart with the differences between what those tiers gets you too.
Also:
Can I publish anything I want to Rogue Play?
You're allowed to publish content that is neither sexual in nature or illegal under either UK law and the laws of your country of residence.
What happens to my files if I cancel my subscription?
When you cancel your subscription your files will be locked and you won’t have access to them until you buy a new license. They will be scheduled for deletion in 30 days.
What happens to my files if I downgrade my subscription?
It's your responsibility to free the necessary space before downgrading. Your files will be deleted after 24hs unless you take action.
----
He just asserts that the underlying technology has come along. It hasn’t.
Maybe this doesn't matter because it's already fast enough but the difference in look and feel will be noticeable.
Dunno, native app doesn't have URLs nor deep links. I can't link you to a page in my native app that you can click on.
In my iOS HN app I'd have to click "Copy website link" to share a submission. If there were no website, I couldn't share it at all. Same with Reddit.
For most apps, that's a lot to give up when you app is basically just a website without a url bar.
It's also widely implemented in practice. For example, Instagram allows copying links to posts, and if you can view an Instragram link in the browser, it opens in the app.
No, because it fails to support the feature of running virtually anywhere.
For many people this is the #1 feature. Everything else is just icing on the cake.
Who cares about an app that is 2x faster but doesn't run?
It was an interesting process to watch start, because people were like "finally an app!" and "moving on from 'just' a website!" but without any real justification for it. The app itself was the accomplishment.
And I should note the Logseq app is a good piece of work. In absolute terms it's great. It is, however, not what it used to be and not really what I want. I'd like to fork Logseq, deprecate the app, and have a self-hosted browser interface with storage on the server, synced to a git repository for backup.
I hear this sentiment from developers much more than non-developers. I wonder what percentage of developers do all their work within a browser.
And I also hear developers complain more about performance issues than non developers.
Given that the entire article argues pretty strongly against this, you need to at minimum argue against the points posed, or present your arguments for why "well-implemented native apps are always better". It's not enough to make a straw man of the worst possible scenario and claim that it holds true for the general case as well.
No, not always. I don’t care how well implemented or optimized your “app” if it’s something that could’ve been a static web page.
> They don't work offline, they use way more resources than anything native and they leak data like a sieve generally
False, false and false.
This isn't true. Offline functionality is the raison d'être for Service Workers. You can run an entire HTTP request router on the client to respond to requests while offline: https://hono.dev/docs/getting-started/service-worker
If I pitched the idea of having SMB shares work online by shipping a driver that could intercept low level SMB calls and reroute them to a mock SMB server that holds the cache they would have assumed I'd lost it.
Surely the browser could help you a bit more to implement offline sites in a more integrated fashion.
You can of course use the CacheStorage API directly as well (you're not obligated to use a mock server): https://developer.mozilla.org/en-US/docs/Web/API/CacheStorag...
I've certainly seen crazier things though. People routinely include entire copies of Ubuntu LTS in their Docker images to ship tiny HTTP servers.
My favourite thing about using a website? It can't send me attention grabbing notifications. It can't harass me for perms.
I'm 100% an outlier. My friends don't blink twice to install all manor of loyalty, news, social media, lifestyle, games etc etc and rarely clean up. It's all just choices and preferences - the world does not suit me.
On my computer I have a few programs installed, which I just constantly. On the phone I need each app only a few times a month, if that, yet they all insist on being actual apps.
I believe it's primary use case is storage efficiency but it works perfectly fine in your use case of preventing the code from running while you're not actively using it
But it works the same as for apps. You get prompted once on iOS at least. You either opt in for notifications or you don’t. There’s no difference.
Chrome, being a division of a huge ad company that makes money from these agencies, not merely played along but took a leading role in sowing the confusion.
I'm probably not the target market, but my first impression of Poki is that it's absolute trash; it looks like a shopfront for the lowest quality mobile games I can imagine. The first thing I tried was a block-puzzler that involved drag-and-drop to move pieces, but the drag didn't track the mouse cursor properly.
If someone asked me "which site is leading the charge in the Browser Games Renaissance?", I would say itch.io, hands down.
When the original article is talking about escaping the tyranny of the app store it sounds to me like they don't want to share the loot box revenue with Apple/Google, like our chinese friends at Epic.
Unfortunately for them, there are still pay once real games. Some of the good indies are on itch.io indeed.
Stop calling lootbox dispensers "games" please. I prefer paying for a game in advance instead of being monetized.
Marketing and availability, i.e. is it within reach when a customer thinks about it, are core problems needing to be solved.
And really, who has the time to maintain a website and two apps? Or rebuild a decade old platform in a janky cross compiling solution like Flutter that is always on the brink of being sunsetted?
Not me. I'll spend that time on improving my websites, thanks. I'll let my competitors go bankrupt on trying to monetise an expensive app that should have been a website.
I'm a solo dev for a startup and this is something I always hammer home to my non-technical co-founder. I tell him that spinning up an app that would have parity with our current app will not only take close to a year for a single person to develop, but from there on out every feature will come out slower since we need to have mobile parity as well. Out current plan is to slowly make all the pages on our website mobile friendly and even that is a big lift for a complex business app
He is just trying to piggyback an another distribution channel to get more visibility and another place to be found. It has nothing to do with UX.
Browsers can't access all the APIs in iOS.
> Developers pay hefty app store fees
You pay 99$ per year and 15% for each sale. Apple handles VAT, refunds, distribution and so on.
> They’re faster, more flexible, and work seamlessly across devices. Native apps? Not so much.
Enabling iCloud sync for your app is just a single click on Xcode.
> Why Web Apps Are the Future
On a national TV program in Germany, they talked about an app related to trees in Hamburg. That same day, my app on the App Store experienced a significant spike in downloads. When I looked into it, I discovered that the app they mentioned on the news was actually a PWA! :)
I feel like the author doesn't have any idea about native app development.
> apps had unique features like notifications and offline access.
Browsers can do those things. If you're going to offer "Browsers can't access all the APIs in iOS" then, at the very list, provide one or two examples of what you're referring to.
Hardware APIs: There is of course a good reason why websites don't get unlimited access to those APIs (and why they can't access them in the background). But Bluetooth and USB are both available on Chromium browsers on every platform except iOS (because Chrome on iOS is Safari).
Example: When Google closed down Stadia, they offered a way to unlock the Stadia controller so you could connect it via BT to any computer and use it as a regular controller. You just went to their website, hooked up the controller via USB, and the site would update the firmware on the USB device.
But sure, there are many use-cases for native apps. Also, there are many native apps that should just be a website (you shouldn't even need to install it if you only need to use it once or twice).
I was not denying that not every app needs to be native -- I was replying to a comment asking for what is not supported.
It’s very common for something like a comment box to keep the text pinned above the virtual keyboard. This is impossible on the web. If you have ever seen an implementation of this on the web (for iOS) please point me in that direction as I would love to copy the implementation.
Notifications just came recently, but weren’t available for a decade after availability to native apps.
The final hurdle is discovery. It’s not possible for a site or app to act as a one click installer of a PWA (add to homescreen) and sites can’t prompt to be added.
And nor should they.
Every single API that gets added to a browser increases the likelihood that you will be accurately fingerprinted and tracked across the web. This data is then packaged and sold to third parties whom you will never know about.
Every time I hear the PWA argument it's always what is in the best interest of developers not users.
b) You are simply confirming my point which is that when you visit a website it is able to tie you to an consistent identifier through the APIs your browser supports.
This would have made news if so.
I can control a web app through customizations to my browser in ways I can't with a native app. It's about user choice.
So, hosting doesn't cost?
Too many app-but-websites should be local, but because are web requires hosting and likely a database (that must be 'web-scale' so it survives bots).
My web app cost far more than my older native one. And is far harder to maintain...
Eventually, it became nice because it worked to give the app a wider reach. Then I added an e-commerce front, so it made sense. But is it less costly than native? Not.
> Enabling iCloud sync for your app is just a single click on Xcode.
How well does that work on Android, Linux and Windows desktop, ChromeOS?
Always laugh at the argument. Surely this matters for yet-another-mobile-crud #3553333.
> You pay 99$ per year and 15% for each sale. Apple handles VAT, refunds, distribution and so on.
15% until 1 mil, isn’t it? And even without that, 15% is ridiculous price.
> Enabling iCloud sync for your app is just a single click on Xcode.
How many Xcode clicks to port iOS app to Windows, Mac, Android and Web?
But it will never be more than that.
1. Game ops is too entrenched in mobile. The entire stack (user acquisition, analytics, monetisation) is tried and tested on mobile. These are difficult problems that seem easy to port to web games, but “devils in the detail”. Eg When you’re waiting on appsflyer to ship an update to properly attribute reinstalls for 6 months and end up wasting 25% of your UA budget during that time.
2. Consumers don’t want web games. The UI just isn’t there yet. You misclick out of a tab and lose progress or get distracted / start browsing another tab. Also to do with the ephemeral nature of a browser tab.
3. Unity’s dev network effects are too large. People who know how to make games use unity. People who want to make games therefore learn unity. It’s a flywheel.
4. Something psychological about downloading an app and seeing it on your Home Screen leads to retention.
Source: 7 years game dev and each studio I’ve worked in has been paid multiple tens of thousand dollars to port a game to web. Metrics were never anywhere near as good.
> 2. Consumers don’t want web games. The UI just isn’t there yet. You misclick out of a tab and lose progress or get distracted / start browsing another tab. Also to do with the ephemeral nature of a browser tab.
Fullscreen mode mostly solves the misclick problem. PWAs solve it entirely. Do consumers care at all about what the underlying technology is.
> 3. Unity’s dev network effects are too large. People who know how to make games use unity. People who want to make games therefore learn unity. It’s a flywheel.
There's Unity web. And people who really know how to make games can also use e.g. Unreal, which as compiled for web for ages.
> 4. Something psychological about downloading an app and seeing it on your Home Screen leads to retention.
PWAs can install to Home Screen.
[1] There is admittedly one company unable to implement modern web tech.
I do disagree in the developer point though. Those who know unity really do not translate well to unreal. Totally different languages and ecosystems. Also unity web has always really really sucked for anything other than gimmick games.
I wrote about developing my own block editor from scratch[1] using C++ and QML after finding that Notion (and so many other web apps) are extremely slow and inefficient - in terms of CPU/RAM/battery life.
I detailed a comparison between native and web block editors, and the difference is huge. The fastest web app (MarkText) is 60x slower at loading texts and uses 3x more RAM than my native app. Also, all web apps couldn't handle loading a very large text file (they were all hanging).
Modern computers are blazing fast and efficient, there's no reason a text editor couldn't load large files. This is why, in my view, web apps aren't really the progress people make them to be. We're going backward, not forward, with web apps. This need to change.
[1] https://rubymamistvalove.com/block-editor
[2] https://rubymamistvalove.com/block-editor#8-performance
My point is that it's much harder to write efficient code in the web ecosystem because you're bound to specific abstractions from the browser. Once deviating from said abstractions, it's not trivial to write efficient code.
Define "large". If it's bigger than the biggest text file I'll ever open, then I don't care.
My point is that "efficient" code isn't absolutely necessary in many, many cases.
We could keep going, but it maths out to mind-blowing amounts of waste just copying bytes around between buffers with no value add.
(Old man editorializing at clouds: "and all so we can employ people who don't know how computers work to satisfy corporate product pipelines by shoveling digital shit onto people that they neither want nor need")
I’d consider 28MB to be a medium sized file. Maybe 100MB+ would be large?
notepad++ solved this problem 20+ years ago.
I agree it’s an uncommon use case but it’s kind of sad when an app struggles to open a file like that on a modern machine in 2024. Just sad.
And secondly the kinds of apps that are referred to here are not the type that need massive efficiency or some complex feature - when inconvenienced by yet another single-use car park payment app, I've never once thought how marvellous it was that the text downloaded so much faster than the many web sites I regularly use: mainly because that responsiveness is blown away by the need to faff about installing the app (not to mention the effort needed to avoid giving unnecessary phone access out!)
Again, from my understanding, Obsidian is not that. If I remember correctly it is based on CodeMirror which is designed to only handle (EDIT: rich) text.
Edit (addendum): BTW, I'm not sure your Obsidian RAM reading is correct, an empty instance of Obsidian with one note uses 285MB (all 4 processes together) on my machine (M1).
[EDIT] Here is memory consumption of Daino Notes: https://pasteboard.co/z5pciLoh99i6.png
EDIT: Btw, I do have plans to cut RAM usage significantly in Daino Notes (I focused more on load time and responsiveness). But getting back to my point - I can do these optimizations because those RAM inefficiencies are a result of my code, not some abstractions I can't change.
Funny, but how about a log of one Jenkins run weighting at - checking... - 630 MB? Or two of them so someone can compare them?
VSCode is close to counting… but it absolutely sucks on RAM usage, so I try to avoid it when I can.
RAM is cheap for you.
It's always silly when people bring up their top-of-the-line computer into discussions about performance. Software shouldn't be just for the top 1%.
Let's say I spent $50 on 32GB of RAM. Over the lifetime of the computer that upgrade would cost ~$0.02 per day. Two pennies a day. And that's US prices, it can be less expensive elsewhere.
I've used VSCode on a computer with 2GB of RAM, and it worked. I expected everything to run slower - and it did run slower, but it ran. And I developed, and contributed to the project I was working on while away from my workstation. This was a cheap $70 Windows 10 tablet. YMMV.
I'm sure that's pretty cheap for you, yes. Taxes and other fees tend to increase those prices outside the US, by the way.
> I'm not sure who you think has a computer, is developing software, and can't afford that.
There is a market for lightweight code editors, isn't there?
> Too bad if that's you, but "top 1%" is a laughable claim when RAM is so cheap.
That was a bit of hyperbole on my part, but let's not forget that just being an employed SWE in the US easily places you in the top 1% globally.
> I've used VSCode on a computer with 2GB of RAM, and it worked. I expected everything to run slower - and it did run slower, but it ran. And I developed, and contributed to the project I was working on while away from my workstation. This was a cheap $70 Windows 10 tablet. YMMV.
Fair enough. VSCode is hardly the worst offender though - it actually runs quite well for an Electron app.
And not being able to afford $30 as a developer for a decent amount of RAM puts you in the bottom 1% of developers globally. Yes, I made that up just as you are making up your own numbers. But as I explained, you don't need 128GB of RAM, you don't need 64GB of RAM, you don't even need 8GB of RAM, you can still develop with VSCode with 2GB of RAM. Nobody is handing out free RAM, so if you need more, save your rupees, or pennies, or euros, or whatever. The daily cost of it spread over time is miniscule for anyone on the planet, and you will get back the investment in saved time.
So while you think web apps are going "backwards", they've likely helped contributed to modern computing hardware speeding up your native programs!
So in my view, browsers became capable, but then plenty of "heavy" web apps appeared, which required more beef in the machine.
That's also the typical way it goes: current hardware being okayish but not great is one of the strongest drivers for better hardware. Whether it is gaming (PCs), camera (smartphones), the web bloating (both).
Web apps can just up and disappear, spontaneously grow paywalls, or slowly enshittify over time, and unless both the user is technically savvy and the web app is fully open source, there’s nothing the user can do about it.
In contrast, when a new release of a native app is worse or its company goes under, the user retains a useful product (old binary) that can be run bordeline indefinitely one way or another (hacks, emulation, etc).
The biggest problem is with apps that show you content. Web sites give the user more control over what content to save, better exposure to scrapers and APIs, standard navigation to every other web site.
Websites can give more control but that’s hardly a rule these days and depends on how the site/webapp in question was built. Something built with a canvas-based UI (as is sometimes necessary for displaying high volumes of information without performance degradation) for example isn’t going to give the user any better control than a native app would, and in some cases less.
I’ve wanted to do the same thing you did but with coding notebooks (e. Jupyter) for a while now. It frustrates me to no end that the only native software for notebooks is JetBrains IDEA (and even that’s only an “I think it’s naive” lol). Hopefully I can take what you learned and documented and apply it to my app ^-^
Even the logo is almost identical.
Is this the same project? Looks like two separate GitHub repos by the same author. Why two similar projects/websites?
7. The previous version of Daino Notes, called Notes is FOSS (free and open-source software) available at https://www.notes-foss.com/ and the source code is available at https://github.com/nuttyartist/notes. I decided to make Daino Notes closed source due to difficulties in monetizing FOSS. In order to comply with Notes' MPL license, all common files between Notes and Daino Notes are published in https://github.com/nuttyartist/daino-notes-public
Multiplayer was quoting the correct reason. I also exeplained more about the timeline here: https://github.com/nuttyartist/notes/issues/690#issuecomment...
Tldr: The FOSS version earned a stable revenue through Google Ads placed on the website, since the website ranked high on Google searches. Two years ago, that changed since the website got de-ranked, so I created a different, proprietary version of the app based on the FOSS version but with a totally revamped block editor that I wrote from scratch - that I worked on full-time for a whole 1 year.
As you have pointed out, QML is buggy. Chromium's rendering engine is probably the most stable and polished GUI toolkit there is, not to mention a cross-platform one too. Throughout the last 10 years I only had to deal with 2 Chromium bugs and they were very minor. Well-written JavaScript is fast and the machines are getting faster every year. It does not take much real time computation to provide a UI for a desktop app, it's not a video game. And many of the those things that are real time, like the caret in the text editor or hover states are implemented in native code by the web browser, with no JS interaction. I agree though that a block editor is a little more real time than the average UI.
The key word is well-written JavaScript. What is the most popular state management framework? Redux, possibly. What is the most inefficient state management framework? Also Redux. With Redux, if you have an app that displays a timer that updates every second, every subscription to any piece of the state throughout the entire app will trigger. I'm not sure if the app used Redux, but I used to use a time tracker app that would use 30% of my CPU when idle (I since moved to a CLI C++ solution and it is so much faster, but that does not mean a decent time tracker could not be built with web technologies). So if Redux is the most popular framework, you can see just how little the average web dev cares about writing apps that are not slow resource hogs.
> Also, all web apps couldn't handle loading a very large text file (they were all hanging).
Could it be that QT has some optimisation technique to not render all those lines out of view? I.e. if you have a huge file that can still be loaded to RAM, C++ won't sweat it, but is it actually getting all rendered at the same time in a savvy implementation, whether at the level of the app or the framework? Probably not. On the other hand, the textarea element or a contentEditable div just was not made for something like this. It could still be developed by implementing a custom element / component that loads the text dynamically while scrolling. If it's too much for JS to hold, it could use WASM or another process and pass it with IPC. It is definitely possible to write an Electron-based text editor that can open a 1 GB text file efficiently, it's just not out of the box experience and most people do not think there's a need for such a use case.
Like with anything, we're dealing with abstractions. Qt and QML are also abstractions. But I'd argue they are better abstractions than the web for dynamic semi-complex to complex applications (for static sites/simple applications, the web is fine). The reason Qt and QML are a great abstractions are mainly:
1. Native modules/APIs - you can always plug in native modules into your app as needed. For example, I use native Objective-C APIs to draw the window on macOS for my app. It just looks better than what you get with just Qt.
2. Performance - Almost all QML-based components (called Qt Quick), are written in fast, compiled language C++, and if needed, you can create your own components in C++ and expose them via QML.
3. There are many more reasons, one of them is that I think QML is the best declarative UI language I've seen, and it plays very nicely with Qt style of C++ (signal and slots etc.).
> Could it be that QT has some optimisation technique to not render all those lines out of view?
Well, I detailed in my blog post my technique - it's not really novel - you can build virtualized lists in many languages, including JavaScript. You can look into the source code of many web apps that have done the same type of block editor that I implemented. MarkText[1] seems to be the most efficient one from my testings. My point is that building upon the abstractions of the web makes it very hard to write truly efficient code that is well-optimized for your computer resources. You might be an amazing programmer, but you're limited by a certain upper bound of performance, by the mercy of the web standards council and web browser engines implementation of those standards.
[1] https://github.com/marktext/marktext
Yep. That's precisely the point, you get all this stuff from a billion dollar project for free.
I really would not mind writing some C++ instead, even if it was more difficult. If anything, it would only be better because of higher moat of the project as well as my own skills. I agree 100% on the principles that native is better, faster and JS is an unnecessary layer of abstraction slowing things down.
However, if I can compare 2 timelines, one where I am using QML for a project, another one where I am using Electron and think about the time spent working around bugs, reporting bugs and the users of the app complain about crashes in the former, or not have any of that at the trade off of having something slightly slower, to me it's a no brainer.
In the context of what you wrote in the article:
> One of the most frustrating aspects of developing a Qt application is the slew of Qt bugs you encounter along the way. During ten months of development, I reported seven bugs, three of which were assigned 'critical' priority—two of which resulted in crashes. I also came across many bugs already reported by others that remain unfixed.
I would rather have an app that is slightly slower than one that can crash unexpectedly. Even if they are quick to fix bugs, new bugs may be introduced in new releases. Your intent was to promote QT in your blog post, but unfortunately it has only affirmed to me that it's not something production-ready (QML on desktop).
That's just the unfortunate state of industry where we are at. Hopefully it changes one day. Maybe Chromium could be forked into a C++ GUI toolkit where DOM could be manipulated directly by C++. Has anyone ever considered that?
Haha, that's interesting. But to be honest, it's really not that bad as it seems. Again, crash reports tend to be highly prioritized and most of the time you can find your way around them until they get fixed. It's indeed a frustrating experience when non-crash related bugs aren't being prioritized, but then again, like I explain in the blog, I could use a different library, probably an open source solution like I described using QBasicHtmlExporter[1] since QTextDocument toHtml uses weird inline HTML (and has some other bugs).
The thing is, with experience I kinda start to have my own boilerplate of battle-tested components/tools/libraries. I made the following client for Ollama[2][3] while not working on it full-time (still WIP) in around a month. It already is better than many web apps I tried who kept hanging while the model was generating a response. Also, try to copy text from a code block in web apps while a model is still generating a response -> it's almost always impossible since most web apps keep re-rendering everything on each completion, while I (like the native macOS chatGPT app) do incremental parsing which is much more efficient. The binary is 28MB (and can be even smaller), the app is fast and can handle very large amount of data. So I can build QML apps really, really fast these days due to the experience I gained and still gaining. I'm also wondering if I should open source my components as AGPL and then have some commercial licensing for it... Not to mention, I rarely use my own heap allocations myself - I try to put as much as I can either on the stack or in QML - so Qt handles all the heap allocation itself. While I'm relying on Qt to do an appropriate job, it seems to be very, very stable for now.
[1] https://github.com/Open-App-Library/QBasicHtmlExporter
[2] https://rubymamistvalove.com/client.mp4
[3] https://www.get-vox.com
I'm a big fan of the PWA phenomenon, and got very annoyed with my CEO when I was CTO'ing a new platform about 10 years ago, because he wanted to move to native apps just so that a loading screen looked a little nicer. Ended up using a native shell, did the loading screen the way he wanted and then fell back to a WebUI view for core functions.
However, there are some areas where I think native wins out, primarily the developer experience - I'll take SwiftUI + Swift over almost any other UI based developer workflow out there.
WebASM should mean we see a nice little bit of innovation in the web app dev experience in the near future, and I keep meaning to find time to try Elm out, but at the moment the next app I'm thinking about (which has some tricky low latency UI needs), I'm eyeing up native a lot.
Some sites prevent rhis, diverting you to install their app.
It's all about advertising, always, everywhere.
So while i am rooting for webapps it is still long way to go.
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.“
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
This issue becomes even worse if you try to make software that can both be used with keyboard & mouse and on a small touchscreen. With very few exceptions, you end up with something that works poorly with both interfaces, instead of working great on one of them. Trying to do that in a browser rather than the OS only makes the issue worse (what happens when you press "Alt" ?).
Websites are at least supposedly sandboxed so they are not as much of a risk as running native binaries. But this is getting worse and worse as browsers expose more and more of their host operating system's functionality. The benefits of using a website instead of a native app are quickly disappearing while the drawbacks have only been somewhat mitigated. We're getting to the point where browsers are worthy of the decades old criticism Emacs has received. They have eventually become an OS with many fine features - simply lacking a good web browser.
The browser, and the web, has been destroyed by the insane security model of modern OS-Browsers: running every executable they're sent from anyone with not a care in the world as if it is normal. This one thing has made it so browsers cannot be in control of the user, made it so that CA TLS is pretty much required and so that browser devs write entirely for the security use cases of the insane corporate web applications instead of writing for human people looking at website documents.
And this same security model makes it so that web apps basically cannot communicate with each other at all, unlike real applications where piping between small applications is the entire idea.
I really wish that we would have similar isolation options on desktop/laptop OSes.
Those who sacrifice freedom for security deserve neither.
For example, Chromium was able to mitigate Meltdown/Spectre within days, even if the OS was still vulnerable. (Chrome already had site isolation ready to ship, a feature that completely isolates websites into their own process). Even better, Chromium browsers tend to update themselves (or via Google Play) automatically.
Meanwhile, OS vendors were scrambling to ship an OS update.
(Also, worth mentioning that iOS users were vulnerable until Apple shipped an OS update, because every browser on iOS has to use Apple's WebKit)
> Please stop making web apps
No.
> the web is for documents
No it isn’t.
I 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 feel this is difficult for many more people with less motor skills, or that can’t read.
https://webventures.rejh.nl/blog/2023/ios-web-push-requires-...
OTOH, in tired of everyone pushing apps that could easily be a website.
I had an xfinity technician aggressively pushing me to install their xfi app when they came to install the service. They told me it was the only good way to configure the WiFi (!) and that they had to check a task in their technician to do list that they “walked the consumer through installing the app”.
Horrible consumer experience. Between the borderline lies and the nefarious push for the app, if I had had any other choice I would have rejected the installation on the spot. But alas xfinity was literally the only provider that could offer service with any decent speed.
But, I guess if you're paying for one for one of their all-in-one packages where the service is managing voip/streaming/tv/internet I guess I can see their equipment and management tool might be necessary. Wouldn't know, have avoided all that. Try to keep them just as an ISP.
You can send the users a notification even when they aren't using the app
It's much harder or impossible for users to block in-app advertising
It's easier to track users via apps, and your tracking data will be richer, more accurate and therefore more valuable.
Until this changes, we'll get stupid apps that should have been websites.
And to obstruct users e.g. from screenshotting content such as my bank transaction data.
I still remember the look on the tech's face back around 2002 when he saw a text login prompt on my FreeBSD box.
(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)
Only as long as external dependencies (like APIs) are satisfied.