9 ms·

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 quickl

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. [1] https://rubymamistvalove.com/block-editor https://rubymamistvalove.com/block-editor [2] https://rubymamistvalove.com/block-editor#8-performance https://rubymamistvalove.com/block-editor#8-performance

oneeyedpigeon 2y ago
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.
- rubymamis 2y ago
  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.
  - oneeyedpigeon 2y ago
    > Any text editor that struggles to load a large text file... Define "large". If it's bigger than the biggest text file I'll ever open, then I don't care. My point is that "efficient" code isn't absolutely necessary in many, many cases.
    - rubymamis 2y ago
      The problem with that mentality is that you start seeing inefficiencies spring everywhere (why loading Discord takes so long? Slack? etc, etc).
      - xcv123 2y ago
        It’s a third world mindset where we end up with the software equivalent of public defecation, living in squalor and filth.
        kebokyo 2y ago
        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???)
      - jknoepfler 2y ago
        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")
nmstoker 2y ago
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!)
- wiseowise 2y ago
  You forgot constant 100MB updates, which are just one page refresh on web.
  - what 2y ago
    And that one page refresh is probably also 100MB these days.
    - wiseowise 2y ago
      Uncompressed - maybe.
mvladic 2y ago
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.
- rubymamis 2y ago
  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).
  - mvladic 2y ago
    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 https://pasteboard.co/uW2lPNSbL7f7.png [EDIT] Here is memory consumption of Daino Notes: https://pasteboard.co/z5pciLoh99i6.png https://pasteboard.co/z5pciLoh99i6.png
    - rubymamis 2y ago
      This is what I get with an *empty* vault: https://pasteboard.co/N3IdNUKUUNKq.png https://pasteboard.co/N3IdNUKUUNKq.png EDIT: Btw, I do have plans to cut RAM usage significantly in Daino Notes (I focused more on load time and responsiveness). But getting back to my point - I can do these optimizations because those RAM inefficiencies are a result of my code, not some abstractions I can't change.
darknavi 2y ago
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!
- freehorse 2y ago
  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)?
  - tanewishly 2y ago
    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).
- liontwist 2y ago
  No. The motivation to make existing flows faster and do more of those at once is constant. It wasn’t initiated by bloated web apps
cosmic_cheese 2y ago
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).
- la_fayette 2y ago
  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...
  - cosmic_cheese 2y ago
    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.
- jkestner 2y ago
  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.
  - cosmic_cheese 2y ago
    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.
kebokyo 2y ago
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 ^-^
- rubymamis 2y ago
  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.
alternatex 2y ago
This app looks exactly like one I had used in the past. Took me a while to find it: https://www.notes-foss.com/ https://www.notes-foss.com/ Even the logo is almost identical. Is this the same project? Looks like two separate GitHub repos by the same author. Why two similar projects/websites?
- Multiplayer 2y ago
  I was wondering about that too. This is in the article linked to https://rubymamistvalove.com/block-editor https://rubymamistvalove.com/block-editor 7. The previous version of Daino Notes, called Notes is FOSS (free and open-source software) available at https://www.notes-foss.com/ https://www.notes-foss.com/ and the source code is available at https://github.com/nuttyartist/notes 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 https://github.com/nuttyartist/daino-notes-public
- rubymamis 2y ago
  Hi there! Yes, I will switch to a more distinctive icon in the future once I can afford to hire a new designer. Multiplayer was quoting the correct reason. I also exeplained more about the timeline here: https://github.com/nuttyartist/notes/issues/690#issuecomment-2323045649 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.
mckravchyk 2y ago
I am not sure if it's worth it though. As you have pointed out, QML is buggy. Chromium's rendering engine is probably the most stable and polished GUI toolkit there is, not to mention a cross-platform one too. Throughout the last 10 years I only had to deal with 2 Chromium bugs and they were very minor. Well-written JavaScript is fast and the machines are getting faster every year. It does not take much real time computation to provide a UI for a desktop app, it's not a video game. And many of the those things that are real time, like the caret in the text editor or hover states are implemented in native code by the web browser, with no JS interaction. I agree though that a block editor is a little more real time than the average UI. The key word is well-written JavaScript. What is the most popular state management framework? Redux, possibly. What is the most inefficient state management framework? Also Redux. With Redux, if you have an app that displays a timer that updates every second, every subscription to any piece of the state throughout the entire app will trigger. I'm not sure if the app used Redux, but I used to use a time tracker app that would use 30% of my CPU when idle (I since moved to a CLI C++ solution and it is so much faster, but that does not mean a decent time tracker could not be built with web technologies). So if Redux is the most popular framework, you can see just how little the average web dev cares about writing apps that are not slow resource hogs. > Also, all web apps couldn't handle loading a very large text file (they were all hanging). Could it be that QT has some optimisation technique to not render all those lines out of view? I.e. if you have a huge file that can still be loaded to RAM, C++ won't sweat it, but is it actually getting all rendered at the same time in a savvy implementation, whether at the level of the app or the framework? Probably not. On the other hand, the textarea element or a contentEditable div just was not made for something like this. It could still be developed by implementing a custom element / component that loads the text dynamically while scrolling. If it's too much for JS to hold, it could use WASM or another process and pass it with IPC. It is definitely possible to write an Electron-based text editor that can open a 1 GB text file efficiently, it's just not out of the box experience and most people do not think there's a need for such a use case.
- rubymamis 2y ago
  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. [1] https://github.com/marktext/marktext https://github.com/marktext/marktext

