Other than that, it's hard not to be impressed by how quickly they made another release. Congratulations!
Visual Studio Code 1.7.1
11–20 of 145 posts
Re: Visual Studio Code 1.7.1
#12Electron is a great framework. I've used the same applications on several OS's, each seemed stable and fully functional.
Re: Visual Studio Code 1.7.1
#13Electron is a great framework. I've used the same applications on several OS's, each seemed stable and fully functional.
I'm curious why Atom gets so much crap for being an Electron app, whereas VS Code is generally praised for it's speed. Are they doing something significantly different from each other?
Re: Visual Studio Code 1.7.1
#14Earlier quoted context omitted.
I'm curious why Atom gets so much crap for being an Electron app, whereas VS Code is generally praised for it's speed. Are they doing something significantly different from each other?
Yeah, their JavaScript is better. Electron has nothing to do with the speed.
Re: Visual Studio Code 1.7.1
#15Electron is a great framework. I've used the same applications on several OS's, each seemed stable and fully functional.
I'm curious why Atom gets so much crap for being an Electron app, whereas VS Code is generally praised for it's speed. Are they doing something significantly different from each other?
In my day-to-day usage I'm not seeing any significant performance differences between Atom and Code, but that may just be a function of my particular use cases, or it may well be that newer versions of Atom have, at least somewhat, caught up to VS Code.
Re: Visual Studio Code 1.7.1
#16Re: Visual Studio Code 1.7.1
#17I'm using WebStorm mostly but I'm not "married" to any particular IDE, I've used others and I switch around relatively easily.
I'm doing a slightly different programming style when it comes to types: I don't use "no types" or TypeScript or Flow, but I do use "types", sort of. What I've done is JSDoc the hell out of my code. There is not a variable without a JSDoc or Closure compiler type annotation. Those are all just comments, so I don't need to "Babel" my code. Since I'm using the latest node.js and only those ES 2015+ features that it happens to support that is enough.
It works because the IDE (WebStorm) uses the JSDoc comments to infer types, and the IDE itself provides the equivalent of what something like Flow or TypeScript wold do.
Well - to a point. I'm not really satisfied. I always keep submitting tickets for WebStorm, and while they have solved a lot there still are too many fundamental issues with how they infer types. For example, I get offered object properties from files I don't even include in the file I'm in, not even indirectly! For example, "mocha" might have an internal (!) variable somewhere that has a property "data". Since I have a property "data" too I get the definition inferred from that mocha file, which makes no sense, since a) I'm not even in a test file that includes mocha, and b) even if I was, that is an internal variable that's not exported.
They don't seem to be able to solve this issue, and with new EAPs I often get two steps back for very hard-fought step forward. To be honest, I believe their code for inferring types in Javascript is just too messy, it seems each time they plug a hole it doesn't last long and two new ones appear.
However, when I try VStudio it seems that I only get type inference if I use TypeScript?
I would be open to using "Flow", but I really, really don't want to have a different language. I just want types and standard Javascript! Yes I know TypeScript appears pretty much the same as ES 2015, but it still rewrites my code. I would not mind, except that there really is no reason at all since ES 2015 has everything I need (I don't use classes or even prototypical inheritance, no inheritance at all, only composition and functions).
From my limited research the best albeit not quite satisfactory solution for my case still remains only WebStorm? I mean, if they fix the problems introduced with the EAP version a few weeks ago when all JSDoc based type suggestions stopped working I can live with that state.
It would be nice though if I could have a "comment based type system" (JSdoc/Closure compiler) or Flow. How would VStudio do in this scenario?
Re: Visual Studio Code 1.7.1
#18Electron is a great framework. I've used the same applications on several OS's, each seemed stable and fully functional.
I'm curious why Atom gets so much crap for being an Electron app, whereas VS Code is generally praised for it's speed. Are they doing something significantly different from each other?
Re: Visual Studio Code 1.7.1
#19Can I say that I really like the speed of these updates? The team Microsoft really seems to be invested in this free code editor. And a lot of the features are cool, however I really like: | Help > Keyboard Shortcuts Reference brings up a printable PDF reference sheet of VS Code command keyboard shortcuts. Keep this reference handy and you'll be a VS Code power user in no time.
It's great strategic marketing. Making Visual Studio Code costs a fraction of what Microsoft spent on the Surface RT marketing campaign (as an example), and the benefits to their image are much more powerful and long-lasting.
The Microsoft brand has been completely reborn in the eyes of developers over the past few years. The lows of 2007-2010 seem a distant memory.
Re: Visual Studio Code 1.7.1
#20Earlier quoted context omitted.
I'm curious why Atom gets so much crap for being an Electron app, whereas VS Code is generally praised for it's speed. Are they doing something significantly different from each other?
I suspect there's some bandwagonism at play in some of it, but I think the VS Code team has generally applied lessons learned from some of Atom's more obvious performance shortfalls (large file handling, for example, for which support was added very incrementally). In my day-to-day usage I'm not seeing any significant performance differences between Atom and Code, but that may just be a function of my particular use…