top | item 38873065

(no title)

noergl | 2 years ago

Its true, that a browser engine has a higher resource usage initially - it can easily hog 50-100MB without any content being loaded, but seriously, thats not much of a concern anymore these days. On the other hand it provides a great programming environment for web devs with many bells and whistles (which arguably might not even be needed for certain electron apps).

What concerns me more is what web devs actually do within that environment - it's almost like many devs have lost a basic sense of resource management, like memory comes for free, gets garbage collected anyway, so why should I care. Many electron apps are overly shiny in appearance, backed by tons of graphics and animations, but in fact are lousy managed under the hood. I am not quite sure if this is a direct effect of using a GC language, or if Javascript+HTML in particular makes it too easy to get quite far without some comprehension of inner works of the browser and the machine underneath. This is also a pain with modern webpages - I really dont get it, why a browser with 8 tabs opened can easily grow to several GBs after a while.

There are a few counter examples - electron apps that do heavy lifting while still being nice to your RAM and CPU. Sadly thats exceptional, not the common case. I tend to blame sloppy web devs here.

discuss

order

sawka|2 years ago

Wave uses electron for rendering, but a Golang backend for networking and heavy lifting. This gives Wave the ability to be cross platform and still efficient under the hood.

noergl|2 years ago

I totally understand choosing a HTML engine for output rendering, given the type of additional content you want to provide on top of normal terminal stuff. This would be really painful and expensive to implement & maintain in native GUI libs across several platforms. And vscode kinda shows, that it is possible to maintain a reasonable resource footprint while delivering a productive app with electron. They also achieve that with a relatively small team, which prolly would not have worked out with platform native solutions.

May I ask how you drive the terminal emulation? Is this done by xterm.js or a custom terminal emulator? I am asking, because xterm.js put quite some effort into optimizing things to be on par with other fast desktop terminal emulators, speed and memory-wise.