With enough effort and care, a frictionless experience can be made with a TUI should some "Jetbrains" come along and try to make a commercial product out of it.
With enough effort and care, a frictionless experience can be made with a TUI should some "Jetbrains" come along and try to make a commercial product out of it.
It's sufficiently comical to be satire
If I care about that, I’ll probably care about Electron using hundreds of megabytes of RAM I shouldn’t even have to buy in the first place. It’s thinking like this that make people say sad things like "16GB of RAM is a bit tight nowadays, maybe you should go up to 32".
(Edit: to people who think buying a bit more RAM is no big deal: remember that our resources are finite, that computers are one of the most polluting industries out there, and the climate clock is ticking.)
I start my code editor maybe once or twice a day, so the launch speed does not even register
RAM and computers in general are so cheap that I just max out every laptop configuration I buy. If you’re a programmer and will use a machine for work spending $3-4k every couple years should not be a problem, we’re paid very well and should therefore use the best tools we can find.
I start my main editor (with the shortcuts I like and all) every time I write (or edit) a commit message. And back when I used Mutt, every time I wrote an email as well. (Now I’m using Thunderbird, but I did like the ability to use my preferred text editor everywhere.)
RAM is cheap at the individual level. But if the entire world needs to go from 16GB to 32GB or whatever, the sheer volume of the resulting electronic waste does not exactly increase my faith in humanity.
Some valuable advice I got about Emacs after switching from Vim is that it's not really a text editor, it's more like an operating system. You shouldn't need to reboot the OS between saving a file and commiting it. I typically only start Emacs once, then do everything from inside it. That being said, it's a very different workflow from Vim or VSCode, and not everyone's favorite way to work.
I even got it setup so I open multiple projects in the same single instance, and slightly change the background color based on what root directory a file is in. This way I don't get turned around when working in both a client and server, or producer and consumer.
I've configured $EDITOR to start `emacsclient "$@" -a ""` with necessary arguments (I get emacs frame instantly when necessary).
https://stackoverflow.com/questions/4458800/how-to-use-one-i...
JetBrain's IDEs are extremely slow and memory intensive - well beyond VSC and ST - and yet, complaints are always directed at VSC.
I like to be able to edit new text files instantly, and the simple, pragmatic solution, is to keep an editor always open in the background.
VS Code is not just mildly popular, it's significantly more than twice as popular as any text editor has ever been in the modern era.
Source, it's currently used by 74% of programmers (https://survey.stackoverflow.co/2022/#technology-most-popula...), the next highest text editor, since the survey started in 2015, was Sublime Text in its prime (2016) at 31%.
It's fair to call VS Code's popularity unprecedented and historic. And it's already being used to shape the future of the industry. E.g., we're watching the decline of local development right now (outside of specialized use cases) largely through VS Code's support for remote development features.
This is most likely just beginning of how VS Code will leverage its position to shape the future of programming.
74% of the respondents to the latest Stack Overflow survey, you mean.
Then it has to be Windows Notepad. Android does not have a default text editor, if it did then I'd agree.
I think you are missing out the part where it's technology developed continuously for almost half a century.
VSCode is very nice, but I quickly become frustrated by it's lag in comparison.
It does beats the pants of every other GUI IDE out there, with JetBrains IDEs coming a significant second place.
But Vim or Emacs with LSP are extremely capable IDEs and have unmatched speed compared to any GUI IDE you can name.
I do not doubt that they are. I use Emacs with a simple config as the default editor to open files with, but I do not know elisp to set up something more feature-rich, and have not felt the need to yet, but I would like to try some day. It is a truly unique piece of software with lots of love put into it, and it is also GPL which I like. The problem is just that the defaults are painful and I want to know exactly what my elisp is doing, and this would take some work. Yes I know that Spacemacs and Doom Emacs exist.
But my comment (the phrasing could be clearer) was about the choice of TUI vs GUI if one was to start creating a new IDE today, in response to the parent comment:
> With enough effort and care, a frictionless experience can be made with a TUI should some "Jetbrains" come along and try to make a commercial product out of it.
In such a case my preference would be to have a decoupled architecture which would allow for both. You can make such nice things with today's computing power and graphics cards, that it would be a shame to not take advantage of it. And the performance can be stellar. We are talking TFLOPS nowadays.
The underlying problem with Electron is that browsers are also massive resource hogs and I don’t see people switching to elinks anytime soon.
Maybe I’m stuck in a cycle of consumerism - accepting slower software and buying faster hardware - but I value convenience a lot and in the grand scheme of things vscode using up like $5 worth of RAM is not enough to look for alternatives.
The ‘native’ there is redundant. The only thing that matters is if VSCode works well enough and is performant enough to be a viable option.
Often native apps will win on the ‘works well enough’ criteria, due to superior OS integration and familiarity, but that isn’t a given. If you use multiple platforms then having a solid cross platform option also has advantages in that area.
I agree. The reason Electron got popular is because front end devs can quickly build a desktop app for use cases where a web app will not work.
And I say that as a web dev who has worked on probably a dozen apps with Electron. Mostly internal tools, but also stuff in production for end users.
For the end user projects we ended up replacing Electron with native apps using the native web view. Each app had a tiny native layer for stuff like downloading files, etc. I don't remember the exact numbers but our macOS app went from +100MB to about 5MB download. Memory usage was also great reduced. The macOS app barely used something like 15MB of RAM IIRC. That was in 2018. Today there are projects that already do this.
I think Maui will rather compete with Flutter and QT, not Electron.