Visual Studio Code 1.8 • Hacker News Board

Re: Visual Studio Code 1.8

#51

Post by octref » Wed, Dec 14, 2016, 10:33 PM UTC

netcraft wrote: post #44

mmanfrin wrote: post #8

VS Code is, along with Typescript and Vue, one of my favorite things to have entered my world in the past 6 months. They have been rapidly improving VSC and I am exceptionally happy with it.

Do you use typescript with vue? I had researched it at one point, though admittedly not too far in depth, but came away with a conclusion that vue doesn't lend itself well to types.

vue-class-component[0] seems to be adopted by vuejs org, and I'm planning to use it in my next project.

[0]: https://github.com/vuejs/vue-class-component

EDIT: Just saw this on twitter: https://vuejs.org/v2/guide/typescript.html

Re: Visual Studio Code 1.8

#52

Post by mattbierner » Wed, Dec 14, 2016, 10:33 PM UTC

protomyth wrote: post #43

Is there anyway to get user-defined macros? Sublime and JEdit handle them well and was wondering if there is something coming or a preferred extension?

No built-in support yet, but this new extension is worth trying https://marketplace.visualstudio.com/items?itemName=geddski....

The vim extension (https://marketplace.visualstudio.com/items?itemName=vscodevi...) also supports vim macros

Re: Visual Studio Code 1.8

#53

Post by berdon » Wed, Dec 14, 2016, 10:33 PM UTC

Tyriar wrote: post #31

berdon wrote: post #30

Earlier quoted context omitted.

+1 Now I only hope they add in hot-disk support. Sublime Text 3 checks to see if the currently opened version differs from the file system. If it does, it prompts the user to keep the current version or replace it with the disk version. VS Code just replaces the current version with the disk version and doesn't retain history so you can't undo this. I lost about an hour of work yesterday because I had a file open in…

FYI that's being tracked here https://github.com/Microsoft/vscode/issues/15749

Thanks Tyriar!

Re: Visual Studio Code 1.8

#54

Post by lambda » Wed, Dec 14, 2016, 10:34 PM UTC

rl3 wrote: post #47

Anyone using Visual Studio Code for Rust development? If so, how is it? https://areweideyet.com/ Going by feature set alone (plugins included) it appears like a good choice, though I've yet to try it myself.

I'm an Emacs user, so that's what I've written most of my Rust in, but I tried out VSCode and setting up all of the Rust integration, and it was pretty easy to set up and seemed to work pretty well playing with it briefly. Didn't seem to be worth switching from Emacs for, but I was fairly impressed, and will likely recommend VSCode for anyone looking for a Rust IDE who doesn't already have a strongly preferred editor or IDE.

Re: Visual Studio Code 1.8

#55

Post by seanmcb » Wed, Dec 14, 2016, 10:37 PM UTC

WA wrote: post #29

earthnail wrote: post #17

I know they're working on styling, but now that the titlebar is black, too (on Mac), I really, really would appreciate if the status bar would blend in, too.

Can't upvote this enough. One dev mentioned in a GitHub issue that the blue color is for branding reasons [1]. This is so absurd, it hurts. That status bar is the most distracting and annoying thing ever. See link for suggestions how to mitigate. I use the tip from the person named sysrpl. VSCode is unusable with that blue color for me. 1: https://github.com/Microsoft/vscode/issues/1884

We do have a plan to enable this - unfortunately it did not make 1.8 but we plan to work on it in 1.9. So you should have some additional options soon.

Sean - VS Code Team Member

Re: Visual Studio Code 1.8

#56

Post by miguelrochefort » Wed, Dec 14, 2016, 10:39 PM UTC

thenewwazoo wrote: post #41

miguelrochefort wrote: post #36

Earlier quoted context omitted.

You can't be serious.

I'm not sure why not. AFAIK that's still your only option if you want to debug NodeJS code headlessly.

What about conditional break points, call stack, time travel, watch list, live editing, etc?

Re: Visual Studio Code 1.8

#57

Post by WhitneyLand » Wed, Dec 14, 2016, 10:40 PM UTC

Why are people using this instead of WebStorm? It seems like:

- It a little faster for Typescript (but no better TS features from what I can see).

- A lot of people are trying it because it's new, or because they like MS tools.

- It's free

On the other hand WebStorm still has more functionality overall, a few less rough edges, and a more standard UI (some people don't like how MS Code doesn't have a tabbed doc UI).

My personal calculus is that WebStorm is so cheap, I would not allow my primary tool to be even 1% worse to save money. Also I like those crazy guys - they have been pushing out features very fast for years now.

Re: Visual Studio Code 1.8

#58

Post by wwalser » Wed, Dec 14, 2016, 10:42 PM UTC

amadeusw wrote: post #21

miguelrochefort wrote: post #13

Earlier quoted context omitted.

I'm confused. Did javascript people not use a debugger before VS Code?

It was console.log() all the way

The Chrome based dev tools have been an option for years using node-inspector. Had all of the basics that you would expect from a debugging. Breakpoints, step into/out/over, variables available at that location in the stack, REPL console etc.

Re: Visual Studio Code 1.8

#59

Post by WhitneyLand » Wed, Dec 14, 2016, 10:45 PM UTC

WhitneyLand wrote: post #57

Why are people using this instead of WebStorm? It seems like: - It a little faster for Typescript (but no better TS features from what I can see). - A lot of people are trying it because it's new, or because they like MS tools. - It's free On the other hand WebStorm still has more functionality overall, a few less rough edges, and a more standard UI (some people don't like how MS Code doesn't have a tabbed doc UI). M…

Downvotes? Would be interested to know which points were inaccurate.

Re: Visual Studio Code 1.8

#60

Post by laurencerowe » Wed, Dec 14, 2016, 10:45 PM UTC

thenewwazoo wrote: post #41

miguelrochefort wrote: post #36

Earlier quoted context omitted.

You can't be serious.

I'm not sure why not. AFAIK that's still your only option if you want to debug NodeJS code headlessly.

Running 'node debug script.js' will drop you into the command line debugger. It's a little painful though as the command line debugger does not have support for moving up/down stack frames.