Node.js – the developer’s Swiss army knife

Mike Sedzielewski on October 02, 2017

After reading Anthony's article on how JavaScript is eating the world, I thought I would share our experience with this technology. While Anthony... [Read Full]
markdown guide
 

It's very yellow header. I agree that node is great and become very mature in the last couple of years, but it's definitely not a Swiss's army knife. Event-driven programming is a great idea for i/o bound operations which is almost all of the api's. But single execution thread and dynamic nature shoots you in the foot in case of heavy cpu bound operations. Of course you can write a c++ module for node, but either way you gonna get more suitable instrument for this (some multithreaded stuff, like go, rust, c# or java). Machine learning and data science also struggles due to lack of tooling (AFAIK every non-data-scientific language sucks besides python).

 

I think the comparison to a swiss army knife is rather apt. It has multiple uses, but in quite many cases, it will only be a more or less poorly performing drop-in replacement for the real tools of the trade.

What I like about JavaScript is how it is developing as a language, a community and and an ecosystem. Sure, we won't see it in real-time-critical applications soon, but that's fine for now. Eventually, computers will become so fast that it won't make a difference anymore.

By the way, you can actually do multithreading in JS, in the browser either using Workers or WebGL and in node.js using childProcess.fork().

 

Agreed! I quite like C# with .NET core for data science as I can get it to scale nicely on Linux docker containers or Hadoop clusters.

I found when writing my specifically odd types of dynamic neural nets in JS is that JavaScript's difficulty with number precision and dates always left me uncertain that I wasn't losing data.

I'm keen to try compiling C# to wasm.

 

Node is great for automation in tooling, but definitely has its quirks. It's great for APIs if you outputting JSON, but it's still your worst choice for RDBMS databases. Golang also dealing with asynchronous code much better. Even with async/await, still not easy to manage async code, never will. I don't have experience with Java, C#, etc., but seriously, just look at goroutines, why other languages f*cking with us when we have to write asynchronous code!? And you will have to write async code in Node.js, a lot. And you will screw it up, just like anyone else.

My favourite one when a well known package author gave me a "solution" for executing it's function asynchronously and taking screenshots to files one by one. His promise example didn't worked. Then I thinkered a little bit and rewrote it with async/await. Of course, his answer was, he just gave me "directions" how to write such code, his example not meant to work... :)

Even the goddamn package authors (which package using promises under the hood) don't know how to write asynchronous code properly in Node.js. I don't know, too. It's a mess. Save yourself some seizures and look at another languages as well.

Modern re-thought languages like the Golang takes away this problem from you.

 

It’s gone through the Java-community critique
I stopped reading here.

 
code of conduct - report abuse