12 ms·

It's great to see more projects in the space, but for me it's not really about the editor itself any more, it's about the ecosystem and the extensibility. The a

• zygy 5y ago
  https://blog.robenkleene.com/2020/09/21/the-era-of-visual-studio-code/ https://blog.robenkleene.com/2020/09/21/the-era-of-visual-st...
  • thomasahle 5y ago
    It's interesting he values company management so much. What's stopping Microsoft from one day abandoning VS Code, like Atom was abandoned? Is Microsoft even making any money from it?
    • hizanberg 5y ago
      It’s a play for dev mindshare where they get to control the platform and have access to devs using their software, they have no intentions of making money from it directly only to maximize its appeal & marketshare. It’s a cross-platform dev environment they can easily deliver extensions to connect to their commercial products. There’s no point in them continuing to invest in fragmenting the dev community by developing 2 competing platforms now that they own GitHub so I’m not expecting to see any increased investments in Atom.
      • azalemeth 5y ago
        I didn't know atom was abandoned. That's sad. Do you mind linking to a release that states that officially? For me, plain vim is a great thing. My computer is hot enough without another electron app, and for that reason I've never tried VSCode (ium) -- I feel there is a vast amount I still have left to learn in vim, and although I've been using it for >10 years, I'm far from an advanced user. It just works, is fast, and matches my brain. Microsoft also has a very, very long way to win back my headspace. I take it this new editor -- which I will give a quick go to -- doesn't come with telemetry and nonfree core code, for example.
  • torh 5y ago
    I'm looking at the graph, and in 2019 the text editor popularity combined was a whooping 117%!
• kevincox 5y ago
  It is a chicken and egg problem though. The quality of the ecosystem can be improved with a really strong editor underneath. However bringing the ecosystem to the editor is incredibly hard. I think vim is a messy pile of hacks, and I would love to see that changed. Neovim is nice with the extend and evolve approach but I'm always looking for something that can really provide a clean base for extensions to build on. (Yes ,yes, I know emacs is an editor-writing IDE) On the other hand I see nothing about plugins here. I think the approach to extensions is a very important question to answer early on.
  • pradn 5y ago
    How about Emacs in eVIl mode?
    • Koshkin 5y ago
      The worst of both worlds?
      • drums8787 5y ago
        Nah, it's the best. A recent thread on this convinced me to try Doom Emacs. It's great and just doubled my nerd factor.
      • 1_player 5y ago
        Evil mode is better than VIM itself and a good editor for the Emacs operating system which previously lacked one.
        • alpaca128 5y ago
          Many people constantly recommending Evil mode don't seem to get why some use Vim. No, Evil mode is not better than Vim itself. For one it's slower, defining keybindings is much more verbose, everything outside the actual text file has completely different controls, and I lose most of the seamless interoperability with other terminal tools. And it runs within an environment that tries to be literally every text-related tool by itself, making it overly complicated in many aspects.
• m8s 5y ago
  Maybe I'm not the common use case, but when you say "because [Sublime] is that fast", what do you mean? Creating a new file in VSCode, for example, couldn't be any faster. Is it the case that you close VSCode often? Is it booting the application that is slow? This isn't criticism by the way, I'm genuinely curious since I hear this a lot.
  • robenkleene 5y ago
    VSCode is many times slower than most non-Electron apps, e.g., in the below examples it's 9 and 14 times slower: 1. It takes nine times as long as Vim to open a minified JavaScript file, and then format it with Prettier: https://twitter.com/robenkleene/status/1285631026648276993 https://twitter.com/robenkleene/status/1285631026648276993 2. It takes 14 times as long to open an empty text file than BBEdit: https://twitter.com/robenkleene/status/1257724392458661889 https://twitter.com/robenkleene/status/1257724392458661889 I'm just as surprised as you are that people do see it, that some people don't see it. I have no idea what the explanation is, but there's something radically different about me versus people who can tolerate VSCode's slowness (I'll use VSCode if I have to, but I'll avoid it if at all possible, just because it's slow).
    • floydnoel 5y ago
      I think what the poster you replied to may have been referring to is that the marginal cost once the editor is open is roughly zero. If VS Code is being used, a user can hit Ctrl/Cmd-N and have a new empty text field in no time. Similarly, opening a text file is so quick that I can't perceive any passing of time between clicking on it in the file tree and seeing the file open. Perhaps users with slower computers have a different experience?
      • robenkleene 5y ago
        The second example I posted, illustrating that VSCode is 14 times slower than BBEdit, was opening a file with VSCode already open (it's not obvious, but VSCode was already open in both recordings, so this difference has nothing to do with its launch time). There's some truth to your comment though, in that VSCode's optimizations are very on rails, i.e., if you go the slightest bit off the beaten path (like I opened a file from the Finder, instead of from the sidebar, in the BBEdit/VSCode video), then VSCode approach to optimization falls apart (you can find accounts of the tricks VSCode uses to appear fast online, there's a lot of smoke and mirrors based around specific workflows -- I think making a new tab is actually the example they use). It wouldn't surprise me if part of the reason I perceive it as so slow is I expect every feature to be fast, not just to most common ones. And I think this is a perfectly fair metric to measure by. Emacs, Vim, BBEdit, and Sublime Text are all fast at everything they do, therefore I think it's fair to call VSCode a slow editor, even if technically it's average for a couple of features.
