As an Electron hater, I’m constantly surprised at just how much VS Code doesn’t suck.

My personal evolution has gone from Sublime Text 3 to Atom to VS Code to Sublime Text 3. I've never been a heavy plugin user, mainly sticking to code highlighting. The thing I really like is speed. Sublime Text rarely chokes on me. I love being able to type `cat some_one_gigabyte_file | subl` and getting it to open up with little difficulty. VS Code chokes on files of non-trivial size, and that was the thing I liked about it the least.

For anyone wondering why I'd open up a 1 GB file in a text editor, I guess the answer is largely because it's convenient. Big log file? No problem. Huge CSV? No problem. Complete list of AWS pricing for every product in every region stored as JSON? No problem.

>> VS Code chokes on files of non-trivial size

VS Code isn't really designed as a general purpose text editor. It's meant as a development environment.

If MS choose to optimise the experience of 99% of the use cases (i.e. editing source code, which should never even approach 1GB), then that's the correct call IMO.

>> For anyone wondering why I'd open up a 1 GB file in a text editor, I guess the answer is largely because it's convenient.

I can completely appreciate the use of a text editor to open a massive log file, etc, I just don't think that's something VS Code is designed for. You can always use Sublime or Atom to open those files; while getting the nicer (IMO) dev experience with VS Code.

This. VSCode isn't Vim and vice versa.

Over time I've tried quite a few popular text editors, Notepad, Emacs, Vim, UltraEdit, Sublime Text, and of course VSCode.

VSCode is surprisingly good for a Microsoft product and they had to do some crazy smart engineering work to make it not sucks while being built on top of Electron.

That said, it still quite slow and memory hungry, I've gone back to Sublime 3 a few weeks ago and I am not coming back to VSCode.

I'm an atom user, and it chokes for the very same reason.

However I also use vim for tweaking server side stuff, and use less by default whenever I want to read something (logs is an obvious one)...

This is both for speed but also UX, i believe vim style navigation (which less basically gives you), is great for reading and searching - what I cannot stand though is doing more than small edits in vim, for development (and i mean code is flying around like crazy stage of development, not read for 1 hour and make tweaks), then I am fastest with the kind of flexibility atom provides.

I know it can be tempting to have one tool for everything when it seems like the tools are supposed to be doing the same thing, but in my mind lean text editors tend not to compete with the big fat slow electron style editors - so just use them both, for their respective strengths.

I hear you on the value a text editor on the server side. I have picked up the basics of vi for this use case, but I ain't fast with it :)

Vim handles large csv files pretty good, as well.

Not saying you should use it, just something that I found out years ago.

I've tried pure text editors, but they haven't really grabbed me, and my fingers are quite clumsy.

> Complete list of AWS pricing for every product in every region stored as JSON

Is this a hypothetical file that you mention or something you actually have? Asking since I have a use-case for this data and am interested in knowing how to get it. I have read AWS has APIs for pricing info - is that where you got the data from?

It's a thing.

https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2...

i just use less for big files, convenience is a matter of taste

I don’t open big files at all. There’s no point. Files exist as data made to be transformed from one form to another. It is only worth looking at a file in its final form unless you are making some kind of edit.

And even then, I make edits on large files through a series of commands, never opening the file.

By thinking of files in this way, it becomes easy to create programmable tool chains for manipulation.

What's your typical strategy for parsing something like a large text file for some relevant data?

Suppose you could cat and grep, but what if you don't know what you're looking for?

not everybody uses a computer for the same exact thing you use a computer for

Of course, if they did there would be no point in making my comment, it would be redundant.

I think the issue with your original comment is with "there's no point," which is in effect invalidating the opinion of others.

The reason for this, I think, is developers of VS Code really understand the problem field in this case, as they are making the tool for themselves.

Also, there's probably a ton of resources involved.

Interesting past thread on Atom's performance struggles and how they got outplayed by the VSCode team: https://news.ycombinator.com/item?id=14140421

It doesn't suck, but try Jetbrains IDEs. C++ and other "not JS" language support is vastly superior including refactoring that actually works.

