Because you need Lisp. That's the actual "power of Emacs". Emacs is a Lisp-interpreter with a built-in text editor. Everything stems from that. Anyone challenging "the choice" of Lisp as the configuration language for an editor, saying things like: "Why? If X is better - faster, more modern, more popular...", etc., have misunderstanding of what makes Lisp so uniquely powerful.
A specific language is not the point - to implement anything similar to Emacs, you'd need a homoiconic language or at least a language that gives you live, reflective, late-bound image with code-as-data. Without that single aspect tons of things simply and inevitably (as history shows) will get complicated.
Why we have not seen such differentiator with VSCode? Because of their design choices - the extension language and the editor internals live in different worlds behind an API boundary. Emacs essentially has no such boundary. That's the power, and also a consequence of the image + homoiconicity combo.
JS was already pretty close. Babel allows a fantastic degree of power in code transformation, it just doesn't preserve blank space.
If I were to use my preferred terminology I would simply call these transform-your-own-code formats "embeddings", and there can be many embeddings for a single language.
> Babel allows a fantastic degree of power in code transformation
That's still not homoiconicity. It reminds me old Stuart Sierra's presentation from Clojure/conj¹. Around 6 minute mark: "Adding eval to a language, even successfully, does not count as homoiconicity"... "and you didn't even succeed at that..."
I'm sorry, but that's not homoiconicity. I'm not trying to devalue your work (if you're talking about BABLR/CSTML), but you really cannot bolt homoiconicity onto a non-homoiconic language with a layer, because the defining trait is the absence of a layer.
It doesn't look like your real goal was homoiconicity at all, but rather "stay in JS semantics, keep the JS ecosystem, and build structural editing over any language". Homoiconicity is a word you grabbed to borrow from Emacs's fame, but not a requirement you're were ever trying to satisfy. If it was the actual requirement, there are dozens of options that exist already - Squint, cherry, Clojurescript, Scittle, Fennel-to-JS, even Gleam - any of them gives you code-as-data cheaply.
Because to replicate the power of Emacs, you'd need to throw away a lot of privacy/security in the browser. You'd need to let one tab read the contents of another by default. A change to make your mail reading better may break your banking app (yes, that's a reality with Emacs).
Also, Emacs windows vs tabs. Think of having each tab be a non-overlapping window within the browser window.
Finally, most browsers don't let JS code modify the browser itself. If I suddenly decide I'd like Firefox's menu completely rearranged, I don't think JS will give it to me.
If I have two editor tabs open as two browser tabs they should already be able to talk if they're from the same origin, which different editor tabs would be.
The JS code won't be able to modify the browser itself, but neither can ELisp modify the actual Emacs binary code. The customizability in both cases is really coming from an "OS" being implemented in user-controlled scriptspace. You'd have just as much ability to customize that HTML-and-JS OS if it was running in the browser as you have to customize Emacs I think...
> The JS code won't be able to modify the browser itself, but neither can ELisp modify the actual Emacs binary code.
You misunderstood the problem. Remember when Firefox' GUI was made of XUL and that was indeed accessible from JavaScript (before they abandoned add-ons in favor of Google's extensions). Then you had add-ons like Firebug or KeySnail that could indeed take control of the browser's "chrome" (i.e. the visual elements that don't belong to the HTML page, s.a. tabs, menus, address bar, buttons around it).
If you don't remember... life was a lot better back then. I've built a tool for interactively highlighting selected DOM elements in the page from a dedicated toolbar for example (this was before the developer tools). You could completely remap all browser keys. You could call external editor to edit the text in text areas or text inputs. You could call programs on the local filesystem (there used to be an FTP add-on that did that).
Wait, so what is the problem? For me the biggest problem is that CSRF makes it unnecessarily difficult to write a "browser within a browser", which would otherwise not be all that hard
Basically, the problem is that the Web browser doesn't give enough control to developers to be used as an application platform. Simple things like key bindings are impossible for example (because there are some key bindings that the browser will not let you modify).
Another problem is integration with other desktop applications and system utilities. The browser intentionally removes and restricts this functionality because the browser's model of the users is that users are incompetent bumbling idiots who must be protected from bad choices at the cost of being able to perform useful actions if necessary. Emacs has some safeguards of that sort, but they are intentionally made easy to disable (eg. loading directory-local code).
Emacs itself serves as a communication interface for other programs and uses operating system interfaces to the same effect. It's trivial to run a program from Emacs and feed its output to another program, while displaying the result in Emacs. In the browser, you'd have to arrange for a custom protocol, a server that listens to requests from that protocol, and write wrappers around every utility you want to run so that they can wrap their outputs into messages of that protocol... essentially re-implementing IPC system abilities in browser (but a lot less efficiently).
> If I have two editor tabs open as two browser tabs they should already be able to talk if they're from the same origin, which different editor tabs would be.
I can interpret your original query two ways:
1. Why can't we replicate Emacs like power in the browser?
2. Why can't we replicate Emacs like power in the browser using existing web sites as apps?
I was answering 2 above. If your mail application is Gmail, then non Google tabs can't read your emails and vice versa.
If you meant it from the perspective of 1, then you can get much further. You'd have to write a generic mail app in JS that can connect via IMAP, etc.
The other headache you'll have to deal with is not having easy access to the disk. Can you easily implement a file manager in JS and run it from the browser? Or access the processes on your computer (e.g. say you want to write a "top" tool for the browser)?
Essentially, the Emacs ecosystem has lots and lots of useful Elisp packages written over the decades. The browser doesn't. And the ones that exist are self contained (i.e. you don't find a JS TODO app that is meant to integrate with someone else's JS Mail app).
And browsers don't have an easy way to install a JS app. How would you do it? Bookmarklet?
As for customizing the browser via JS - yes, you're technically correct. The difference is that much of Emacs is designed to be modifiable via Elisp, whereas that's not the case in most browsers.
So to answer your question, it is technically feasible. You just need a better browser and a lot more people writing client side JS apps.
Access to disk is... not great, I agree, but I'm not terribly worried about it. My plan is to eliminate the checked out file tree and plug the version control straight into the core data structure of the editor. I just hash the nodes of the underlying concrete syntax tree, which is my Emacs-y homoiconic data structure.
The downside is that the ecosystem for this product starts out empty. It's a whole new set of protocols, data structures, and APIs. Even so, the JS ecosystem does contain quite a lot of code that I think will be of value
As much as I don't like all the choices they've made, the choices have been the result of iterating on the problem space over time.
And... yeah the consent thing is messy. There's a kind of implicit consent in knowing that a user that does not consent can block scripts. But then it can quickly become coerced consent if there's some IRL reason you need to use the page and it absolutely does not work without JS.
That said, I'm a JS-webapp UI guy. Partly that's just what I've built my career on, largely because it was the new field emerging as I was coming up. I could learn things quickly and convert what I learned into a salary. But the second reason is that I'm disillusioned with HTML as the wire format for the web. If you choose to render HTML on your server, you're centralizing costs in a way that will eventually force you towards an extractive relationship with your users. Not only are you centralizing the cost of rendering and transmitting the HTML, but you're also centralizing the cost of building and maintaining the UI layer.
This is (partly) because HTML failed at being a semantic language. There was a brief flicker of hope with XML and XSLT -- for a hot second you could write a compact semantic document and send it over the wire. No longer...
I hate to tell ya this... LiveScript was renamed to JavaScript in 1995, and the first ECMAScript standard was published in 1997. So not 40 years old, but 31 years old.
NodeJS (liberating JavaScript from the browser) was first released in 2009... so again, not 40 years old, but old enough to have a drivers license.
I agree with you on the other side though: despite the language being relatively old and stable, it feels like the wheel's getting reinvented over and over again and "this will be a good enough pattern for the next decade" hasn't ever really shaken out, unlike Lisp or even Python.
Also notable that the way changes are introduced to the different languages is so different that this is just hard to really look at. Notably, elisp of today is not dramatically different from elisp of 20 years ago. JavaScript? Basically a brand new language after ES6+.
ES6 was released 16 years ago. I'm building on top of ES6 like it's rock solid, and so far I haven't been disappointed. After ES6 the langdev process changed materially, and it now rewards introducing language features that are, in my view, half-baked. I have had to take over parts of the work of the standards committee to be able to do this project at all.
I think I'm composing in the right direction! Terminal protocols are 50 years old, have some wild backwards incompatibilities, and are not accessibility-friendly. Funny enough CSTML functions both like a terminal protocol and like a replacement for HTML and XML
What it could at least let you do is view JS code using more "Pythonic" syntax rendering. The semantics would still be JS, but you could get rid of the curly braces while you were reading it if you just preferred semantic indentation, for example
A specific language is not the point - to implement anything similar to Emacs, you'd need a homoiconic language or at least a language that gives you live, reflective, late-bound image with code-as-data. Without that single aspect tons of things simply and inevitably (as history shows) will get complicated.
Why we have not seen such differentiator with VSCode? Because of their design choices - the extension language and the editor internals live in different worlds behind an API boundary. Emacs essentially has no such boundary. That's the power, and also a consequence of the image + homoiconicity combo.