Maybe text editors with an extensible feature set really are more complex than we've been led to believe?
It's a bit weird to bring up scripting languages. The problem is that people want a customizable and scriptable editor. Solving that problem by providing a script language to its users is not overengineering, it's simply meeting a demand.
Looking at this, it uses some native facilities simply to setup a web browser view. Within that, it doesn't even use the built-in functionality of a browser to render the text you're editing, but resorts to custom rendering and layout using webgl. This isn't simple or clean. It's a convoluted waste of resources in that regard. Why not use one of the smaller cross-platform OpenGL wrappers?
Maybe it'll be a fine editor, but it's much more complex than it needs to be. I guess that because they set a "Web-compatible build artifact" as a goal on the roadmap, it makes sense, but is that really an interesting goal? What problems will be solved once the editor is a tab in Chrome?
It's extraordinary how wasteful some apps can be.
I actually have better performance with Sublime Text and JavaScript than I do with vim and JavaScript. I wish that weren’t the case.
If you know if any better ways to get vim working with Syntastic for linting (eslint), I would love to know.
Also, you can choke vim with large (>5gb) test files. Or is that fixed now?
I seem to recall (though haven't tried it for a while) that the Visual Studio Code editor handles them okay.
It's not a big issue -- since these are machine-generated, it's not normally necessary to edit them by hand. Every once in a while, though, I'll accidentally click on one of them in the file tree. Then I'll curse and kill the editor process.