Lapce dev here. Firstly sorry for the bad experience for some people.
Just a bit of context here to explain the status of the project. The first line of code was started around 2018 as a personal project. And as of today, we still don't have anyone who works on it full time. We don't want to defend ourselves too much here, because there are very good quality code editors out there such as Helix, which is also community developed. But still, GUI is just such a beast of complexity, which consumes lots of time and energy which we already lack. That said, we had developed our own cross platform GUI toolkit called Floem, because as you may know there aren't any good ones that exist.
The journey was fun and challenging, but the aim of the project isn't a toy, and we believe by taking slow but firm steps, we'll reach production quality, one day. Before that, please do bear with us, and help us if you can (as in code).
Don't apologize! It's not like you've taken anyone's money. HN can be a tough audience, but I don't see any (serious) comments that are putting down what you've done--just pointing out issues they personally experienced. I posted one myself. Informal bug reports.
Honestly this is about what I'd expect from pre-alpha software, though I do agree with other commenters that that label should be more prominent on the website to manage expectations.
Taking on something like VS Code as a competitor is ambitious, as is building a native UI library from scratch. Personally I applaud your effort and I hope this project succeeds.
Thanks your contribution! I just downloaded it, installed the Rust add-on, and it automatically used rust-analyzer showing all the information of types and structs. It maybe needs some polishing, but looks like it works like it should, and it does it really fast. I'll test it better tomorrow, the running and debugging interface seems really simple and interesting tbh
On the side of the GUI, what made you make Floem instead of using egui or other similar library? As far as I looked, looks like a non-native reactive GUI using some 2D graphics library like the other ones. Does the granularity in that reactivity have a big importance in that?
Apart from that, if Floem is easier to use than other graphical libraries for complex designs, or if you make a GUI designer like you have in Visual Studio, Qt, and similar, it can help a lot of people developing apps in Rust
I think it might be better for all if the landing page was geared more to contributors (coders and bug finders) as opposed to end users.
From Servo's site:
> These pre-built nightly snapshots allow developers to try Servo and report issues without building Servo locally. Please don’t log into your bank with Servo just yet!
I'm shopping for an IDE with Vim keybindings, but this doesn't seem to be it yet. Points for having Vim-like support out of the box, but most of what I tried failed, including:
- Exiting insertion mode with ctrl+c or ctrl+[
- Shift+U to undo all changes done to the current line
- `di[` to delete the contents inside the current [
- `dta` to delete everything until the next `a`
- Shift+[ and shift+] to jump paragraphs
- Shift+D to remove everything until the end of the line
- `.` to repeat the last action
It's a good start, and I'll definitely check it again in the future, but I'd hold on advertising "Vim-like" editing until the support gets better.
The rest of the editor is awesome, no complaints so far.
Me too. Both extension for VS Code have too many quirks for me, and I left the Jetbrains world and intend not to go back (due to too many disappointing support issues).
I try this editor every few months to see how it's progressing and is still way too early to use as a daily driver.
People suggest this over Zed very frequently. In my experience Zed is way more mature and stable. That being said, it's no one near as usable as neovim with a good plugin setup, let alone a mature ide like Jetbrains products.
Jetbrains IDEs might be slow, but I'll get a hell of a lot more done in 8 hours with it. Once you learn to use the features well, it's incredibly powerful. I love vim, but generally use jetbrains.
If Jetbrains took 500ms to load a file vs 1ms to load, my productivity isn't going to change dramatically. It's fast enough. Yes initial indexing is slow, but it's easily worth it.
All this being said, I think Lapce is very informative as a resource to anyone trying to build an editor in rust.
I've tried Lapce several times over the past year or 2, and have never gotten more than 5 minutes in without it hanging or crashing. I wish I was a rust programmer, but Lapce is not a good poster-child for the language, IMO.
It's not the speed, or even the phoning home that make me rage-quit VSCode on the regular. It's the RAM. EVERYTHING slows down if you only have 24GB and try to use VSCode.
I too use intellij and neovim for everything and agree mostly, but what's your motivation to check out new editors? Is it for just for fun? In my mind an editor is one of those things I wouldn't consider changing unless the alternative is heavily funded and leagues much better than my current choice.
I try new stuff regularly. People can build cool stuff. Google is releasing a new IDE soon. I'll try it. Cursor.so is a cool idea. I tried it. Zed sounds great (I love high performance) so I tried it. Haven't switched yet though!
But I was 100% vim for years and over time, slowly started using intellij and friends. I hated how slow it felt. But as I learned the features, it became a no-brainer.
If I didn't try new stuff I wouldn't have used it.
I did the same thing with terminals for a while, and settled on Kitty. (I'd never use fig / warp). Speaking of which, IntelliJ 2024 EAP terminal is horrific. I had to downgrade.
As someone who uses Neovim, I would love to have a near-vim experience in something that has all of the convenience of VSC + a great plugin ecosystem. However, I'm not sure about the fact that in `normal` mode `:` just brings up the `cmd+shift+p` command dialog. Maybe I could get used to it, but the fact that something as simple as my muscle memory for "I'm in `normal` mode, better type `:w` just to make sure I've saved" automatically bringing up that dialog and then suggesting I `Close current window` immediately... is not helpful. If the command experience is going to be so different from vim them it's not really going to ever be a suitable replacement even for brief stints/pairing IMO. It's a shame because the VS Code vim plugin leaves a lot to be desired.
Neovim with Lazyvim is pretty good out of the box. In the old days, both Emacs and (Neo)vim although highly extensible, well, it was hard to configure and set up for the things you wanted to do.
Now, we have Spacemacs, Doom Emacs and Neovim with Lazy, Packer etc., so I really can have a 1st class "IDE" without needing to learn LISP or Vimscript (or Lua). So you do need a little bit of that to be able to edit the package.el or init.lua, but it's pretty much uncomment or cut & paste.
If you're looking for a (Neo)vi(m) tutorial, try this:
Just to be clear I love neovim (though I don't really like Lazy particularly, maybe I should give it another shot). Mostly I'm looking for something that is close enough to vim for me but also close enough to VSCode for the people I pair with.
Helix is a very good and well-managed project, but it's quite hostile towards its own community. There are no plugins, and they won't be in Wasm like users want, but in Scheme dialect named Steel, that nobody want... if at all. Missing features like copilot or file browser expected by the community are essentially never merged into the master. This might be a better path than total dispersion and destruction of what works, but my expectations do not align with what the creators offer, so I give them the freedom to choose. I keep my fingers crossed for its development, but I personally use something else.
Copilot has many fans, and for many, the ability to use Copilot is more important than all the other "batteries-included" features. It's not for me or anyone else to judge. Everyone should make their own choices.
Regarding plugins, I'm with Helix from the beginning, i have read everything, and I understand the motivation well and can accept it. Perhaps this is what the ideal editor looks like for creators, but it definitely doesn't look like the ideal editor for me. I respect their decision, but I'm sticking with Neovim and might switch to ZED when Linux support becomes available.
Why do you consider switching to ZED from Neovim? ZED is lightyears away from a good Neovim setup in terms of functionality and efficiency. The problem with Neovim is the setup and config to do all, but you already mastered it.
Generally agreed, but in the editor space that's where plugins come into play. The plugin story for Helix is a long one, but I think it's converging and bet it's coming within this year.
Helix is a dream, as far as I can say from having played a lot with it, but only played. To be fully comparable to some IDE or Neovim setup like LazyVim, you need to complement it with other tools and use some workarounds, e.g. working the files (tree) or custom snippets.
(I'm still using VS Code to get my stuff done, but in a couple of weeks I got some time to spent to re-evaluate Helix and Neovim.)
Since v1.0+ of this extension I have been constantly having issues with neovim's and VSCode's buffers got out of sync. I cannot reliably reproduce the issues however. There are a few similar reports, e.g. https://github.com/vscode-neovim/vscode-neovim/issues/1624. I've switched to other VIM extension (VSCodeVim) which I found more reliable, albeit less powerful.
There are plenty of out of the box configs that do most of the work for the user in terms of configuration that begs the question: why demand vim in other code editors?
When I'm developing alone I mostly don't miss anything when in Neovim. However, even with mouse features enabled vim is not a great experience when I'm pairing with someone who is only used to using VSCode (which is a lot of people I work with). Ideally I'd like to have an editor which is very close to vim in the ability to use basic navigation, editing, commands (for instance, macro support would be nice but I can probably live without it) when pairing.
Does anyone have insight into how Lapce and Zed compare to each other? I.e. what are the differences in project goals, current capabilities and roadmap? Thanks!
Now that Zed is open source they're actually quite similar in capability (even sharing a number of underling libraries). The biggest difference is probably that Zed is backed by a commercial company (and I believe they have plans to sell collaborative functionality on top of the core editor) whereas Lapce is more of a community open source project.
Lapce is also cross-platform whereas Zed is currently macOS only. But they seem to be making rapid progress on linux support so this may not be relevant soon.
This is my question too. I think I’m going to have to try both. AFAICT so far, Lapce is ‘just’ someone’s open source project that has got popular, while Zed is made by a funded-looking startup with several employees that announced they were switching to open source just a couple of weeks ago. Zed also has Copilot built in. Both look like great editors at a glance. Zed has more easily findable information about their goals - there’s a blog and a roadmap on their site. (I guess with Lapce it might be possible to get a sense of goals/vision by sifting through GitHub issues and comments, which I haven’t done yet.)
What makes you say that remote development is mandatory? I think it has less to do with "this day and age" and more to do with your current employment.
For me and a lot of people it is. But not because of employment. one big use of remote is to remote into docker containers. why docker containers? I can have a different set of dependencies for each project and yet have my different systems communicate with each other over a network.
but for me, the big issue is I run phoenix framework and the older version I'm running my project on can't run the tests on the arm version of docker os I had to create a x86 machine on hetzner.
From a developer perspective, Zed's licensing prevents it from being used/inspected outside of the context of other GPL projects. For example, Helix can't use nor read any of the code in Zed because it would pollute the licensing.
Making a fast editor is such a common hobby, everybody seems to be working on one these days apparently, yet memory safety and speed has never been a real problem in editors.
It would be much more impressive to explore a novel approach for editors more extensible than Emacs, or with a more innovative editing model than vim's.
If we are reinventing the wheel, why not at least try to make a better wheel that's never been done before?
Editors don't get made in Rust because people want better memory safety in an editor. They're made in Rust because people like Rust, and the Rust trademark makes anything associated more cool, no other language has reached such a godlike marketing status.
Counterpoint: The only really pleasant + mainstream + cross-platform languages for new client/desktop software today are Go and Rust. Depending on the Python interpreter or the JRE or whatever is a huge pain when you don't control the environment. Just spitting out a native binary really helps. (I say this as someone who doesn't personally find Go pleasant, but I understand that lots of other people do, and I respect the tradeoffs it made.)
Kakoune too. But if a project focuses on a novel editing model and not some other aspect of an editor, then implementing it inside Emacs might be the best approach.
If implemented inside Emacs, then it composes with the rest of its package ecosystem. Kakoune, Helix, etc. are somewhat set back by having to reproduce functionality equivalent to Magit, Org, LSP mode, and so on in order to be on equal footing for many users.
Evil, Meow, and God mode seem to show that Emacs is a good platform for such experimentation.
I don't have a lot of experience with Emacs, let alone evil (and none at all with meow or god). But my experience with it was that evil felt distinctly.. hacky? For example, Evil felt like it interfered with selecting restarts in Sly.
I've had similar issues with VscodeVim being weird in VSC. Ultimately the text editor is so core to a text editor (duh) that deeply modifying it is bound to give a worse experience than implementing it from scratch, even if it does give you a lot of nice stuff 'for free'.
> But my experience with it was that evil felt distinctly.. hacky?
Honestly that was my experience with all of Emacs, not just evil. I tried Doom Emacs a while ago, and while Doom does a great job at abstracting a lot of that hackiness away, whenever I tried to configure something myself it just felt like the entire Emacs ecosystem is based on random hacked-together 10000 line elisp scripts with 3 GitHub stars which abuse some weird undocumented legacy parts of Emacs. Basically everything except a few famous big packages (eg. Org, Magit, etc.) felt very weird to use.
Kinda surprising considering how comprehensive the Neovim ecosystem feels compared to Emacs', despite it also being a very niche editor
Was just trying it out earlier this week. Or at least wanted to, after hearing all the good opinins about it over the net. Unfortunately using xmonad it simply refuses to display in certain positions. When I found a position where the interface was displayed, there was still no tooltip on the icons, which makes recognizing their function non-trivial. Anyway, after I spent 8 minutes trying to find a place to set custom include folder unsuccessfully for my project, I gave up, and went back to QT creator.
Just installed this on windows 10. First time I tried to open it the window hung for 3 minutes until I killed it. The second time, I couldn't reposition the window by clicking and dragging. Third time I loaded it, it hung again.
It's an exciting product pitch but isn't working for me. I see now that there's a "pre-alpha stage" disclaimer on the download page and wish that were in larger font.
Not sure if you tried the installer or the portable version, but for me, running the latter required me to put it in a location where it had permissions to create the 'lapce-data' sub-folder. (And no, there was no sensible error message when that inevitably failed).
Having said that, there doesn't seem to be very much "there" there, right now. I managed to open a C# project using the 'csharp-ls' language server, but, other than suggesting some refactorings that I couldn't successfully apply, there wasn't much that indicated that this actually worked. Debugging certainly didn't.
It did load very fast, though, so that might make it worth checking out again in, oh, a year or so...
Experience on Ubuntu: It opens, but double clicking the header doesn't make it expand. Then `Open Directory` doesn't do anything; no typing, no nothing. So close again, and open from command line with the directory as agument, works. Now I can't see my mouse.
My experience on Windows 11 wasn't as bad as yours, but I opened a small Rust project with Lapce (~20 files) and it uses 1400MB of RAM vs VS Code's 900MB, and has very noticeable latency when navigating the code and typing.
But like you said, it's pre-alpha, and I hope this project succeeds. I'm sure these issues are solvable. It's exciting to see Rust-based non-web UI libraries finally starting to become usable for reasonably complex apps.
Edit: I just disabled RA in both editors and restarted them. VSCode is now at 320MB and Lapce is at 770MB.
Edit 2: To be clear, my above comments are meant in the spirit of an informal bug report/feedback. I get that Lapce is a labor of love for its core developers, and I'm not shitting on it. In fact I think it's pretty impressive. I'm keeping an eye on it as something to potentially switch to once it matures a bit.
Portable version loaded instantly for me on Windows 10. Remote SSH functionality doesn't work at all unfortunately[1]. Would be nice to try out but I don't do any local dev.
Correction: Remote SSH works fine, we haven't reimplemented the remote file picker in new GUI toolkit but that can be workarounded by using `lapce` CLI and built-in terminal.
It boggles the mind. Good for the team building this, lots of respect entering this crowded and race to the bottom pricing product. But I don’t get how this differs from vs code or why someone would be excited about it. I get the feeling people like trying new editors so they throw stars around for every ide project they come across.
None of the features advertised beat neovim nor does it have the crazy plugin ecosystem.
Isn't keyboard layout a function of the operating system? How is a usermode application supposed to support (or not support) different keyboard layouts?
On Ubuntu for me on my laptop, it opens, then I try to drag the top status area and it sort of hides under the icon bar at the left part of the screen. Then I try to click on it again and it is completely hidden. The icon is still there though.
Opened in macOS and it appears impossible to open a folder of any sort. I type the folder path into the Open Folder thing at the top and it just silently fails.
There's no menu or anything to open a folder either. This seems lacking some _basic_ UX principles that should never be overlooked.
I did eventually figure it out and the TS integration doesn't work at all. The file browser icons constantly and consistently do not render correctly.
Guess this is something to check back in on in a year or three. It's a long way away from being complete, let alone usable.
> Opened in macOS and it appears impossible to open a folder of any sort. I type the folder path into the Open Folder thing at the top and it just silently fails.
That sounds like it could be Lapce failing to handle macOS full disk/folder security permissions (which you can grant in the System Preferences app)
I still don't understand how Zed or Lapse can build a viable business out of an OSS editor but at the same time there is an OSS VC funded Python linter so it's probably me.
I'm not sure what the selling point is, not criticizing the product, but as an emacs user of some odd ten years, I feel like as soon as I open the page I should see _something_ that would entice me to switch.
They rewrote the UI recently in their own toolkit, Floem [^1], and that broke all scaling under X11 for me (now the UI and fonts are rendered so large that it's unusable). It works fine in Wayland though...
Here's some issues that were filed for this same problem:
I think VSCode is also moving in the direction of wasi extensions[0], including for its serverside extensions host[1]. So there's
a chance we get some of that for free.
That's exciting. While I have some minor gripes about VSCode, it is fine enough. What gets me worried is the plugin ecosystem continually becomes a selling point in which no other editor can compete. I want other editors to be built and have a chance to thrive, but it becomes impossible if all of the good development tools get locked to one program.
I’m a big fan of this project. A native, GUI, fast code editor is a welcome change from what VSC does to my laptop’s battery. Unfortunately, I have to step away from it while I figure out a potential data corruption issue. While editing a complex config file in lapce yesterday, I reopened it later to find all KINDS of errors—dozens of deleted, moved, and changed lines. I haven’t pinned it on lapce and it may well end up being something else, but it’s the primary suspect at the moment unfortunately. But to be crystal clear: if the problem is with lapce, that’s on me for using early stage software with a real document. It’s a great project and I don’t blame the software at all for my choice! (Just … ymmv at this stage.)
I have my CapsLock key remapped to Escape with `setxbkmap` and yet it's not recognized in the modal editing mode (I have to actually press Escape) - anyone else experiencing that?
On Manjaro I opened it and it stuttered for a bit and then crashed my entire desktop to a TTY. I get that it's pre-alpha but I was not expecting it to be that unstable.
I remember the old days of using tinyIRC which boasted that it was hand-written in assembly. And indeed, it was great to use. But there’s nothing really notable about any of this today when so many editors are flexing speed. Two weeks can’t go by without a new editor coming out. I’m still on VS Code after ST shit the bed.
I could use a decent Rust IDE. I can't believe I'm saying this, but the VSCode plugin for Rust seems to be the best there is at the moment, way better than the JetBrains plugin. This cannot be the last word on that.
Ultimately, for Rust all you really need is an editor with good LSP support. rust-analyzer offers a lot of what you could want out of an IDE (although when trying RustRover I noticed some other nice things such as the ability to 'factor out' a function from a selection, which I don't think I was able to do with RA).
Which editor that is doesn't really matter. VSCode is probably easiest, but Neovim, Kate, LiteXL, Lapce, Emacs, kakoune, helix, really pretty much all of them should work decently well.
Please improve the UI before adding all the features of VSCODE but better :-)
On a positive note, just to be sure I tried to run Eclipse - its UI is much worse.
HN: please suggest open source code editor with great UI for MacOS.
With neovim you're still dependent on plugins written in some scripting language, and their overhead can add up. Lapce plugins are compiled to WASM/WASI, so they should run a bit smoother.
Lua is not some random scripting language, it is designed for embedding and is very fast with minimal overhead. I'm not saying that using WAS* is bad but bashing Neovim when it uses the one of the best proven technologies for extension is just silly.
My point of view as well. Once you learned how to configure Neovim with all the features you need, there's no better IDE out there (except IntelliJ for Java), because none is as customized to your personal needs and preferences. The challenge is the getting there, but why should one leave it?
The reason I am sticking with cursor.so is the AI. It is convenient to be able to a) let AI read whole files b) feed in direct documentation of a certain package to have proper context.
Might not be worth to expert coders out here but definitely saves a lot of time for me debugging or onboarding into a new framework
Wish Lapce had that. Also Zed does not have the quite depth for AI compared to Cursor
I am constantly confused by text editors pitching themselves on speed. Is the world really full of developers going crazy with frustration because they’re waiting on vs code to do something? I opened a 100,000 line text file a few days ago & it rendered in like half a second, considering I do this about once a year it’s really more than good enough.
I would invert that: when was the last time you tried using a text editor that boasts speed instead of VSCode?
I am forced to use VSCode for extension-based reasons, but have Sublime Text installed as well that I can very occasionally use. The difference each time is staggering, like a slap in the face. Scrolling smoothness, input latency, snappyiness to jump between files, or search workspaces. Each time it's so obvious. It's just so much more pleasant. Like going from being hunched over a tiny laptop screen to sitting in front of an all encompassing ultrawide, or going from an old laptop to a new desktop.
It doesn't mean that VSCode is an unusable pile of garbage, just as a tiny laptop screen isn't unusable. But the difference, at least to me, is undeniable.
I'm often coding on a server with like 10ms round trip latency, so I'm not bothered by the small latency that my editor introduces. I'm using Vim, by the way.
Ever tried the Remote-SSH plugin from Microsoft?
With it I had the exact opposite experience, I'd regularly forget I was working on a remote dev machine!
In this case it's important to note though that this is a necessary side-effect of offering a powerful extension API.
If you – for example – install some badly coded extension that blocks the main thread to parse the open file into an uncached AST on every keystroke before rendering the input, that's the extensions fault.
Take my example with an ounce of saltt as I've never coded a VSCode extension. It is very well possible that the extension API prevents this particular example. I guess normally things like parsing source files have to follow guardrails that prevent this kind of bug, or at least discourage coding this way. And ASTs are exposed by VSCode's core for the natively supported languages.
Still, it's probably safe to assume that there is a lot of badly written code out there that does not pay attention to performance, or follows an "optimize-later" mindset.
Features surely often seem tempting to implement in a slow and unoptimized way, and anyone can contribute to VSCode extensions.
I think the comment you're replying to was blaming slowdowns on the size (in lines of code) of individual files, rather than the total size (in number of files) of the codebase.
I have exactly the same workflow: VSCode when I want a specific extension and Sublime as a fallback.
I think a lot of people don’t notice the difference but I can’t un-notice it.
Huge generated files and whatnot, VSCode just spins but Sublime opens them instantly.
Not to knock VSCode: it’s amazing what they’ve done especially comparing it to other web-stack apps (like what is Slack doing that it’s slower than VSCode with 6 extensions running?!).
Even when things are running smoothly, the just-perceptible delay in switching files or a slight stutter scrolling feels like the digital equivalent of working with a cheap tool.
The cheap ratchet is a little sloppy and occasionally the pawl doesn’t catch but it still does all the same stuff. Yet Snap-On still has customers.
VSCode is blazing fast on my 5 year old personal laptop. VSCode is frustratingly slow on my M2 work laptop full of corporate nannyware.
It’s not VSCode’s fault ;)
JS-based apps happen to interact terribly with nannyware for some reason. I see it every time I run one of our node services, everything just grinds to a halt while the antivirus freaks out about how dare I run a piece of uncompiled code.
Slack and friends have the same problem. Discord actually runs better in a browser than as a standalone app.
This probably needs far more attention than it's given.
A half-wild guess here is that because viruses uses various ways to hide themselves the anti-virus software probably scans W^X codepages on changes, so anything JIT compiled (all modern JS engines) will trigger a lot of spurious scans (kinda like how compiling and writing .exe files can grind turnaround times to a halt).
I'm in almost the same boat. Speed absolutely matters, but you only notice it when you don't have it.
I'm working on a large Dart project and a long time ago someone thought that having the project split up into 100 packages would be a great idea (it's not).
My previous editor was IntelliJ as I am used to its keyboard shortcuts, but it struggled with our setup: constant freezes and even if it didn't freeze, it would take seconds until the suggestions came up (or when I wanted to rename a local variable, smh).
I was so frustrated by it, that I installed helix, it was fast so I'm now learning to use it as my daily driver.
I have now both open, doing my editing on helix, and if I feel like I can go something faster in IntelliJ (which now happens less and less often), I do that little thing in IntelliJ and come back to helix.
Why helix: it's "great by default" and I didn't have much success with setting up and customizing NeoVim (it didn't feel good, the plugin were annoying to learn, and it started to slow down). I'm sure it a skill issue, but helix just works for me, and I can live without plugins for now.
It’s the small latencies that add up for me. I usually use a tmux + nvim setup, but for codebases that require a bit more language server support (eg. C++20 and sometimes Rust), I have a VS Code setup with the nvim plugin that I’ve spent way too many hours tweaking hot keys and things.
Despite all my tweaking, VSCode sometimes just feels like it’s a beat behind, and keyboard commands get dropped in the transition between panes and such. Even just scrolling with nvim keybinds feels a bit off. My key repeat rate is fairly high, and I’ll hold down ^D to skim through a source file. VSCode’s renderer struggles to keep up smoothly sometimes.
This is all nitpicky stuff, not enough for me to swear off VSCode or anything. But it’s just annoying enough that every once in a while I end up in some rabbit hole of VSCode internals and css tweaks, instead of doing actual work. Most coding does not require a ton of bouncing around, but it does feel very liberating to have confidence in my inputs as I navigate around.
Wow, that's a great way to phrase it. I'm currently setting up a basic laptop with speed like you're describing as a goal. "Confidence in my inputs" is an underrated value in HCI. Of course websites have to implore users to not click on this again while it loads, they don't have confidence in their inputs!
I honestly don't see that? If it drops inputs, you can't have confidence in your input; but, if it is merely slow to process them, then you don't lose confidence. If you know for sure that something will happen--and even that it will happen in the correct order, as in this case--you can just move on with your life. Have you never worked with a remote text editor over high latency? Or played a musical instrument that had a slow reaction time?
For avoidance of any doubt, I care deeply about my editor latency and agree that those terminals who claim to be "fast" and yet only care about average--not even common--throughout instead of latency misunderstand the problem space... and yet, I still can't say that it is reasonable to lose "confidence in your inputs" if a system is merely slow to process without losing any of your events. If an editor drops any of my inputs at all ever I 100% lose all confidence in what I'm doing; but if it always works then I can close my eyes and still use it without issue!
I think this gets at my feelings on latency as well.
Terminal emulators with GPU-accelerated rendering became popular, but I often found the latency to be quite bad. (I eventually settled on Kitty and foot.)
With VS Code in particular, it’s just not designed to be operated via keyboard. With enough effort, you can map/script everything, but many actions translate to opening a pane and then focusing it. It’s an implicit modality switch that often ignores input during the transition. Also, opening a new terminal is oddly slow, I think due to VS Code injecting things into zsh init.
With tmux+nvim, it’s much more predictable. For example, if I think “I want to copy three lines out of this file and paste it into a new shell”, it’s just: `3yy alt+enter ctrl+shift+v`, and I know it’s going to work every time. Not to mention the composability of keybinds in different scenarios.
(Also, hi saurik! Cydia on my OG iPod Touch is a big part of what got me into coding in the first place :)
You are a data point for the notion I mention in my own reply to the parent that keyboard-only navigators might be feeling this more than mouse/trackpad users. Which seems likely to me.
Agreed. I elaborated a bit more in a sibling comment about how many keybinds result in opening a pane and focusing it, and it’s just not built for being operated by keyboard. Although you could make the argument that using the mouse just hides all the latency. Scrolling through text buffers is super smooth… but at what cost?
> but for codebases that require a bit more language server support (eg. C++20 and sometimes Rust)
Unfortunately, for this use-case, neither Zed or Laplace will likely to fill the gap, as they rely only on LSP as Neovim. That's also my issue with both: They should focus more on providing features to support coding, not just speed.
Some corporate employees use a notebook loaded with extremely invasive and performance-degrading security and spying software that can't be uninstalled. When your available cpu and disk time is 10% of what the hardware can do, you need as efficient editor as you can get.
Don't need to install them if they are portable (most everything can be made portable with some work, see scoop packager manager for instance). As long as the company isn't batshit crazy and has the resources and IT spend to afford to use something like applocker, in which case I'd seriously recommend looking for other employment if you cannot get explicit guarantees about administrative access.
For me it's the latency. It's not a deal breaker, of course. It's more of a first world problem akin to I don't know, guitars? High vs low action if you know guitar "problems". There's no coding problem where it's dependent on speed of typing; programming is mostly about reading anyways. It's more about the feel of it, like we're picky about keyboards and touch feedback we get. I guess spoiled, but nonetheless...
Gonna pile up. VS Code with barely any plugins on M1 is noticeably slower than IDEs I've used 15 years ago on a hardware from 20 years go. Slower to render, slower to react to my inpit. It's bordering on unusable on a x86 laptop from few years back.
Better showcase on how ridiculous the tech stack is would be to open a 500 line file with a code and scroll. Startup isn't great either, though it isn't comically bad as it used to be.
So yeah, I want to see the authors of any desktop software to address this modern problem of writing slow UI. Otherwise I might assume they don't care.
What IDE do you use nowadays if not VS Code? I'm curious because I'm also using an M1 Mac and I've ran through the gamut (Sublime, PyCharm, Atom, etc).
Sublime mostly, not a fully-featured IDE I'd say. For front-end I'm using VS Code, that's only here and there, and that's where the struggle comes from.
Last time I've tried Idea/etc was quite a few years ago. It didn't feel great. But maybe I should force myself into it. Might be better on M1.
I also open regular Visual Studio every few months for C# on Windows, and while it's slow to start, the editor feels really solid, quick, and responsive.
Yes. I have an org issued machine with crap specs and dozens of repos I switch between all day long. Waiting 30s-2m doesn't sound like much but it breaks flow and leads to a lot of "what was I doing again...?" Sidetracks
Sounds like your org is bad at basic arithmetic. 12230s = 12 minutes per day minimum. Assuming an engineering salary at perhaps 100k usd /year, that is about 40,7 usd per hour, they would save money by giving you a max specced frame.work(2500$) after 307 days (maximum). Assuming you do this more than “2 dozen” times per day, as you say “all day long”, at minimum they would make that money back in 7.7 days. The same numbers for a max specced MacBook Pro (at 7200 usd) is 22.1 to 884,5 days.
I get mad at this attitude from some companies. It’s like telling a carpenter that they have to build a house, but are not allowed power tools. It makes no sense.
This is the case for most orgs with corp IT. Their KPIs are around security, which often manifests itself as a game of "how many security products can one run in parallel". Crapware like Cisco Secure Endpoint (not to mention Umbrella), Thycotic, Netskope, and whatever else is the current cool way for a corp to MITM itself and introduce kernel vulnerabilities.
This in turn puts departments at odds, as their argument for speed is turned into an argument against security, which is a very hard position to be in if your department is a few layers down the corp stack.
I don’t understand. How does speed implies inverse security, even with corporate blinders on? Let’s say the add all the bloatware in the world, how would a slower developmental speed compromise the security? That their ability to push code goes up and their potential for bugs increase?
Security solutions impact speed, rendering reasonable and performant machines borderline useless. There is no implication that working fast is bad for security.
We should be clear that it isn't ALL of corporate IT that is on board with this, or probably even the majority. Its the windows sysadmins that have to deal with non-technical end users, and are constantly being hounded about trivial shit like people clicking on phishing emails and that sort of thing. In fairness to the windows people, you probably wouldn't believe just how awful the majority of workers are with computers. So it's understandable why windows sysadmins become hyper paranoid and irrational in a lot of cases. The low pay doesn't help either. Windows sysadmin is usually a lower tier job within IT and is the most likely to suffer cost cutting and be forced to "outsource" security work to a pile of rotten security software. It's also entry level, and so sometimes they are only marginally better with computers than their end users.
Ideally, most programmers should be in IT or have some kind of alignment with IT and able to give some pushback about this during CAB for instance, and/or get some exceptions but that is increasingly difficult the more 'agile' an organization becomes and the more it seeks to silo infrastructure people from application people. A good IT department imo is one that doesn't do this and retains a more traditional culture where programmers are part of IT and able to actually influence the technical direction of the company, not just be treated like a product factory for business units.
Just from personal experience working as a programmer on the infrastructure side...complaining about windows sysadmins was the favorite past time of probably the majority of higher tier IT employees. It makes our jobs incredibly difficult for the same reason it makes application developers jobs difficult.
Problem is that most corps in my experience are run by such windows sysadmins, and when you're a subsidiary or two away from the IT department it doesn't matter whether you're all greybeards - you don't have authority. Best you can do is manage to fly under the radar.
On the other hand, you'd be surprised by just how many career programmers are completely inept at sysadmin work and have no sense for security (nothing like CI pipelines using personal credentials and committing keys into public repos), so just letting all programmers do whatever isn't a great policy either...
This assumed by the way that the speed goes to infinity, which is untrue. But the result would most likely be indistinguishable from instantaneous from the point of view of the developer.
I'm on the team working on Pulsar, the community fork of Atom. You have no idea how much we hear "Atom is slow", "are you making it fast?" etc. I have honestly yet to work out exactly what is meant by it. Startup times, sure, you are never going to get Pulsar/Atom or VSCode to launch as fast as a terminal editor or a super lightweight native one but that isn't how I personally use that kind of editor - once it is open it stays open for a long time. Keystrokes, context menus, highlighting performance, I honestly don't see where this perceived slowness is.
I'm not saying it isn't valid criticism but I guess the way I work with an editor just isn't the same as others who experience this.
Sometimes it’s actually speed that’s the issue (when e.g. opening massive text files) but usually “speed” is more about responsiveness in editing, text navigation, etc, which some people are very sensitive to. The time between action and reaction is best minimal as possible.
I have a sneaking feeling that the people who use only their keyboards to navigate are the ones who really notice latency in e.g. VSCode.
I navigate with the trackpad on a Mac and seem not to ever feel it, but I know others do not like this way of working, which is fair enough.
Lapce is interesting to me for other reasons: it is one of the few[0] GUI text editors with a remote dev option that matches what VSCode can do. And it might have a smaller footprint on the remote machine/in the container while doing it.
VSC’s remote dev support is very nearly non-negotiable for me now, so I say more power to them; I intend to try it again properly soon.
[0] there is another editor that was mentioned here recently that can achieve this with a plugin, but I forget the name
> Is the world really full of developers going crazy with frustration because they’re waiting on vs code to do something?
Absolutely. How new/fast is your developer machine? A lot of developers are working on computers that are several years old and may not have been that high-spec to begin with. It's generally not basic editing that's slow on it's own. It's trying to run several editor windows at once (say a frontend and several backend services) along with all the other things required for work: the project itself, compilers, video calls, etc.
As a reference point my 2015 MacBook Pro struggled with VS Code + Google Meet at the same time.
> Is the world really full of developers going crazy with frustration because they’re waiting on vs code to do something?
If programming in Rust on a medium-to-large project, you might be waiting minutes for your editor to finish checks to highlight compilation errors every time you save. That was me on a Rust project last year when I was trying to program on a 2019 macbook air with 16GB of RAM and 1.1 GHZ quad-core intel processor. Typical wait times to check what I'd written would be 30 seconds to just over a minute. It was excruciating.
I finally demanded the employer set me up with a cloud VM that I could use when working with that codebase, as the network lag with VS code opening the project remotely was so much more tolerable
A few years back, someone built a webpage that had various text fields with different typing latencies.
A bunch of my friends tried it, and it was really interesting to see that many of them were not bothered in the slightest by even quite high latency numbers.
Personally, I was mildly bothered by the "single frame of latency" example and _intensely_ bothered by all the higher numbers. It just felt really yuck to use; I would hate to be doing that all day.
I can't tell you what exactly it is, but yes: the world contains many developers going crazy with frustration - not because of a 30 second wait, but because of a 30ms render delay.
Similarly with monitors, 60Hz LCD panels are OK, but 120Hz panels are just so much easier on the eyes. At least for me. Try dragging windows around or scrolling quickly, and you'll see the difference between 60 and 120 very fast.
Frustration often comes with extensibility: adding extensions on top of VSCode that need to run at file save time (eg: formatters) can lead to pretty significant performance drops.
This extensibility is probably what made VSCode popular though, especially for web devs since the extension mechanism is JavaScript-based.
Makes me wonder if those Rust-based tools (Lapce, Zed) will have as much success with Rust-based extensions authoring.
a good example is magit on emacs, magit seems great, and i really want to learn it and use it, but its very slow (at least on windows its slow enough to make you unable to practically use it)
Yeah I find delays make me lose my train of thought and can be frustrating. Especially once you've experienced an editor where everything is instant (kakoune).
I think it's just that everybody has been looking for THE editor, and so it is natural that people would develop their own. I think what we're seeing is that VSCode is becoming THE editor (if it's not already there). At this point it's hard to compete. I think the biggest contender is IntelliJ, as many people really seem to enjoy it, but I would predict that it's going to be hard to fight against free.
Is anybody else finding Intellij more and more getting in the way in an obtrusive manner? Code completion suggestions are getting worse, formatting ability is basically none existent if your statement is missing a comma or a lambda, it keeps reindexing my local maven repo, code completions are slow to appear... I was a huge fan of their products but now I'm getting more and more annoyed. Maybe I'm getting old?
Several times I have been on the brink of trying out spacevim for java development , out of pure frustration but the amount of config and tweaking needed scares me. I don't need much, lightning fast auto complete, auto import and Google code formatter integration. One of these weekends I'll bite the bullet I think and set it all up.
I noticed that a couple of years ago. 10 years ago or so, Jetbrains was the gold standard. Then support and quality started to rot. Issues not resolved for years, esp. for Webstorm. Instead building new products and features I was not interested in. I needed proper tailwind support back then, not some cloud colab solution for enterprises.
Not sure about how Jetbrains does in general but I have zero hesitation paying for perpetual license of their all inclusive package. It is peanuts compared to value. I still use VS code to do some remote editing / debugging as it is somewhat better experience. Hopefully Jetbrains catches up in this department one day.
So yes. These two are THE editors for me.
I only deviate from these when I need to do Delphi / Freepascal development.
Notepad++ / Notepadqq are being used as in place hotkey invoked text editors.
I still try new ones out of curiosity but I have hard time understanding why any would succeed. How they're going to get the same amount of extensions / plugins in order to match functionality?
I had such high hopes for Sublime Text, but then development slowed to what seemed like a glacial pace, with every upgrade requiring another licensing fee.
I tried the same in my Linux terminal emulator, and it took 0.2s, when I added colors, 0.3s. That's 100x faster - maybe diff in VSCode means something different than running diff and printing the output? Did you include the time needed to open the files?
Yes, the files themselves open quite quickly, but I will admit that it's a complicated diff (lots of expected differences), and VSCode is not primarily a diff tool.
But also 10k line file should be nothing for a modern PC.
if vs code felt as responsive as emacs or vim, i'd use it. I don't really care about 'start-up time', and if I did then using emacsclient or some such with a daemon takes care of that issue entirely.
there is no convenient way for me to 'plug-in' the responsiveness of something like vim or emacs into vs code.
to be clear : responsiveness is things like opening a context menu of any kind, switching contexts, text drawing and blanking ; just things that add up to create a quick feeling piece of software. vs code/atom/whatever and other 'larger' graphic-heavy text editors feel slow.
It's not about speed in terms of absolute cumulative time. It's about the interleaving, the user experience of latency, and the effect that has on our cognition.
A few ms of noticeable latency here and there, a few hundred ms freeze every once in a while, it's maybe an extra minute per day in clock time. If it was just a 1 minute startup penalty, that would be different. But this 60,000 ms is split up throughout the working day into hundreds of small pauses, making the system feel laggy and unpredictable. If you're lucky, it's merely a subconscious drag on your attention. If you're unlucky it will, have you constantly breaking concentration to wonder "is my editor frozen? Oh wait, never mind." Hundreds of times a day.
Now contrast that to a text editor with literally zero instances of noticeable lag. It's not that it has zero latency, it's that the I/O latency on modern hardware is faster than our fingers and eyes can work. So we don't experience it.
Hundreds of noticeable pauses versus zero pauses. Once you cross the threshold below which our fingers type and brain can read, you're lag free. Getting a faster text editor doesn't just slightly improve the lagginess, it completely solves it.
They have a download page on their website that will give you a binary. Alternately, you can install it from Flathub[0] or see if they have packages for your distro[1].
Who knew that the existential crisis of the modern developer would be choosing between milliseconds of latency and the perfect shade of syntax highlighting :)
Just a bit of context here to explain the status of the project. The first line of code was started around 2018 as a personal project. And as of today, we still don't have anyone who works on it full time. We don't want to defend ourselves too much here, because there are very good quality code editors out there such as Helix, which is also community developed. But still, GUI is just such a beast of complexity, which consumes lots of time and energy which we already lack. That said, we had developed our own cross platform GUI toolkit called Floem, because as you may know there aren't any good ones that exist.
The journey was fun and challenging, but the aim of the project isn't a toy, and we believe by taking slow but firm steps, we'll reach production quality, one day. Before that, please do bear with us, and help us if you can (as in code).