4 ms·

Even if you are an elisp expert, emacs is by now quite inferior to VSCode for most things; what you get out of the box with vscode beats laborious customization

by patrec 7y ago

Even if you are an elisp expert, emacs is by now quite inferior to VSCode for most things; what you get out of the box with vscode beats laborious customization by expert hands in emacs 9 times out of 10. Emacs still does some fundamentals better (undo), can be used in a terminal and, if you avoid bloatware like spacemacs, also offers better performance. If one is willing to ignore the spyware and proprietary component aspects, vs code by now is a better choice even for most power users, IMO.

taeric 7y ago
I find this hard to believe. Not that you may like one over the other, but that one is superior. Getting used to tramp, magit, and eshell has effectively made it so I will be in Emacs forever. Adding in developer modes helps. Same for org. But really it is the seamless eshell ability to "cd /ssh:mycomputer/" and not with about reconnecting a terminal over and over that is something I don't want to leave.
- jasondclinton 7y ago
  That's also built into VSCode. The feature is called "Remote".
  - taeric 7y ago
    Not the same, from what I have seen. But, more pointedly, I have been doing this specific workflow for over the last decade. So, it is close. But most of Emacs "just works" over a tramp connection. From git to old and new code completion. And has done so for a long time.
agumonkey 7y ago
I tried typescript lsp in emacs (tide) and it gave me a lot for free (realtime type check, formatting). What else VSCode has ? nicer hints (dom based) and refactoring ? Genuinely curious. Also VSCode puts my poor laptop to its knees. Core i5 cannot handle few keystrokes in a row.. that was quite a shocker tbh.
- slightwinder 7y ago
  From my observation, the IDE-parts of VS Code are what put most computers to their knees. VS is very performant when acting like a regular text editor, even better than emacs in certain cases -_- But the moment the language-servers kick in and start analysing code and projects, the horror starts. It eats ram, cpu and grabs all attentions in can gain. Emacs can have those problems too, but there it's simpler to avoid those stuff. But to be fair, in VS Code to some degree you can deactivate it too it seems.
  - agumonkey 7y ago
    That's odd.. tsc doesn't seem to be the issue (I barely notice it on my machine). But I'm no internal dev so maybe.
agentultra 7y ago
> Even if you are an elisp expert, emacs is by now quite inferior to VSCode for most things I've been impressed that VSCode has managed to implement features Emacs has had for decades. One day it might catch up as long as MS keeps pumping millions into its development. For me though it's still not even close.
josteink 7y ago
> Even if you are an elisp expert, emacs is by now quite inferior to VSCode for most things Emacs' core strength is that you can shape Emacs to fit any need and workflows you may have. Secondly, you can also shape Emacs to have those workflows apply consistently across any domain you work with. With VSCode it's always the opposite: You need to adapt to whatever VSCode supports, and each domain needs to be handled differently. In my book, that will always make VSCode an inferior tool, even if what it does, it does indeed do excellently when considered in isolation.
m-n 7y ago
> emacs is by now quite inferior to VSCode for most things; what you get out of the box with vscode beats laborious customization by expert hands I find it interesting that this statement is hard for me, a daily emacs user who has loosely followed and lightly tried VSCode, to assess. VSCode's pair programming stuff looks like it could pull me over if I was on a team of people using it. From a language integration standpoint I'm probably hitting the same lsp server the VSCode user is, probably getting the same red squiggles from the same compiler and linter. Emacs has always been competent enough at general text editing. I enjoy using the Emacs git client Magit. It's not clear how to compare the amount of time I've spent configuring Emacs over the years to what I would have spent learning new environments if I had been swapping editors instead.
ska 7y ago
emacs is by now quite inferior to VSCode for most thing I think this statement illustrates a problem that comes up again and again in tool discussions. I'm pretty familiar with both environments. Objectively there are things that VSCode does very well that emacs is weak at, though you can hack about and get some sort of approximation usually. And there are things that emacs does very well that VScode is weak or nonexistent at, though you may be able to hack an approximation together. The problem with these discussions tends to be that people fall into camps where they consider other peoples must-have functionality to be irrelevant or unimportant, so "their" tool of choice "obviously" is "better". This is especially true of something like VScode vs. emacs, where the natural domain of VScode is much narrower than the natural domain of emacs.

