3 ms·

> That’s a drawback, not a plus. You can’t easily style the app with CSS the way you want it (VSCode, Obsidian). VSCode isn't really styled with CSS if you're

> That’s a drawback, not a plus. You can’t easily style the app with CSS the way you want it (VSCode, Obsidian). VSCode isn't really styled with CSS if you're a user. It's done by some json or yaml. This kind of hack is required: https://marketplace.visualstudio.com/items?itemName=be5invis.vscode-custom-css https://marketplace.visualstudio.com/items?itemName=be5invis..., and it's clearly not supported. You know what does have theming? Win32, GTK and QT. GTK even uses CSS for it. And unlike electron apps, when you change how a button looks in your GTK theme it affects all GTK apps rather than just the single electron app. > Nonsense. Obsidian is sitting at 115 MB right now, zero CPU. I just downloaded obsidian for the first time and launching it spawns 8(!) processes using a total of 827.3 MB of RAM. That's at the launch screen, before it's doing anything. Of course it's using no CPU when idle. That's basically the bare minimum bar for any application. It's well known that javascript is at least an order of magnitude slower than C. That's where it's wasting CPU, not when it's idle. > Define slow. Well to start off with, I can count the seconds obsidian takes to start up. Most native apps I have installed (other than browsers) start faster than I can reasonably react. Typing has noticeable lag, see: https://github.com/microsoft/vscode/issues/27378 https://github.com/microsoft/vscode/issues/27378 And this is on a workstation computer, I don't want to imagine how terrible the experience is on low-end hardware. > P.S. Thunderbird performs worse than ANY Electron app I’ve ever used, and I’ve been using Electron since its inception. Thunderbird isn't a native app either. Just like electron it's using a browser engine to show the UI.

cxr 1y ago
> It's well known that javascript is at least an order of magnitude slower than C If your base is base-2, yes. (It is well-understood that when you don't have your thumb on the scale—e.g. selecting, whether deliberately or carelessly, poor/pathological code to benchmark—that the expected slowdown factor of executing on a mainstream JS engine instead of AOT is in the neighborhood of 2x to 4x. Of course browsers JIT instead of AOT out of necessity—a constraint that doesn't apply to programs loaded from disk.)

cxr 1y ago

> It's well known that javascript is at least an order of magnitude slower than C If your base is base-2, yes. (It is well-understood that when you don't have your thumb on the scale—e.g. selecting, whether deliberately or carelessly, poor/pathological code to benchmark—that the expected slowdown factor of executing on a mainstream JS engine instead of AOT is in the neighborhood of 2x to 4x. Of course browsers JIT instead of AOT out of necessity—a constraint that doesn't apply to programs loaded from disk.)