Plz stop to worry. They only need that to help you around in the future, not to do any harm. Imagine you love their non-free offers later on, but don't know how to contact them to share credit card number - what a disruption on your end.
100%. What ppl often mixup is shell responsibility and the terminal itself. They are not really to blame for that, because their interactive terminal usage is mostly at a shell prompt.
Idk how they implemented things here, prolly by sidechanneling information to/from the terminal widget. Which is bad, they'd better use in-band terminal sequences for that, so the ecosystem of TEs and cmdline apps can eval the sequences and incorparate them, where they are useful (like the prompt marking OSC sequences...)
Very true, the Amish lifestyle alone debunks most of the telling above as heavily skewed. Implying certain society values and a way of thinking as natural or god-given, while in fact it only summarizes, whats currently pretty famous as western lifestyle.
> Maybe I am naive, but do Amish typically worry about money and about materialistic things?
Imho everyone worries about materialistic things to a certain degree, as a potatoe for example is very materialistic thing and we cannot eat virtual goods (yet). The potatoe example can also be used illustrate another aspect - all materialistic things will decay over time, thus naturally ppl would not hoard tons of goods beside what they need for themselves or for trading for other goods (which will also decay, so it makes no sense to overly hoard traded goods either).
This did not change much throughout history. Also there was only one outstanding exception to that naturalistic equilibrium - land. Even old bronze age societies already fought for fertile land as thats the very base to sustain life and furthermore it provides access to other resources like ore and such, that we learned to process into other goods. So history tells us - yes thats possible, also the Amish kinda still live in that tradition.
What really changed that almost-equilibrium was the invention of the modern money with the bank system. The big difference now is, that this virtual good "money" does not decay naturally (given the economy is stable). Instead the system even boost itself by constantly creating more money de-valuating itself. Most of us love to see the numbers increasing, because we tend to believe we can buy more things from that. But later we realize that goods just get a higher price tag instead (inflation), which furthr boost the money hunger.
Here we are - the big hoarding tendency in western societies has a lot to do with our money system.
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.
Wow, so much discomfort expressed here about slow scrolling. Are we all adopted to read tons of pages of terminal output flying by? I'm certainly not, and XOFF doesnt work anymore in many setups. Pagers for the rescue, though not working everywhere...
Is it just me or does the article read a lot like disguised paid promotion? I have no problem with paid promotions at all, but rather would like to see a disclaimer then.
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.
Keyboarders are prolly the ppl with fastest trained finger action on earth, be it on a computer keyboard or a music keyboard. In digital music production there is a magic threshold of 15-20ms latency for input signals - if a signal takes longer to process through your DSPs/computers lineup, any good musician will start to perceive the latency (btw thats more like an on/off phenomenon). Below that range we cannot detect any latency chance anymore, as our neural system is not made for higher time resolution (also the reason why 60 FPS gives us the illusion of a movie).
Typing latency on modern computers is really high compared to electronic or semi-digital typewriters of the 80s - those old machines had very little circuitry between the keypress and some output action, they were like hard-wired realtime machines to some degree.
On today's machines there are tons of buffers, clocks, context switches etc. to pass, with no realtime promises anymore (at least not on typical consumer OS). We really have a "long line" in our machines today.
Electron adds another buffer stack to this madness - the browser engine needs to get the PTY chunks somehow, which is often done with websockets as IPC. Which means put chunks into a http frame, send through network stack to the electron browser engine, decode there - and finally the terminal sees the data as input. A desktop TE does not have to go through that, it can simply write the PTY chunk to its data structures in the same process. Thats the real overhead happening for data IO intensive electron apps regarding input latency.