Hacker News Reader

Comment by santoriv | Hacker News Reader

I imagine I'll get downvoted for participating in the language flame wars but....

I've been working on a NodeJS backend at my main gig for the last two years.

For two years before that I was working on an backend application written in C#.

Based on my experience with those two systems, the answer to the question "When should I use Node for the back end?" should be: Only if your main language is javascript and you don't have the time and/or inclination to learn something else.

For me, working with C# was massively more productive. Static typing, robust async/await, and the fantastic tooling you get with Visual Studio + Resharper are huge benefits. Dynamic typing, callbacks and/or weird promise logic, and dodgy open source libraries which may not be very well documented or maintained are huge downsides for Node JS.

I would never choose to write a new project's backend in Node JS.

YMMV.

View on HN

I did the same as you, and my experience couldn't have been more different. It was tremendously freeing to escape the whole .NET framework that came with C#.

My view is that you're always more productive in the language you know better. I find things like being able to use functions as variables tremendously useful in JS. Not to mention the ability to share code between the back and front end of a webapp.

>I find things like being able to use functions as variables tremendously useful in JS

A thing in C# for 9 years now.

> Not to mention the ability to share code between the back and front end of a webapp

Technically possible if you care to do so, but TypeScript + a framework with bindings should be good enough on the front end to not have to completely tear down your conception of what you're doing when you move from front to back.

Wouldn't you agree that a compiled language is typically much easier to maintain than an interpreted one (refactoring, etc). Also, it's been years since I've worked in C#, but I would imagine you could stay in the language but ditch the frameworks.

It's not interpreted vs compiled, it's static/strong vs dynamic/weak. These just usually happen to fall along the interpreted vs compiled dichotomy.

But, for instance, IronPython and IronRuby are compiled, yet dynamic, and GHCi is a Haskell interpreter that runs an extremely strong/static language.

Have you tried TypeScript on the backend? I've seen that a couple of times now recently - .NET shops adopting nodejs on the backend via TypeScript and the feedback has been positive.

I used Typescript on the front end a couple of years ago but not on the back end yet. I imagine that it would be better than es6 since there would be some typing. I'd still rather go with C# and not have to deal with callback/promise land.

ES6 and ES7 fixes everything here except strict typing, by the way.

Also still no multithreading, which causes callback hell in the first place

Like others have said, callback hell is fixed with async/await, yield/generators, and even lightweight libraries like fibers and promises. Personally, I dislike promises, and I don't use them at all. That said, you have plenty of other choices when it comes to style.

The single-threaded nature of node.js was very intentional and was thought to be a better design choice for a certain class of applications (IO focused, not computation focused) like routers, web servers, and other networked applications.

Single threading was not intentional. It's because they used js, now they're trying to sell it as a feature. They've tried to implement threading several times but it's a huge change to the V8 engine and js isn't designed for it.

Promises/async were needed to make the language usable because it's stuck on a single thread. The normal solution is to just use multiple threads and people have been doing g that for many years in other languages

"its because they used js"

But, this was intentional. As for them implementing threading, I am not sure about the history here. Was it like: "We used JS and knew we were going to have a ST environment, but because people wanted MT, we tried..."

Or, was it more like: "Let's use js and we'll of course need MT like everything else... oh wait... nvm."?

I second that. JS is singlethreaded by intention, and IMHO it's ok that way and the reason why the ecosystem mostly works and async libraries can be reasoned about. There are JS implementations (like Nashorn on JVM) which are multithreaded, and imho they would be a much poorer choice. Once you have callbacks and multithreading in a single system there are dozens of things you need to care about (from which thread will callback be fired, how to synchronize that with the remaining logic, ...) and the complexity grows immensely. I think that's exactly the scenario that the JS inventors wanted to circumvent.

Java and c# manage threads+async just fine. You're overestimating the difficulty of using then together. In practice you just add the word async or await and go about things normally like in node.

Js is single threaded because it was designed that way, not because it's a good design

