Earlier quoted context omitted.
Very much so. As the first Electron app we were so excited about people being able to do anything they imagined. It was cool but ended up really constraining us. This time we really want to drive our API based on the most important things people actually need to extend. We need to navigate the trade-offs more intelligently.
This is interesting. I wonder how Emacs solves that, given that it's one of, if not THE most, extensible editor out there. I'd think that is a good thing, but never considered the drawbacks, besides performance and plugin interop that is.
The web stack is abysmally slow, so you have to carefully pick the levels at which you offer extensibility. Emacs doesn’t have to worry about a DOM, CSS, etc. There’s just not that much between between grabbing input events, storing a character in a gap buffer, updating a glyph matrix, and painting the screen. And it’s all heavily optimized to be usable over ancient serial links: https://web.mit.edu/~yandros/doc/craft-text-editing/Chapter-.... So even making each of those steps heavily programmable in Elisp—every key press invokes a Lisp function that can be rebound, or adviced-around, still ends up performing reasonably well on a modern machine.