Slashdot Mirror


Microsoft Adds Node.js Support To Visual Studio

shutdown -p now writes "Coming from the team that had previously brought you Python Tools for Visual Studio, Microsoft has announced Node.js Tools for Visual Studio, with the release of the first public alpha. NTVS is the official extension for Visual Studio that adds support for Node.js, including editing with Intellisense, debugging, profiling, and the ability to deploy Node.js websites to Windows Azure. An overview video showcases the features, and Scott Hanselman has a detailed walkthrough. The project is open source under Apache License 2.0. While the extension is published by Microsoft, it is a collaborative effort involving Microsoft, Red Gate (which previously had a private beta version of similar product called Visual Node), and individual contributors from the Node.js community."

29 of 197 comments (clear)

  1. Visual Studio... by fisted · · Score: 3, Funny

    ...does it even Clippy?

    Won't purchase without.

    1. Re:Visual Studio... by shutdown+-p+now · · Score: 4, Funny

      Still no feature request. I'm disappointed.

      If there is one in the tracker and it gets over 100 votes, I'll personally implement it. It's going to appear once you open a project and ask, "It looks like you're trying to do some work. Would you like to be distracted?". If you say yes, it'll open Slashdot in a Visual Studio tab. ~

  2. Just what the nodejs by stewsters · · Score: 5, Funny

    I'm sure the NodeJs hipsters running the latest flavor of Linux with custom desktops will close out their sublime text and immediately wget that.

    1. Re:Just what the nodejs by phantomfive · · Score: 2

      Microsoft has been scaling back the use of ASP.net internally. The groups I've talk to use it mostly to talk to the database, and do everything else in Javascript.

      Apparently there are some groups at Microsoft who have gone all the way and are now using Javascript everywhere.

      --
      "First they came for the slanderers and i said nothing."
    2. Re:Just what the nodejs by tibman · · Score: 2

      Column mode like when you do alt+shift+up/down?

      --
      http://soylentnews.org/~tibman
    3. Re:Just what the nodejs by batkiwi · · Score: 2

      It depends on what you mean by "asp.net".

      Over the last 3 years asp.net has evolved from "gui controls you compose on a page with TONS of overhead" to "a lightweight framework that looks a LOT like spring". What most people who have used asp.net in the last 10-12 years think of as asp.net is basically dead.

      http://www.asp.net/web-api for example. Many people us this and knockoutjs for dotnet based web projects.

    4. Re:Just what the nodejs by KingMotley · · Score: 3, Informative

      Or Visual Studio's holding down ALT while selecting a block, or textpad's block mode?

  3. Stop with JavaScript by sanosuke001 · · Score: 2, Interesting

    Please, for everyone's sanity, stop it with the JavaScript crap; it's a terrible language, a terrible platform for applications, and supporting it is just prolonging it's Reign of Terror. (this is why we still have flash).

    --
    -SaNo
    1. Re:Stop with JavaScript by Anonymous Coward · · Score: 4, Insightful

      When you get all browser makers to agree on a new language to use we can stop with JavaScript.

    2. Re:Stop with JavaScript by i+kan+reed · · Score: 2

      Oh yeah, good idea. Let's just be rid of this whole Internet thing, and all the crap people put on it.

    3. Re:Stop with JavaScript by Anonymous Coward · · Score: 3, Interesting

      The performance and capabilities of these browser applications feel like they're from 1993, but yet they require 100x the resources of a modern desktop program.

    4. Re:Stop with JavaScript by Dahamma · · Score: 5, Funny

      Well, duh, the point is not having to port/compile native apps for all platforms. With Javascript you just write one web app that is 100% compatible on all platforms, OSes, and browsers! Man... I thought I could keep a straight face while typing that but I give up.

    5. Re:Stop with JavaScript by royallthefourth · · Score: 3, Informative

      it's so great that it'll allow you to just decide to use some member variable somewhere without declaring it

      Undeclared variables are implicitly global. A code inspector will warn you about mistakes like that!

      there's no way to know the type of a variable

      It should be clear from the way it's used or by the documentation (if it exists). This is true of not only Javascript, but every dynamic language. If that's not good enough, use one of the readily-available and straightforward debuggers. Another quick approach is to just console.log(var)

    6. Re:Stop with JavaScript by OhPlz · · Score: 4, Insightful

      Oh yeah, good idea. Let's just be rid of this whole Internet thing, and all the crap people put on it.

      WWW != Internet

    7. Re:Stop with JavaScript by narcc · · Score: 2

      That would have been really funny 10 years ago.

  4. JavaScript, its better than a kick in the head. by TiggertheMad · · Score: 4, Insightful

    If you know of a better client side web scripting language that has wide spread browser support, we are listening.

    nothing? Yeah, I thought so....

    --

    HA! I just wasted some of your bandwidth with a frivolous sig!
    1. Re:JavaScript, its better than a kick in the head. by Tridus · · Score: 2, Informative

      Not really sure what that has to do with Node.js applications deployed to something like Azure. How many browsers are going to be running that?

      I know I can think of things I'd rather do than inflict Javascript on myself in more places than I have to.

      --
      -- "So they told me that using the download page to download something was not something they anticipated." - Bill Gates
    2. Re:JavaScript, its better than a kick in the head. by devent · · Score: 3, Insightful

      If the W3C would make a byte code standard to access the DOM then nobody would use JavaScript and rather port any other language to use the byte code. Much like for the JavaVM there are numerous languages available (about 25 languages), for example C, Python, Ruby, and new languages like Scala, Groovy, (and about 30 other languages). The JavaScript code is compiled and re-arranged for faster execution to a byte code language that is run under a Virtual Machine anyway.

      The question of whether I know a better client side web language is moot because there ain't no choice. Other then of course plug-ins or add-ons to the browser. It's like asking is there any better gaming operation system then Windows... (at least I can install Linux and run some Linux games that are better then Windows games).

      --
      http://www.mueller-public.de - My site http://www.anr-institute.com/ - Advanced Natural Research Institute
    3. Re:JavaScript, its better than a kick in the head. by shutdown+-p+now · · Score: 2

      The cost of round trips between client and server are still way too high for a lot of stuff, especially when you want smooth UI. Remember those horrible forms which reloaded the page (to show a different set of controls) when you changed selection in some combobox?

  5. Re:Node.js?! How 'bout C89 support? by khr · · Score: 2

    How 'bout C89 support?

    For that matter, how about C64 support? And small enough to fit on floppy disks...

  6. Re:node.js.Extend.too ? by shutdown+-p+now · · Score: 5, Informative

    (disclosure: I am a developer on PTVS and NTVS team)

    I would hope that the track record of our particular team with Python Tools would speak for itself here - it's been out there for two years now, with 2.0 released last month, and it was and remains all about standard Python. While it does support IronPython, for example (but also Jython, PyPy, and other third party implementations), CPython remains the primary target because that's what the community uses, and our goal is to attract developers from said community to VS, Azure, and other Microsoft platforms and products, not to hijack their language/framework of choice.

    The story with NTVS is similar: it's all about making VS a compelling choice for Node.js developers without forcing a Microsoft-top-to-bottom stack on them (which no-one would accept, and rightly so). In that sense, it is in line with Azure offering Linux VMs, or the ability to write Node.js-based Azure push notification services for Windows and Windows Phone.

  7. Re:node.js.Extend.too ? by shutdown+-p+now · · Score: 5, Interesting

    Sure, karma is a bitch. In fact, part of what we're trying to do as a team is to turn it around, both the external perception as well as internal company understanding on openness - not just open source, though that as well, but generally working together on common things, and purging the NIH and the "we must be in charge" syndrome.

    It's not just us, too - it has been a growing thing in the developer division, in general, with a lot more stuff being open sourced, and a broad change of attitude from a single monolithic take-it-or-leave-it stack, to going where the people already are and supporting what they already do. You might have noticed some other glimpses of that if you've been following the general news on MS dev story, e.g. with a renewed effort on C++ standard conformance, or a lot more attention to JS and HTML5.

  8. Re:node.js.Extend.too ? by Nerdfest · · Score: 3, Insightful

    The developers may want to have a word with the legal/patent department if they're looking for goodwill from the developer community at large. What Microsoft is doing with the Android patents is up there with SCO. They also teamed up with Appple as 'Rockstar' for some of the worst patent abuse around, and lobbied against the current patent reforms. It's going to be a big job.

  9. Re:What about Powershell ? by shutdown+-p+now · · Score: 4, Informative

    Why can't Microsoft put out a Visual Studio plugin for Powershell with full intellisense, breakpointing, inspections, etc. ?

    We don't need to - someone else already did that.

    Keep in mind that we're a relatively small group - 6 developers/testers (we all do both) and 1 project manager, covering two projects already (PTVS and NTVS). We can only do so much. Then again, that's precisely why the code for both products is open source - so that people can take it and use it as a foundation for similar products for other languages. Here is one more for PHP, for example.

  10. Re:Node.js?! How 'bout C89 support? by shutdown+-p+now · · Score: 2

    Note that GP asked about missing C99 feature that "would take a week or so to implement". Having said that:

    Do they have stdint.h now?

    It has been there since VS 2010.

    How about conforming to C89's strict aliasing rules?

    A compiler doesn't need to do anything special to conform to those rules, so this has always been the case. Conformant programs have to be written carefully so as not to trip up an optimizer that relies on strict aliasing, though. I have to admit that I don't know whether VC++ optimizer does use the opportunities presented by strict aliasing, like g++.

    Restricted pointers? They have that under __restrict, but again, you have to #define if you want to use restrict with MSVC code.

    There's no support for "restrict" yet, and __restrict is subtly different in semantics.

  11. Re:node.js.Extend.too ? by shutdown+-p+now · · Score: 4, Interesting

    My own personal take on software patents (which is obviously my own only, does not represent the opinion of my employer in any way, blah blah etc) is that they can play a useful role, but they should be significantly scaled down in terms of what you can patent. Complicated algorithms, like, say, MP3 or H.264 or other compression stuff - probably yes, since that takes real time and effort to develop. But I'd love to see the "one click" patents die a fiery death. Some laws that would require non-discriminatory licensing for useful patents for interoperability and standards compliance purposes would also be great.

    So EFF gets part of my paycheck every year. Ironically enough, it qualifies for MS donation match program, so they match it dollar for dollar. ~

  12. Re:Node.js?! How 'bout C89 support? by shutdown+-p+now · · Score: 2

    Designated initializers?

    They're there in VS 2013 already.

    Compound literals?

    Also in VS 2013.

    _Bool / stdbool.h as well, and most C99 standard headers except for tgmath.h are there as well.

  13. Re:Node.js?! How 'bout C89 support? by shutdown+-p+now · · Score: 2

    Also, array sizes defined at runtime is theoretically easy

    Dynamically stack-allocating arrays is indeed easy, which is why this feature is also being standardized in C++14. The problem with C99 VLAs is that they are far more than that - you also have things like VLA typedefs (which should remember the size at the point of the typedef, even if the expression that defined it changes later), or parameter arrays where their size is specified by another parameter. Also, the abomination that is dynamic sizeof.

    but depending on their codebase (ie, if they are crappy compiler writers that depended on things they shouldn't have), I could see it being hard.

    The compiler itself is really ancient. Consider this: gcc 1.0 was released in 1987; Microsoft C was released in 1983, and that was built on top of an even older third-party codebase that was purchased back then. It probably changed a lot since then, like gcc did, but all legacy codebases of that size acquire a lot of legacy cruft (hence why Apple decided to stop mucking around with gcc and just do Clang from scratch). I don't know much about current VC code, but one piece of information that the team has shared publicly is that the front-end doesn't actually operate on an AST, but is rather a multipass process-as-you-parse thing, which makes a great many modern C++ features like constexpr very costly to implement.

  14. Re:LOL, WUT? by shutdown+-p+now · · Score: 2

    jQuery is about JavaScript running on the server side - in the browser. Node.js is about JavaScript running on the server - instead of C#/ASP.NET. The "event-driven, non-blocking I/O model" basically means that all APIs that are normally blocking are instead done asynchronously, with you having to provide a completion callback every time you call one - so threads are never blocked waiting for I/O. For a C# developer, this is basically very similar to all the new stuff about System.Threading.Tasks and async/await in .NET 4 and 4.5, and specifically support for the latter in ASP.NET.