by patrec 7y ago

taeric 7y ago

I find this hard to believe. Not that you may like one over the other, but that one is superior. Getting used to tramp, magit, and eshell has effectively made it so I will be in Emacs forever. Adding in developer modes helps. Same for org. But really it is the seamless eshell ability to "cd /ssh:mycomputer/" and not with about reconnecting a terminal over and over that is something I don't want to leave.

jasondclinton 7y ago
That's also built into VSCode. The feature is called "Remote".
- taeric 7y ago
  Not the same, from what I have seen. But, more pointedly, I have been doing this specific workflow for over the last decade. So, it is close. But most of Emacs "just works" over a tramp connection. From git to old and new code completion. And has done so for a long time.

agumonkey 7y ago

I tried typescript lsp in emacs (tide) and it gave me a lot for free (realtime type check, formatting). What else VSCode has ? nicer hints (dom based) and refactoring ? Genuinely curious. Also VSCode puts my poor laptop to its knees. Core i5 cannot handle few keystrokes in a row.. that was quite a shocker tbh.

slightwinder 7y ago
From my observation, the IDE-parts of VS Code are what put most computers to their knees. VS is very performant when acting like a regular text editor, even better than emacs in certain cases -_- But the moment the language-servers kick in and start analysing code and projects, the horror starts. It eats ram, cpu and grabs all attentions in can gain. Emacs can have those problems too, but there it's simpler to avoid those stuff. But to be fair, in VS Code to some degree you can deactivate it too it seems.
- agumonkey 7y ago
  That's odd.. tsc doesn't seem to be the issue (I barely notice it on my machine). But I'm no internal dev so maybe.

agentultra 7y ago

> Even if you are an elisp expert, emacs is by now quite inferior to VSCode for most things I've been impressed that VSCode has managed to implement features Emacs has had for decades. One day it might catch up as long as MS keeps pumping millions into its development. For me though it's still not even close.

josteink 7y ago

> Even if you are an elisp expert, emacs is by now quite inferior to VSCode for most things Emacs' core strength is that you can shape Emacs to fit any need and workflows you may have. Secondly, you can also shape Emacs to have those workflows apply consistently across any domain you work with. With VSCode it's always the opposite: You need to adapt to whatever VSCode supports, and each domain needs to be handled differently. In my book, that will always make VSCode an inferior tool, even if what it does, it does indeed do excellently when considered in isolation.

m-n 7y ago

> emacs is by now quite inferior to VSCode for most things; what you get out of the box with vscode beats laborious customization by expert hands I find it interesting that this statement is hard for me, a daily emacs user who has loosely followed and lightly tried VSCode, to assess. VSCode's pair programming stuff looks like it could pull me over if I was on a team of people using it. From a language integration standpoint I'm probably hitting the same lsp server the VSCode user is, probably getting the same red squiggles from the same compiler and linter. Emacs has always been competent enough at general text editing. I enjoy using the Emacs git client Magit. It's not clear how to compare the amount of time I've spent configuring Emacs over the years to what I would have spent learning new environments if I had been swapping editors instead.

ska 7y ago

emacs is by now quite inferior to VSCode for most thing I think this statement illustrates a problem that comes up again and again in tool discussions. I'm pretty familiar with both environments. Objectively there are things that VSCode does very well that emacs is weak at, though you can hack about and get some sort of approximation usually. And there are things that emacs does very well that VScode is weak or nonexistent at, though you may be able to hack an approximation together. The problem with these discussions tends to be that people fall into camps where they consider other peoples must-have functionality to be irrelevant or unimportant, so "their" tool of choice "obviously" is "better". This is especially true of something like VScode vs. emacs, where the natural domain of VScode is much narrower than the natural domain of emacs.