Hacker News Reader

Comment by sneed_chucker | Hacker News Reader

Awesome, this looks like an editor I've wanted to have for a while. I'll definitely be trying it out.

Basically it seems to take the good parts from a few other editors and combines them:

It's like VSCode, but without the bloat of electron or Microsoft's telemetry.

It's like sublime text, but it's open source and has first class LSP support.

It's like Neovim, but it doesn't require downloading and configuring a bunch of mystery meat plugins just to get what have been table stakes editor features for decades.

View on HN

> It's like VSCode, but without the bloat of electron or Microsoft's telemetry.

But isn't the bloat of electron which enables the greatest benefit of VS Code? By which I mean the plugins with their wide range of abilities and UI-integrations.

> It's like sublime text, but it's open source and has first class LSP support.

Sublime has LSP since a while now.

> But isn't the bloat of electron which enables the greatest benefit of VS Code? By which I mean the plugins with their wide range of abilities and UI-integrations.

Maybe for some users. I'm sparing with extensions because I find them hard to vet; I checked and I'm only using clangd and prettier right now. But I don't think Electron is required in order to have rich extensions - just see Vim/Neovim, Emacs, or any IDE.

> Sublime has LSP since a while now.

My bad then. I thought sublime's LSP support came from a third party package.

> But I don't think Electron is required in order to have rich extensions - just see Vim/Neovim, Emacs, or any IDE.

I don't know about IDEs, but I wouldn't put vim & Emacs on the same level as VS Code in terms of interfaces. They go much further than your average text-editor and also grow over time, but at the end they are still text-based interfaces with some fluff. Though, It of course depends strongly on your requirements. For most developers, text with fluff is more than enough.

I mean, aren't there whole web browsers and email clients written inside of Emacs? Isn't there a whole "Emacs is an operating system" joke?

But in any case, I try to avoid bespoke custom editor setups unless there's a situation that really warrants it.

Only one web browser, I think. The w3m package exists, but that's just a communication layer between Emacs and w3m.

> I mean, aren't there whole web browsers and email clients written inside of Emacs?

Depends on your definition of "whole". Those modes work by removing features from the webstack, or by borrowing from external GUIs. Emacs browser w3m for example, is AFAIK unable to handle JavaScript. Electron-apps on the other side offer you whole webstack, including all available components, widgets, libs, frameworks, or whatever. So it's very easy to take some webapp or component and integrate into your workflows. Apps like Emacs are unable of doing this, and thus constantly on a game of fetching up on popular features and services.

I see the limitations of vim an advantage not a disadvantage. Because everything is a buffer and the layout is just windows, the usual keys just work.

It's one of the things I have about "real" IDEs with a vim mode. The one in vscode is pretty good, it's pretty rare I break it when just editing code (mostly '.' not doing what I expect). But everything else doesn't fit the vim model. I have the file manager or something open in the left and I can't reach it with ctrl+h, because it's own weird UI thing not just a split (like it would be in vim).

This is exactly what has always kept me bouncing off of these things.

As a vim user I can reach a sort of uncanny valley where the core editing loop feels "right," but I end up having to fight against all that muscle memory when it comes to using features outside of it.

I had the opposite experience.

Every plugin in nvim required to learn some new different bs shortcut to have basic features. Plus, I ran into plenty of crashes and weird error in some plugins - and performance wasn't always great.

The editing is fine, you can get used to buffer editing - it's everything else which is not polished and feels like a pile of half implemented features.

I don't really keep up with the state of the art of vim, so I don't know what the community has shifted to doing in plugins, but in vim you have to go out of your way to override the base keys in your plugin buffer. I guess that might be more popular now, I don't know.

But the principle I'm talking about applies without any plugins at all. If just do :terminal it'll make a split, you can now switch between whatever you were doing and that terminal the same way you would switch between a regular split.

None of the proper IDEs do that. I can't just look at what's on my screen and do "move focus to the thing below where I am". You need to memorize shortcuts for each bloody tab rather than them being context aware, and I hate it.

> I don't think Electron is required in order to have rich extensions - just see Vim/Neovim, Emacs, or any IDE

At the cost of difficulty. Recently I wrote a VSCode extension myself with zero prior knowledge (shameless plug: https://github.com/CrendKing/universal-format-on-type/), in probably one day. All I needed to study is their extension API that I cared about. No need for learning a whole new language or DSL. Also easy to debug since there is no compilation and little environment setup.

There is a good reason even though everyone acknowledge about Electron's performance cost, everyone is still using it.

I haven't made a vscode extension, but I don't agree that neovim extensions are created with any great difficulty. The lua API is easy to use and well documented. There is a huge ecosystem of neovim extensions precisely because it is so easy to get started.

VS code is reasonably fast, sane defaults and language support, that's why it's popular.

Plugins are overrated and I try not to use them as much as I can.

> It's like VSCode, but without the bloat of electron or Microsoft's telemetry.

Just did a quick comparison on Windows 11 and vscode with hello world uses 400MB but lapce used 900MB :)

I've tried it on Linux, load it with a Rust project, and it only consumes around 100MB. Dunno what happens on Windows though

Reply on news.ycombinator.com