Indie-Resource.com

Not my title!

http://www.youtube.com/watch?v=1e1zzna-dNw

I went to YouTube to find an introduction on Node.js and came across this video that explains his opinion on Node.js... and that it actually sucks and people shouldn't use it!

I don't know enough to form an opinion, so I was hoping people on both sides of the fence could explain their thoughts on the subject?
What are the pros and cons of Node.js compared to other options?

And quite honestly... what even are the other options?

This has to be satire. I can only assume it is. Because his issues are all laughable. But anyway, here we go, just in case he is serious (and after seeing his other videos, I think he is serious):

1. Javascript is slow: node is throwing down on pretty much any benchmark tests, equal to or faster almost any other platform. And that is pretty much the end of this complaint. It seems like this guy only looked at the front page of node and made up his mind. He hasn't looked at the whitepapers, and the thousands of people using it. Is he saying that the dev teams at Fortune 500 companies are incompetent and don't even know they are using inferior technology?

2. Whatever he said about non-blocking I/O: He doesn't understand what asynchronous programming is, obviously, because he completely missed the point on the "non-blocking" aspect. The language or its base execution is almost never a bottleneck. I/O is, and asynchronous I/O has shown to be amazingly fast and easier to handle than threading. .NET, Java and just about all the other major players are either in the process of adding async I/O or already have (to be fair, Java was already dipping their toes in the async I/O waters with NIO back in 2005).

3. Data-intensive: It can be, thanks to being asynchronous, but again, he totally missed that. Backed-up with a NoSQL database like CouchDB or MongoDB that carries state in-memory and on-disk, node is capable of churning out data much faster than most other platforms.

4. Real-time: It is. That is how I am making my MUD with it. That is why pretty much every real-time HTML5 MMO is backed by it on the server.

5. Microsoft: He didn't know how to pronounce Azure.

6. eBay: He didn't know how to pronounce concurrency.

7. Runs its own HTTP server: This is a bad point? So instead of having our app roll out only what it needs in an HTTP server and nothing more, we want to have pages and pages of customization options, server back-doors, publicized vulnerabilities if we don't keep up with patches and updates, etc.?

8. To have suitable scaling, you have to have some kind of cache on the front end: Wrong. I have never even heard of anyone doing this before. If you want caching, node has its own options.

9. Anything in node is not well tested: What?! Node is deployed on countless servers all over the world. How is that "hardly being used" or "hardly been deployed"?

Basically, this guy, if he serious, sounds like he is defending some other technology, likely either PHP or Rails (edit: and he is, after seeing his other video lists). The fact that he doesn't even know how to say node is quite telling that he has dismissed it without considering it (he calls it "node dot jay-es", when it is just called "node". The .js was added just to distinguish it from the Node class used in linked-lists and other data structures when web searching. You never actually say "node dot jay-es"). And there is no need for that, because no one platform just comes along and guts everything else in its path. There is still a place for Rails, PHP, Python, etc. There are some projects I would choose PHP for over node. This guy is just nervous for whatever reason because of how much he hears about node. Instead of learning a bit about it, he dug his hands into the ground, and is trying his hardest to make everyone stop growing and changing around him by insulting them. If you think like this, you will end up being the gray-haired old man complaining about how assembly is all you need, and these people using high-level languages are all "cheating".

This guy would be better spending his time to actually try node first before ranting on it. It took me less than 2 weeks to feel extremely comfortable with it.

Here are my pros and cons:

Pros: Always single-threaded but async makes it blazing fast (so no concurrency issues), Javascript on the front and back-ends which is so powerful, the way apps are structured make Web Sockets easy thus spawning the beautiful Socket.io, very well-designed for simple, care-free networking, no tinkering with 3rd-party web servers, works great with NoSQL databases, a huge, inventive and welcoming community.

Cons: The single-threaded nature will slow down your app if you have to do huge processes or calculations inside of a callback. But it is not as much of a concern as he made it out to be. A modern processor can figure pi to 1000 decimal places (the problem he mentioned) in around 1ms or less. Processes are almost always slowed down by either I/O or thread pooling issues. Almost never today is a program slowed down by in-memory calculations. A modern CPU can do 2 - 15 billion processes per second. Something like $ans = $a + $b would be 5 processes on most platforms. So to even have a shot at slowing the processor down you have to be iterating over thousands of objects and doing a ton of calculations on each one, or spend the next year writing one script to slow it down.

EDIT: A 2nd con I thought of is that if you aren't careful with structure, your application can just become a huge pile of event handlers, and that is not extremely maintainable. There are plenty of solutions for this, however you want to handle it.

The alternatives:

