Not a bad idea, but for a lot of users they'd want that external editor to be MS Word rather than emacs and I suspect that would cause a lot of other issues....
The tricky part is the user interface, text transformation (sed, query-and-replace, pipe through external programs...), text parsing (for syntax highlighting and code folding for instance) and invoking external applications, for instance to compile code or post-process your document. Web browsers are not particularly good at any of these things since they're not needed to purely "browse" the web.
If you want performance while handling big files you also need to optimize the way you stream data from the disk, something browsers are terrible at. Is there any web-technology-based editor that handles big files decently? Last time I've seen a benchmark it was pretty abysmal. Not that Emacs is great at it (it was pretty bad for a long time actually, especially pre-64bit computers) but it still was orders of magnitude faster than Atom for instance: https://github.com/jhallen/joes-sandbox/tree/master/editor-p...
There are web extensions that let you do that but it's often a bit clumsy I found, so I just tend to edit my text in Emacs and then copy/paste it in the box.
Regular <textarea> editing on the web is not generally a pleasant experience (I just had to grab my mouse to extend the comment area so that I can actually see what I'm typing) but rich text "WISIWIG" editors are even worse because the edition shortcuts always intersect somewhat with the regular browser shortcuts (sometimes in fun and interesting ways), they're slow and generally simply not up to par with stand alone editors.
Why does everything need to be in the browser? It's a complete anti-pattern as far as I'm concerned. Emacs is often mocked as the "emacs OS" because of how extensible it is but generally this is done by calling external programs, not reimplementing everything in elisp from scratch.