VSCode is based on Electron, a glorified hack/resource hog of Chromium than even Github largely abandoned. It maybe "great" and mildly "popular" here and there, but it's built on a foundation of mud. Build native apps that work and are performant.
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.
That's an interesting counter argument. I would think that for the target audience on HN, rsync would absolutely be preferable to Dropbox. We are developers, not regular consumers. Same would apply to IDE's and editors.
Yet I’m seriously considering moving away from Emacs solely because it does not boot instantly. Sure I could set up an Emacs server and all that, but come on: it’s a text editor. It should not take more than 200 milliseconds to boot on a modern machine.
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 understand your point, but I can’t say I relate at all.
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 code editor maybe once or twice a day
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.
Have you tried Magit in Emacs? It's an embedded git client with a very smooth workflow. No need to open and close Emacs just to edit the commit message. Once I got really used to Magit, it's definitely my favorite way to interact with git.
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.
Just for reference, start emacs once, run M-x server-start and set your global git editor to emacsclient -t and you end up with an instant in terminal emacs editor for git, that will also leverage magit when necessary.
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.
Github didn't abandon Electron. Github created Electron for their editor called Atom. Microsoft later used Electron for VS Code. Microsoft bought Github. Github is sunsetting Atom (not Electron) to focus on VS Code.
Why should I prefer a strict grid of characters based on technology from more than half a century ago to a GUI for something with the functionality of a tool such as VSCode or Sublime Text?
> 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.
«it lists different values that each tool prioritizes, and how "Core values are self-reinforcing. They attract like-minded people, who will then defend them."» https://news.ycombinator.com/item?id=29159433
It is useful in corporate setting when you have to edit files over ssh on some random machine and you already have terminal open. VS code has remote option but you have to set it up and navigate again etc
I agree that electron apps are unnecessarily wasteful but if there’s something important enough to deserve the resources is a code editor.
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.
It will be interesting to see if Microsoft's Maui effort will be able to compete with Electron using a somewhat more native approach. I suspect that it will not.
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.
and yet millions of people use it every day just fine. It's not any more of a resource hog than emacs when you load up enough lsp's and add ons to make it useful and modern.
lol you probably never wrote a live of code in your proffesional life xD i've used Idea and it's shit and slow as fuck. VSCode works fast even on a laptop, with intellisense scanning code in background. Noob.
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.