oneeyedpigeon 2y ago

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.

rubymamis 2y ago
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.
- oneeyedpigeon 2y ago
  > Any text editor that struggles to load a large text file... Define "large". If it's bigger than the biggest text file I'll ever open, then I don't care. My point is that "efficient" code isn't absolutely necessary in many, many cases.
  - rubymamis 2y ago
    The problem with that mentality is that you start seeing inefficiencies spring everywhere (why loading Discord takes so long? Slack? etc, etc).
    - xcv123 2y ago
      It’s a third world mindset where we end up with the software equivalent of public defecation, living in squalor and filth.
      - kebokyo 2y ago
        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???)
    - jknoepfler 2y ago
      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")

nmstoker 2y ago

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!)

wiseowise 2y ago
You forgot constant 100MB updates, which are just one page refresh on web.
- what 2y ago
  And that one page refresh is probably also 100MB these days.
  - wiseowise 2y ago
    Uncompressed - maybe.

mvladic 2y ago

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.

rubymamis 2y ago
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).
- mvladic 2y ago
  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 https://pasteboard.co/uW2lPNSbL7f7.png [EDIT] Here is memory consumption of Daino Notes: https://pasteboard.co/z5pciLoh99i6.png https://pasteboard.co/z5pciLoh99i6.png
  - rubymamis 2y ago
    This is what I get with an *empty* vault: https://pasteboard.co/N3IdNUKUUNKq.png https://pasteboard.co/N3IdNUKUUNKq.png EDIT: Btw, I do have plans to cut RAM usage significantly in Daino Notes (I focused more on load time and responsiveness). But getting back to my point - I can do these optimizations because those RAM inefficiencies are a result of my code, not some abstractions I can't change.

darknavi 2y ago

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!

freehorse 2y ago
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)?
- tanewishly 2y ago
  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).
liontwist 2y ago
No. The motivation to make existing flows faster and do more of those at once is constant. It wasn’t initiated by bloated web apps

cosmic_cheese 2y ago

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).

la_fayette 2y ago
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...
- cosmic_cheese 2y ago
  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.
jkestner 2y ago
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.
- cosmic_cheese 2y ago
  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.

kebokyo 2y ago

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 ^-^

rubymamis 2y ago
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.

alternatex 2y ago

This app looks exactly like one I had used in the past. Took me a while to find it: https://www.notes-foss.com/ https://www.notes-foss.com/ Even the logo is almost identical. Is this the same project? Looks like two separate GitHub repos by the same author. Why two similar projects/websites?

Multiplayer 2y ago
I was wondering about that too. This is in the article linked to https://rubymamistvalove.com/block-editor https://rubymamistvalove.com/block-editor 7. The previous version of Daino Notes, called Notes is FOSS (free and open-source software) available at https://www.notes-foss.com/ https://www.notes-foss.com/ and the source code is available at https://github.com/nuttyartist/notes 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 https://github.com/nuttyartist/daino-notes-public
rubymamis 2y ago
Hi there! Yes, I will switch to a more distinctive icon in the future once I can afford to hire a new designer. Multiplayer was quoting the correct reason. I also exeplained more about the timeline here: https://github.com/nuttyartist/notes/issues/690#issuecomment-2323045649 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.

mckravchyk 2y ago

I am not sure if it's worth it though. As you have pointed out, QML is buggy. Chromium's rendering engine is probably the most stable and polished GUI toolkit there is, not to mention a cross-platform one too. Throughout the last 10 years I only had to deal with 2 Chromium bugs and they were very minor. Well-written JavaScript is fast and the machines are getting faster every year. It does not take much real time computation to provide a UI for a desktop app, it's not a video game. And many of the those things that are real time, like the caret in the text editor or hover states are implemented in native code by the web browser, with no JS interaction. I agree though that a block editor is a little more real time than the average UI. The key word is well-written JavaScript. What is the most popular state management framework? Redux, possibly. What is the most inefficient state management framework? Also Redux. With Redux, if you have an app that displays a timer that updates every second, every subscription to any piece of the state throughout the entire app will trigger. I'm not sure if the app used Redux, but I used to use a time tracker app that would use 30% of my CPU when idle (I since moved to a CLI C++ solution and it is so much faster, but that does not mean a decent time tracker could not be built with web technologies). So if Redux is the most popular framework, you can see just how little the average web dev cares about writing apps that are not slow resource hogs. > Also, all web apps couldn't handle loading a very large text file (they were all hanging). Could it be that QT has some optimisation technique to not render all those lines out of view? I.e. if you have a huge file that can still be loaded to RAM, C++ won't sweat it, but is it actually getting all rendered at the same time in a savvy implementation, whether at the level of the app or the framework? Probably not. On the other hand, the textarea element or a contentEditable div just was not made for something like this. It could still be developed by implementing a custom element / component that loads the text dynamically while scrolling. If it's too much for JS to hold, it could use WASM or another process and pass it with IPC. It is definitely possible to write an Electron-based text editor that can open a 1 GB text file efficiently, it's just not out of the box experience and most people do not think there's a need for such a use case.

rubymamis 2y ago
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. [1] https://github.com/marktext/marktext https://github.com/marktext/marktext