4 ms·

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 mul

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.

patates 10y ago
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.
- sjellis 10y ago
  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 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.
- trishume 10y ago
  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...
  - pitaj 10y ago
    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.
freyir 10y ago
> 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. The JS issue is another story.
- trishume 10y ago
  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/ 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.
  - 0xcoffee 10y ago
    Well Atom and VSCode are both electron based, but Atom already has a minimap-scrollbar implemented so it is possible. https://atom.io/packages/minimap https://atom.io/packages/minimap 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 https://v8project.blogspot.com), so it will only get better :)
nojvek 10y ago
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.
- Nition 10y ago
  I've found Notepad++ very good with opening huge files. I'm not sure how it compares to Sublime Text, but Notepad++ is already open source: https://github.com/notepad-plus-plus/notepad-plus-plus https://github.com/notepad-plus-plus/notepad-plus-plus

patates 10y ago

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.

sjellis 10y ago
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 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.
trishume 10y ago
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...
- pitaj 10y ago
  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.

freyir 10y ago

> 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. The JS issue is another story.

trishume 10y ago
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/ 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.
- 0xcoffee 10y ago
  Well Atom and VSCode are both electron based, but Atom already has a minimap-scrollbar implemented so it is possible. https://atom.io/packages/minimap https://atom.io/packages/minimap 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 https://v8project.blogspot.com), so it will only get better :)

nojvek 10y ago

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.

Nition 10y ago
I've found Notepad++ very good with opening huge files. I'm not sure how it compares to Sublime Text, but Notepad++ is already open source: https://github.com/notepad-plus-plus/notepad-plus-plus https://github.com/notepad-plus-plus/notepad-plus-plus