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.

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

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.

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.

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.

"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

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.

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.