15 ms·

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 waiti

• tasn 3y ago
  Nowadays I just assume "lighting fast" means "written in Rust". Even if it's actually slower than the status quo. I'm a Rust fanboy, so not dunking on Rust. Just an observation.
• Fraterkes 3y ago
  Vscode is nearly unuseable when my 5 year old thinkpad isn't plugged in. So yeah.
• franky47 3y ago
  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.
  • maleldil 3y ago
    I don't know about Lapce, but the plan for Zed is to have WASM extensions.
• mafuyu 3y ago
  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.
  • bemusedthrow75 3y ago
    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.
    • mafuyu 3y ago
      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?
  • dleink 3y ago
    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!
    • saurik 3y ago
      Something actively dropping inputs is an entirely different category of problem than it merely being slow to process them.
      • dleink 3y ago
        Yes, But for "confidence in inputs" the difference doesn't matter.
        • saurik 3y ago
          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!
• jahsome 3y ago
  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
  • jonathankoren 3y ago
    What are you waiting two minutes to do?
    • formerly_proven 3y ago
      With corporate Windows laptops the real question is "what aren't you waiting two minutes to do?"
    • jahsome 3y ago
      My machine to respond to double clicking an icon, or using Windows search, or open teams (just kidding that one takes closer to 10).
  • Cort3z 3y ago
    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. Edit: typo
    • reaperman 3y ago
      Except carpenters bring their own tools, so they can determine the price: value that’s right for their pocketbook.
• baby 3y ago
  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.
  • FireBeyond 3y ago
    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.
    • andrepd 3y ago
      I'm happy with it even with "slow updates". What features are you looking forward to?
  • jlengrand 3y ago
    Not that I disagree, but IntelliJ has a free version, and they're building up Fleet as an attempt to compete. Future will tell.
  • FpUser 3y ago
    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?
  • pandemic_region 3y ago
    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.
• antisthenes 3y ago
  Okay, just as a counterpoint, I opened 2 10,000 line files and tried to do a diff between them in VSCode. It took more than 20 seconds? Yes, it breaks workflow and is incredibly slow. Just like refreshing elements in UI shouldn't take multiple seconds, or a webpage shouldn't take multiple seconds to load on a good connection.
  • stracer 3y ago
    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?
    • antisthenes 3y ago
      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.
• stracer 3y ago
  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.
  • mattlondon 3y ago
    You're probably not going to be able to install random binaries from the internet on those kinds of machines though.
    • stracer 3y ago
      Sadly true... Maybe in a few years, if it gets popular enough, and the key decisionmaker gets wooed into allowing it.
    • akdjidensb 3y ago
      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.
• tomlin 3y ago
  They are saying it's made in rust, so they are probably trying to counter concerns.
• Keyframe 3y ago
  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...
  • bemusedthrow75 3y ago
    Hm, except high action is also a positive choice for some, not an inherent problem. (Though I like the attempt at an analogy and I see how it works for you at least) I am a high-action player —- I know I know, a monster! (but also a brass and heavy glass slide player)
• spullara 3y ago
  Just a bunch of people optimizing for the wrong thing.
  • rstat1 3y ago
    Optimizing for efficiency and performance is never "the wrong thing"
    • spullara 3y ago
      Optimizing for efficiency and performance over utility is absolutely the wrong thing.
• systems 3y ago
  for me its the plugins speed 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) in short, speed changes everything
• jwells89 3y ago
  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.
• bemusedthrow75 3y ago
  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 Update: Zed is that editor.
• veber-alex 3y ago
  It's like phones with 120Hz displays. You don't know you need it but once you have it it's hard to go back.
  • bloopernova 3y ago
    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.
    • FpUser 3y ago
      I can spot the difference but the value proposition is zilch to me. I would not pay 1 extra cent for it. If I was a gamer this would of course matter.
• serf 3y ago
  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.
• myaccountonhn 3y ago
  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).
• xutopia 3y ago
  If you pair program every ms counts. In video conference another half second does a huge hit.
• deleted 3y ago
  [deleted]
• SCdF 3y ago
  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.
  • nox101 3y ago
    my machine must be faster than yours. I have both. I can't tell the difference
    • lrhegeba 3y ago
      i guess which and the number of extensions will have a significant effect on lag
      • Bjartr 3y ago
        Also, some people are just more sensitive to it than others.
      • robin_reala 3y ago
        Also, size of files. Less of an issue for typical codebases, but VS Code historically has slowed to a standstill on anything remotely large.
        • nox101 3y ago
          I regularly work on a code base with 250k files. Haven't noticed any slowdown
• akdjidensb 3y ago
  It's less about waiting for vscode to do something and more about the general feel and experience of movement and typing in the editor. "Speed" is probably the wrong word, it's latency that matters.
• pcthrowaway 3y ago
  > 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
• Daeraxa 3y ago
  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.
  • maccard 3y ago
    > 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 Would you consider something like emacsclient's approach - a daemon running in the background that a window connects to?
• danielheath 3y ago
  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.
• giancarlostoro 3y ago
  As someone who owns a Sublime Text license if its not an IDE it better be as fast as Sublime or im just going to use Sublime instead.
• nicoburns 3y ago
  > 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.
  • deleted 3y ago
    [deleted]
• rplnt 3y ago
  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.
  • jmrm 3y ago
    Some people need to use at least one time in life IDEs like Visual Basic 6 in a Pentium 4 to feel what it's like to use a fast IDE
  • pwython 3y ago
    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).
    • rplnt 3y ago
      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.
• camel_gopher 3y ago
  Is it as fast as vim or emacs? If not then a tough sell from my view. Same with chewing up cpu cores.
  • School-Cotton 3y ago
    Emacs is not known for being particularly fast.
• perrygeo 3y ago
  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.