I disagree. In my experience from seeing lots of code multithreading issues are one of the most common. E.g. in Android or C# GUI frameworks it's a super common error that people try to manipulate GUI elements from a background that just invoked their callback - which is not allowed. The issues there are typically that people without much experience don't even think about from thread an event can be fired - and what you should do if it's another one than the main thread. Even if you know about these problems it's often not clearly documented what the threading model of libraries is. Afaik the JS creators explicitly intended to avoid these issues by using a singlethreaded model.

The most common use case for node is probably as a web framework. At least in this case multithreading doesn't cause issues in c# or java. You just add an async decorator to your methods and it works.

You're defending the single threaded model as if multithreading is a problem but it's just a feature. you could choose not to use it if you don't mind the performance penalty, just like async.

Node not having multi thread support is definitely a negative.

It was very intentional. The original developer wanted to create an event loop based system because at the time the C hackers had begun to learn how fast those systems could be for the purpose the parent comment mentioned (io bound, network servers, etc.) and instead of using something like lua he chose javascript to give it wider appeal.

JavaScript is single threaded. This wasn't an intentional choice of Node.js, unless you consider @ry picking JavaScript as the basis for your claim. "Non-blocking" code however was the original claimed benefit of Node.js for the reasons you mentioned.

This seems like nitpicking to me.

With proper use of promises, async/await and generators, there is no reason for callback hell.

But why would you need threading? 99% of the time will be spent waiting for io. And you can allways spawn a process if you need something computationally heavy.

If you max out the core running your node thread, you are just about to need a second machine and load ballancing anyway.

That's just not true. With SSD's and cheap ram less time than ever is spent waiting on IO. Almost everything these days is CPU bound and it's only going to go more in that direction as the speed disparity between storage and memory shrinks

Your statement is true if we only consider a single machine. But, people using node.js are most often writing networked applications (right?).

Do you count waiting for io from the db? I know in my apps there is very little processing going on in node itself.

Insert relative access times chart here.

async-await is in neither of those, though TS does support it and downlevels it to ES5/ES6.

Async-await is one of the main features of ES7.

You are mistaken. The only new syntax ES7 added was the exponentiation operator. async-await was still in stage 3 at the time. It will be in ES2017 (ES8).

Hm, that's unfortunate.

Ts is great on the backend. And if it gives you only "some typing", you are doing it wrong.

With noexplicitany and strictnullchecks, you can get really nice, typed code.

Even stringly typed code can be typed now, with keyof.

I imagine I'll get downvoted for participating in the language flame wars but....

From the guidelines:

Please don't bait other users by inviting them to downvote you or announce that you expect to get downvoted.

https://news.ycombinator.com/newsguidelines.html

If you think you might get down voted, take extra care to ensure you're expressing your thoughts clearly and civilly. There are those who will down-vote regardless, but you can "decrease the attack surface" by writing the best comment you can.

I apologize. I was unaware of that rule. I won't do it again.

No need to apologize. Just wanted to bring it to your attention as you'll likely get down voted just for mentioning downvoting.

See!

That rule is stupid. The only times I don't get buried when saying something unpopular is when I ask not to get buried.

Downvotes aren't usually from a lack of civility. They are from saying something that contradicts other people's worldview.

I love how this community of "disruptors" is obsessed with following the HN commandments.

I have never used C# but I'd rather learn it than write code in Javascript.

One does not preclude the other. C# is a pleasure to work with, and a powerful language and environment, but Javascript is the tool for the web-based front end, and a nice language in its own right. Provided a certain discipline, one can use it to write reliable and maintainable code.

I tend to get downvoted to hell a lot, so I can't downvote you, because I don't have enough karma.

But when you say "callbacks and/or weird promise logic" I can't help but cringe a little bit. Syntax really depends on what the developer is familiar with.

When you get used to the syntax, and use a decent editor, the syntax is a less important consideration -- a for loop is "fo + enter" in every language. The base libraries and API are important, but I don't consider that syntactical. That said, some languages lend themselves better to certain styles of programming -- but that may be a matter of flavor as well.

Reply on news.ycombinator.com