Then optimize what actually needs optimizing.
There’s no easy, generic answer on how to get a given electron app to “appear performant”. I say “appear”, because even vscode leverages various strategies to appear more performant than it might actually be in certain scenarios. I’m not saying this to bash vscode, but because techniques like “lazy loading” are simply a tool in the toolbox called “performance tuning”.
BTW: Not even using C++ will guarantee a performant application in the end, if the application topic itself is complex enough (e.g. video editors, DAWs, etc.) and one doesn’t pay attention to performance during development.
All it takes is to let a bunch of somewhat CPU intensive procedures pile up in an application and at some point it will feel sluggish in certain scenarios. Only way out of that is to measure where the actual bottlenecks are and then think about how one could get away with doing less (or doing less while a bunch of other things are going on and then do it when there’s more of an “idle” time), then make resp. changes to the codebase.
The “Where to start” section should be a “Not You” meme, with Electron in the middle square
deleted by creator
I’m curious what witchcraft Microsoft did with VSCode to make it so responsive and performant when no other electron app is.
deleted by creator
The term to look up is Monaco. That’s the secret sauce part of VS Code that made it faster but I don’t know enough about it to describe it well
Just looked it up a bit: https://microsoft.github.io/monaco-editor/
AFAIU,
monacois just about the editor part. So if an electron application doesn’t need an editor, this won’t really help to improve performance.Having gone through learning and developing with
electronmyself, this (and the referenced links) was a very helpful resource: https://www.electronjs.org/docs/latest/tutorial/performanceIn essence: “measure, measure, measure”.
Then optimize what actually needs optimizing. There’s no easy, generic answer on how to get a given electron app to “appear performant”. I say “appear”, because even
vscodeleverages various strategies to appear more performant than it might actually be in certain scenarios. I’m not saying this to bash vscode, but because techniques like “lazy loading” are simply a tool in the toolbox called “performance tuning”.BTW: Not even using C++ will guarantee a performant application in the end, if the application topic itself is complex enough (e.g. video editors, DAWs, etc.) and one doesn’t pay attention to performance during development.
All it takes is to let a bunch of somewhat CPU intensive procedures pile up in an application and at some point it will feel sluggish in certain scenarios. Only way out of that is to measure where the actual bottlenecks are and then think about how one could get away with doing less (or doing less while a bunch of other things are going on and then do it when there’s more of an “idle” time), then make resp. changes to the codebase.
Atom was a lot less responsive and generally laggier than VSCode though. I used to use Atom and was surprised how much more responsive VSCode was.
Didn’t they basically take all the slow bits and rewrite them in not electron?