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) one 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, I 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.
- WebForms vs MVC–The War Is Over - September 25th, 2014
- Create A Desktop Application using Angular, Bootstrap and C# - October 15th, 2015
- Are You Doing Angular Right? - November 5th, 2015
- Adventures Working With Angular’s $scope - November 26th, 2015
- Using Gulp to Bundle, Minify, and Cache-bust - January 28th, 2016
- Reactions to React JS and Associated Bits - March 17th, 2016
- An Explanation of the Flux Pattern - March 31st, 2016
- Ext JS 6 by Sencha - The Good, The Bad, The Ugly - April 7th, 2016
- Do This To Increase Your Client Side Web Development Speed - April 21st, 2016
- ES2015 Code Coverage and Jest (React JS Unit Testing) - May 5th, 2016
- 4 Reasons To Drop MVVM - July 27th, 2016
- You Can Start Using Node Today - August 2nd, 2016
- TypeScript and Electron The Right Way - September 6th, 2016