Node is far from the only game in town for this kind of programming, nor was it even the first. It is just the most popular and has become the poster child. Ruby has the "Event Machine". Python has "Twisted". .NET has "SignalR". I think Java has something similar, too, but I am not familiar with it (and if it doesn't, it will once more async I/O functionality hits the platform). EM and Twisted have very similar libraries to what node offers, and I think even Socket.io has been ported to them. SignalR works a bit differently, but essentially it exists because of node, or perhaps more accurately, Socket.io.

In closing, I have learned to typically ignore people who say things like "If you do X you an idiot". This guy is getting ripped apart in the comments for the way he presented his arguments. It could have gone completely differently if he had chosen another tone. I have no problem with any other languages or platforms, and don't think anyone is an "idiot" for liking them. There are obviously redeeming qualities to all of the top 20 languages in the world, or they wouldn't be where they are.

If you ever find yourself hating a language or the people who use it, learn it.

Thanks Jack that was very informative. I had a feeling that guy must be off in left field.

Well there is some truth. The way async is made in C#/.NET (I don't know how Java is made but I would say it is the same as .NET) and the way it's done in node.js is completely different. In node.js you subscribe to some "callback" method more or less the equivalent of an event in C#, yet when this callback is called, it will be the only thing running at that time. That means, you can't have a "timer" function running and at a same time a socket.io callback. For most this will be fine as it avoid concurrency issues (no need to lock variables for example), however it's NOT multi-tasking and it's not really async. You simply don't need to pool to wait for an event which is already great.

For the realtime, well all depends what is your definition of realtime. Where I work, a realtime OS is an OS which has pre-defined / well known timer interrupts. For example, if I want to be waked up every 1/10 of sec, it will be exactly 1/10th of a second, not once 1/9 and the next time 1/11 as it's on windows. The price of such OS are extreme, as well as all the tools to develop on them. But for most those are totally useless and a normal OS like Linux and Windows are more than ok. For stock exchange, realtime news means less than 50ms delay (I don't know the real number here, but it's really a fraction of a second) between the news, and the time you get it. So if the price of a stock goes down you should get it in realtime, for that you pay a lot again. So what's the definition of realtime? All depends what YOU need. For me, node.js is realtime enough for the game I'm developing.

The issues I do see about node are the lack of multi-processor support per default. That means, if you make your little web server or socket.io server with node.js it will use only one core / thread. If you want to use more, then you need to spawn more processes. While this seems to be odd in today worlds, it does have some logic (as simplification of the core of node.js as well as maybe allow more tweaking???) however for most it can be a source of annoyance. Yes there is some "cluster" solution for node, yet it's not in by default and I don't know how the communication with socket.io from one instance talk to the other. If they don't then you have an issue.

Another issue is the "stability" in term of API. Each release of node.js do change the API, and many times it's not backward compatible. Now they promised that the core should be more or less stable as API, but as we are still not with a V 1, I may expect they will actually change things.

Error handling can be an issue too, as some errors are not within your code, and as you cannot make a try catch around callbacks, you will basically not catch them so easily. All async code do have issues with error handling, same in .NET. Yet in .NET, maybe due to my higher knowledge, it seems easier to catch those issues.

Last thing, is the tools. node.js is pretty new and not developed by a company like Microsoft, so no visual studio for node.js. No incredible debugger. Yes there is tools, yes there is editors (WebStorm for example is really great) but we are FAR away from a visual studio.

a_bertrand wrote:Well there is some truth. The way async is made in C#/.NET (I don't know how Java is made but I would say it is the same as .NET) and the way it's done in node.js is completely different. In node.js you subscribe to some "callback" method more or less the equivalent of an event in C#, yet when this callback is called, it will be the only thing running at that time. That means, you can't have a "timer" function running and at a same time a socket.io callback. For most this will be fine as it avoid concurrency issues (no need to lock variables for example), however it's NOT multi-tasking and it's not really async. You simply don't need to pool to wait for an event which is already great.

Really they are not that different. The async call in C# is the same as the async call in node. In C#, the "await" is the same as your callback. However, there is an important difference between the two. C# gives a bit more flexibility before the "callback": the code before the await keyword will run instantly after the async call is made, and then will freeze at the await until the async call returns. This is basically like how you can fire off an async call in node and then it will start to execute all the code below the end of the callback, but C# gives a bit more flexibility since you can reliably know how far the code will run before the async call returns. Note however that there are packages for node that can achieve this same model, such as some of the various implementations of promises.

a_bertrand wrote:For the realtime, well all depends what is your definition of realtime. Where I work, a realtime OS is an OS which has pre-defined / well known timer interrupts. For example, if I want to be waked up every 1/10 of sec, it will be exactly 1/10th of a second, not once 1/9 and the next time 1/11 as it's on windows. The price of such OS are extreme, as well as all the tools to develop on them. But for most those are totally useless and a normal OS like Linux and Windows are more than ok. For stock exchange, realtime news means less than 50ms delay (I don't know the real number here, but it's really a fraction of a second) between the news, and the time you get it. So if the price of a stock goes down you should get it in realtime, for that you pay a lot again. So what's the definition of realtime? All depends what YOU need. For me, node.js is realtime enough for the game I'm developing.

You are more defining a "real-time OS", which is something totally different than a "real-time networked app", which is what node was referring to. You pretty much hit the nail on the head for a real-time OS, which are very common in embedded systems. But when the node website mentions "real-time", they really more mean the "real-time web".

a_bertrand wrote:The issues I do see about node are the lack of multi-processor support per default. That means, if you make your little web server or socket.io server with node.js it will use only one core / thread. If you want to use more, then you need to spawn more processes. While this seems to be odd in today worlds, it does have some logic (as simplification of the core of node.js as well as maybe allow more tweaking???) however for most it can be a source of annoyance. Yes there is some "cluster" solution for node, yet it's not in by default and I don't know how the communication with socket.io from one instance talk to the other. If they don't then you have an issue.

It is somewhat of an issue, but node does include clustering out of the box (I think this was added to the default download a few minor version updates back). As you could probably imagine, any communication between processes in node is done with...you guessed it...events lol. If you really, really need multiprocessor support (and most average users don't, since node has performance comparable to other platforms using multiple processors), it is there, even if not perfectly baked. Honestly the worst part about this is in the business world where you have to explain to the IT department that their godly 32-core server just has 1/32 of its CPUs in action lol.

a_bertrand wrote:Another issue is the "stability" in term of API. Each release of node.js do change the API, and many times it's not backward compatible. Now they promised that the core should be more or less stable as API, but as we are still not with a V 1, I may expect they will actually change things.

node seems like it has stabilized out quite a bit, but I understand the concern. I would like to see a 1.0 release. But then again, this doesn't seem completely like an isolated issue. I have been noticing more and more software projects hesitating to move to 1.0 for some reason. I think more projects are beginning to see it as an excuse for any potential problems, like they are leaving the "We aren't even 1.0" card in the deck potentially for years. Same thing is going on with a lot of F2P MMORPGs, which seem content to stay in beta for years after they are commercially running (Runes of Magic was in "beta" for almost 5 years after their real-money store opened).

a_bertrand wrote:Error handling can be an issue too, as some errors are not within your code, and as you cannot make a try catch around callbacks, you will basically not catch them so easily. All async code do have issues with error handling, same in .NET. Yet in .NET, maybe due to my higher knowledge, it seems easier to catch those issues.

Last thing, is the tools. node.js is pretty new and not developed by a company like Microsoft, so no visual studio for node.js. No incredible debugger. Yes there is tools, yes there is editors (WebStorm for example is really great) but we are FAR away from a visual studio.

I admit error handling isn't what I would like (I would also rather have try catch blocks), but apparently this is a casualty of asynchronous programming all across the board. This is due to the way the stack works during asynchronous calls. The exceptions would not be thrown up the stack correctly and would wreak havoc. So instead in node, an error argument is sent in to the callback, which you can check to see if an error occurred and react accordingly. Not perfect, but it has been working fine for me.

As for tools, to be fair to node, no language has another Visual Studio. Honestly, that is the problem with .NET, is that Visual Studio forever spoils you. The closest I have ever found, believe it or not, are some of the modern Embarcadero Delphi versions. Java has some decent IDEs, but nothing to the level of Visual Studio. WebStorm is great and all, but having the support that VS gives .NET for JS is impossible because the support that VS offers is built into the languages of .NET in their extensive metadata. That is how Intellisense works so well and so "magically". VS is analyzing your code and building up metadata representations of it that it can consume to read your intentions. This is also how the .NET runtime JIT compiles the MIL to run so well. So an IDE alone can't physically compete with VS. It needs the language, platform and IDE to all work as one.

WebStorm does actually give you pretty decent debugging, however. I have only had to use it a couple of times, but it has helped me easily both times, with full local watches, live mouse-overs, etc. It was pretty nice, even if it is no VS

I still believe the async provided by node.js is different. In C# when your callback from any async event is fired, for example, if you do a beginreceive on a socket, the callback runs on a NEW thread. Those threads are thread pooled by .NET so you don't have to worry about spanning 2000 threads, and if your code is short enough you will again not have too many concurrent threads, yet, it does run on a separated thread which gives you the option to continue to run your main code while at the same time answering to network callbacks. Node.js will run only 1 code at a time, as it doesn't seems to be threaded, and therefore, either you run in your main code, or in an event code, but not both at a time, and certainly not multiple events at a time.

For the realtime, well as you point out, I'm pretty sure he was talking about "realtime" web. Where realtime here means little due to the network infrastructure. And for me socket.io simply cover all.

For the multi-core, well, so far I can't really complain myself. WSIRC has it's decent 300 visitors per day (not a lot I know), and cubicverse seems to work well too, plus all my PHP stuff all on the same server. No issues currently so I can't complain. Yet if I would want to scale up, node.js would not make my life easier, while in .NET it's basically built in.

For Visual Studio spoiling it, sure thing. Basically, .NET is great mainly due to Visual Studio (of course the framework offers incredible things too) but still. And yes, why should we not expect something similar on another language? Sorry but why stop at .NET? If somebody managed to offer something of that level, then we should expect that level for other things as well, don't you think? I'm joking somewhat here, as I fully know what kind of effort it is, and why it is way not easy to port that kind of experience on other languages.

a_bertrand wrote:I still believe the async provided by node.js is different. In C# when your callback from any async event is fired, for example, if you do a beginreceive on a socket, the callback runs on a NEW thread. Those threads are thread pooled by .NET so you don't have to worry about spanning 2000 threads, and if your code is short enough you will again not have too many concurrent threads, yet, it does run on a separated thread which gives you the option to continue to run your main code while at the same time answering to network callbacks. Node.js will run only 1 code at a time, as it doesn't seems to be threaded, and therefore, either you run in your main code, or in an event code, but not both at a time, and certainly not multiple events at a time.

Really? .NET async is running on another thread? Isn't that kind of breaking the point of asynchronous programming by re-introducing concurrency issues? If it is using secondary threads, they would definitely have to be quite watered down and losing most of the benefit of threading to automatically avoid concurrency issues. Basically, asynchronous programming's benefit is serving many requests without the concurrency issues of threads, and threading's benefit is nearly unlimited scaling while unloading all of the safety concerns on the programmer. It seems like mixing them would be the worst of both worlds.

Are you sure that is the case? Because most Microsoft documents I can find seem to be implying (without coming right out and saying it as far as I can find) that .NET async is all single-threaded. But I am not 100% sure on that.

a_bertrand wrote:For Visual Studio spoiling it, sure thing. Basically, .NET is great mainly due to Visual Studio (of course the framework offers incredible things too) but still. And yes, why should we not expect something similar on another language? Sorry but why stop at .NET? If somebody managed to offer something of that level, then we should expect that level for other things as well, don't you think? I'm joking somewhat here, as I fully know what kind of effort it is, and why it is way not easy to port that kind of experience on other languages.

Don't quote me on this, but I think I remember there was some talk about adding a standardized system to build structure-defining metadata for JS to help create better tools and faster execution as a reaction to HTML5 JS apps. If it is true, it is obviously still years away from usable implementations, but that would be awesome!

Found it! From this MSDN page:

Async methods are intended to be non-blocking operations. An await expression in an async method doesn’t block the current thread while the awaited task is running. Instead, the expression signs up the rest of the method as a continuation and returns control to the caller of the async method.

The async and await keywords don't cause additional threads to be created. Async methods don't require multithreading because an async method doesn't run on its own thread. The method runs on the current synchronization context and uses time on the thread only when the method is active. You can use Task.Run to move CPU-bound work to a background thread, but a background thread doesn't help with a process that's just waiting for results to become available.

It runs the exact same way that node does

Sure not. Node.JS use only one thread (unless YOU fork your process but then you have other issues). While in .NET world, callbacks runs on separated threads. That's a huge difference.

Think about 1 process, which starts listening to port 80 in async mode (a web server )
Now this callback when somebody connects to port 80 takes 1 sec to answer. What happen if you have 2 connections in the same second? On .NET you will see 2 threads answering each their connection, on node.js you will deal with one connection, finish the job there, and then jump on the second one. NO CONCURRENCY. Is it always bad? No, if your callbacks are fast enough you should be fine, but you can't use the available resources, and you must be careful with what you do inside the callbacks.

So no, node.js doesn't work AT ALL as .NET or Java. It look like at first, but that's it.

Also, callbacks in node.js are NOT like events in .NET. A callback is one single function for a given "event" in node.js while in .NET with the += operator, you are basically adding your function to a list, which means you could have 100 or more functions called from a single event.

This thread is awesome, it's already given me dozens of keywords and phrases to Google!