• TacticalCoder 5y ago
  > I still use nano as my default editor for commit messages. You don't work with Git as a DVCS? Or you work with Git and Emacs but don't use Magit!?
  • mijoharas 5y ago
    I'll admit to doing that. Command line git is baked into my muscle memory now. (magit is brilliant, but for some reason it's never stuck with me, unless I want to interactively stage a few specific chunks, and then it's much nicer than using the cli).
  • ljm 5y ago
    I use magit extensively because it's an utter fucking marvel, but sometimes I'm in a shell without emacs open, or I have to run some internal tooling that wraps around git. My point overall was that I see all of these as a collection of tools. Which one I choose depends a lot on context, and it's served me well to be baseline comfortable with all of them rather than depending too heavily on my emacs setup.
• Rapzid 5y ago
  > I'm keen to see something as novel as light table play out again All these years and I was starting to believe I had imagined light table. How else could one explain no editors adopting inline, always-on evaluation?!
  • icholy 5y ago
    I think that Julia's Pluto notebooks are the closest realisation of that dream.
• dataflow 5y ago
  > On the flip side, I use sublime text as a notepad replacement because it's that fast. Try SciTE if you want something super lightweight!
• simias 5y ago
  It's interesting because I come from the exact opposite direction. I started with IDEs, then Emacs for almost 15 years, and last year I switched to Vim. Ecosystems change all the time, even if you've been coding in C for decades chances are that you've dealt with a bunch of build and package systems over the years. The more time passes the more I value ecosystem- and language-agnostic tools. Dummy completion, tag-based cross-reference (admittedly not completely language-agnostic, but close enough), find, (rip)grep, fzf etc... No setup, no configuration, it's lightning fast and it just works. I'm not arguing that my approach is better than yours btw, if you like more integrated environments then go for it. I just sometimes wonder if "kids these days" even consider that there's a world outside of Visual Studio and ultra-heavy language runtimes. The zen of a 10 line Makefile.
  • majkinetor 5y ago
    Yeah, give me generics and a language to pipeline them into anything I want. Full stop. Let Harry Potter and his friends play with magic.
  • zozbot234 5y ago
    LSP and Tree-sitter seem to have the right approach, aiming to provide a standard layer that can support a wide variety of languages and ecosystems throughout. Language-agnostic tools can interoperate with this approach too but they only provide very basic features, not really enough to compare well with existing workflows.
    • rodgerd 5y ago
      LSP seems like a real blessing for editor authors, since "it can't do anything useful with my preferred programming language" has been a big lock-in.
      • xpe 5y ago
        ?. This is a back handed compliment? Can you explain?
• deviantfero 5y ago
  This could probably help you, it's my emacs setup for typescript, it works like a charm: https://gist.github.com/deviantfero/45b9354b433f44450de51c827f63cc68 https://gist.github.com/deviantfero/45b9354b433f44450de51c82... make sure you add `:ensure t` if you don't have it automatically set to true. * web-mode for general html/css/typescript/javascript editing * tide + company for autocompletion * flycheck for eslint support * prettier for auto format on save if configuration is present lsp is good for many other languages, but for javascript/typescript it's just not there yet
• bjornjajayaja 5y ago
  VS code has nice features but man.. every time I close the editor an update gets applied. I uninstalled because of that. Lately I prefer purpose built IDEs for whatever task is needed. I’m over with editor evangelism. :) Funny thing is a lot of the features are... just like a file system or Perl script to rip through and replace strings.
• lallysingh 5y ago
  I'm an emacser, but I disagree. Most editors are awful. IDE editors are generally poor (name it, I've probably tried it). Large language ecosystems are only good when you don't need them. If they're just gravy, then life is good. If you need a lot of stuff to be moderately productive, that sucks. LSP is the shining hope here, but you suddenly get into questions about your build environment, and that's another rabbit hole just to get decent completions.
  • FractalHQ 5y ago
    > Most editors are awful. IDE editors are generally poor (name it, I've probably tried it). What’s awful about VSCode? Genuinely curious. I use it daily and enjoy it. I love all the extensions I have access to. > If you need a lot of stuff to be moderately productive, that sucks. I don’t see why I would ever not have access to my extensions, nor is it very difficult to copy-paste my extensions.json file to a new machine and press “install all”.
    • cnasc 5y ago
      > What’s awful about VSCode? Genuinely curious. - palpably slow on a recent 16-inch high-specced MBP - does a lot of extra distracting stuff that can’t be easily turned off (I know I opened a .java file, I don’t need you to open an extra tab that takes focus to tell me I don’t have a Java extension installed. I especially don’t need you to try and launch several Java-related daemons that you know I don’t have and then also put up some notifications about failure to find them)
    • lallysingh 5y ago
      VSCode is fine, not great. Nice scrollbar. Still rather mouse dependent, not enough keyboard navigation (e.g. for git, AFAICT), and tabbed layouts don't use large monitors well. I like many files visible at once to see context. Re:extensions: great when they work well. But they tend to move fast, and come and go fast. That makes combinations of them brittle. If they're conveniences, that's no problem. But if they're necessary parts of my workflow, then life can suck.
• mypalmike 5y ago
  In case you didn't know, you can reasonably use sublime text for commit messages by making your editor "subl -w".
• xenodium 5y ago
  > I use emacs not because I'm a neckbeard, but because I can script it to do whatever the hell I like. This. With some elisp knowledge, you can bend Emacs your way. No need to write full-blown packages. A function here and there can get ya very far. I wrote about this yesterday[1] [1] https://xenodium.com/emacs-dwim-do-what-i-mean https://xenodium.com/emacs-dwim-do-what-i-mean