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...
> 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.
Ah, yeah, I was answering 1.
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
> 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