As an Electron hater, I’m constantly surprised at just how much VS Code doesn’t suck.
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 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.
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.
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.
Not saying you should use it, just something that I found out years ago.
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?
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.
Suppose you could cat and grep, but what if you don't know what you're looking for?
Also, there's probably a ton of resources involved.
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.
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.
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.
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.
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.
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.
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).
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 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.
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.
(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.)