Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Era of Visual Studio Code

blog.robenkleene.com

Post reply on HN
Print view View original

161–170 of 698 posts

Re: The Era of Visual Studio Code

#161

Post by httpsterio »

andrewstuart wrote: post #21

I'm not a fan of VS Code because everything is a plugin. And plugins are inconsistent, buggy, inconsistently documented, hard to use and find and update and goodness knows who developed them. Plugins can be duplicated, outdated, abandoned and incompatible. But worst of all, a big pile of plugins isn't a consistent integrated product vision. I gave VSCode a solid go, and I had to keep installing plugin after plugin, b…

I'd rather take an editor where I add in the stuff I need instead of it coming with all the xruft I won't be using. Visual Studio would be nice but the UI is way too cluttered for me and I can't focus if I can't organize the views as I need them. No issues with VS Code. I'd just wish it'd be possible to pop out the file explorer and git views into their own windows but I can use other tools for those so no harm there.

Re: The Era of Visual Studio Code

#162

Post by munificent »

I like the enthusiasm, but this article is a little too breathless to be fully believed.

> The most important thing I look for when choosing which tools to use is longevity.

In my time, I've programmed using Director, Microsoft QuickBASIC, FutureBASIC, THINK C, CodeWarrior, BBEdit, TextMate, Visual C++, Visual Studio, Sublime Text, Eclipse, Atom, VS Code, IntelliJ, XCode, and probably a few others I'm forgetting. I don't have any particularly strong attachment to any, except for maybe Sublime (which supplanted TextMate, which supplanted BBEdit).

Instead, what I've found is that IDE evolution is converging such that hopping between them gets easier and easier over time. The shortcuts and mouse behavior is becoming standardized, and the feature sets are getting more similar. These days, I just use whatever IDE is the "main" one for whatever language I'm developing in. Within a day or two, I'm up and running fine.

The only one I particularly enjoy using is Sublime and that's mostly for what it doesn't do than what it does. Sublime is fast and unencumbered, so it stays out of my way when I use it. I strongly prefer it when I'm writing prose for that reason.

Re: The Era of Visual Studio Code

#163

Post by Zenbit_UX »

Anyone else think it's weird they used the term "text editor" ~100x in that article but what they're actually just comparing IDEs.

It's weird to read an article comparing the most popular "text editors" of all time and not have one mention Microsoft Word... I'd expect notepad, open office docs and pages to get honerable mentions on such a list.

Re: The Era of Visual Studio Code

#164

Post by yepthatsreality »

mlboss wrote: post #134
yepthatsreality wrote: post #118

VS Code is nice for green developers, however I always encourage finding a different editor. This helps encourage exploration, customization, and configuration. You will need to take the training wheels off sometime in your career. Another reason to prefer other editors is they tend to stay out of your way. VS Code tries really hard to make you not even leave the window. Anecdotally, a previous colleague once sold me…

Biggest selling point for Sublime Text is speed.

Yes agreed. It’s miles ahead of VS Code in that department but I thought that was fairly obvious and overstated, so I withheld the criticism.

It always interests me when others don’t include speed in their requirements.

Re: The Era of Visual Studio Code

#165

Post by zeroxfe »

macinjosh wrote: post #156

If you want a text editor with longevity try vim or emacs. They aren't dependent on the benevolence of a greedy corporation. Over time VSCode _will_ be raided by the bean counters at MS and it will begin to track you, give you ads about MS products, and lock you in to their ecosystem. I'll never understand why a professional developer would give so much influence over their work to the likes of MS, JetBrains, etc. Su…

Two decades of vim here, and I switched to VS Code. As a "professional developer", it's just nicer to use, and makes me feel way more productive than ever. I definitely wouldn't call it a toy.

Re: The Era of Visual Studio Code

#166

Post by nickjj »

orange8 wrote: post #146
nickjj wrote: post #139

The thing that bugs me about VSCode is it's labeled as open source but a lot of pretty critical and interesting components are closed source so you have no idea what's going on under the hood. Normally that's not too big of a deal (I use plenty of closed source apps), but when it's Microsoft it's hard to trust what they are doing with that data. That and I feel that this promotes vendor lock-in at multiple levels. Ov…

What are some of all these pretty critical and interesting components you mention?

