> While both of these [Emacs and vim] can probably compete with Pulsar in number of extensions available and the amount of customizations and keyboard shortcuts, neither of them have a graphical user interface, and they are completely incapable of doing things like showing images or, for example, a Markdown preview (which by the way you can open in Pulsar by pressing Ctrl+Shift+M).
Claiming that Emacs has limited customization, no GUi, and can't display images tells me they've not used Emacs and probably shouldn't be making any claims without fact checking them. Really colors how I read the rest of their pitch.
Thank you. I just got around to reading the article and was horrified to find him disparaging vim, and emacs, while being completely wrong about both. Very soured.
This article can be summarized as "I use Pulsar because that's what I'm used too" combined with incorrect "facts" about other editors and some shit slinging at them.
Nothing they describe about Pulsar is unique at all, apart from the slow loading time I guess. If you wanted time to load up HN while your editor loads, maybe Pulsar is right for you!
Everything they describe there is fairly basic functionality that is available in pretty much every popular(and niche) editor at this point. The "How to code 10x faster than an average programmer" article linked also describes basic things; hot reloading and real time linting.
Use whatever editor you want, write about whatever editor you want, but at least do some research about other editors before confidently stating your favorite one is the best along with incorrect facts about others.
This reminds me of the blub paradox[0] except for editors instead of programming languages.
The author asserts that Emacs uses modes (it doesn't by default), does not have a GUI (it does), and cannot display images (it can). Not that this detracts from the point they should have made, which is that it has a steeper learning curve than Pulsar.
Clearly the author has never used Emacs, because they have confused Emacs "modes" (which are more like features that get turned on and off) with modal editing (like vim).
There are also plenty of markdown preview packages available for both Vim and Emacs (even live preview). Emacs has had preview-latex since before Atom even existed.
Also, as a vim user, modes are completely fine and I do not believe that modes slow me down. I’m not sure why the author is so insistent on this point.
Intuitively having to press more keys in order to accomplish an action sounds like it would be slower than a single key combo. Of course this fails to account for the fact that pressing something like Option+Fn+Backspace to forward-delete a word is far more awkward than f-d and therefore takes longer.
I hate to defend the author since it's clear the author has some significant knowledge gaps, but Emacs very much uses modes by default.
What is a mode? It is when key presses do different things depending on the mode (e.g., normal vs insert mode in vi). Emacs very much has modes, by default, and many more of them than Vim (or vi), including multiple vi-like modes. Emacs is so much more modal that it is trivial to implement vi/Vim modes in Emacs (and notably the reverse is not true).
Just because Emacs does not enable the exact three or four mode key binding sets that vi/Vim does on an out-of-the-box startup does not make Emacs "not modal". vi/Vim does not own the concept of "modes" by implementing three or four very specific mode key binding sets; lots of software implement modes and to put it somewhat confrontationally, Vim users tend to be a bit full of themselves thinking that their modes are super special (and I say that as a former Vim user; I still occasionally use vi, but not as a primary editor).
> I know several world class programmers, and interestingly, the commonality among them is that they all seem to use Vim as their code editor. Many people I know who think of themselves as world class programmers use Emacs.
Considering how confidently utterly wrong the author of this article seems to be about Vim and to an even more substantial degree Emacs, I'm not inclined to put much stock in this as an insight.
I think it was just a bad joke rather than an insight. As a neovim user myself, I personally know a couple of extremely oustanding programmers who use emacs.
I don't really use Pulsar as its heavy weight. But I'm glad for every legit open source project that pushes editing forward be it NeoVim, Emacs etc. The mono culture of do everything in vsCode under MS's thumb is not a great idea. Microsoft has proven itself untrustworthy time and time again.
I don’t consider VSCode the best code editor, but I will say: it is the best thing to happen to code editing for quite some time. LSP has made it much easier to create an editor, or add support for niche languages. Even for big names like vim, which have always had a deep bench of plugins, it’s amazing to see this stuff “just work” now which used to require constant fussing (and the occasional blood sacrifice to tim pope).
Ditto for the Atom folks with Tree-Sitter. You see both these technologies show up in neovim, emacs, hip new kids like helix…like: yes, input latency or memory usage are important for a text editor—but it’s a bummer when people’s takeaways from these two are “lol electron, trash corporate engineering”, when the teams behind them were out-implementing the even-more-open-source world on important things like this.
As for the closed-source world…Jetbrains has been basically unchallenged in the general-purpose IDE game for ages. It’s exciting to see what they’ll do now with a fire lit under their butts.
I don't understand what the author bases his claim on. Pulsar is based on Electron, so it isn't going to be faster than VS Code. And taking a quick look, it's way behind VS Code in terms of features. It doesn't even have a built-in terminal.
If you want to use anything other than VS Code as an editor, why not pick something based on native technologies? What's the point of picking an editor that takes 6-8 seconds to start and still is way behind VS Code in terms of development?
Readit News
Claiming that Emacs has limited customization, no GUi, and can't display images tells me they've not used Emacs and probably shouldn't be making any claims without fact checking them. Really colors how I read the rest of their pitch.
Nothing they describe about Pulsar is unique at all, apart from the slow loading time I guess. If you wanted time to load up HN while your editor loads, maybe Pulsar is right for you!
Everything they describe there is fairly basic functionality that is available in pretty much every popular(and niche) editor at this point. The "How to code 10x faster than an average programmer" article linked also describes basic things; hot reloading and real time linting.
Use whatever editor you want, write about whatever editor you want, but at least do some research about other editors before confidently stating your favorite one is the best along with incorrect facts about others.
This reminds me of the blub paradox[0] except for editors instead of programming languages.
[0] https://paulgraham.com/avg.html
This was true when the article was written, but it is no longer true.
https://zed.dev/blog/zed-is-now-open-source
There are also plenty of markdown preview packages available for both Vim and Emacs (even live preview). Emacs has had preview-latex since before Atom even existed.
What is a mode? It is when key presses do different things depending on the mode (e.g., normal vs insert mode in vi). Emacs very much has modes, by default, and many more of them than Vim (or vi), including multiple vi-like modes. Emacs is so much more modal that it is trivial to implement vi/Vim modes in Emacs (and notably the reverse is not true).
Just because Emacs does not enable the exact three or four mode key binding sets that vi/Vim does on an out-of-the-box startup does not make Emacs "not modal". vi/Vim does not own the concept of "modes" by implementing three or four very specific mode key binding sets; lots of software implement modes and to put it somewhat confrontationally, Vim users tend to be a bit full of themselves thinking that their modes are super special (and I say that as a former Vim user; I still occasionally use vi, but not as a primary editor).
haha, shots fired!
Ditto for the Atom folks with Tree-Sitter. You see both these technologies show up in neovim, emacs, hip new kids like helix…like: yes, input latency or memory usage are important for a text editor—but it’s a bummer when people’s takeaways from these two are “lol electron, trash corporate engineering”, when the teams behind them were out-implementing the even-more-open-source world on important things like this.
As for the closed-source world…Jetbrains has been basically unchallenged in the general-purpose IDE game for ages. It’s exciting to see what they’ll do now with a fire lit under their butts.
If you want to use anything other than VS Code as an editor, why not pick something based on native technologies? What's the point of picking an editor that takes 6-8 seconds to start and still is way behind VS Code in terms of development?