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.
That also coincides with:
https://medium.com/@caspervonb/why-i-still-use-vim-67afd76b4...
And
https://github.com/jhallen/joes-sandbox/tree/master/editor-p...
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.
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.
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.
Correct indentation when pasting is a pain in my opinion.
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
:set paste
:)couldn't be easier my friend
Aside from that, electron apps do not look, act or feel native.
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.
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.
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.
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.)
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 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!