Used this a few years ago in early stages before VS code remote was a thing. It's very useful to add some interface extensibility components into VS Code's framework. I suspect microsoft made some intentional design decision to make this harder to do in VS code's apis, totally eschewing any real editor extensibility in favor of a "apps in the editor, not extending the editor" design vs Atom's much more open ended allowance for modifications. For example, if you wanted to make a form builder in VS code for VS code extensions - that would not be usable outside of the Webview tab functionality without modifying the editor source. Glad eclipse foundation recognized this and is providing some groundwork to make a real IDE out of VS code.
Theia was also the first to provide support for running vscode-as-a-platform and run via web browser, at least support that was functional and working.
When comparing VS Code with Atom, vim, Emacs, others, an underappreciated fact is that extensions just work, and are very easy to install and configure, which has much to do with its model. Atom was unusable for me, because, as you installed extensions, something always broke.
This is also similar to the old Firefox vs Chrome. The former was great for power users, but it crashed a lot and Firefox installs of regular people were riddled with insecure extensions that broke the browser and that couldn't even be un-installed.
VS Code does have flaws, but having limited extensions is not one of them, IMO.
They don't "just work". There are many many extensions that require external tools in the path etc. and some even go as far as to try to download such dependencies (and leave them on the system). Generally one should definitely read the extension documentation and there may be some manual steps needed (meaning that they don't just work).
It's true that the most popular extensions work fairly well though.
For the purposes of the general end user who really doesn't care whether extra dependencies are on the system, it does "just work." Indeed, they might even want such behavior, that plugins manage their own dependencies without any end user input.
> VS Code does have flaws, but having limited extensions is not one of them, IMO.
Exactly. Of course as somebody who writes extensions I'd sometimes like the possibility to change stuff at a "deeper" level - like having multi-line text decorations. But as a user I really prefer the model to the Emacs' one. Emacs (and I guess *vim) works best if the user writes all the code themselves.
> an underappreciated fact is that extensions just work, and are very easy to install and configure
This is partially because of cultural reasons. VS Code was originally a code editor made for web developers, by web developers. It follows directly in the footsteps of Atom. Web developers, for good or for bad, value the user experience of software working out of the box so they tend to bundle everything. Systems engineers, those of the C/Python camp tend to optimize for efficiency and prefers the user to manually setup out-of-band binaries.
I've been using vim and neovim for over 15 years with many 10s of plugins and I can probably count on one or two hands when an update has caused problems.
Also use Arch for about as long.
It's so odd to me when someone says that updates break their vim or Arch frequently.
There are so many threads about it on /r/neovim that people have started to ask just which plugins actually work together cohesively without breaking [0], something that is not asked about for VSCode. Just go through their "Needs Help" flair and you'll see lots of issues [1]. For me, I also use tens of plugins but inevitably something breaks at least once every couple of weeks.
just use lazyvim[1] and be done with it! some people takes care of the compatibility and they are probably more competent than you (i mean a newcomer who starts writing their nvim config)
One of those threads is about lazy.nvim, not lazyvim. The other is a question about what to do after accidentally installing lazyvim with the wrong shell on windows, not about plugin updates breaking things.
Lazyvim is powered by lazy.nvim, at some point it'll break. These are example posts, you can feel free to go through reddit for more examples but yes Neovim does routinely break more for me than VSCode ever does, which is basically never.
it never has been my experience! i have used lazyvim distro for the last year or so and run some :Lazy update for time to time and usually i just need to close neovim and restart and it will all be working well..
I think i had an issue when they moved to conform.nvim from the deprecated language server based method but that's maybe about it (I deleted the nvim cache and it was all good after)
Your anecdote does not somehow counter dozens of others that clearly exist across the internet. Just because it works for you does not mean it works across the board.
I keep hearing of bugs and breaking changes in neovim, with no sign of it affecting the upstream vim. I am a little frustrated that neovim could give people a bad impression of vim from a stability/compatibility standpoint. Unlike emacs and atom, where you can modify the editor fundamentally, vim is extended with sandboxed scripting language(s) (I assume the same is true with neovim as well), so there's no fundamental reason why an update should break your plugins. Conflicts can occur due to overlapping hooks, but VSCode has the same problem. To be clear, I'm not suggesting people switch their text editor.
Would love to hear from a more seasoned vim user if I'm missing some egregious stumbles in vim's updates that affected their workflow.
Yeah I'm always amazed how Microsoft can make both the best performing electron app, Vs code, and the absolute worst one in ms teams. At the same time. Clearly zero coordination going on there :(
