I definitely envy VSCode's nice debugging interface. I wish there was a standalone debugging app that integrated with Sublime (and other editors) to provide multi-language debugging like VSCode.
For now, Sublime's plugin ecosystem is still better. And Sublime has more polish on a ton of little things.
It will never catch up to Sublime on performance though. Not only because it is written in JS but also because a ton of the work that went into Sublime was writing custom systems for fast text editing.
> It will never catch up to Sublime...because a ton of the work that went into Sublime was writing custom systems for fast text editing.
Why couldn't the creators of VSCode and the open source community catch up to Sublime's systems for fast text editing -- especially considering Sublime was written by a single developer who seems to not work continuously on the project.
In theory they could do some of them, but they'd have to be done in asm.js or WebAssembly. Both for speed, and because otherwise the lack of statically sized structs will kill you on memory overhead.
For other things (like a very nice minimap that actually renders based on the shape of characters) you are limited by what the DOM is capable of in terms of custom rendering. You can get around this by doing what https://www.figma.com/ does and rendering everything with WebGL from asm.js, but that would be a total rewrite and you lose all advantages of using Electron and you might as well just use C++ and OpenGL directly, and at that point you are just cloning Sublime.
Also Jon Skinner is a performance-obsessed wizard who does things like write a custom regex engine just to make the fastest syntax highlighting engine even faster. Whereas the VSCode team is the kind of team that wrote a text editor in JS. I will hand it to them that they did pretty well at optimizing and VSCode is the fastest JS-based text editor, but they don't seem to have the kind of performance-at-all-costs approach it would take to match Sublime.
It's not so much that it's impossible, just that I'd bet at high confidence that VSCode will never match or exceed Sublime's performance on most text editor operations.
Maybe it isn't as 'technically good', but it does the job and imo looks good. 3M+ downloads.
As for performance, they try to keep up with electron, which keeps up with Chrome, which is currently being retrofitted with a new blazing fast javascript engine (https://v8project.blogspot.com), so it will only get better :)
Yah I'm aware of Atom's minimap, hence why I wrote "that actually renders based on the shape of characters". Atom's renders with blocks instead of tiny characters because the DOM couldn't handle full rendering. With Sublime on a Retina display I can even read some of the text. Not a huge deal, but I like it better and it's indicative of the kind of things Sublime can do.
As for V8 it gets faster but is still far from C++. The main issue being it's impossible to make memory-efficient data structures, which are super important for editing large files.
I'm pretty sure that it's rendered in a canvas, not with the DOM, but I may be mistaken. Either way it's simply because of laziness or complexity-avoidance that the minimap uses blocks, not a restriction of the medium.
The minimap could be on par with sublimes, but for whatever reason the dev who made the plugin hasn't made it so. That doesn't mean that it's impossible or impractical due to some restriction of atom itself.
You're right that it does use a canvas, but I'm not sure that it could do full rendering at decent speeds. The trick is scrolling at 60fps. I'm not sure JS Canvas can draw 100,000 characters in 16ms. I think you could do it with WebGL but it's gonna be a while/forever before anyone does that, and then the JS preparation of the data might bog your CPU.
if you open even a 10mb file in atom or vscode, they grind to a stand still. sublime can pretty easily handle hundreds of mb, AND can do regex search over them.
on performance, they aren't even in the same league.
Debugging will even get better. Honestly that's one of the major reasons I like vscode. It integrates deeply with the language and runtimes. It has debug adapters and language services for most major languages.
As for performance. When I need to open large log files, I still go for sublime text. If some core parts of sublime were open sourced, it would be a huge.
IMHO the performance of VSCode is good enough. At least for most of my coding. Inspecting huge, archived logs from 3rd parties is the exception. I think nothing can beat sublime in that.
It's not mature yet, but xi can apparently already handle files of several hundred MB with no tearing or lag at all: https://github.com/google/xi-editor. It completely separates the (Rust) back-end process that manages the whole file from the front-end windows, which only render the on-screen sections.
Part of what you lose other than large files is little features that need high performance to work.
For example Sublime's fuzzy finder previews files behind it as you type, VSCode/Atom/Emacs can't load files fast enough to do that.
Sublime's minimap beautifully renders each character in the correct shape (at small size) using the same renderer as the main body. The DOM memory usage and thrashing when you type an unclosed quote and the whole file gets re-highlighted would kill Atom/VSCode if it did that.
Also the little things just have far lower latency. Opening a file, typing in the fuzzy finding window in a large project, deleting a closing quote that re-highlights the rest of the file, etc...
You could use a canvas or an SVG to avoid "DOM thrashing" so there's no legitimate restriction that has led to minimap being implemented in the way it is.
For now, Sublime's plugin ecosystem is still better. And Sublime has more polish on a ton of little things.
It will never catch up to Sublime on performance though. Not only because it is written in JS but also because a ton of the work that went into Sublime was writing custom systems for fast text editing.