This is a false dichotomy. Vanilla Emacs needs 38Mb on my machine, and it has all the tools you'd ever need to develop plugins for it. Visual debugger, byte-compiler, object inspector, jump to definition (including straight to C implementation when needed), visual font pickers, color palette, documentation browser & docstring viewer for symbol at point, you name it - it's all there.

Browser engines are not optimized for handling text editing. They are optimized for basically everything else but text editing. You can make them into kind-of OK text editors, but you have to put a lot of effort just to get to where text-editing frameworks are already[1]. And 200Mb of unnecessary code doesn't make getting there any easier.

To my mind, developing a text editor with a web browser is a bad technical decision. It may pay off in the number of devs available and eager to help - it may be worth it, I don't know, it's for the projects' leads to decide. Technically, though, these projects would be much better off with a text-editing framework.

[1] LightTable is a good example here. Well-funded, motivated team worked on it for a couple of years - and still failed to provide anything more than Emacs with plugins. Well, it looked a bit better.