But Github is doubling down on Electron with their next github client on Mac/Windows etc. Also how would they write blogs about performance if it is plain old native text editor.
Eh, I feel like the web platform as allowed it to be massively extensible in a much more convenient and familiar way than a lot of other editors. I tried it for a little bit and it felt like the "Sublime Text but more open and flexible" that I really wanted. If they can work out a way to improve performance without sacrificing too much of that, it would be great.
This isn't about emacs. Atom is for people who want an alternative to Emacs. If you only need to know JS and CSS to write an extension, that vastly increases the pool of people who are able to write extensions.
That "pool" of people "able" to "write" "extensions" is exactly the people you don't want touching your text editor, or any software for that matter. Anyone that has a psychological barrier to take a look at a language that they are not familiar with, let alone a framework or an ecosystem, is not someone that I want being anywhere near the software I use. In an ideal world, I wouldn't want them to be anywhere near the web I visit either, but that is a lost cause.
That's debatable for the vast majority of them. "Clearly" is a strong word here. And certainly, regardless of how "good" they are, almost none are worth the hit in performance in the most basic of tasks for me.
Emacs Lisp is much less performant than a modern Javascript implementation. I don't see how choosing JS as the extension language raises any serious performance issues.
Extension quality is a bit subjective, sure. But if you are going to claim that emacs extensions are of higher quality because they're written in a more obscure language, then you should give evidence. That is not my experience.
If you weren't referring to the performance of plugins when you talked about the "hit in performance", then you are changing the subject from the quality of plugins to overall editor performance. I didn't say anything about that.
That was my point all along. The people that write extensions in this case are also the people "hacking" on the editor itself, and saying they (or web "devs" in general) are not performance conscious is an understatement to say the least.