The biggest feature is probably remote. This is what allows you to have your code in a remote location (SSH, WSL and containers) and still get an integrated experience as if things were all running locally. If your app is Dockerized or you use Windows with WSL and you like intellisense, you're likely using this feature.

Some of the language servers for popular languages are closed source too, which is weird because I thought the idea of a language server was to work together so all editors could get excellent language specific features without having to reimplement the same logic in every editor.

That's not an exhaustive list, just what I know off the top of my head. I also vaguely recall reading something about a year ago about some core bits of the editor being written in C++ for performance reasons and those are closed source but I can't find a reference and don't know enough about the code base to track that down so I don't want to say that with any type of authority. Would be great if someone more knowledgeable in the area could track that down, or come up with a more exhaustive list of things that aren't open source.

Re: The Era of Visual Studio Code

#167

Post by orange8 »

pjmlp wrote: post #2

Given the talks from Microsoft's own React Native team regarding the 300x performance loss from Electron based apps, I am looking forward to the day it gets rewritten in React Native. https://youtu.be/IUMWFExtDSg?t=1146

I bet you are also looking forward to the day when web assembly kills js, and everybody stops using html and css.

Re: The Era of Visual Studio Code

#168

Post by yepthatsreality »

macinjosh wrote: post #156

If you want a text editor with longevity try vim or emacs. They aren't dependent on the benevolence of a greedy corporation. Over time VSCode _will_ be raided by the bean counters at MS and it will begin to track you, give you ads about MS products, and lock you in to their ecosystem. I'll never understand why a professional developer would give so much influence over their work to the likes of MS, JetBrains, etc. Su…

Tracking and advertising already happens via telemetry and suggested extensions.[0] However currently you can turn it off.

[0] https://code.visualstudio.com/docs/getstarted/telemetry

Re: The Era of Visual Studio Code

#169

Post by city41 »

Waterluvian wrote: post #133

> Learning software is an investment, and if you have to switch to another application later, you lose some of that investment. I think the author missed a critical fifth point that they hinted at here. In my opinion VSCode is trivially easy to be productive with and not much of an investment to get into. Whereas heavier IDEs and then Vim at the far extreme demand some serious “learn how to ride this bike before you…

Vim has another problem. Once you grok it, it's very difficult to use anything else. If I ever find myself in an editor without some kind of vim mode, I'm totally hating life.

Re: The Era of Visual Studio Code

#170

Post by TeMPOraL »

jimbokun wrote: post #149
TeMPOraL wrote: post #76

Earlier quoted context omitted.

Use Emacs - it's a big pile of stuff that's very well integrated, because the platform lends itself to deep interoperability - thanks to a strong conceptual model and extreme reprogrammability. :). Jokes aside, I guess what VS Code needs is to grow a strong community of people who care about the editor as much as what they do using it. Emacs has managed to do that, so it's possible.

It seems like Emacs shares the same product philosophy of VS Code. Outside of the core functionality everything is an ELisp/Javascript plugin. That explains Emacs amazing longevity, but as the article points out, Emacs longevity is actually a problem as its keyboard and UI conventions predate the modern conventions that came with Windows and MacOS.

It's a slightly different philosophy. Emacs is best viewed not as text editor with plugins, but as a Lisp Machine emulator with a text editor. The joke about it being an OS is more true than people think: what you get is a (2D, not 1D like shell) text-oriented programming environment, back from the times where "a programming environment" meant a fully end-user-programmable OS.

This has an important downstream consequence on the "plugin" ecosystem: since these "plugins" are better seen as small applications running on in a shared, restriction-free OS, they don't need a fixed and restrictive API to interoperate. The entire Emacs is the API, and as long as an elisp app follows conventions and plays nice, it will almost seamlessly interoperate with every other app. And in cases where it doesn't (e.g. you try to use two apps that do roughly the same thing), it's relatively trivial to patch out the conflicts yourself. Having an integrated debugger and REPL is also helpful :).

VSCode philosophy feels more restrictive compared to that.

As for the keyboard conventions, it's true and it impacts the market share, but that's a problem for almost any software that reaches longevity. Conventions come and go, so it shouldn't stop one from learning a tool that keeps proving its worth over decades. And in case of Emacs, if you don't like the default keybindings, you can quite easily patch them up to follow whatever convention you fancy :).

Terminology is a slightly worse problem because you can't patch that out if you don't like it - but then again, it's just a bunch of terms you need to learn; par for the course for any developer.

Post reply on HN