Hacker News Reader

Comment by orliesaurus | Hacker News Reader

So what does HN think are the downsides of using Node, the article didn't really state them explicitly?

Performance. The article pretends it's good, but it isn't. Perhaps when you compare it to Python/django/flask, but node is not the best solution for file I/O, and takes a lot of memory.

What isn't it good compared to? You said it's good compared to python and I don't think it's fair to compare it to compiled languages like go, C, C++, Rust. In techempower[1] benchmarks node usually falls somewhere in the middle, and es4x (claimed to be the fastest js runtime) is usually in the top 50, and an overall place of #9. Benchmarksgame[2] also seems pretty okay to me.

[1] https://www.techempower.com/benchmarks/#section=data-r19&hw=...

[2] https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

It's entirely fair to compare Node to compiled languages. People often choose between it and those languages for backend code. The reason they choose Node most of the time is simply because they want to use the language across the stack not because performance is a top priority.

Java (from the benchmarks page) can be quite a resource hog too, but those benchmarks are hardly relevant to servers. ES4X is written in Java, BTW.

I think it's totally fair to compare node/js at least to Go. Go is quite simple: it's a GC language, almost without pitfalls except for nil and not error checking type conversions. It's really not unlike JavaScript in many aspects.

Also: node's performance is ok when passing small amounts of data per request. It's when you use it to serve files (images, videos in particular) or larger data tables that it loses steam. And it will take quite a bit of memory, though, unless you start optimizing.

Node is one of those environments that makes it easy to start a project, but difficult to bring it to fruition.

> It's when you use it to serve files (images, videos in particular) or larger data tables that it loses steam.

Pretty much every guide/tutorial/documentation says to not use node for this. Isn't this the same for a lot of languages like php, python, ruby, etc? Those all usually run behind a reverse proxy that handles file serving.

You know what, i'm just gonna say it: Javascript and NPM.

Javascript itself.

- But you can just use Typescript! Good, I like Typescript but what about some good web framework? You can use NestJS (https://nestjs.com/) which is amazing.

But if you step back, you see that you are basically writing C# that will transpile to JS. So then I just switched to .NET Core.

I feel like it's difficult to be an infrequent Node user since everytime I come back to a project or I want to re-use something, I need to manage the dependencies. The modules are often updated and there are breaking changes....

Performance is the primary reason.

Backend performance is usually directly related to cloud resource costs.

Better have a compiled language, even if its within a VM, like C# or Java, rather than interpreted ones like JS or python.

> Better have a compiled language, even if its within a VM, like C# or Java, rather than interpreted ones like JS or python

I'm not sure you understand how these languages work as none of the are truly compiled in the sense I think you mean (natively). Both Java/C# and Javascript work in the same way: they are compiled to bytecode which is then interpreted. The only difference is that Java/C# is compiled AOT whereas V8 (presumably) compiles on first execution and caches the output. Python is a truly interpreted language although PyPy can give a huge perf boost.

Your comment caught me by surprise.

For one, I am under the understanding that strongly typed languages like C# and Java, are optimally compiled to bytecode such that the overhead of running in a VM is minimal and performance is comparable to native code.

I maybe wrong, I dont have a up to date knowledge of JS runtime and optimizations, but for such a dynamic, loosely typed language, there is only so much AOT and optimization you can do. V8 might have bridged that gap a fair bit, but is nowhere close to performance of C#.

However, in almost all benchmarks, for real world use cases, .net always trumps JS runtimes.Also, a developer needs a high level of awareness and knowledge of underlying systems in JS to write performant code. The same is not true with C#, in the sense that as a seasoned developer, the strongly typed nature of C# mostly saves me from writing poorly performing code. I dont have to worry too much about underlying mechanisms in C#.

Edit : https://stackoverflow.com/questions/35457486/performance-and...

I found this. So, a program made for performance comparision between C# and JS would probably be equally fast in both. However, JS loses performance in real world due to its dynamic typing.

Due to start times, in a serverless environment that argument doesn't stack. Will probably change in the future though.

maintenance ability. building any big system with node is just difficult. typescript helps a bit but it's no where close near a statically-typed language

Under what definition is typescript not statically typed?

In the one that it is statically typed on compile time, but what gets executed is not because the javascript vm is not statically typed.

What you might be trying to say is that TypeScript is not _strongly_ or _soundly_ typed. "Only statically typed at compile time" is a meaningless statement because "checks types at compile time" is the whole definition of static typing.

The JVM also does erasure of generics. Yes, it's not _all_ types but it too relies heavily on compile time typings.

^ I see that you're not joking with this comment :D. Jokes aside, I'm adding facts

TypeScript is statically typed because of the type annotations and how the compiler checks the type compatibility between objects.

You may can consider TypeScript weakly-typed, because the TypeScript type information are not being encoded into the compilation result.

This is similar to C (being staticcally and weakly typed). You can print int as string and the compiler won't complain.

On the other hand, JavaScript is a dynamically typed and strongly typed language. It is strong as the types are encoded in the runtime. The proof is the keyword `typeof` and its ability to do Reflection.

Reference: Static vs Dynamic: https://en.wikipedia.org/wiki/Type_system#Type_checking Strong vs Weak: https://en.wikipedia.org/wiki/Strong_and_weak_typing

You've misunderstood what "weakly typed" means. If a language implicitly converts values (like your C example) or otherwise lets execution move forward in the presence of what are or should be type errors, it's weakly typed.

JavaScript has plenty of implicit conversions and will generally only halt execution if it literally cannot do something (like make a function out of `undefined` or the like), much like C, and is a weakly typed language.

Reply on news.ycombinator.com