Jetbrains IDEs (and others for that matter) provide so much more than the glorified text-editors, including extensive debugging support (both in my own code, library code, platform code), code-autocompletion, code navigation, code-formatting, refactoring, linting, static-analysis (works well for Python as well), great syntax highlighting, spell-check, a good plugin ecosystem. I'd never go back to editing code without that support.

The Jetbrains ecosystem is real cheap too, I pay US$160/year for the personal-license all-product suite I can install and use anywhere ... and I use PyCharm (Python), IntelliJ IDEA (Java et al), and Datagrip (DB) extensively, dipping into CLion (C++/Rust) as well ... but they have IDEs for many other languages and ecosystems as well. It's definitely a good deal.

Jetbrains suite, along with Docker, Atlassian SourceTree, and Homebrew (and connection to AWS/Kubernetes) are my main tools these days.

I keep periodically re-trying VSCode, but holy cow. It's a massive step down from a Jetbrains IDE, in every single language I've dev'd in.

Jetbrains stuff works, VSCode mostly handles the basics if it's possible to configure it correctly. Which is quite the achievement, and it's a very reasonable option and far better than much that came before it. But it's not where I want to spend my time if I can avoid it.

You're working with statically typed compiled languages tho. Once you try using a dynamic language you realize another editor is enough IMO. I use emacs for anything dynamically typed (including compiled languages like elixir) and intellij for scala/java.

Webstorm or PyCharm isn't as good as IntelliJ or ReSharper, but holy hell is it better than just a text editor, even emacs.

I really don't understand why so many programmers proudly proclaim that they do things the hard way and wear that as a badge of honor.

Phpstorm compared to vim is like an oceanside resort compared to a walk in the desert without a water bottle. If there's not thousands of bugs I have prevented or discovered thanks to phpstorm, I am not surprised.

Jetbrains products are absolutely critical if you're using a dynamic, uncompiled language and to turn down the offer is professional misconduct even if it requires buying a new computer with more ram. I don't know who thought it's a good idea to pretend that a typo in one use of a variable is a legitimate expression of developer intent, but Jetbrains saves your users from that hell.

That's an old, old trope. "Real men" do it the way that takes 3X as long and yields code with more bugs.

I feel like "tool use" follows roughly the same curve as a Gartner Hype Cycle, but without an upper bound on the right (as it implies a below-peak asymptote).

In the very beginning, less is often better, since the tool is prompting you with too many things you don't understand. Then you get past that point and you're massively more productive, since it's catching all your simple mistakes. Then you become disillusioned since it doesn't catch all mistakes, and you start learning in detail how it has failed you, and you just (╯°□°)╯︵ ┻━┻ the whole thing (the "real man" trough). And in the end you go back to sophisticated tools, as you realize a 70% solution can still give you magnitudes more productivity.

But the tooling on emacs or whatever is up to par. That was my original point, not that a plain text editor is a real man's way, just that it's good enough. PyCharm or whatnot isn't necessarily much better than what you can do in emacs, but it isn't portable to other languages or as flexible. A text editor like vi or emacs isn't much different than an IDE's functionality when looking at a dynamic language. It's a WHOLE DIFFERENT WORLD with scala though (IMO - that's arguable but refactorings etc aren't on parity with intellij), and I don't foresee myself ditching intellij for scala dev any time soon.

I remember showing a scala developer who was using sublime the "extract method" feature and some refactorings in intellij and he was like "HOW DOES IT KNOW ABOUT THE CODE THOUGH???" - the IDEs have great features, but they're less differentiating for dynamic languages as a lot of the OSS tools are just as good. Eg VS Code MS Python extension for example. It's just great.

It's miles better on Python and most javascript that I've touched (VSCode's ecosystem does tend to have more breadth, and if you're working on something that VSCode has plugins for but Intellij does not, yea - VSCode can be noticeably better for most purposes). Most commonly around stuff that requires better understanding of the structure of the language / project, like refactoring and accurately finding usages.

But yes, for many dynamic languages a fat IDE is less beneficial, especially for small-ish projects (anything where you can really "know" the whole system).

VSCode is more editor then IDE.

The editor that most closest to IDE.

jetbrains stuff is written in java btw, for all languages. (when we talk about “native”/“not native”)

