Hacker News Reader

Comment by kcbanner | Hacker News Reader

I am still unsure why anyone uses Atom when it consumes so many resources. The emacs instance I have had open for some time now is using 92Mb. Atom instances have been reported in the hundreds of megabytes [1]. Of course, this is because it is actually a web application running in an entire browser, renderer and helper processes included.

I understand the need for people to be able to "easily" hack on it (easily in quotes here because really that just means "people who know web languages"), but that goal could still be accomplished in a native application that embedded a JS runtime for plugins.

[1]: https://discuss.atom.io/t/high-usage-cpu-and-memory/16165/3

View on HN

but that goal could still be accomplished in a native application that embedded a JS runtime for plugins.

The easy-to-hack bit is not about the specific scripting language but about the UI being completely hackable.

No other editor (except emacs) lets you hack the interface as well as Atom.

And any attempt at exposing enough hooks to allow a native text editor UI to be as hackable would, in a kind of Greespun's 10th rule, probably result in a bug ridden, poor implementation of an HTML engine.

Because it has a friendly interface, while Vim and Emacs have all these "weird" keybinds and whatnot. These are people switching from e.g. SublimeText to Atom.

I am not trying to harp on Vim or Emacs, I myself am a Vim user and use it for C++ code.

> Because it has a friendly interface, while Vim and Emacs have all these "weird" keybinds and whatnot.

vim and emacs are friendly and welcoming to people who already know them; new users in 2016 have some weird expectations due to growing up using insufficiently-powerful UIs, which means that they have quite a learning curve when picking up a powerful UI.

> vim and emacs are friendly and welcoming to people who already know them; new users in 2016 have some weird expectations due to growing up using insufficiently-powerful UIs, which means that they have quite a learning curve when picking up a powerful UI.

Having first used both vi and emacs (and other text-mode - and even line-mode -- editors), though only casually then, I disagree; vi and emacs are, like almost anything, friendly and welcoming to people who have become deeply familiar with them, but they simply aren't as accessible as tools that benefit from the advances in the intervening years in making UIs easy to use for people that haven't invested huge amounts of time in familiarity.

This is really a different issue than UI power (though if vim and emacs didn't have both powerful UIs and substantially bodies of users with long investments, they wouldn't stick around in the face of their disadvantages in terms of onramp.)

Older users just didn't, when they were new, have alternatives with a simpler learning curve. So, there really was no trade off for the power vi and emacs offered (less powerful alternatives of the time were still just as inaccessible), where now there is.

> So, there really was no trade off for the power vi and emacs offered (less powerful alternatives of the time were still just as inaccessible), where now there is.

There's simply nothing out there as good as emacs. Nothing. Eclipse, IntelliJ, Atom, SublimeText, all those pale in comparison. vim has its positive points (it's an excellent way for a human to edit line-oriented text), but ultimately it too falls down in the general case. emacs is simply the best way for a human being to use a computer to edit data.

There still isn't an alternative to vim and emacs. I kinda wish there were, but there ain't. Someday I'd like to use a modern emacs-like editor, implemented in Common Lisp (or a successor language), but right now emacs is the pinnacle of editor evolution.

> vim has its positive points (it's an excellent way for a human to edit line-oriented text), but ultimately it too falls down in the general case

I think the only thing that Vim doesn't do that it should is actually use a proper language for scripting. Emacs has elisp, but Vim has VimScript which is a horribly stunted langauge.

Aside from that, I much prefer vim to emacs. Just because everything is mode-based, and the keybindings don't require 10 hands to do anything.

Check out spacemacs: the modes of vim, and the extensibility of emacs. Not really by cup of tea, but it sounds pretty cool.

If you care about resources then you should really be using ed[1], not emacs.

"easily in quotes here because really that just means "people who know web languages""

It's my go-to editor/IDE for Rust, which is far from a web language.

"that goal could still be accomplished in a native application that embedded a JS runtime for plugins"

Kind of like Chromium with V8? With full hardware/OS access and linking to native code? If only such a thing existed.

[1]:http://www.gnu.org/fun/jokes/ed-msg.html

I have a project that wish to be Cross-platform (windows, osx, linux in that order).

The only tool I could use with some decent widgets is Delphi (but cost too much and kill the idea of release the tool as open source).

After that, what exist? QT is horrible. GTK look bad and weird (equal others like wkWidgets). Doing one for each target is the best but harder.

I know some people think QT/GTK is good, but as user of Delphi, them are ugly in comparison and less featured. Even winforms is barely a match.

HTML+JS+CSS is far easier, at least, to get the look. Then is the problem in how make it attractive for contributors.

I wish exist a way to get a html fast/light html rendered for the GUI.

> I am still unsure why anyone uses Atom when it consumes so many resources. The emacs instance I have had open for some time now is using 92Mb. Atom instances have been reported in the hundreds of megabytes [1].

It works well on the size files I mostly want to use it with, has a strong community producing support for the languages I want to use it with, doesn't want to impose its own structure and management artifacts on projects the way IDEs tend to, and imposes less cognitive overhead than Emacs [0]. It might use more memory, but that's never been a real practical problem, and even on my cheap 6Gb RAM laptop system, the difference between a programming editor taking up ~100Mb and "hundreds of Mb" just isn't an issue in most cases.

[0] I recognize that this is largely due to familiarity, in that Atom follows closer to currently-popular UX paradigms and Emacs is its own unique beast that predates most of the things that Atom is following, but I've been using Emacs intermittently for many years, and Atom was still instantly more accessible. But even so, there are some languages where the available Emacs packages are so good that I prefer Emacs. Just as there are some things for which I prefer Visual Studio or an IntelliJ-based IDE. Its not like one tool is ideal for every person for every task.

Time was, emacs was the huge bloated editor that would catch flack for using so many resources ("Eight[y] Megabytes And Constantly Swapping)

Personal reason #1: I can install packages and everything works the first time.

Sublime Text almost had it.

Emacs/vim takes too much effort to configure.

Reply on news.ycombinator.com