4 ms·

I highly disagree. Web apps are notoriously slow. I'm developing a Notion alternative in Qt C++ that load large text files on my 2017 MacBook Air while on my fr

I highly disagree. Web apps are notoriously slow. I'm developing a Notion alternative in Qt C++ that load large text files on my 2017 MacBook Air while on my friend's 2021 M1 Pro, the fastest web based block editor (MarkText) takes around 11x longer to load the same file. So, essentialy, my 2017 MacBook Air is FASTER just due to more efficient software. Why are we allowing this degradation of software? Each time I think about opening Spotify (Electron) on my desktop, I dread the loading time and the RAM it would use. For very simple apps, frameworks like Tauri should do the job. But for complex applications, let's please not lose our benchmarking standards. My app: https://www.get-plume.com/ https://www.get-plume.com/

szasamasa 3y ago
you should not generalize cherry picking examples does not mean the web MUST be slow, maybe the web apps were programmed badly... I can write even worse native apps than these web apps and it will not prove anything did you ever try compile c++ code to webassembly and check out the performance "degradation"? it still can be true that for this special task, a native app is the better choice and people would buy it from the App Store even if 30% more expensive I mean nobody will and wants to take away the choice of using native tech. The degradation is on sooo many levels is not a necessity or consequense. Web apps are not replacements, they are a choice, an addition. I really do not understan these kinds of comments that frame web apps as a compulsory security nightmare or replacing superior native with inferior web... Safari stays, native stays, you and every developer can choose. It may move better developers towards the web stack but then faster and better web apps follow. They will make use of web capabilities and technologies (like better js, multi core, web assemly, optimizations etc). Chill! No self respecting company will publish inferior web apps if native is so much better in their special use case!
- rubymamis 3y ago
  > Chill! No self respecting company will publish inferior web apps if native is so much better in their special use case! Slack, Spotify, Teams, Notion... Why do I need to buy the top of the line M3 MacBook Pro to run these apps with a sane performance? What tells you that these same bloated apps won't be even more bloated in the future? There's something fundamentally broken with web apps. It's no wonder the Zed team (that originally created Electron for Atom) has moved completely away from it to develop their own native GUI toolkit.
  - fauigerzigerk 3y ago
    >There's something fundamentally broken with web apps. While the web stack may be somewhat slower in the extreme, I think the reason why big bloated apps like Teams are slow is not down to technology at all. I think the causality works the other way around. Big corporations with large teams that are systemically incapable of paying attention to detail (including performance) choose web technologies because web tech allows them to churn out features faster and gain access to a large pool of easily replaceable developers.
    - rubymamis 3y ago
      That's all very well known. The fact remains that it's just too easy to write slow and resource hog apps (even when you really don't intend to) using web technologies. There are just countless examples. I think everyone can tell the difference when they run an Electron app or a native app. The only exception of late seems to be Notion Calendar (used to be Cron). It's an Electron app but runs pretty smoothly.
      - fauigerzigerk 3y ago
        I think given a certain limited amount of resouces, creating a single web based app will often result in far higher quality than spreading the same resources across four different native apps.
      - szasamasa 3y ago
        I agree that web is currently 99% terrible But I blame web "designers" not web tech because it has become so powerful on so many levels my favourite examples are: - V8 performance (but gecko and webkit engineers are great too) - webassembly - modular modern js - offline websites with service worker caching (I mean I see practically 0 websites making use of it... you download an asset, you cache it, even offline available... how many news sites let you read offline?) - web crypto - 100s of others https://developer.chrome.com/docs/capabilities/fugu-showcase https://developer.chrome.com/docs/capabilities/fugu-showcase
  - wiseowise 3y ago
wiseowise 3y ago
> I'm developing a Notion alternative in Qt C++ ...which is not native to the platform, so you're in a way proving my point. Unless I become professional writer, or develop an OCD about typing latency - standard browser and Electron apps (looking at you VSCode and Logseq) are good enough for my use cases. And don't misunderstand me, there's absolutely a place for native applications - when performance matters. Millions of CRUDs on app store are not one them.
- rubymamis 3y ago
  > ...which is not native to the platform "The Qt Rendering Hardware Interface (RHI) translates 3D graphics call from Qt applications to the available graphics APIs on the target platform."[1] [1] https://doc.qt.io/qt-6/topics-graphics.html https://doc.qt.io/qt-6/topics-graphics.html
  - wiseowise 3y ago
    That’s irrelevant, they’re not using native widgets.
    - rubymamis 3y ago
      It's not because it means a Qt app can match a native application in performance (actually, my note-taking app is way faster than Apple's Notes). In terms of styling, yes, the styling of Qt Quick Controls is not quite good as to resemble native widgets, and I had to do a lot of work to get my own styles right. At least on macOS, I believe my app looks and behave like a native app (with 2 exceptions that I aim to solve soon).
      - wiseowise 3y ago
        > Qt app can match a native application in performance Correct. That doesn’t make it a native application, still.
        rubymamis 3y ago
