I recently installed VSCode just to try and was pleasantly surprised. For Sublime users there's a plugin to remap all keyboard shortcuts to Sublime ones (when available ex. multi-line edit isn't just yet). VSCode is getting updates on a monthly basis it seems and I have no doubt it'll catch up to Sublime in the next 6-12 months.
But it's very slow in comparison to ST. For sure related to the Electron framework beneath VSCode. (Yes, I'm that type of person that opens 25MB logfiles with such an editor)
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.
VS Code collects usage data and sends it to Microsoft to help improve our products and services. Read our privacy statement to learn more.
If you don’t wish to send usage data to Microsoft, you can set the telemetry.enableTelemetry setting to false.
From File > Preferences > User Settings, add the following option to disable telemetry reporting:
"telemetry.enableTelemetry": false
Note: VS Code gives you the option to install Microsoft and third party extensions. These extensions may be collecting their own usage data and are not controlled by the telemetry.enableTelemetry setting. Consult the specific extension’s documentation to learn about its telemetry reporting.
Well you should always care about your privacy. I think the better question is do you need to worry? My personal opinion is no, not for things like telemetry in VSCode. It is used to make the product better (hopefully) and I can't see the data collected on startup time or crashes are a massive invasion of privacy.
Is there a legitimate reason a _text editor_ developer should be allowed to make their software call home?
I've only seen Electron-based editors doing metrics, perhaps web developers are less offended by the idea thanks to pervasive usage of things like Google Analytics.
There's a lot of information developers could use for the benefit of their users, if they had access to it, some of only very mildly privacy invading, some of it extremely so.
Collecting call stacks from crashing threads or executables can be incredibly useful for fixing them.
Measuring what functionality gets used and what not can help direct feature development (should that checkbox be as visible as it is?)
Collecting statistics on Unicode code point usage may direct development of core data structures (UTF-16 might be the best choice for the basic character unit)
Collecting CPU/memory/disk stats similarly may direct development (if most of your users have gigabytes of free RAM, that change that takes 20% more memory but speeds up things may be useful; if they have plenty of idling CPU! But no memory, things are different)
Knowing what percentage of your users run on a 80386 may help making the decision to compile for at least a 80486.
Knowing internet connection speed and amount of free disk space may help make the decision to move all help online.
Knowing the default browser can help direct testing of the help system, if that system uses the default browser.
Knowing the locale of your users may give hints as to what spell checking languages or UI translations to support.
Having access to the custom dictionaries of all your users may be helpful in improving the ones you ship with the editor.
Having access to every edit made (we are deeply into 'extremely privacy invading' territory now) may also be helpful. For example, you may discover that most of your users don't seem to know about a shortcut that combines five other actions.
Everything here can be solved by an Apple like pop-up whenever something crashes that ask you if it's okay to send the crash informarion plus machine information.
Telemetry doesn't bring anything more to the table. When I see an app with telemtry, I am just thinking they don't know what they are doing.
Exactly. No piece of software should be calling home, except to the degree that its core operation depends on it, and even then, that data should be easily available to the user.
So developers should be shooting in the dark on what their users are actually doing with the software and have no data with which to better allocate resources to the features that will cover the most users?
Developers built great software just fine without constant data spying.... on the other hand all that great "important" data collection somehow doesn't assist in making modern Electron apps any less of a CPU, battery and RAM hogging arse of a software.
Most of analytics data never gets looked at and never provides any useful insight because it's setup poorly.
Yes, developers should have to put some thought into designing their own products. If they're curious how their product is being used, they should do the footwork and ask, and open channels for voluntary feedback. They can collect data with permission. End users' control over their own data is more important than making it easier for developers.
When they don't provide a method for their user to audit and/or disable telemetry? Yes, I'd prefer them to be blind. I don't expect that this would be a particularly popular position, and that if I kept it as a strict requirement for software I use, it would make it essentially impossible for me to find options in whole classes of software.
Whether you should care comes down to your ideology. My view: I totally see the value in tracking your users, but I also believe there should always be an option to opt out. Tracking becomes insidious when you lose the right to not participate.
By choosing to opt out, you're showing Microsoft that there are people that genuinely care about being able to not be tracked, making it more likely for them to keep this option for the future.
> By choosing to opt out, you're showing Microsoft that there are people that genuinely care about being able to not be tracked, making it more likely for them to keep this option for the future.
How is Microsoft supposed to know you disabled telemetry? VSCode can't tell them you did, that would be a form of telemetry :P
They still get update requests (_something_ keeps telling me once a month that there's a new version out, even with telemetry off); that can be compared to the number of unique users with actual telemetry to find the number with it off.
I don't know of a better open source IDE for front-end development right now. Performance isn't up to ST3 but it's more than acceptable, and the built-in tools and robust extensions more than outweigh that cost.
IDE's usually offer much more features than text editors. This sounds kind of anecdotal because it is and the line between the two is getting blurrier as text editors get more powerful. Typically, strong auto-complete, debugger tools & project management were differentiating factors but those are becoming more available at the text editor level as well.
By multi-line edit do you mean multiple cursors at once? Does it have a fancy regular expressions generator to replace it? Otherwise that's a non-starter for me, simultaneous editing is too valuable.
It's there, it's just bound to alt-click instead of ctrl-click. And currently you can't rebind any keybinding with a mouse click on it, so you have to use alt-click.
I use them very often in Emacs instead of keyboard macros. They are useful whenever you have to perform the exact same operations in several places simultaneously visible on the screen[0]. By operations I mean both simple ones, like writing something, and more complex ones, like navigating/deleting whole words (of different length), etc.
Mostly I use it for quick renaming of variables, string fixes, and some structural changes in code.
--
[0] - multiple cursors, at least in Emacs, can work off-screen too, but I don't like not seeing what's going on when I do changes.
I also do this, though I use iedit-mode rather than multiple-cursor-mode.
However, I do like to point out that it's really just eye-candy for stuff I was already able to do in emacs. Previously, I would have used either keyboard macros or query-replace-regexp to do the same things.
It's basically a visual regular expressions. So I'll caveat my original statement that if you don't know regex, you need it. I never learned regex because I came from a self-taught, web development oriented background. So if I need to replace all instances of a variable, then go to the end of the line they were on and type in a different variable name or add a semi-colin, that's what I use.
Lots of little things. Select a multiple lines of an object/hash/dict, break into multiple cursors, rewrite line (copying and pasting as needed, it works that out as well) to change to variable declarations, or to add a comma, or to... whatever.
I often use "multiple cursors" as vertical cursors, to indent or dedent a whole block of code 1 space at a time. Often useful for contexts when shift+tab/tab doesn't work.
I desperately want to switch editors (been using slickedit since 93)
I tried VSCode only to find it is hardcoded to only support 3 panes at once. I often have 5-7 panes open.
It was also not clear how much work it would be to add modal selection. I tried the most popular vim emu looking for an example on how to do it only to find that feature has not been emulated yet.
I use VSCode for a few tasks and enjoy it, but Sublime is just so much more polished than anybody else. In addition, Atom/VSCode/ETC all have panes as an afterthought. Sublime's tabs/panes work far better and behave the way I expect them to.
If I already have a Sublime license, and I'm happy and it fulfils my needs perfectly, what would I gain in spending the time to try to get my workflow working in VSCode if it still hasn't caught up, as you say?
If it fulfills your needs perfectly then there's no need to change.
It may be still worth playing with a bit and doing tooling investigation to find out if there are some super useful features for your case.
I switched to vscode from sublime recently, because it has much better autocompletion and "goto definition" especially when working with JS and TypeScript code, which is exactly what I need.
Other than that I was able to replicate all features from Sublime (e.g. multipoint editing) and I'm not aware of any missing feature from what I used in Sublime. One con is that vscode is slower to start and slower to open up a file.
It's closer to an actual IDE for JS than Sublime is (even once you install a bunch of ST plugins). Especially for TypeScript. That said, if Sublime is working for you, stick with it.
I switched to VSCode just for my Typescript projects, and really like it. Main reason I switched was that in Sublime you can hide JS and map files, but it always hides them. With VSCode you can have logic in your config, so you can hide JS files, only if a TS file with the same name exists, that way I don't have to switch config when I'm looking for a js file particularly, and can keep my sidebar clean and show only files I need to edit.
