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.
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.
So while you think web apps are going "backwards", they've likely helped contributed to modern computing hardware speeding up your native programs!
So in my view, browsers became capable, but then plenty of "heavy" web apps appeared, which required more beef in the machine.
That's also the typical way it goes: current hardware being okayish but not great is one of the strongest drivers for better hardware. Whether it is gaming (PCs), camera (smartphones), the web bloating (both).
Web apps can just up and disappear, spontaneously grow paywalls, or slowly enshittify over time, and unless both the user is technically savvy and the web app is fully open source, there’s nothing the user can do about it.
In contrast, when a new release of a native app is worse or its company goes under, the user retains a useful product (old binary) that can be run bordeline indefinitely one way or another (hacks, emulation, etc).
The biggest problem is with apps that show you content. Web sites give the user more control over what content to save, better exposure to scrapers and APIs, standard navigation to every other web site.
Websites can give more control but that’s hardly a rule these days and depends on how the site/webapp in question was built. Something built with a canvas-based UI (as is sometimes necessary for displaying high volumes of information without performance degradation) for example isn’t going to give the user any better control than a native app would, and in some cases less.
I’ve wanted to do the same thing you did but with coding notebooks (e. Jupyter) for a while now. It frustrates me to no end that the only native software for notebooks is JetBrains IDEA (and even that’s only an “I think it’s naive” lol). Hopefully I can take what you learned and documented and apply it to my app ^-^
Even the logo is almost identical.
Is this the same project? Looks like two separate GitHub repos by the same author. Why two similar projects/websites?
7. The previous version of Daino Notes, called Notes is FOSS (free and open-source software) available at https://www.notes-foss.com/ and the source code is available at https://github.com/nuttyartist/notes. I decided to make Daino Notes closed source due to difficulties in monetizing FOSS. In order to comply with Notes' MPL license, all common files between Notes and Daino Notes are published in https://github.com/nuttyartist/daino-notes-public
Multiplayer was quoting the correct reason. I also exeplained more about the timeline here: https://github.com/nuttyartist/notes/issues/690#issuecomment...
Tldr: The FOSS version earned a stable revenue through Google Ads placed on the website, since the website ranked high on Google searches. Two years ago, that changed since the website got de-ranked, so I created a different, proprietary version of the app based on the FOSS version but with a totally revamped block editor that I wrote from scratch - that I worked on full-time for a whole 1 year.
As you have pointed out, QML is buggy. Chromium's rendering engine is probably the most stable and polished GUI toolkit there is, not to mention a cross-platform one too. Throughout the last 10 years I only had to deal with 2 Chromium bugs and they were very minor. Well-written JavaScript is fast and the machines are getting faster every year. It does not take much real time computation to provide a UI for a desktop app, it's not a video game. And many of the those things that are real time, like the caret in the text editor or hover states are implemented in native code by the web browser, with no JS interaction. I agree though that a block editor is a little more real time than the average UI.
The key word is well-written JavaScript. What is the most popular state management framework? Redux, possibly. What is the most inefficient state management framework? Also Redux. With Redux, if you have an app that displays a timer that updates every second, every subscription to any piece of the state throughout the entire app will trigger. I'm not sure if the app used Redux, but I used to use a time tracker app that would use 30% of my CPU when idle (I since moved to a CLI C++ solution and it is so much faster, but that does not mean a decent time tracker could not be built with web technologies). So if Redux is the most popular framework, you can see just how little the average web dev cares about writing apps that are not slow resource hogs.
> Also, all web apps couldn't handle loading a very large text file (they were all hanging).
Could it be that QT has some optimisation technique to not render all those lines out of view? I.e. if you have a huge file that can still be loaded to RAM, C++ won't sweat it, but is it actually getting all rendered at the same time in a savvy implementation, whether at the level of the app or the framework? Probably not. On the other hand, the textarea element or a contentEditable div just was not made for something like this. It could still be developed by implementing a custom element / component that loads the text dynamically while scrolling. If it's too much for JS to hold, it could use WASM or another process and pass it with IPC. It is definitely possible to write an Electron-based text editor that can open a 1 GB text file efficiently, it's just not out of the box experience and most people do not think there's a need for such a use case.
Like with anything, we're dealing with abstractions. Qt and QML are also abstractions. But I'd argue they are better abstractions than the web for dynamic semi-complex to complex applications (for static sites/simple applications, the web is fine). The reason Qt and QML are a great abstractions are mainly:
1. Native modules/APIs - you can always plug in native modules into your app as needed. For example, I use native Objective-C APIs to draw the window on macOS for my app. It just looks better than what you get with just Qt.
2. Performance - Almost all QML-based components (called Qt Quick), are written in fast, compiled language C++, and if needed, you can create your own components in C++ and expose them via QML.
3. There are many more reasons, one of them is that I think QML is the best declarative UI language I've seen, and it plays very nicely with Qt style of C++ (signal and slots etc.).
> Could it be that QT has some optimisation technique to not render all those lines out of view?
Well, I detailed in my blog post my technique - it's not really novel - you can build virtualized lists in many languages, including JavaScript. You can look into the source code of many web apps that have done the same type of block editor that I implemented. MarkText[1] seems to be the most efficient one from my testings. My point is that building upon the abstractions of the web makes it very hard to write truly efficient code that is well-optimized for your computer resources. You might be an amazing programmer, but you're limited by a certain upper bound of performance, by the mercy of the web standards council and web browser engines implementation of those standards.
Yep. That's precisely the point, you get all this stuff from a billion dollar project for free.
I really would not mind writing some C++ instead, even if it was more difficult. If anything, it would only be better because of higher moat of the project as well as my own skills. I agree 100% on the principles that native is better, faster and JS is an unnecessary layer of abstraction slowing things down.
However, if I can compare 2 timelines, one where I am using QML for a project, another one where I am using Electron and think about the time spent working around bugs, reporting bugs and the users of the app complain about crashes in the former, or not have any of that at the trade off of having something slightly slower, to me it's a no brainer.
In the context of what you wrote in the article:
> One of the most frustrating aspects of developing a Qt application is the slew of Qt bugs you encounter along the way. During ten months of development, I reported seven bugs, three of which were assigned 'critical' priority—two of which resulted in crashes. I also came across many bugs already reported by others that remain unfixed.
I would rather have an app that is slightly slower than one that can crash unexpectedly. Even if they are quick to fix bugs, new bugs may be introduced in new releases. Your intent was to promote QT in your blog post, but unfortunately it has only affirmed to me that it's not something production-ready (QML on desktop).
That's just the unfortunate state of industry where we are at. Hopefully it changes one day. Maybe Chromium could be forked into a C++ GUI toolkit where DOM could be manipulated directly by C++. Has anyone ever considered that?
Haha, that's interesting. But to be honest, it's really not that bad as it seems. Again, crash reports tend to be highly prioritized and most of the time you can find your way around them until they get fixed. It's indeed a frustrating experience when non-crash related bugs aren't being prioritized, but then again, like I explain in the blog, I could use a different library, probably an open source solution like I described using QBasicHtmlExporter[1] since QTextDocument toHtml uses weird inline HTML (and has some other bugs).
The thing is, with experience I kinda start to have my own boilerplate of battle-tested components/tools/libraries. I made the following client for Ollama[2][3] while not working on it full-time (still WIP) in around a month. It already is better than many web apps I tried who kept hanging while the model was generating a response. Also, try to copy text from a code block in web apps while a model is still generating a response -> it's almost always impossible since most web apps keep re-rendering everything on each completion, while I (like the native macOS chatGPT app) do incremental parsing which is much more efficient. The binary is 28MB (and can be even smaller), the app is fast and can handle very large amount of data. So I can build QML apps really, really fast these days due to the experience I gained and still gaining. I'm also wondering if I should open source my components as AGPL and then have some commercial licensing for it... Not to mention, I rarely use my own heap allocations myself - I try to put as much as I can either on the stack or in QML - so Qt handles all the heap allocation itself. While I'm relying on Qt to do an appropriate job, it seems to be very, very stable for now.
[1] https://github.com/Open-App-Library/QBasicHtmlExporter
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