mmcnl 3y ago
Nitpicking, but Tauri is still in beta for mobile, Capacitor is the incumbent. But these frameworks solely exist because the mobile OS doesn't provide sufficient access to native APIs. If PWAs would be supported properly, and the standard would evolve, then we wouldn't need Tauri or Capacitor. The web-to-native bridge would be part of the web engine that is installed on the OS. The reason we allow these native bridges (Capacitor on Mobile, Electron on Desktop) is because they allow you to develop the same app once for all platforms. Without them you would need 3x the resources for each desktop app (Windows, Linux, Desktop) and 2x the resources for each mobile app (Android, iOS). Linux would be dead in the water without Electron. It's the reason we have Spotify, Slack, Discord, VS Code, etc. on Linux.

szasamasa 3y ago

you should not generalize cherry picking examples does not mean the web MUST be slow, maybe the web apps were programmed badly... I can write even worse native apps than these web apps and it will not prove anything did you ever try compile c++ code to webassembly and check out the performance "degradation"? it still can be true that for this special task, a native app is the better choice and people would buy it from the App Store even if 30% more expensive I mean nobody will and wants to take away the choice of using native tech. The degradation is on sooo many levels is not a necessity or consequense. Web apps are not replacements, they are a choice, an addition. I really do not understan these kinds of comments that frame web apps as a compulsory security nightmare or replacing superior native with inferior web... Safari stays, native stays, you and every developer can choose. It may move better developers towards the web stack but then faster and better web apps follow. They will make use of web capabilities and technologies (like better js, multi core, web assemly, optimizations etc). Chill! No self respecting company will publish inferior web apps if native is so much better in their special use case!

rubymamis 3y ago
> Chill! No self respecting company will publish inferior web apps if native is so much better in their special use case! Slack, Spotify, Teams, Notion... Why do I need to buy the top of the line M3 MacBook Pro to run these apps with a sane performance? What tells you that these same bloated apps won't be even more bloated in the future? There's something fundamentally broken with web apps. It's no wonder the Zed team (that originally created Electron for Atom) has moved completely away from it to develop their own native GUI toolkit.
- fauigerzigerk 3y ago
  >There's something fundamentally broken with web apps. While the web stack may be somewhat slower in the extreme, I think the reason why big bloated apps like Teams are slow is not down to technology at all. I think the causality works the other way around. Big corporations with large teams that are systemically incapable of paying attention to detail (including performance) choose web technologies because web tech allows them to churn out features faster and gain access to a large pool of easily replaceable developers.
  - rubymamis 3y ago
    That's all very well known. The fact remains that it's just too easy to write slow and resource hog apps (even when you really don't intend to) using web technologies. There are just countless examples. I think everyone can tell the difference when they run an Electron app or a native app. The only exception of late seems to be Notion Calendar (used to be Cron). It's an Electron app but runs pretty smoothly.
    - fauigerzigerk 3y ago
      I think given a certain limited amount of resouces, creating a single web based app will often result in far higher quality than spreading the same resources across four different native apps.
    - szasamasa 3y ago
      I agree that web is currently 99% terrible But I blame web "designers" not web tech because it has become so powerful on so many levels my favourite examples are: - V8 performance (but gecko and webkit engineers are great too) - webassembly - modular modern js - offline websites with service worker caching (I mean I see practically 0 websites making use of it... you download an asset, you cache it, even offline available... how many news sites let you read offline?) - web crypto - 100s of others https://developer.chrome.com/docs/capabilities/fugu-showcase https://developer.chrome.com/docs/capabilities/fugu-showcase
- wiseowise 3y ago

wiseowise 3y ago

> I'm developing a Notion alternative in Qt C++ ...which is not native to the platform, so you're in a way proving my point. Unless I become professional writer, or develop an OCD about typing latency - standard browser and Electron apps (looking at you VSCode and Logseq) are good enough for my use cases. And don't misunderstand me, there's absolutely a place for native applications - when performance matters. Millions of CRUDs on app store are not one them.

rubymamis 3y ago
> ...which is not native to the platform "The Qt Rendering Hardware Interface (RHI) translates 3D graphics call from Qt applications to the available graphics APIs on the target platform."[1] [1] https://doc.qt.io/qt-6/topics-graphics.html https://doc.qt.io/qt-6/topics-graphics.html
- wiseowise 3y ago
  That’s irrelevant, they’re not using native widgets.
  - rubymamis 3y ago
    It's not because it means a Qt app can match a native application in performance (actually, my note-taking app is way faster than Apple's Notes). In terms of styling, yes, the styling of Qt Quick Controls is not quite good as to resemble native widgets, and I had to do a lot of work to get my own styles right. At least on macOS, I believe my app looks and behave like a native app (with 2 exceptions that I aim to solve soon).
    - wiseowise 3y ago
      > Qt app can match a native application in performance Correct. That doesn’t make it a native application, still.
      - rubymamis 3y ago

mmcnl 3y ago

Nitpicking, but Tauri is still in beta for mobile, Capacitor is the incumbent. But these frameworks solely exist because the mobile OS doesn't provide sufficient access to native APIs. If PWAs would be supported properly, and the standard would evolve, then we wouldn't need Tauri or Capacitor. The web-to-native bridge would be part of the web engine that is installed on the OS. The reason we allow these native bridges (Capacitor on Mobile, Electron on Desktop) is because they allow you to develop the same app once for all platforms. Without them you would need 3x the resources for each desktop app (Windows, Linux, Desktop) and 2x the resources for each mobile app (Android, iOS). Linux would be dead in the water without Electron. It's the reason we have Spotify, Slack, Discord, VS Code, etc. on Linux.