Why would you use a full web stack terminal emulator, over.. well a normal native and actually reasonably fast terminal emulator?
The trend is catching on, so maybe one day we can't even reach for a native email client because it will be unmaintained in favour of the hackable html webstack email client.
And I agree: Electron is horrible to deal with as an end-user. I've been using Vim for some time and then decided to use VS Code. The integrations, plugins, and everything else were awesome, but man the 3-4GB of RAM was just crazy. Despite the fact my machine has 16GB of RAM, I'm dealing with quite a few VMs and Docker containers locally, so actually 16GB isn't a lot.
What kind of files do you usually work with? Because I've currently got two 10000+ line python files open which are part of a project that is at least a million lines of code, and my VSCode instance is using less than 300 MB of RAM.
I've got three Go files open and looking at all the processes related to "Visual Studio Code.app", I see a residential memory footprint of 660MB. I'm using the latest version.
I've been using VSCode for years and it's been great, but I'm always looking for learning something new. I keep reading about Vim and last time I checked it seems SO complicated to use. I don't understand how it's so popular. Is it because it's blazing fast?
Vim isn't that popular with coders. Visual Studio and Notepad++ are the most popular across the board while Vim is preferred by Sysadmins according to this Stackoverflow survey from 2017 - https://insights.stackoverflow.com/survey/2017#technology-mo...
Notice how those numbers don't add up to 100%. They let you pick multiple answers on the survey. Therefore, I would consider Vim percentage even lower in reality since many people would specify it on a survey since they basically have to use it while working on a server.
Vim is used by a small but very loud minority. Don't listen to them - they're optimizing for the wrong thing (keeping your fingers on the home-row of the keyboard) at the expense of just about every other aspect of computing.
> Vim is used by a small but very loud minority. Don't listen to them - they're optimizing for the wrong thing (keeping your fingers on the home-row of the keyboard) at the expense of just about every other aspect of computing.
It would be good if you could unpack this some more and explain it in detail. If I'm wasting my time then I'd like to know why and consider whether or not I should change my practices.
The part of your statement that stands out to me is, "keeping your fingers on the home-row of the keyboard". I think this is called touch typing and I can assure you, I don't do it. I'm fast on the keyboard, but not as fast as a touch typist. I throw my fingers all over the place, actually.
Vim for me simply boils down to being a fast, simple, lightweight tool that offers years upon years of development in both the core of the product and plugins, themes, etc.
I'm not really sure how my choice of hammer can be optimising for the wrong thing if it does the same thing your hammer does and we're both productive?
It does not do the same thing as my hammer. Not even close. As a matter of fact, with Vim you cannot get even half the functionality of a good graphical IDE or even something like VSCode without drastically lowering your standards.
> Optimizing the wrong thing...at the expense of just about every other aspect of computing...
Vim lacks discoverability. That's the first major aspect of computing that Vim just completely throws out the window.
Speaking of windows - Vim also lacks integration with the rest of your graphical OS by default. You can't use your normal graphical file picker, you can't just drag files into Vim and you can't easily configure Vims activity to be reflected in the rest of your OS (in areas such as recently-edited-files and so on). Sure, you can get a graphical version of Vim, but now you have 2 problems - you have to configure different versions of Vim to use it the way you want to.
Even the mouse pointer a hallmark of modern computing, is largely useless in Vim!
Also, text-based configuration is throwing out another majorly useful aspect of computing: convenient and easy to access settings.
Anyway, if you enjoy editing text like it's 1976 - that's fine with me. Just don't try and tell me it's as good as my hammer because it simply is not.
I switched over the past month or so - started by using the vim plugin, and then eventually when ditched it and went with vim itself.
The scary thing for me, even after getting used to navigation, was the lack of it feeling like an IDE - autocomplete, compile on save, etc.
After installing some plugins - it's now wonderful and I enjoy it much more than VSCode.
There's a ton of little extra benefits you get from the switch besides the usual - for example, when you use a mouse, the time you spend navigating visually is kinda wasted. With a keyboard, that time is spent thinking about "what's the next parenthesis" or "what's inside these quotes" which turns idle time into something more useful like getting more familiar with the code.
> And somehow I find the VSCode's multi-cursor feature so much more convenient than Vim's macros.
That’s not an unpopular opinion, I suspect it’s because multiple cursors provide an extremely tight visual feedback loop (feedback after every action) as compared to macros where you kind of just shove actions into a black box and pray it works correctly for the next location you test it on
Using vim is like driving a car with manual transmission. The first time you do it, it seems so extremely complicated and you think you never would be able to be fast with it.
After some time you are got used to it and you think it‘s impossible to be fast without it.
Does editing text with the keyboard alone make sense to you? That's the gist of it, you use commands to manipulate text. It's hard to grok at first when you're only used to textarea style editors without modes.
It has a learning curve that'll take about 2-3 weeks to convert to muscle memory and become habit. Give it a shot. You'll learn something new and if it doesn't work out, VSCode will still be there :-)
"Electron is horrible to deal with as an end-user" - this is not reflective of your average user at all. Most people are just happy to have an app that looks, acts and feels native.
The average end-user has less than 4GB of RAM and would struggle to run electron apps at all. They would get frustrated with the computer being slow but would not know who to blame.
Aside from that, electron apps do not look, act or feel native.
It really depends, some work might necessitate 8GB+ but most really shouldn't and only do because the tools they use were built by developers with that much RAM.
At work I need my 16GB but that's because Visual Studio and the app I'm working on the most are memory pigs. Visual Studio 2017 doesn't really have any compelling features over 2005, but 2005 ran quite comfortably in 2GB, so with this piece of software alone I need a lot more memory for no gain.
At home in the other hand I have a fairly low end (and now 3 year old) dell laptop with 8GB of RAM, but with my current c project and DE (i3, riced way more than necessary) I'm using less than 2GB (with vim+unix as the IDE), so plenty to burn when required. This is a more productive environment too, I have a fully incremental build that will compile, run unit tests and run memory tests in the blink of an eye every time I save a file, so I'm getting much more feedback much quicker than I do with Visual Studio.
Devs on lower resource machines will also be dogfooding much better. If their apps are slow and bloated then they'll feel the pain their users will and be much more likely to address them. Windows 10 might have a start menu that didn't take several seconds to open if the developers weren't on top of the line surface pro's.
I can work productively on my 6yo notebook with 4 GB RAM, because a terminal, CLI tools, vim and a browser covers my needs. If I had to use Electron apps, I'd probably have to look into buying a new notebook, which is quite wasteful both on the money side and on the material resources side of things.
Some developers will probably need more than that because of the resource demands of their specific fields, but other than that, 640 KB ^W^W 4 GB should be enough for everyone.
I'm generally pretty pragmatic about using stuff that is convenient even if might not be too efficient, but I have to agree with most usage of Electron that I find. I'm using a MacBook that, while a few years old, still does almost everything well. It struggles when I have a few Electron-based apps open and that's just ridiculous. It also drastically impacts battery life.
It's reached a point where I use my iOS devices for Spotify and/or Slack just so my laptop can run whatever other crappy Electron app I need to use.
I find that VSCode is almost worth it, but that's perhaps one of the few exceptions (and I still go for Sublime Text most of the time).
Any app that needs to be persistent really has no business using Electron. It's a terrible waste.
Oh and as for the title on that article, Bunch of people took offence and no one got it but it's a reference to when Balmer called GPL/LGPL cancer and hippie culture.
Because it's pretty. Because you get state of the art Unicode decoding and support. Because you can get a terminal on Linux in a first class GUI system that's normalized across all major operating systems backed by billions of investment.
Because you get state of the art Unicode decoding and support.
What does this even mean? UTF-8 decoding is trivial. In fact it's designed to be simple: it's a prefix code that is self-synchronizing.
Rendering glyphs and composing characters is hard in comparison. But Cocoa, Qt, etc. have had great support for rendering unicode for ages now.
I have no recollection of having problems with iTerm, Terminal.app and many Linux terminals for rendering unicode the last decade or so. (Only with people setting their locales wrong.)
Most modern terminal emulators will give you all of this, in fairness, and it’s probably one of the simplest classes of programs for which to provide this!
Look several years into the future and what you could have there is electron being faster/lighter.
Being web-based gives you a standard way for fetching and displaying content. It's just a matter of time that the performance improves. Especially when many people are experimenting with it.
> maybe one day we can't even reach for a native email client because it will be unmaintained in favour of the hackable html webstack email client.
It's definitely possible, once the browser becomes the new OS.
Why spend the time and effort to do that, though? The amount of resources used to bring Electron into something reasonable could be better used elsewhere, advancing things that we don't already have.
That's what has been said for a while about Electron: it'll be optimized and less heavy. Most applications use Electron are just as heavy as they always has been, and where there are exceptions, it's more due to moving away from the Electron-stack and putting functionality in lower-level languages, or things like this where it uses only a few elements and defers to other rendering techniques.
Why would you use a full web stack terminal emulator, over.. well a normal native and actually reasonably fast terminal emulator?
The trend is catching on, so maybe one day we can't even reach for a native email client because it will be unmaintained in favour of the hackable html webstack email client.
Congratulations on reaching v2 tho!