Join the DZone community and get the full member experience.Join For Free
A true open source, API-first CMS — giving you the power to think outside the webpage. Try it for free.
- Node.js Compared to ASP.NET without IIS
- WEBAPI vs Node.js
- Node.js Compared to J2EE
- What makes Node.js Faster than Java?
Here’s a simple example. You post data from the web browser to the server that needs to go into a database. In ASP.NET, the default way of handling this would be to receive the request, send the data to the database, wait for the return value from the database, and return to the server. All as a blocking call.
In Node.js, you would/could see this default behavior. Information is sent to the server, the server sends to the database asynchronously and immediately returns to the client. Of course, there are error handling issues that need to be addressed here, but the main point is that you don’t HAVE to wait and you probably shouldn’t. If you need to send an error message back, that would be handled separately.
So, I ask, which is going to appear to be faster?
Who Needs Multi-threading?
OK. So, we’ve addressed the environment issue. But now I have to ask, when is the last time you really needed your application to be multi-threaded? I can count the number of times that I used multi-threading capabilities in one of my applications (sever side or desktop application) on two hands in the last 28 years of programming. The need for multi-threading is quite low relative to the number of programs written. And even if you COULD write a multi-threaded application, the benefit compared to the complexity in your code tends to be relatively minor.
Multi-threading if You Need It – Client Side
Multi-threading if You Need It – Server Side
In the response I initially added to the multi-threading issue and suggested running child processes. This is the server side equivalent of using a worker process on the client side. You spawn off some worker processes, wait for them all to return, collect the information they provide, and continue on. As was pointed out, this is not “true multi-threading” because in a real multi-threaded application every thread has access to the same memory space. But you could argue that this is a good thing too. There are a lot of issues with multiple threads accessing the same shared memory. I’m not sure I would want the average programmer ABLE to do this.
Today Is Not Tomorrow
Only Use Multi-Threading Where You Need It
OK. But what if you REALLY need multi-threading capabilities?
Wrapping It Up
But maybe you aren’t. You know what, while I think it might be a career mistake, it is your career. You don’t have to agree with me. And since neither of us are omniscient, only time will tell which of us made the better choice.
Published at DZone with permission of Dave Bush , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.