You can't maximize it, but you can set its width and height. Right click in taskbar -> Properties -> Layout. There are settings for size, position and buffer size. I have mine the size of the whole window and with the biggest possible buffer, as well as a more readable font.
For me the lack of many unix tools is a killer and cygwin doesn't cut it. Many build scripts assume a unixy environment and windows is flat-out not supported. Lack of a proper package manager also makes installing and configuring workstations a hassle.
I've tried having all these installed, and having them all in my %PATH%, along with msys and the platform sdk and so on, but i found I just ended up with my PATH env var being truncated because I went over the environment block size limit.
I've given up pretending windows is unixy and ditched it in favor of homebrew on osx
I like this. I smuggled Node into our company to suplant a very difficult to test/debug WCF process and it's slowly been creeping out into bigger use cases. I've tried using VS for managing my Node scripts but it just wasn't a very elegant fit given VS's concept of projects and solutions so I kept falling back to Sublime. I'm excited to see if I can finally maintain just a single editor for both my .NET and Node code.
I like Web API a lot and would have no problems using it more. I've never messed around with SignalR, I had already started playing with Node at that point.
As I mentioned, but didn't elaborate on, in my first post I had an urgent need to fix a production problem as quickly as possible. But the service giving us the problems was opaque, and encumbered by these massive 100+ project .NET solutions that had grown unwieldy for rapid development.
Being able to kick VS+TFS and their ceremony to the curb and hack out a solution with Node and Sublime Text was liberating. But it wasn't really VS I had a problem with, it was paying the price for years of technical debt. That's why I'm excited, I still think VS is a great IDE for my .NET work.
This is the kind of thing that makes me want to switch back to Windows.
I like VS since I've been using it to develop a C# app these last two months. I miss a lot of things because I'm too deep in CLI usage (like git...help me...), but had I had it when I tried to play with Ruby on Windows 7 three years ago and discovered the pain of the windows CLI, maybe I would've stayed there.
These Node.js tools are especially great. I spend a lot of time on CLI running my app, installing a module, watching my dev logs,... I couldn't ever imagine anyone using node.js on windows. Now I can and it looks great.
I had used cmd for about 15 years before that, so while using "cd" or "dir" and the classic lingo was okay, doing everything rails-related in CLI just felt..clunky: "why would you have such a bad interface? EasyPHP does everything just fine with a GUI!". Had I known CLI could be more intuitive (hello pipes!), I'd have looked up for a better alternative sooner =)
RailsInstaller does a really good job now. Windows now feels second class but that's much better than 4th-5th-good luck getting anything to run. I see more people in the #RoR Irc channel admit to using windows so its gaining traction. I don't think it'll ever be 1:1 and I have a Linux host for a reason but it isn't a jarring experience anymore for sure.
For Mac or Linux noders who would prefer an IDE to a simple editor + command line tools, IntelliJ with the Node plugin is pretty good. It has code assist and debugging built in, and IntelliJ is just generally a very good IDE.
Edit: WebStorm from the same company (JetBrains) is cheaper if you don't need all the java tools support.
visualnode was a fork of http://pytools.codeplex.com and they've joined the NTVS project (which is also forked from the same source). Bart Read from red-gate did the npm GUI for NTVS in fact. they stated that they'll shut down visualnode.
Firstly, thanks for signing up for the beta of Visual Node, and trying out the tool. Your feedback has been incredibly helpful to us.
Today we have a very exciting announcement for you. Since the summer Red Gate has been working with Microsoft on a free, open source Node development environment for Visual Studio called Node Tools for Visual Studio (NTVS). We've just released the first public alpha of NTVS, which you can download from:
I'd like to take this opportunity to thank you again for participating in the Visual Node beta program. As I said, your feedback has been very helpful, and continues to influence the development of NTVS.
If you have any questions about anything in this email please do post to the discussion URL on Codeplex - we'd love to hear from you.
Seems like overkill. Part of why Node is great and so easy to get started with is that all you need is a browser, a text editor, and the terminal. I suppose for people that already use VS this is good, but maybe we should encourage them to write Node apps outside of that environment instead of shoving Node into a giant IDE.
There's more to development than a text editor, though. Sometimes you do want debugging. And maybe you want syntax highlighting in your REPL. And, perhaps, you'd like some profiling to figure out how to make your Node app run faster.
Yes, and most of those things are already available as modular open source tools that fit well in the Node ecosystem. Encouraging people to use one giant, closed, monolithic program for all of those purposes is not a good step forward for Node.
I'd disagree. It allows people to use the tools they're most comfortable with, instead of imposing a singular idea as far as what the blessed environment is. Obviously, some people don't like the string of tools together approach, or else this wouldn't have been developed.
Well, they're not taking that away from you. You can still get started with the basics. But even node apps can get big.
It's the debugging story I'm really digging here. Being able to just set a breakpoint and hit f5 is real exciting as opposed to having to type "debugger" in your code and then sit around for ages. It's a shame I do all my node work on a Mac.
I'm guessing this won't be available for VS express?
Just like Python tools for VS it probably won't work with VS express, but it probably will work with the freely available VS shell (that is just the bare Visual Studio IDE without any existing language support in it). So you can get the whole package for free, but obviously only this node.js plugin will be open source.
WebMatrix 3 makes a decent free Node/PHP IDE. It isn't as polished as this looks to be and nothing really beats VS proper as it were but it makes a pretty convincing run at being second place behind VS Express and at least supports a basic idea of plugins/extensions.
you have a point. i dont think node in a fat IDE is for everyone / every scenario. i look at it as just another tool in the dev's toolbox. ideal (imho) is a decent web-based tool or light-weight editor plus a capable IDE for larger scale apps that need complex debugging, profiling, mutli-lingual project, etc. support.
The profiling will only get better. Right now it profiles everything, but it could potentially be scoped down to "just my code." Plus, it's a sampling profiler as it is so you will need to push some real traffic to work hot spots (as opposed to just browse and click around) in order to get results.
What's cool about it, IMHO (I wrote the post above) is that it takes the V8 profiling stuff and feeds it into the VS visualizer...as it should.
TypeScript uses npm as a package manager yes, but there is unfortunately no support for using Node within TypeScript yet on Visual Studio. There are definitions for node/express/etc, just cannot compile them directly in Visual Studio and also have debugging (unless the linked package in the OP has changed that).
Looks correct to me and makes the most sense to build the tools in the language TypeScript compiles to. On another note, it would appear they will be adding TypeScript support in the beta, which makes me very happy.
It's actually been done, to more or less success, but hasn't been kept up, and the differences in embedding SpiderMonkey vs V8 were cumbersome iirc. Not to mention compatibility with compiled modules. I was interested as E4X support would have been nicer earlier on, but it's surprising how quickly json has taken over.