is there any good reason to avoid Node.js for traditional web apps
Yes, if you have N years in web platform X then clearly you can developer an application in platform X faster.
If you want to do Y and platform X has a pre-made solution Y that does X then do so.
All the generic reasons of why you should use one platform over another.
the sort of CRUD apps you build for internal business applications?
Yes there are other platform that let you write a generic application faster, ruby on rails comes to mind.
However, that said. I have experience with node and can't claim I would choose another platform over node unless it does a massive amount of features out of the box for me.
Basically it's a simple question of
Does a tool exists that does all of this for me? No, then pick the most convenient platform to write the tool.
There are no solid reasons why node.js is an inconvenient platform (other then "i hate javascript")
I'm now looking at node.js and it's performance implications (I'm addicted to speed), but I haven't delved into it all that much.
Profile, profile, profile. That's the only way to know that your speedups are having the proper affect. You can guess that it's fast enough. But most people like to prematurely optimize. That's worse than playing with yourself during a date.
I'm wondering if node.js can completely replace my typical web development in C# and ASP.NET MVC, if it's better as a complement to C# and ASP.NET MVC, or if there's some things that should just "leave well enough alone".
Are there use-cases for/against C# and node.js?
Sure, if you're in a shop that routinely writes code in C#, then you should use MVC (it's a lot better than WebForms, and is called WebPages). You're going to not lose a lot of time to tooling training, and it's something your workflows should already handle.
What you don't seem to indicate above is the reasons to choose each. You've given two current market options, one still in Alpha stages, the other on its full third year of platform release. I wouldn't want to compare the current testing model electric cars with the Honda hybrids that are already out on the market. They're in two different leagues.
Now, here's a reason for you to stay away from node.js, if you're nominally a C# shop.
You don't currently work in asynchronous evented i/o, you currently work in a procedural format.
That's the antithesis to what nodejs is going to do for you.
However, if you're frequently writing async code in C#, and you use it a lot in an evented style, then yes, node.js is for you to strongly consider.
Here's what you'll give up:
IIS - This is actually important to a lot of people. Things like native A/D integration are already done, and pretty bug-free. Actually node.js now integrates well with IIS.
- Razor templating - If you've done any serious C# MVC, then you are using and loving Razor and how quickly you can churn things out. There are similar templates in node, and I'm certainly not knocking node, but the entire toolchain is already present in C#, and a lot of it is currently being built in node world. NB: a lot of this tooling is now rather mature_
- compile-time building of dlls - node.js generally gets compiled on the fly, that is to say, not all paths are checked at startup. It's entirely possible to have really bad code in node that nobody ever touches, checks, or tests against.
- All the tools currently built into VS that you use daily - There just isn't that much VS support for javascript. Partly because everything in javascript is so dynamic. NB: Microsoft is obviously working on tooling support for javascript_
Here's what you'll gain:
- everything you develop will be in the same language, assuming you do client side scripting as well as serverside. (or why would you even consider javascript on the server)
So, since I seem to be bashing Node here entirely, let me point out that node is my play language at home, I love it, and I help people debug it sometimes on the stackoverflow chat servers (room 642). I see that it has great and stupendous potential in the future.
I'm just saying, don't throw out the baby and wonder why the bathwater is dirty.
You haven't given a reason why you should give up your years of experience and start on something new. Are either bad tools? Not at all. Both are great and make development a breeze.
Can node replace C#? Yes, quite certainly. So could PHP or Java or Ruby. You're not asking about those.
Here's how you know when you're ready to program node.js instead of C#:
- You're considering writing a book to help other people "get javascript" instead of the boring old programs they've written before in C# and etc.
- You've got problems with synchronous (blocking) I/O stopping your apps from doing actual work.
- You aren't using ANY libraries in C# other than the default MVC and that just for routing, and you're pretty sure that you can do a better routing engine, and you're coding everything as close to the metal as you can.
- Every data object you design you see as a hash instead of a strongly typed object.
Best Answer
The traditional web server port is 80. However, this is a port in the privileged area on many systems (requiring the administrator of the machine to run the program that listens to that port).
This rules out 80 and 800 as options for ports to set up a server on. The next value in that series would be 8000. Many web servers are configured to listen on port 8000 (or the developers just use that as a convention - more on this below). Some go to 8080, or 8888 for their development port areas, but 8000 is the next value in the series. The key bit being that they are unique. You can't have two different programs both listening to the same port.
Tomcat happens to have its configuration files shipped to listen on port 8080 - though this may have changed with other version. This may be because some web developers are also running an apache httpd server on port 8000 (I've occasionally run that configuration myself - it's not uncommon) as part of the technology stack in use.
That the default configuration of a program that responds to web requests listens on port 8000 should be no surprise at all and is a convention for development servers that dates back since at least when I fired up NCSA HTTPd on port 8000 on a machine I didn't have root on.
This is a convention for development web servers or things you don't want root running (application servers vs a slim httpd proxy) and is unlikely related to any developer's favorite numbers. It's a port. It's a convention for developers that long predates Node (or even Javascript).