Sublime is written in C++ while Atom is written in JavaScript. Atom is going to be slow by design.
Emacs uses 'slow" elisp to implement major functionality, but the critical functionality is written in C. Perhaps that approach could be taken with Atom?
Given that VSCode is fast on the same Electron core also written in JavaScript, I think it's a lazy approach to simply dismiss it as, "Must be JavaScript! Case closed!"
And, there have been editors written in a variety of higher level languages for decades, many that are slower than JavaScript, that aren't (as) slow as Atom. There's more to it than language choice.
I'm convinced it has something to do with the syntax highlighting.
Disable that, and it runs flawlessly on 10+GB files.
I looked into it a bit a few weeks ago but got distracted. It uses regex and many of the statements could be improved. Plus they use a fairly off the wall regex engine that has pretty poor performance but they use it because it supports every damn encoding under the sun.
I think if that can be figured out, the only "sluggish" part left will be startup (which IMO is acceptable at this point, but improvements would always be welcome)
Javascript runtimes these days are plenty fast. You can definitely have a snappy editor and in only rare cases might need C. The issue is probably reducing the browser overhead, i.e. rendering DOM updates and the memory weight of the entire browser stack, etc.
Emacs uses 'slow" elisp to implement major functionality, but the critical functionality is written in C. Perhaps that approach could be taken with Atom?