I think the point is not necessarily that "text editors intrinsically require gigabytes of RAM and gigahertz CPUs", but that they have "insane" latency requirements.
On the one hand, yes, our computers ought to be able to handle text editing. On the other hand, as long as you meet the latency requirements one way or another it doesn't much matter whether you barely met them or utterly blew them out of the water by four orders of magnitude... instant is instant, to a human.
A browser is a tough place to build a text editor. You're running a huge, complicated, sophisticated text rendering and typesetting environment, which you're using only a vanishing fraction of but the browser doesn't know that and can't much optimize for it. (Some, sure, I'm sure it's got special routines for monospaced text, but it still can't know you won't just stick a picture in the middle of it a moment from now.) You're running on top of a fairly slow language, even after all the optimization work on it [1]. You're running in an environment that is deeply structured to be synchronous so if you accidentally write a for loop over anything that turns out to be larger than you expected, you've frozen your environment until you're done, to say nothing of accidentally handing the browser a big rendering job ("did you just open a directory with 20,000 files? here, let me render that for you..."). Any of these things individually might be overcome, but the combination is quite challenging. It's nifty that the browser lets you run "anywhere" but it is also in a lot of ways a crazy place to try to build a programmer-quality text editor.
[1]: I have to justify this every time I say it since somehow the idea that "Javascript is fast!" has sunk into the community, but it's not true. The easiest proof is asm.js... if Javascript was already "C-fast" or even close, it would not even exist. It exists precisely because Javascript is not a fast language. Javascript is much faster than it started out as, but it started out as an extraordinarily slow afterthought meant to run a statement or 4 in response to a mouse click. It has still stabilized on "much slower than C" and appears to have essentially plateaued. The result of speeding up something miserably slow by quite a bit can still result in something slow in the end.
> I think the point is not necessarily that "text editors intrinsically require gigabytes of RAM and gigahertz CPUs", but that they have "insane" latency requirements.
What about the latency requirements is insane, then? I can't think of what "insane" could possibly mean in this context other than technically challenging or infeasible.
> A browser is a tough place to build a text editor.
I agree. To some extent I'd call that in itself an "insane requirement". The merge request proves, however, that you can attain reasonable performance by avoiding additional abstractions on top of the already very abstracted platform. Looking at the call graphs, Javascript itself or even the DOM obviously were far from being the bottlenecks.
"I can't think of what "insane" could possibly mean in this context other than technically challenging or infeasible."
Apparently, responding to keystrokes by putting a character on the screen in less than a couple hundred milliseconds is still technically challenging, or at least, doing everything we want to do within that time frame is still technically challenging for a high-powered editor. Which is less silly if you think about it. A single keystroke in "notepad" is one thing, a single keystroke in a programmer editor is quite another.
"Looking at the call graphs, Javascript itself or even the DOM obviously were far from being the bottlenecks."
If Javascript really was a fast language on par with C++ or something, that amount of abstraction would not have been a problem. The fact that Javascript is slow really is a problem. It is not necessarily the problem, because many other things are contributing, but it is a very significant part of the problem.
You can bring a Java or C++ program with its knees with too much abstraction too, but it takes a lot, lot more work than that. (Many have managed to leap this bar and more, though!)
It's one of the reasons I'm really trying to get the 1990s-style dynamic scripting languages out of my professional life. It really isn't that hard to reach a point where you simply can not have both of "a good design" and "sufficient response time" because you literally want to do more work than the language can get done on one core in 100ms unless you essentially manually inline everything, but that's not practical for its own reasons.
In fact, on that note, note that this is it for Atom. This is the fastest they can go with this layer. Should they end up pushing the editor a bit farther and should they end up needing a bit more performance to do something else properly, they won't be able too, because they just tapped out this well.
Does it really need to happen on one core? The platform supports webworkers and serializing certain events across channels wouldn't take much... if you look at, for example some of the cross channel rendering with react that has been experimented with, there's merit there.
For this use case, I suspect you wouldn't be able to win much with WebWorkers. You'd have to profile, but having done a lot of profiling with multithreading in several environments I've learned to expect disappointment relative to my initial lofty hopes. It feels like it ought to be easy to get linear speedups and that it ought to take something really unusual and special to slow it down; in practice you're lucky to even get "good" speedups.
Games in js have had similar requirements, or even tougher. expectation out of a game has been increasing for a long while, and there are games being built on js (even full fledge games using asm.js and webgl),
So i dint think the requirement for latency is as insane, you just need good dicipline, which game develers have had for decades
An asm.js game using WebGL drops the slow language problem and drops the vast bulk of the browser layout problems, leaving only the problem that you're still sorta stuck on synchronousness, but games have dealt with that for years. The fact that you reached for those details to justify your point is further evidence of my point, not denial of it.
On the one hand, yes, our computers ought to be able to handle text editing. On the other hand, as long as you meet the latency requirements one way or another it doesn't much matter whether you barely met them or utterly blew them out of the water by four orders of magnitude... instant is instant, to a human.
A browser is a tough place to build a text editor. You're running a huge, complicated, sophisticated text rendering and typesetting environment, which you're using only a vanishing fraction of but the browser doesn't know that and can't much optimize for it. (Some, sure, I'm sure it's got special routines for monospaced text, but it still can't know you won't just stick a picture in the middle of it a moment from now.) You're running on top of a fairly slow language, even after all the optimization work on it [1]. You're running in an environment that is deeply structured to be synchronous so if you accidentally write a for loop over anything that turns out to be larger than you expected, you've frozen your environment until you're done, to say nothing of accidentally handing the browser a big rendering job ("did you just open a directory with 20,000 files? here, let me render that for you..."). Any of these things individually might be overcome, but the combination is quite challenging. It's nifty that the browser lets you run "anywhere" but it is also in a lot of ways a crazy place to try to build a programmer-quality text editor.
[1]: I have to justify this every time I say it since somehow the idea that "Javascript is fast!" has sunk into the community, but it's not true. The easiest proof is asm.js... if Javascript was already "C-fast" or even close, it would not even exist. It exists precisely because Javascript is not a fast language. Javascript is much faster than it started out as, but it started out as an extraordinarily slow afterthought meant to run a statement or 4 in response to a mouse click. It has still stabilized on "much slower than C" and appears to have essentially plateaued. The result of speeding up something miserably slow by quite a bit can still result in something slow in the end.