[BeetleB]

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.

[conartist6]

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...

[crabbone]

> 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).

[conartist6]

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

[crabbone]

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).

[veqq]

> so what is the problem?

That browsers/web tech is moving in the opposite way and blocking various emacs-esque usecases.

[conartist6]

There's nobody more interested than me. Which use cases? Blocking how?

[BeetleB]

> 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.

[conartist6]

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