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

VS Code Roadmap 2018

github.com

Post reply on HN
Print view View original

111–120 of 236 posts

Re: VS Code Roadmap 2018

#111

Post by omaranto »

SiVal wrote: post #52

I'd love to have an editor scripting language in VS Code that would be a lighter-weight way to create an editing macro than building an extension. Despite the annoying scripting languages, both vim and emacs get a lot of their power and popularity by enabling users to easily add little, custom editing features that they can then bind to keystrokes. Not a macro recorder, but a real scripting language in which cursors,…

The scripting language would most likely be JavaScript, of course.

I don't use VS Code and I'm surprised there isn't already a lightweight way to run some JavaScript code to script the editor. Are you saying you need to bundle up any code you write in a proper extension before you are allowed to run it? Sounds bureaucratic to me, VS Code should learn from Emacs.

Re: VS Code Roadmap 2018

#112

Post by Sir_Cmpwn »

Fuzzy_Logic wrote: post #93
bunderbunder wrote: post #90

Earlier quoted context omitted.

To extend on that, dotnetcore is dead in the water without a decent and supported cross-platform development experience. Visual Studio and vsmac get the job done for now, but for the long run they need something that also works on linux and is consistent across all three platforms.

VSCode and the dotnet cli tooling fill this role on Linux. The tools are consistent across all three platforms.

I've had no end of trouble using .NET on Linux in the past couple of years. Most of my existing projects are broken, too.

Re: VS Code Roadmap 2018

#113

Post by Vinnl »

balefrost wrote: post #89
Vinnl wrote: post #79

Earlier quoted context omitted.

> some don't like the electron-based thing/performance It's mostly not liking Electron-based, performance is very reasonable for VSCode, I think. As for the end-game: it's most likely luring you into Azure. Tight integration with a proper editor/IDE might give it an edge over competitors.

