I'm not going to claim that you can't make performant editors with web tech but recent snapshots of Light Table and VC Code are not all that fast for me for files that get beyond a hundred lines or so. Same with Atom.
It seems to usually be the syntax highlighting engines on first load of a file, or if you're moving code around, a simple cut and paste will show this too. I'd happily turn off highlighting since I find it distracting 99% of the time but ironically these editors don't allow that. Some of the editors make highlighting async but it makes it even more obvious when interacting with the view. There's a distinct pop-in then style effect that often happens.
Now the question: Why is highlighting slow? It seems like a lot of these editors still run lots of logic including highlighting i the UI thread still. Web workers could potentially help but of course there are still limits to how values are exchanged with the UI so it's likely non-trivial work. So, remind me again why it's an advantage to use a browser engine for this application? Portability is about the only thing I can think of but that hasn't stopped Sublime Text obviously.
I just did a quick, unscientific test using a 3.5 MB bundled (but not minimized) .js file.
Sublime 3 results:
Opening the file took 13 seconds, of which only for the first 5 seconds the editor interface was unresponsive. Syntax highlighting was available throughout the entire file immediately after opening.
As an additional test, I tried doing a select all, cut and paste of the entire 3.5 MB source. The paste took 6 seconds. The editor interface was unresponsive during the entire time. Syntax highlighting became available immediately after the paste completed.
VS Code results:
File opened in 7 seconds. The interface was fully responsive for the entirety of this duration. Syntax highlighting took an additional split second, but this did not affect responsiveness either.
Cut and paste completed almost immediately, but syntax highlighting did not become available for another 7 seconds, but responsiveness is once again completely unaffected during the entire process.
So it looks like in terms of pure syntax highlighting speed, the two are rather evenly matched. However, it would appear that VS Code has an edge over Sublime 3 in both initial loading speed as well as in terms of UI responsiveness.
As for your question:
> So, remind me again why it's an advantage to use a browser engine for this application?
My own answer would be that it's simply the most accessible way to build cross platform applications. The web platform simply has had more optimizations and standardization work put into it than any other interface technology out there today.
It also happens to have a very simple model for concurrency that is very well suited for event-based UIs: the single UI thread with message passing through web workers. While it's true that the traditional, free-for-all multi-threading based concurrency model is more powerful, it also presents a much heavier cognitive load on the developer and is notoriously error prone to implement.
It was probably a much simpler task to implement Web Workers in VS Code than it would have been to architect Sublime 3 into a fully multi-threaded application on all the platforms that it must support, in order to have the UI be fully responsive during intensive tasks like in VS Code.
I just opened a 2.8 MiB file in ST3-dev (JS, using babel syntax def) and it opened sub 1 second. I think it must be the dev branch that has this sort of performance boost? Give it a shot.
That makes sense. Still, it's good to know VS Code can load a file that size. It seems like the nicer of the web-tech based editors that I've toyed with.
It seems to usually be the syntax highlighting engines on first load of a file, or if you're moving code around, a simple cut and paste will show this too. I'd happily turn off highlighting since I find it distracting 99% of the time but ironically these editors don't allow that. Some of the editors make highlighting async but it makes it even more obvious when interacting with the view. There's a distinct pop-in then style effect that often happens.
Now the question: Why is highlighting slow? It seems like a lot of these editors still run lots of logic including highlighting i the UI thread still. Web workers could potentially help but of course there are still limits to how values are exchanged with the UI so it's likely non-trivial work. So, remind me again why it's an advantage to use a browser engine for this application? Portability is about the only thing I can think of but that hasn't stopped Sublime Text obviously.