I don't care what it's written in.

Native UIs seem to matter more for small to medium size apps. Huge all-encompassing things like Blender, IDEs, etc. seem benefit from a unified, attractive, easy to use UI but it doesn't seem to matter quite as much that it's native. These things are intrinsically huge too so bloat matters less.

I don't think I agree with you; but I will accept that a cross platform toolkit is necessary because you cannot write three tools of the quality of one Jetbrains. But I think you could do the same in Qt with ~manual memory management and it would be significantly more efficient. Qt, I think, is less like Java and rather more akin to an alternative native toolkit (in much the same way that you can choose on X, "oh, I will use Gtk; I will use motif; I will use Qt", you can say the same on Windows "oh, I will use winapi; I will use WPF; I will use UWP; I will use Qt" or MacOS "oh, I will use Cocoa; I will use Qt"). It just happens to be provided by a third party so there's no OS lockin.

I have no problem getting more ram for a Jetbrains product, because they are cheap at the cost of a new laptop. But it would nice to find a 16 GiB laptop would be able to cope with my codebase, my web browser and my vm.

Check out clangd or ccls for VSCode. They have refactoring that actually works (probably still rather basic when compared to Jetbrains IDEs).

VSCode is Electron? I had no idea. That’s the only electron app I use willingly then! Good job MS!

The first clue is a text editor that uses 180mb of ram :)

For comparison, I just opened up an org-mode file in Aquamacs (Emacs with macOS native GUI) and it weighs in at 105MB, which is actually lower than I would have guessed.

I am running Emacs on macOS, and it only takes 43 MB barebones, and my regular setup takes about 81 MB. Both opening the same org-mode file. Point being that it really depends on what you choose to run on Emacs, and it does not have to be about 100 MB.

Just to add to that, I don't think anyone should be concerned about their text editor taking 200 MB anymore. I doubt it is worth worrying about.

If the electron apps that I ran were the main programs I'm using and weigh in at 200 MiB, I wouldn't worry. But they're mostly background apps - chat, music - that should be using limited resources since I want them on all the time without inhibiting me. Genuine background tasks. And they're using a lot more than 200 MiB.