One very specific performance metric is startup time, and Sublime beats the pants off VSCode in that department. Creating new top-level windows in VSCode is also annoyingly slow compared to Sublime (presumably because it's spinning up a new browser context). Other than that, it seems snappy enough.

I'll give you that, startup time could be better. I don't really consider that much of a problem, but I can see how people would disagree.

Re: VS Code Roadmap 2018

#114

Post by irontoby »

isthisnagee wrote: post #94
manyxcxi wrote: post #76

Earlier quoted context omitted.

> I’m not monogamous with my code editors I’ve always wondered why some people seem so married to a single editor. Based on the file type or context I might bounce between a number of them. I used to use Sublime Text a lot, but that’s been completely replaced for me by VSCode. I use IntelliJ IDEA predominantly for Java, Groovy, Python, Kotlin, PHP. I’m not a fan of its type hinting for JS or suggestions for HTML/SASS…

I’m not married to an editor so much as my bindings. I’d really hate to use an editor/ide that doesn’t have a decent implementation of at least some vim bindings, though I have to sometimes. Ultimately I think it’s familiarity and a subtle fear that learning any new system will be a time sink.

> I’m not married to an editor so much as my bindings.

Agreed, and it's extremely annoying that VS Code has different default bindings on different platforms. I switch between Windows and Linux a lot and there's no simple way to e.g. say "use the default Windows bindings on Linux" or vice-versa.

I have to manually create my own keybindings and then copy them to every machine and then bother with keeping them in sync.

Re: VS Code Roadmap 2018

#115

Post by jeffisabelle »

manyxcxi wrote: post #76
veidr wrote: post #2

VS Code is such an excellent open-source project, and also such a great tool despite the obvious and much-bemoaned inherent disadvantages (aka "tradeoffs") that come with being an Electron-based app that it, along with its cousin TypeScript, fundamentally changed my perception of Microsoft. I'm not monogamous with my code editors and typically have a few of them open. These days, I notice VSCode is very likely to be…

> I’m not monogamous with my code editors I’ve always wondered why some people seem so married to a single editor. Based on the file type or context I might bounce between a number of them. I used to use Sublime Text a lot, but that’s been completely replaced for me by VSCode. I use IntelliJ IDEA predominantly for Java, Groovy, Python, Kotlin, PHP. I’m not a fan of its type hinting for JS or suggestions for HTML/SASS…

> I’ve always wondered why some people seem so married to a single editor.

I'm thinking exactly opposite. I wonder why people change their IDE's/Editors so much between Eclipse/Visual Studio/IntelliJ or between notepad++/sublime-text/atom/VScode/coda/text-mate etc.

What's wrong with using vim or emacs and being happy rest of your career? It's funny so many of my colleagues kid me by saying "emacs is a great operating system but it lacks a good editor" without ever trying it while I'm using emacs without a problem for the last 6-7 years and people around me changing their editors every year to "popular editor of the year" for better features/performance.

Re: VS Code Roadmap 2018

#116

Post by omaranto »

Tehnix wrote: post #107
pbiggar wrote: post #20

Earlier quoted context omitted.

Yes, absolutely. I'm running vim in iterm2, and I haven't had time to figure out why it's slow. Things that are really slow in vim are scroll speed, a 1s-ish pause when ALE fills the quickfix window, and an undiagnosed merlin-related pause when opening ocaml files. So scrolling is slow. Terminal related? Maybe - terminals are slow. But when highlights an error in elm or ocaml code, scrolling becomes unusably slow (no…

I definitely share the sentiment that Spacemacs is slow, which annoys the crap out of me (for a lot of things it feels less performant than Atom/VSCode because people don’t write things in an async way in elisp often it seems). With regards to vim though, there is no reason for it to be slow, except for some specific plugin pulling you down. Are you using synchronous linters? I thought Ale was async. I would also rec…

It's not just plugins slow Vim down, a few things that come with Vim are slow too.

The worst is probably language specific support for LaTeX files, particularly syntax highlighting, there is even a tex-slow (http://vimdoc.sourceforge.net/htmldoc/syntax.html#tex-slow) entry in the Vim manual. On my old netbook (haven't heard that word in years!) it was so bad Vim lagged behind my typing, and I'm not particularly fast. I turned off syntax highlighting which fixed the lag, but missed it so much I switched to Emacs instead (and discovered AucTeX which is fantastic, so I wouldn't switch back now).

Re: VS Code Roadmap 2018

#117

Post by Sean1708 »

oaiey wrote: post #97
bunderbunder wrote: post #90

Earlier quoted context omitted.

To extend on that, dotnetcore is dead in the water without a decent and supported cross-platform development experience. Visual Studio and vsmac get the job done for now, but for the long run they need something that also works on linux and is consistent across all three platforms.

Actually the C# plugin for VisualStudio Code does an amazing job supporting .NET Core (on any platform). I stopped using VisualStudio in favor of Code in regards of .NET Core development.

I think bunder's point is that VSCode is the "something that also works on linux and is consistent across all three platforms".

Re: VS Code Roadmap 2018

#118

Post by salvar »

davedx wrote: post #31
veidr wrote: post #5

Earlier quoted context omitted.

I upvoted you to try to offset the misguided downvotes. That is indeed the worst thing about VS Code. I have my computer configured so that most file types open in Sublime Text for that reason. For projects with a lot of TypeScript I'll open a project folder in VSCode, and then just leave it open indefinitely. Because that part is annoyingly slow, as you say. I find it less annoying than Slack, though — seems to me t…

Why do people use desktop Slack? I always run it my browser, I just don't see the value proposition of a native application?

To me a native application just feels more... native. If everything is in the browser then the OS just becomes a secondary thing.

Re: VS Code Roadmap 2018

#119

Post by Sean1708 »

yodsanklai wrote: post #19
ssijak wrote: post #3

As much as I wanted to like and use VS Code, Electron base still ruined it for me. If it was some other app where I do not expect instant snappiness and lower memory usage, for example, Slack (also Electron app), I would swallow it, but for an editor, I can`t.

> Electron base still ruined it for me It works just fine for me. It's just as usable as any other editor. It slightly less snappy that vim in a terminal, but it doesn't make much of a difference most of the time. I still use vim occasionally though in some contexts (single file editing, constraint environment...).

I think there are a lot of people who open and close their editors pretty regularly, I can imagine that the start-up time for VSCode can become quite significant to those people.
Post reply on HN