I tried the desktop app and was shocked at the performance. Conversations would take a full second to load, making rapidly switching intolerable. Kicking off a new task seems to hang for multiple seconds while I'm assuming the process spins up.
I wanted to try a disposable conversations per feature with git worktree integration workflow for an hour to see how it contrasted, but couldn't even make it ten minutes without bailing back to the terminal.
The more content is available, the more curation is important and IMO their algorithm currently does a good job at it.
Steam kept pushing a game as "recommended for you" with 99% negative reviews.
In what world would I possibly want to buy a game with a <1% approval rating?
> pretty solid
Huh?
it is
While there are legitimate/measurable performance and resource issues to discuss regarding Electron, this kind of hyperbole just doesn't help.
I mean, look: the most complicated, stateful and involved UIs most of the people commenting in this thread are going to use (are going to ever use, likey) are web stack apps. I'll name some obvious ones, though there are other candidates. In order of increasing complexity:
1. Gmail
2. VSCode
3. www.amazon.com (this one is just shockingly big if you think about it)
If your client machine can handle those (and obviously all client machines can handle those), it's not going to sweat over a comparatively simple Electron app for talking to an LLM.
Basically: the war is over, folks. HTML won. And with the advent of AI and the sunsetting of complicated single-user apps, it's time to pack up the equipment and move on to the next fight.
From the person you're responding to:
> I would guess a moderate amount of performance engineering effort could solve the problem without switching stacks or a major rewrite.
Pretty clearly they're not saying that this is a necessary property of Electron.
Maybe you can give ones of competing ones of comparable complexity that are clearly better?
Again, I'm just making a point from existence proof. VSCode wiped the floor with competing IDEs. GMail pushed its whole industry to near extinction, and (again, just to call this out explicitly) Amazon has shipped what I genuinely believe to be the single most complicated unified user experience in human history and made it run on literally everything.
People can yell and downvote all they want, but I just don't see it changing anything. Native app development is just dead. There really are only two major exceptions:
1. Gaming. Because the platform vendors (NVIDIA and Microsoft) don't expose the needed hardware APIs in a portable sense, mostly deliberately.
2. iOS. Because the platform vendor expressly and explicitly disallows unapproved web technologies, very deliberately, in a transparent attempt to avoid exactly the extinction I'm citing above.
It's over, sorry.
Thunderbird is a fully-featured mail app and much more performant than Gmail. Neovim has more or less the same feature set as VSCode and its performance is incomparably better.
TB is great and I use it every day. An argument for it from a performance standpoint is ridiculous on its face. Put 10G of mail in the Inbox and come back to me with measurements. GMail laughs at mere gigabytes.
Using market success to excuse poor UX is pointless.
OK, I shop at Amazon, am a Prime member, all that stuff, but their web site is horrible. Just pathetic.
I appreciate that they are huge and sell a pretty much incomprehensible number of things, and that what it takes behind the scenes to make it all happen is hugely complex and very impressive on its own terms, but still: the web site is horrible.
Try enabling 10k lines of scrollback buffer in vscode and print 20k lines.
In any case, what I personally find more problematic than just slowness is electron apps interacting weirdly with my Nvidia linux graphics drivers, in such a way that it causes the app to display nothing or display weird artifacts or crash with hard-to-debug error messages. It's possible that this is actually Nvidia's fault for having shitty drivers, I'm not sure; but in any case I definitely notice it more often with electron apps than native ones.
Anyway one of the things I hope that AI can do is make it easier for people to write apps that use the native graphics stack instead of electron.
Sigh. Beyond the deeply unserious hyperbole, this is a no-true-scotsman. Yes, you can use native APIs in Electron. They can even help. That's not remotely an argument for not using Electron.
> the in-editor terminal makes use of WebGL
Right, because clearly the Electron-provided browser environment was insufficient and needed to be escaped by using... a browser API instead?
Again, folks, the argument here is from existence. If the browser stack is insufficient for developing UIs in the modern world, then why is it winning so terrifyingly?
Gen X and Boomers strangely enough managed to write portable native code, across multiple hardware architectures, operating systems and language toolchains.
As is an insurmountable challenge apparently, to master Web UI delivery from system services, daemons to the default browser like UNIX administration tooling.
If McDonald’s hamburgers taste like warmed-over shit, why are they the most popular in the world?
Setting that aside, I think you learned the wrong lesson here. There's no fight. Performance comes from app architecture engineering more than the underlying tools. Building on the trash fire that is the current JS ecosystem may make it harder, true, but apps like VS Code, Discord, Slack, etc show that with enough effort a team can use those tools to deliver something with relatively much better performance. The underlying browser engines are quite sophisticated and very efficient for what they are asked to do, it's just a question of good engineering on top of that. Based on the observable behavior I'm guessing the Claude app is doing something like triggering reflow for the entire chat thread every time they append a few characters to the chat. Totally avoidable.
The big reason web tech is ubiquitous is it has the best properties for distribution. That may last a little while or a long time, but there is no fundamental reason why it's more durable than say Win32 and MFC.