(I use PhpStorm and Visual Studio Pro and Rider as my main foreground apps. If Jetbrains products used a mere 200 MiB, I would be worried that something had broken and reset them or reinstall them. But they're not text editors.)

It can do A LOT more than editing text.

I’m under the impression it’s striving to be an IDE.

I love vs code, and its plugin system, but if I’m on my laptop without a charger, I use something else. When I’m running vs code, my battery life is cut nearly in half.

What do you use instead? In my experience, normal IDEs (Android Studio, Xcode, Visual Studio) all perform worse than VS Code in terms of memory use and battery. :/

Qt Creator or if my battery is real low, a text editor like Gedit (yes, I’m probably saving more there just by not having features like code completion and syntax checking).

Not old versions of Visual Studio.

As a Visual Studio user, I can't get into VS Code. For once, the interface moves constantly. Things resize at all times. It feels sluggish, however Visual Studio is becoming also worse so in the end VS Code end up feeling quicker... VS Code feels _very far_ from Sublime Text usability to me.

Same here. I am all native guy, including back end C++ servers but VS code is very decent. But then again I think the level of developers who did the main task is way above the average. And MS itself wrote that they worked super hard to optimize it for memory and performance. Something that regular developer usually ignores / does not really know how to do due to their lack of understanding how lower level tech works.

Anything is capable of not sucking if you go out of your way to spend several man-decades optimizing it.

Both VS Code and Atom use significant amounts of WebAssembly and low level libraries to achieve that performance. In addition to that they've written their own view layer for an IDE in modern JS which makes it more performant and stable.

I despise electron and html-wrapper apps. But I gotta give credit where it's due. VS Code is pretty good.

With the advent of the new WinUI, React+Native on Windows, and Blazer. I'm betting the future of windows is more web based technologies mingled with low-level native libraries.

> Both VS Code and Atom use significant amounts of WebAssembly and low level libraries to achieve that performance.

Atom has some internal data structures written in C++. VSCode uses a native executable to do the file search, but no further low level magic is used to make it go fast.

I don't think any of them are using WebAssembly yet.

I guess this is a semantics thing, but WinUI/React Native is not “web based”. It is JavaScript building “native UIs”.

Figma is pretty much replacing all web design applications precisely because it’s leveraging web tech for collaboration on a single document at the same time.

I think Figma’s success is less about being web first and more to do with filling in gaps in what Sketch offered, especially in collaboration. Today you need to buy at least 2 apps, Sketch and Abstract, to match the feature set of Figma.

Design is one of the areas where one could arguably create a native app, largely because the user base is much more homogenous in OS than most other user bases.

I think we can safely exclude 'collaborative web design' applications from the set of hardcore tools not gaining much from being implemented as web apps for understandable reasons.

Huh? Why? Designers had previously been using native apps for ages — Photoshop, Illustrator, Sketch... Figma has been successful not just because it's collaborative but also because it's performant, powerful, and reliable. Not sure why you think that can't be achieved with other kinds of software

And yet it is a hardcore tool, and does gain a lot from being implemented as a web app. Another example might serve your point better.

Ok, I see my point being not so understandable, after all. I didn't mean Figma isn't a hardcore tool, I meant that we exclude it because it specifically concerns with web technology (being a tool for web design) and leverages web to implement collaborative usage. So it's probably logical for it to be a web app.

You're still way off. It's not a "web" design tool; it's a visual design and prototyping tool. Folks are designing a lot more than websites and web apps with Figma.

> So it's probably logical for it to be a web app.

Ah, gotcha. Although I'd have assumed that Figma is used more to design native apps that web apps, this helps me understand where you're coming from.

Figma is a great tool and all but it will still take it years, if not decades, to replace immersive content creation technologies like Ventuz, one of the best in the game! https://www.youtube.com/watch?v=nu2FnEVk9_U

Is this an ad or are you serious?

No, it’s not an ad...I posted in defense of the power that native desktop apps bring since the use case of Figma was being stretched into territories other than web/mobile UI design...immersive content/interaction creation is that category!

VSCode, because of electron, doesn't allow you to have multiple windows that share state while working on a project. This makes it terrible with multiple screens.

It’s not because of electron. They could have multiple windows but it would be a massive over haul of the architecture . So they say just use another instance

I would argue that it is, because Electron doesn't allow you to share a js context across windows. So while it is not impossible, it is much more involved than it would be in most other frameworks. In fact, this is my only gripe with Electron where I think the normal HN objections about performance, bloat and lack of native UI elements are overstated and not something that bothers me.

That's basically the whole reason I'm sticking with PyCharm these days. Apart from that VSCode seems to tick all my boxes, but it's a deal-breaker for me. There's some kludgey workaround possible involving workspaces but it's rubbish.

VS Code is slow at basic things like having characters show up on screen after hitting the key. It's good at everything else though so that lag doesn't matter as much.

It probably depends on your hardware. I have an "older" (several years at least) Windows work laptop with iGPU that is quite sluggish with VS Code when hooked up to an external 4K display. However, it's snappy compared to Microsoft Teams in the same situation.

Meanwhile, my similar era MacBook with dGPU hooked up to the same screen is very snappy and I honestly would probably not be able to tell the difference in a blind test between VS Code and typing in a native text box (like the one here in Safari).

I'd consider myself pretty anal about latency -- I was never able to deal with Atom's, for example (disclaimer: I haven't tried it in years). I even dumped Wayland for X11 when I had a Linux desktop because of latency (triple buffering or something?) I couldn't get rid of.

But VS Code is not bad.

I'm using a 5K iMac with Radeon Pro 580 8 GB. I'm making the comparison vs Sublime Text which has no lag and is my standard.

On a real system or just in some syntetic benchmark? Because for me it looks quite fast in barfing out characters.

At least in base-mode. It can becoming slower when the IDE-features kicks in and autocomplete needs some time to meditate about the stae of it's world. But this also scales with size of your active sourcecode, the codebase and used language.

Also, this is some problem of all IDEs, not exclusive with VS Code.

I'm using a 5K iMac with Radeon Pro 580 8 GB. I'm making the comparison vs Sublime Text which has no lag and is my standard. This is based on my experience, not benchmarking, just try it side by side and you'll see.

My Sublime Text is decked out in plugins and so on too, there are instances where it slows down but only when it's obviously doing some processing. The basic rendering is fast, totally unlike vscode. But like I said vscode is still "fine" just uncomfortable.

That lag matters to me, but in my experience it's no worse than, say, VIM with the number of plugins that I normally run. Fully bare-bones I imagine vscode is performant as well.

Usually professionals using text editors for their work are not concerned with the absolute keystroke-to-screen latency. It’s totally fine if it’s fast enough, and it is.

Disagree on both points

OnShape (https://www.onshape.com/) offers professional level CAD which runs in a browser. Works great.

“Professional level” covers a lot of different uses... Juicero and Airbus both use CAD, I seriously doubt the latter are going to replace CATIA with OnShape

I'm in agreement with @namdnay...I don't think it will replace enterprise packages like Siemens NX or CATIA anytime soon. I do all of my CAD design in Solidworks and I do like the out-of-the-box thinking/features of OnShape...but...their pricing model ends up being more expensive in the long run ($2100/year for Pro Version). I paid $4k for Solidworks in 2016 and it's paid itself off more than 10x times since then...all without the need for a forced upgrade! When a newer version substantiates its value for my workflow, I will upgrade. Not to mention, most of my work can easily be done in Solidworks 2008-2010 because that is the innate nature of CAD packages, regardless of the version, they will get the job done.

So is Autodesk Fusion. But you won't see Autocad stop selling their desktop software. People don't buy extreme rigs to use for production, and then trade even 5% of the perf for convenience.

What's your use-case?

I work for an indirect competitor backed by the same commercial geometry kernel (Parasolid) and it did not do well with our models (which, granted, are pretty different from typical mechanical CAD models).

This writeup from a few years back caught my attention and gave me hope of near natively fast, cross platform electron apps https://keminglabs.com/blog/building-a-fast-electron-app-wit...

It's quite simple to use the web view process for nothing but the actual UI, and to move any intensive logic to a separate process (or even native code). It's also very possible to make that UI code quite performant (this takes more work, but VSCode has shown that it's possible).

If you don't see web app replacing Blender, give a try to OnShape. I was so surprised by it. It is slower than comparable desktop app, but it is usable for real world projects.

> It is slower than comparable desktop app, but it is usable for real world projects

Which means that under a high enough load it will be unusable, while Blender will deal with it just fine.

Blender in the browser. Ugh. <shudders>

I don't find it that crazy, if properly compiled with web assembly. The thing is that Blender's UI is all synchronous python, so, yeah, that and the addons system would be to need rewritten. Python in the browser is a no-go performance-wise, of course.

> Python in the browser is a no-go performance-wise, of course.

"Running the Python interpreter inside a JavaScript virtual machine adds a performance penalty, but that penalty turns out to be surprisingly small — in our benchmarks, around 1x-12x slower than native on Firefox and 1x-16x slower on Chrome. Experience shows that this is very usable for interactive exploration."[1][2]

[1] https://hacks.mozilla.org/2019/04/pyodide-bringing-the-scien... [2] https://alpha.iodide.io/notebooks/300/

So, an already slow language made slower?

No thanks.

The main point though, is that running Python in the browser it's an unnecessary abstraction because you get a crappier version of something that runs pretty well natively. If you're starting from scratch, I think that the browser might be close to native performance in some tasks. Porting existing applications is a pain when you start looking into the details.

The problem is not so much the run-time performance of the code, it's the overhead of loading the Python run-time environment over the network the first time you open the page.

VSCode uses a C++ backend to get that performance.

Yes, Chromium.

No, there's actually a C++ backend under there that implements the editor, if I recall correctly.

A C++ backend, aka Electron.

I think you're confusing Atom and VS Code.

VSCode uses the same c++ based regex parser for syntax highlighting as TextMate, Sublime, Atom, etc

For anyone interested, this is the Oniguruma [0] regex library written by K. Kosako. It's also used in Ruby and PHP.

[0] https://github.com/kkos/oniguruma