by kirillrogovoy on 11/9/21, 8:45 AM with 90 comments
VSCode is clearly a code editor. Emacs is used by many as an operating system / UI framework / app platform.
Emacs's adepts have been using it for email, calendars, process management, taking notes, terminal GUI, coding (dah), and some even browse the web without leaving it.
I've been using Orgmode (+ org-roam) for a couple of years already and no other software can replace it for me.
I have huge respect for this almost 40 years old piece of technology and all the people keeping it alive and active. I love the hacker community around it.
All that said, I mostly hate using Emacs. It's slow (I have i7 with 4 cores and 32Gb of RAM). Emacs Lisp drives me crazy. I constantly mis-press some weird key chord and enter a state where I can't do anything unless I restart the app. It's hard for me to find docs on how to integrate with various parts of the UI, so I mostly rely on reading the source code of different extensions. Two years in, I still can't read Emacs Lisp well.
I feel unproductive when changing how Emacs behaves. And I've been coding for 7+ years, including functional programming.
---
Now, I've been using VSCode for quite a while (after 4 years of Vim).
I've noticed that, on the surface, VSCode extensions can do everything Emacs does.
If you think about it, VSCode is a UI framework too — there's an API for all the UI components such as the sidebar or the text editor area itself; and you can also add your custom commands that can be triggered in a number of ways.
Which means you can actually implement things like Orgmode in VSCode.
Also: - You are coding using the most popular ecosystem in the world (Web). - The community is larger than one of Emacs. - The docs are much friendlier.
---
From what I understand, the main difference is that with Emacs you can start hacking any part of the environment right from the start. It's designed to be played with.
With VSCode, you just have a strictly defined JSON config file, and everything else requires you to work with "extensions" which sounds like something less accessible and "oh, that sounds grand, I'm not sure how deep that rabbit hole is". You can't just open a file, define a new hook or whatever and now your VSCode behaves differently.
But are there any other reasons, technical or otherwise, why people don't seem to use VSCode for things beyond editing code?
If only you could open some special file, write some Typescript, and modify anything about VSCode in a dirty hacker manner, would you use it?
by qsort on 11/9/21, 9:09 AM
Master Foo nodded.
The novice continued: “Isn't it also the Unix way that the wheel should not be reinvented?”
Master Foo nodded again.
“Why, then, are there several tools with similar capabilities in text processing: sed, awk and Perl? With which one can I best practice the Unix way?”
Master Foo asked the novice: “If you have a text file, what tool would you use to produce a copy with a few words in it replaced by strings of your choosing?”
The novice frowned and said: “Perl's regexps would be excessive for so simple a task. I do not know awk, and I have been writing sed scripts in the last few weeks. As I have some experience with sed, at the moment I would prefer it. But if the job only needed to be done once rather than repeatedly, a text editor would suffice.”
Master Foo nodded and replied: “When you are hungry, eat; when you are thirsty, drink; when you are tired, sleep.”
Upon hearing this, the novice was enlightened.
EDIT - source: http://www.catb.org/esr/writings/unix-koans/shell-tools.html
by kangaroopouch on 11/9/21, 9:25 AM
The best answer I've seen to this question is https://www.murilopereira.com/the-values-of-emacs-the-neovim...
Amongst other things, it lists different values that each tool prioritizes, and how "Core values are self-reinforcing. They attract like-minded people, who will then defend them."
Emacs: Extensibility, Freedom, Introspectability, Keyboard centrism, Stability, Text centrism.
VSCode: Approachability, Integration, Maintainability, Progressiveness, Velocity.
That is, even if VS Code achieves technical parity with Emacs (wrt introspectibility/extensibility), its community might not prioritize using VS Code for things beyond editing code.
Or maybe it will. These things are difficult to predict!
by rglullis on 11/9/21, 9:12 AM
C-g
> You can't just open a file, define a new hook or whatever and now your VSCode behaves differently.
By that definition of extensibility, even gEdit "could be the new Emacs".
> the main difference is that with Emacs you can start hacking any part of the environment right from the start. It's designed to be played with.
You just answered your own question.
by u-rate on 11/9/21, 9:39 AM
by vbezhenar on 11/9/21, 9:13 AM
by dvh on 11/9/21, 10:05 AM
by jrib on 11/9/21, 9:23 AM
I think you nailed the big difference right there.
I mostly use vim but configuring the editor is a gateway to programming new functionality. You start small by defining a function bound to a key. Then you start exploring more of the api and gluing functions together. Eventually you refactor it a bit if you find it worth sharing.
I've only used emacs for a bit and I understand it has more of that "OS" aspect to it where people stay in their editor for a lot of tasks that are more than just"edit text". But like vim, users can tweak functionality in a relatively accessible and not overly-limiting way. And they are introduced to this early on.
I've used vs code. It's pretty. It works well. I have the impression that to change functionality I either have to hope it already exists as a toggle somewhere or go read how to write a full vs code extension. At least in my experience, it lacks the incremental aspect described above.
by kryptiskt on 11/9/21, 10:00 AM
Practically speaking, now that VS Code extensions can present web views, they can be arbitrarily powerful as long as they don't need to mess with the editor's internals that is not exposed by the extension API. So making things like a mail reader or pixel editor is fine. Rearranging the whole UI is not.
by mih on 11/9/21, 9:48 AM
Sure VSCode has its strengths and as an IDE easier to get started and work with, especially for newcomers. That said, the fact that it requires a desktop environment to operate in means there are niches that Emacs fills which VSCode currently cannot.
by alfiedotwtf on 11/9/21, 10:24 AM
99% of my time in front of the computer is spent in an editor (for both work and play). Having invested and continuing to invest so much time and effort in my tools and my environment, I would hate for something so fundamental in my life to not be free as in freedom:
"Microsoft's releases of Visual Studio Code are licensed
under this not-FLOSS license and contain telemetry/tracking"
https://code.visualstudio.com/license
by rvieira on 11/9/21, 2:53 PM
org-mode was my "gateway". I always wanted to learn Lisp, so I guess that was a plus too (I'm aware Elisp is not the best way to learn it). </disclaimer>
I don't know if VSCode will be the new Emacs but I doubt it. It will be, and already is, hugely more popular, and I'm glad it is. I believe in people having a good choice of open source tools and using whatever they feel better using.
What I like about Emacs is that you are given vanilla editor and you have to make it "your own". Now some people like this, some people hate this. Some people like to quickly download a VSCode extension and just get on with it.
I also like how Emacs' "things" can have a synergy. I just recently setup my blog to be written in org with Jupyter-like code examples, pre-processing and exporting. This involves a few packages but they worked together nicely, It's all text after all.
I don't know how to do that in VSCode (parsing using an extension, processing the result using another, exporting with yet another, etc). Perhaps it's simple, but I guess that if you are doing this, then between VSCode and Emacs, they both require a reasonable amount of work.
Regarding speed I'm using Emacs 28 native and I feel it's a massive improvement.
by thom on 11/9/21, 12:03 PM
by peterkelly on 11/9/21, 10:42 AM
> It's slow (I have i7 with 4 cores and 32Gb of RAM)
Something is wrong here. I can't remember the exact specs of the machine when I first started using it but it might have been as low as a 486 with 1 core and 32Mb of RAM.
by bjackman on 11/9/21, 10:13 AM
- It's really slow (noticable keyboard latency) and this bums me out.
- Haven't yet got into a proper VSCode git plugin but I'm pretty sure when I do I'll still miss Magit.
- The only place where I really miss Emacs' ultra flexibility is the window management. VSCode's model is pretty simplistic and seems dumb to me.
On the whole with my hatred of ELisp I think the relative inflexibility of VSCode is a wash, especially when you factor in how easy it was to get started. But it does make me sad to know if I stick with it I'll never escape the slowness.
by searene on 11/9/21, 9:42 AM
by _huayra_ on 11/10/21, 2:28 AM
The Emacs community, although perhaps lacking the sheer number of vscode users, is incredible. There are folks like Henrik Lissner who are almost pathologically addicted to making Emacs awesome, not to mention the myriad other folks who escape my mind at the moment.
The vscode community is mostly full of valiant, short-lived one-person projects and things maintained by large companies. I must admit that for working with Azure, I do switch to vscode because the integration (e.g. for the ARM templates) is awesome.
Emacs has the better community for the long run (and has the track record to prove it), but I do wonder about the technical limitations of Emacs, mostly revolving around the quirkiness of elisp that Emacs is mostly married to at the moment. You can listen to Henrik discuss this here [0]. I experience some hickups when using Doom emacs, mostly when projects get big and the tooltip stuff has to render many options. Still, this is well worth it for the amazing benefits of Org mode, Org Roam, Org-ref, etc.
by loxias on 11/9/21, 10:49 AM
I want to process and respond to this question, but I can't get past:
> It's slow (I have i7 with 4 cores and 32Gb of RAM)...
Consider that you must be doing something deeply wrong? I have a broadwell (2015) i7, 2 cores, 16GB of ram (8 of which is reserved), and Emacs is quite fast.
I tried to use VSCode once, around when it came out. It was a pathetic joke. Once you manage to stop laughing at the concept of using an editor, hosted in a webbrowser, written in javascript, you were able to enjoy exactly the performance you would expect from such an "application".
I couldn't type more than a few lines before the high latency, and the fact that I could feel my CPU heating up, gave me all the info I needed.
What's VSCode for?? I don't do much (any) UI work, so I'd believe you if that's its strength, but.. an editor???? I doubt it!
Having noticeable latency between keystrokes and requiring huge amounts of system resources make it kinda ... hard to take seriously.
by kortex on 11/9/21, 9:31 AM
Some people like customizing the heck out of their editor, getting super deep into metaprogramming and macros. Personally, I don't really have time for that. I want an editor which does 95% of what I want out of the box. For me, that's pycharm, but vscode is really nice as well. It feels lighter than pycharm.
You can usually configure all kinds of macros and plugins for IDEs. Like you said, it's a bit of a rabbit hole, but so is emacs lisp.
by truly on 11/9/21, 9:35 AM
On the joke side, Emacs also started out as a resource hungry beast, just like VS Code now.
Emacs feels to me a bit more extensible, and does a number of things better than VS Code (e.g., can cut rectangles, better shortcuts, regexp support, and others).
by taylodl on 11/9/21, 8:11 PM
VSCode has become my go-to for everything else.
As with most things it's not a question of emacs or VSCode, it's both - and the knowledge of when to use each.
by eb0la on 11/9/21, 12:10 PM
I usually start working on VSCode, but I run test from the terminal (python and solidity), and half of my git commits are from the command line.
When a test breaks, I usually use vim to fix it since I am already on the terminal.
by orionblastar on 11/9/21, 10:08 AM
by nodejs_rulez_1 on 11/9/21, 9:24 AM
by doniphon on 11/9/21, 10:09 AM
probably the best thing that come from Microsoft in decades
update: has momentum, a huge marketing budget (helps) and the cost of entry way lower than emacs' one (typescript ecosystem a fair bit less exotic than lisps').
performance is OK, really. i remember more than 20yrs ago when one had to use vi, micro emacs and lesser options because emacs was then the resource hog. at same age / stage vscode is way less hungry than emacs then...
by joeman1000 on 11/9/21, 11:14 PM
by a-b on 11/9/21, 9:59 AM
by havkd on 11/9/21, 9:53 AM
On the other hand vscode is first class, or almost.
by throwawayswede on 11/9/21, 10:17 AM
What the fuck does "the new emacs" mean?
by vfclists on 11/9/21, 10:54 AM
Elisp is antisocial and restricting because Stallman fought against the use of modules and they only become available in with Emacs 25. As for FFI Emacs developers are still dragging their feet inspite of other developers an Emacs developer actually having done the work. All the core developers need to do is to integrate it.
As for question itself, yes VSCode can be the new Emacs if your workstations are powerful enough, Apple M1 Pro Max or whatever.