Can 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.
The team Microsoft really seems to be invested in this free code editor.
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.
> 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.
Maybe in the eyes of some developers - for many of us who are still dependent on MS products that haven't been getting much attention (SQL Server and it's related BI tools), the lows are still getting lower. Sure, there's improvements in the overall functionality (with SQL 2016) - but trying to get bugs fixed (or even acknowledged) for anyone but a fortune 500 company is still an exercise in futility. Trying to get support via MSDN forums (as is a purported benefit of our multiple MSDN developer licenses) is a joke.
We're dropping any MS related tech that we can, because frankly it feels like we're throwing money away when we could be getting the same (or, most likely better) support using open source technologies instead.
I have connect issues that have been open and unacknowledged for going on 4 years now. Meanwhile, I have posted bug reports to open source projects on github and received responses back with 5 minutes of hitting submit.
VS Code is great, don't get me wrong - but the experience with that project is a far cry from the products we've PAID MS to use and develop with.
Would love an answer on this one. I implemented the MSFT BI stack into a product for no other reason than we were already using MSFT. However, each time I look at OSS BI stacks I feel like I'm losing out on something.
The Per-Core licensing cost for SQL Server and now Windows too is really a pain, and getting worse with more and more cores showing up in boxes.
We've got some servers that would be happy to putt along on 2-4 cores, but we're struggling to find anything less than 12 cores with our managed hosting provider - so we have to pay for the extra cores, even though we don't want to use them.
"Consolidate!" - sure, but we can only do that so much. Some stuff we have to deploy regionally for latency reasons, other stuff can't share hardware for PCI compliance reasons.
We don't want to have production environments sharing with dev.
Why don't you just run a 4-core VM on your 12-core server and NOT share it with anything else? Wasting the other 8 cores would be worth the licensing savings.
So, because the personal issues you have aren't being addressed, the products aren't getting attention? That's more than a bit of a stretch...
I get frustration with a specific bug not getting fixed. That being said, links to the MSDN posts you've made that have gotten 0 MS attention? Because in my experience, even if the issue can't be fixed, someone at least responds letting you know they're looking into it.
Further, if you're paying for support, I've never had a bug go completely unaddressed.
I don't get the end game though, what is the strategy?
Ultimately, if you end up using Linux .net core + typescript, they seem to be killing off visual studio, IIS, Windows Server, etc.
For what? Azure, glorified hosting that might end up a race to the bottom vs AWS & GCE? Selling SQL server licences?
I just don't get the strategy. I'm genuinely asking, where is this actually taking them apart from burning a bunch of money making free tools? Why are they making .Net core?
IMO the long term strategy is Enterprise Javascript on one hand and Azure on the other one.
Azure is the obvious one.
Enterprise Javascript is basically:
1. Javascript is probably the most popular programming language at the moment (or at least top 3).
2. Since the creation of Node Javascript has entered the realm of back end services applications.
3. There's a lot of Javascript being written these days, and those lines of code will have to be maintained.
4. A large enterprise will need good tools from a solid, respected vendor, preferably one that has a great image in the developer community.
5. These tools, Open Source but beefed up with enterprise extensions, will cost $$$.
Microsoft was losing the back end completely, on the long term. It has already lost the frond end: web, Android, iOS. Now it's clawing its way back with its back end stacks or at least with tools meant for Open Source stacks.
Mark my words, after this huge flurry of development to mark Visual Studio Code as the leading cross platform "light IDE" (ahead of Sublime, Atom and maybe even ahead of some "heavy IDEs" such as Eclipse or Netbeans), Microsoft will release proprietary extensions, especially things targeting big enterprises.
In my eyes, this is a win-win situation. Microsoft still makes money, developers don't get EEEd like in the bad old 90s, etc.
>> There's a lot of Javascript being written these days, and those lines of code will have to be maintained.
Maintained and supported. How many JS libraries have developers jumped on, only to see them die a few years later? Backbone JS is the first that comes to mind.
Everybody was using it, but since then, it's pretty much fallen by the wayside and there is still a ton of Backbone code out there that needs maintaining until those projects can transition to something else.
Having a larger enterprise company maintain a library like Typescript when you know its going to be stable and maintained for some time as opposed to a smaller library where the creator just decides to pack it up and leave everybody hanging just seems like a smarter move to me.
The last few commits appear more about cleaning up some of the documentation.
I guess on Jeremy Ashkenas twitter feed he called Backbone "finished" in terms of API and feature set after the 1.0 version. When you look at the contributions graph, its practically non-existent: https://github.com/jashkenas/backbone/graphs/contributors
Then when you look at the other libraries in the ecosystem, its like a ghost town.
backbone.forms - Open Issues: 172, Issues closed in 2016: 14, Last Release: Jan 21, 2016
backbone.localstorage - Open Issues: 45, Issues closed in 2016: 1, Last Release: Jan 22 2015
backbone.paginator - Open Issues: 20, Issues closed in 2016: 7+, Last Release: Feb 3 2016
backbone.validation -Open Issues: 79, Issues closed in 2016: 1, Last Release: May 8 2015
So not only is interest waning, the creator has called the library "finished" with not much more in terms of features coming and the ecosystem surrounding Backbone has all but dried up. I would be hard pressed to say it still has a bright future.
Maybe the end game is the same as it always was: find the next profitable thing and leap on it? Microsoft is opportunistic. They were a major UNIX vendor in the '80s (Xenix); then they were married to IBM with OS/2; until one day they weren't.
Microsoft has traditionally been the one to get the hate for this because their moves were so brash in the '90s... But the other big tech companies aren't any better. Apple is a friend of open source and standards only when it happens to suit them. Google does lots of open source but they want to be the ones holding the reins at all tiems (Blink, Android, etc.) Facebook spends a lot of money on looking smart and friendly to developers so that we'd ignore the Orwellian pile of information they hold on most people. Etc.
Microsoft in the 1990s, had tried to find a replacement for DOS partnering up with IBM. Commodore had the Amiga, Atari had the Atari ST, and Apple had the Macintosh and their operating systems were better than DOS. So out of an advanced DOS project came OS/2 and then the GUI for OS/2. IBM had their own OS/2 and Microsoft had their own OS/2 as well.
Microsoft was working on Microsoft OS/2 NT 3.0 when they broke off from IBM, and then renamed it Microsoft Windows NT 3.1 using the Windows 3.X GUI. Microsoft also pushed Windows 3.0 and 3.1 that loaded on top of DOS. IBM had OS/2 2.0 that had WIN-OS2 to run 16 bit Windows apps. Then companies quit making OS/2 native apps and made 16 bit Windows apps instead because OS/2 could run them as did Windows.
The big blow to IBM was Microsoft's Windows Tax to OEMs, that is based on how many computers they made, even if Windows was not installed on the new PCs. So if someone wanted to install IBM's OS/2 or Next's Nextstep for Intel chips, or BeOS for Intel, they still had to pay Microsoft the Windows tax. This forced OEMs to preinstall Windows, because they already paid for it with the Windows tax.
So it was a combination of OS/2 running 16 bit Windows programs and companies not wanting to make an OS/2 native version, and Microsoft marketing Windows to be used instead of OS/2 by bundling it with every OEM PC sold, that stabbed IBM in the back over OS/2.
Yes, Microsoft in the 1990s were ruthless and even bundled Internet Explorer with Windows 95 OSR and Windows 98 that got them investigated by the DOJ for antitrust issues.
In 2012ish as a freshman intern at Microsoft, I asked Will Kennedy (then CVP in Office) how did he feel about people pirating Office apps. He said that they would rather permit people to use illegal versions of Office than have them use their competitor's tools. Essentially he was saying Microsoft would rather people use their products free of charge rather than using other products as it promotes Microsoft image and helps Microsoft dominate the workspace. Promoting VSCode vs Visual studio are not competing efforts - the two tools are solving different problems in different work environments / tech stacks. They're simply trying to branch out to permeate more of the workplace, and it's working. Now that I'm in a startup in SF, I look around and I see some people switching from Sublime to VSCode for our web/backend stack, who would never ever use Visual Studio (100% macs here).
I have used Atom for about one year and then went back to Sublime. I do mostly back-end web development, in various languages.
I believe Sublime is a superior product in terms of performance and stability.
Reasons for switching back:
1 - Atom has some long-standing bugs that compromise its usability (e.g. there is a bug where you basically can't scale down a window after it was maximised: https://github.com/atom/atom/issues/10720 )
2 - Atom is slower, you may think a fraction of a second when opening a file or doing a search should not make much of a difference but, when you are using an editor every day for many hours, it ends up affecting your productivity.
PS I liked VS Code but it's different enough from the other 2 editors that it would take time for me to become proficient with it. I especially liked VS Code's debugging features.
Yup, Sublime Text rules. I still use 2.0.1 at work (on a Mac) mainly for Perl and JavaScript. It always works, it's fast, doesn't ever crash. I didn't like VSCode that much (mainly have a problem with the toolbar on the right and don't want to learn new key bindings/menus etc). Also I don't use debuggers that much, so it's a useless addition to VSCode for me. Atom is a lot like Sublime in terms of usage, but it's painfully slow. It is getting a bit better with every new iteration though. I'm using Atom at home for learning new stuff, as Sublime's widgets are fairly different from the general UI in Linux (looks like an editor from outer space) and Atom tends to integrate somewhat better.
No, but if it's not open source and multi-platform (at least Linux and Mac) then I see no reason to switch. That's why I probably ignored it, in fact; also why I keep checking Atom out.
Not op, but I definitely preferred sublime to atom. I have since swapped entirely over to vscode, though, and I have been using it to write / compile / debug Node.js and c# / f# dotnetcore backend applications without many complaints.
I went back to sublime as I had too many stability issues with Atom. You can throw megs of data at Sublime (if needed) and it absorbs it, Atom grinds to a painful death.
> VSCode vs Visual studio are not competing efforts
Yet. Little by little, rather than invest in windows-only vstudio, they'll enhance code until it's building all the same stuff as studio and then they'll announce how amazing code is and stop talking about studio alltogether.
When MS ghosts a product, you know what its future is.
I think the lock in using API or platform is no longer necessary. Their well-integrated services in terms of safety, security, ease of use and reliability will sell on their own. The most important computing battle is on the cloud - get developers to build their tools using MS technologies and then provide much better performance and integration on Azure. If open source implementation of .NET CLR is 10% slower than the one on the cloud, they are saving users 10% in revenue by running it on Azure. I believe Visual Studio Code was supposed to be a website. I think they may have figured out that the web isn't ready yet for such functionality and ended up with a compromise. I can see a future where they are going to include VS code along with all VS online services including deployment automation to Azure through a single web portal. All your software development/deployment/management needs will be taken care of by MS.
But, speaking from experience and lots of recent discussion recently here, Azure doesn't have performance or ease of use.
The very people using Azure are the people MS are going out to burn with all this focus on the new stuff, the people invested in their stack are getting heavily burnt by churn and the substandard performance of .net core. One of the great things about C#/ASP.Net is that it was improving constantly, they've basically put that on hold for 2-4 years while they try and support linux. And for what? ASP.Net/C# was basically a much faster, better tooled, statically typed Rails.
There was a discussion here of what all the HN startups were using the free azure credits for and the consensus was basically "anything non-critical, log parsing, azure is terrible". One of the GCE guys replied to one of my comments about consistent latency of 3-5ms between website instances and SQL instances on azure with basically "ours is much better, 100ns latency, we're now beta-ing SQL Server". With .net core MS have basically opened up the C# space to be eaten by AWS + GCE.
And the recent terrible re-write of Azure web interface hasn't got anyone's hopes up of improvements any time soon.
It doesnt kill of anything, it only opens up Microsoft tech (and it's developers) to more technologies.
You can still use Visual Studio to build everything, and many will continue to do so, over VSCode. IIS is free. Windows Server is the only thing that they might lose out on licensing but they make it up with Azure running the underlying infrastructure. SQL Server is a great database and formidable opponent to the Oracle and other enterprise options while still being available for SMBs.
Meanwhile, many developers can now be introduced to the rich .NET ecosystem and run it alongside their other open-source/linux stacks, only growing the overall exposure and tools, applications, and revenue involved for Microsoft.
>Linux .net core + typescript, they seem to be killing off visual studio, IIS, Windows Server, etc.
Yup.
Kill it all- transition it to linux, put linux on azure, or build systems on azure profit / rent-seeking.
vsCode only exists because vstudio isn't multiplatform and never will be but they need multiplatform in order to make their slice of the cloud revenue larger.
The installation, update, and packaging story of VS Code is so much more polished on Windows than it is with Atom. I gave Atom a shot for a few months (my employer has products based on it), but it had a tendency to overwrite my settings or completely blow away the .atom folder randomly on updates. And the performance on large files is pretty abysmal (granted Firefox has the same issue opening big plain-text logs, so it's not something that only Atom gets wrong), VS Code does much better.
And if you want to embed Atom within an application, it's great that they've finally updated to make apm use npm 3 so the path lengths don't exceed 260 characters. That's a dumb Windows limitation, but until Microsoft fixes it and enterprises actually update to the version with the fix then it's a fact of life. But atom internally still uses the old nested layout for the built-in modules, so you can't install "portable" atom in a top-level path longer than a few dozen characters.
> I wish more companies understood the value of great products that people love to use as marketing instead of spending money on advertising.
Companies understand. It's just that making something that people truely like is expensive, takes a long time and is risky.
Marketing (in many instances) is cheaper, faster and less risky. Also, it's something you can do with 3rd party providers who do this for many companies. In other words, it's a business problem that can be solved by basically throwing money at it.
Building something usually takes insight into the customer, knowledge on how to build the thing that people want and ongoing work at maintaining that thing that makes people so happy. All of this takes a great amount of internal talent, skill and leadership. If the wrong few key people leave, if the corporate culture changes, if the winds of the stock market and profits shift, this can go away. It's much, much easier to just rebrand your way into people's good graces.
Yeah, it's clear they're trying to "save face" in front of the open source community and become more developer-friendly (Bash on Windows too).
But I must say, ten years ago when I had to choose between Java and C# for a SCADA project I picked the latter because of the Visual Studio IDE which was already well above the competition (think Eclipse/NetBeans back then).
I'm glad they've brought it back for all open source software.
I don't think it's so much "sav[ing] face" as much as it is getting the message out they fully support open source.
The long term play is azure which is their big money maker. 1/3 of deploys on azure (IIRC) use linux images. Our startup got a huge credit to host on azure and we don't use .NET nor Windows. Competition is good.
They are doing it the hardway, every one is entitled to earn their accolades including Microsoft, Google or Apple. Is it marketing, change of culture or otherwise, given the increase of footprint of their editor they are providing real value to developers on non-windows platform in spades.
I wonder what I'd get from my Surface RT that I paid more than a pretty penny for a few years back. Would be nice to "trade-in" for a decent discount on a Surface Pro 3/4.
Sublime has served me well for years and I still use it for working with MASSIVE files as all other editors seem to choke on these, but VSCode is leaps and bounds ahead of Sublime Text. A great editor that fell behind a while ago, they didn't step their game up when Atom came out, I doubt VSCode will change anything sadly. Also worth pointing out that VSCode with its debugger, intellisense, addons and other things is ahead of all competitors right now on all fronts.
It's a shame because Sublime is one of the few pieces of software that I use on my computer on a day-to-day basis that isn't a buggy POS (besides the well-written venerable UNIX shell apps).
Firefox? Buggy. Chrome? Buggy. Any other GUI editor? Buggy. Android Studio? Buggy. XCode? Buggy. I could go on all day.
It's written in C++, too, so it's lightning fast. There's no reason UIs should be laggy in 2016 on the very highest-spec Lenovo Thinkpad mobile workstation, but that's the sad reality of anything written in Electron JS (along with zero 4K Hi-DPI support on Linux, so I have to squint to read the microscopic text on Slack, Upwork, Discord, Messenger for Desktop, Whatsie, Skype for Linux Alpha, ...).
Then why does every other Linux program I run work just fine with my Hi-DPI display? This isn't anything new, these displays have been around for years now.
I get the distinct impression that they invested in good tooling, CI and CD, which probably enables all sorts of product engineering greatness. Hopefully it's a trend.
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?
Same excuse Firefox used to always make for its slowness; it's extensions fault. In the case of Atom, it's slower without any extensions installed, in my experience.
a simple example: on vscode, opening a file from remote fs does not lock the ui, atom (and sublime) freezes. vscode is pretty concurrent! the only thing somewhat slow seems to be regex matches which are single threaded but I am not sure they lock the ui
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 cases, or it may well be that newer versions of Atom have, at least somewhat, caught up to VS Code.
The performance difference between Atom and VS Code is very noticeable on low and mid range PCs. Most of us here on HN are very fortunate that we can afford high end PCs that minimizes performances bottlenecks but we should keep in mind that most of the world isn't so fortunate and that good performance still matters.
I've been developing on a chrome book for the past year. I can confirm that vs code runs very smooth, while atom is finicky and just flat out dies on opening large folders/files.
Kudos to another chromebook dev! Are you running Ubuntu in a Crouton, or another setup? I'm doing that and I run Atom without any complaints. It might just be the way I'm using it however.
I removed the write protection screw, upgraded my ssd, flashed on a new bios from https://mrchromebox.tech/, and installed galliumOS--originally I used chrubuntu, then straight ubunutu. Everything works great. Even installed display link drivers, so I can dock to 2 monitors at work.
Can you open arbitrarily large text files/directories in atom these days? Whenever, I open anything over a few thousand LOC atom seems to lock up for me. I was actually forced to switch from Atom to VSC, because I had a bad habit of accidentally clicking on `node_modules` in the file tree and crashing my session.
I had someone on here mention the write protection screw removal method to me before, I just couldn't bring myself to do it on my Pixel 2. But I should try it, I'm glad to hear someone say it worked out great for them. I definitely want to still be able to boot into the normal Chrome OS because it's preferable to me when I'm not working.
I think I see what you're saying. Maybe it's because the pixel is actually a beast, I don't notice it as much. I have VS Code installed, maybe I should give it another shot. I'm probably just used to Atom, and the only time I really used VSC I was trying to work on one of our really large .NET solutions and it just started throwing hundreds of errors at me. I should try one of my MEAN apps in it.
If you take a look at your memory usage I think you would find that Atom consumes significantly more memory than VS Code. That's always been the case for me, at least.
This, my start time on Atom -- using an SSD -- on Windows is several times longer than VS Code, it just feels jarring. On OS X the start times for Atom are a lot better though, in my experience.
The text editor component (i.e. the part people are most likely referring to when discussing performance) is completely different between Atom and VS Code. No relation at all between the two codebases. VS Code's derives from Visual Studio Online.
Just a thought but, it might just be that Atom is naturally compared with the likes of Sublime Text or gVim and VS Code is naturally compared with Visual Studio.
This makes a lot of since. It's not going to load as fast as most text editors, as it does a lot more out of the box. And most people using VS Code have spent years of their life waiting for VS to open.
One of the developers explain why it's faster than atom, basically the are using different threads for different things and many optimization on viewbox
This comes up every time there's an Atom or VSCode post, but I've yet to see a good explanation of the architectural differences that contribute to the performance differences. Does anyone have the scoop?
VSCode actually uses natively compiled C# codebase for all the processing and only uses Electron for the "View" part. Atom does everything in javascript.
Do you have any references for this? I believe most are of the impression that VSCode run entirely on electron/node; even the editor, Monaco, which is written in JS.
Although, I believe their plugin system would allow plugins to be written in any language.
Have you compared the two? Let's say there are "shills" on HN - it doesn't change the fact that many people see obvious differences in performance between the two editors. It's objectively verifiable. Maybe you're an anti-MS shill
I enjoy working in C and C++ (on Windows) using Sublime Text however I am thinking of giving VSCode a proper try. I know many people use VSCode for web related development but MS seem quite serious about improving its support for C and C++.
My question is does anyone here use VSCode for C and C++? What is your setup? task files, etc?
I mainly use Visual Studio for C++, and Atom for all other things. I gave VSCode a chance a couple of weeks ago but its code completion was not as smart as on VS (no semantic analysis), so I ended up giving up and going back to my VS + Atom setup.
Since you are already using Sublime, you might like it. It felt polished and nice to work on. An improvement over Atom IMHO.
Why use VSCode over Visual Studio for C/C++ when your environment is Windows?
If you were on Linux or Mac I would recommend CLion or Qt Creator if you wanted a proper IDE. Or a heavily customized Emacs. But on Windows, I would recommend Visual Studio.
Not sure exactly how the Git integration is better? In addition to improved Git integration with the more recent VS releases there is also a GitHub extension.
VS also has multi-cursor support, if we are thinking of the same thing... editing more than one line simultaneously?
Besides, these two features you mention seem hardly to be of deciding factor, you would think something like code analysis, profiling, and better debugging (memory window, etc) would be of more importance.
> Not sure exactly how the Git integration is better?
I can directly see which lines have changed in VS Code on the left site of a file.
> VS also has multi-cursor support, if we are thinking of the same thing... editing more than one line simultaneously?
You can add multiple cursors by Alt + Left mouse button in VS Code. This allows to even modify multiple words in one line simultaneously.
> Besides, these two features you mention seem hardly to be of deciding factor, you would think something like code analysis, profiling, and better debugging (memory window, etc) would be of more importance.
Profiling isn't something I do every day, but code editing is. Also you can use both of them at the same time, only falling back to VS for these features.
Furthermore keep in mind, that VS is only free for commercial use under some circumstances (under 200 employees IIRC).
> I can directly see which lines have changed in VS Code on the left site of a file.
VS has this too. Except, by default, it is on the right side of the editor. Uncommitted is in yellow. The white "marker" or hyphen, moves with the line number your cursor is on. Just like in VS Code.
You can also see commits on each function and class, by author and date.
You can right click each commit and view details for that commit, or send an email to the author.
> You can add multiple cursors by Alt + Left mouse button in VS Code. This allows to even modify multiple words in one line simultaneously.
In VS you can hold alt + shift and use arrow keys to select the number of lines you want to edit simultaneously, but looks to not be possible to place several cursors on a single line.
Still, VS has a lot more features going for it that are very powerful. And besides, most people who argue a text editor vs IDE and place importance on text editing speed, forget that it is about quality code, not how fast you wrote that code.
The few lines of code the average developer writes a day makes text editing speed of very little importance.
> VS has this too. Except, by default, it is on the right side of the editor. Uncommitted is in yellow. The white "marker" or hyphen, moves with the line number your cursor is on. Just like in VS Code.
>
> You can also see commits on each function and class, by author and date.
Both not working for me. Are you sure that this also works with C++ code?
You have the same Git stuff (color markers) on the sides of the editor for C++. I tried both the Community edition (2015) of VS and Enterprise (15, preview 5). But, the number of references, authors, etc, above functions and classes, seems limited to C#.
I'm blown by the speed of it, considering it's built upon electron. Since I haven't yet decided to upgrade to sublime3, might just give VS Studio a shot. For serious development I use IDE of choice, but for quick text editing sublime might get replaced with VS Studio.
Its an insider preview, it will be hit or miss depending on the release. VSCode release updates often and they have broken things in the past, which usually get patched within a few days.
Don't do Insider if you need a guarantee of stability.
I would love to use this but i cannot get used to the syntax highlighting. How can i remove syntax highlighting in vscode ? There does not seem to be a obvious config option in the docs.
I'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?
Still, I don't want to use TypeScript for the reasons I wrote. I'm as minimalist as possible, and I don't want to use a language that changes my code to something else without any gain for me since I can write exactly what I want in ES 2015+ already. So it's just those types, and I could get them from "Flow" too and in that case keep my ES 2015+ code. Yes I know TypeScript is very close to ES 2015+, but I never know when it does change the code unless I look at the transpiled result.
EDIT: Actually, I did know that, looking at that page I remember why I dismissed it:
> Note any tags not listed explicitly below (such as @typedef, or @constructor) are not yet supported.
But that is something I make heavy use of. It would be really messy if I wasn't able to introduce "custom types" even in my limited "IDE based static type system".
> I don't want to use a language that changes my code to something else
TypeScript doesn't change your code. If you're writing ES2015 code and targeting ES2015 emit, the output code is always exactly what you put in. There isn't any difference.
Right, most of the code changes Typescript performs are the equivalent of babel plugins: the closer you write to the target output version of the language the fewer changes there between the input/output. The further back compatible you try to target the more "polyfills" and reconfiguring Typescript needs to do to support the older versions of JS.
Most of Typescript's output changes when you are writing for the same version of JS that you are outputting are simply just removing the type hints from the final output.
That said, with allowJS "mixed" mode of Typescript now you can also try for a hybrid approach of JS and TS files in the same project and that hybrid approach gets more powerful and capable with each release. I think with some effort you can even get somewhat close enough to the point that you can have some Flow-like behavior by using JS for most files and .d.ts and .ts files for only the really type-dependent stuff.
Also you could just add types to your JavaScript code with TypeScript and nothing else; the result of running through the TS compiler is just the same code with the types removed.
I think it has fast paced development because most of the people in MS use this editor all the time. If it is their native home unlike Store apps or MS Office then why wouldn't they make it feel good. It's natural to take care of place where you live most of the time.
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.