
Node.js Overload - orange8
https://www.thoughtworks.com/radar/platforms?blipid=202005026
======
skrebbel
I'd like to add some context for those not aware.

This is a page in Thoughtworks' "Technology Radar". Thoughtworks is a global
US-based software agency that likes to market themselves as thought leaders in
the world of software. They're not super well known in startup land but my
impression is that in enterprisy environments they're considered "very good".

One way they maintain this image of thought leadership is employing famous
people such as Martin Fowler. Another way is by regularly publishing a
document called "Technology Radar" which is in opinionated list of
technologies that _their tech leadership_ believes ought to be used, explored,
avoided, etc. They explicitly don't position it as a bunch of truths they hold
to be absolute - it's just the opinion of a few senior tech folks at
Thoughtworks who had a fun weekend in a holiday house together or something
like that. I guess they had a disappointing Zoom call this time around.

It's generally a bit more conservative than HN, you often only see stuff
listed under "Assess" that has been commonplace in HN articles for multiple
years. This makes sense, it's targeted at enterprises. At the same time, it's
highly opinionated and they're not afraid to take positions that are not a
match with the current hype cycle.

I really like it for this latter quality, and I encourage you to explore this
edition further than just their recommendation to not always jump to NodeJS by
default (which seems to be a bit of a straw man to me, anyway).

Be sure to click all four "quadrants" (right top of the page), IMO the linked
one, "Platforms", is the least interesting one.

------
Mulpze15
I am an intermittent developer, because I need to sell, and manage my (small)
business too.

In my case, using javascript on the front end and PHP in the back, and as a
scripting language for servers was frustrating. Function names are always
slightly so different...

I increased my productivity and my fun tremendously when I switched to Node on
the backend.

Sometimes I am thinking about using Python for computer vision stuff. Nope...
Everything Javascript, so much better for my sanity.

~~~
shock
For a bit of unconventional (intellectual) fun, you can imagine your post as
being about cooking and food instead of programming and programming languages.

Something like: "I was an intermittent cook, because I need to sell, and
manage my (small) business too.

In my case, cooking both soups and main courses, and some deserts occasionally
was frustrating. Cooking times are always slightly different...

I increased my productivity and my fun tremendously when I switched to only
eating polenta."

I hope this does not come off as offensive, which was not my intention,
instead, I hope this serves as food(pun intended) for thought and reflection.

~~~
pavlov
I’m not sure that’s the right analogy for using different programming
languages in different parts of the stack. A back-end API looks the same to
its consumer regardless of whether it’s written in PHP or Node or Haskrustapl.

Maybe the analogy would be: “I was using three different kinds of butter in my
kitchen. I switched to just one brand. Turns out it didn’t make a difference
in taste, yet saves me effort and money because I can buy larger quantities of
the ingredient.”

~~~
valand
> A back-end API looks the same to its consumer regardless of whether it’s
> written in PHP or Node or Haskrustapl.

It looks looks the same to its consumer, but it will feel different when under
pressure.

I've experienced React SSR server (I know this is heavy) not able to withstand
traffic when pushed to only tens of concurrent users, reaching only 1000ish
RPS even after being clustered.

I'm not opposed to NodeJS though. I've learnt a lot of it and I've ever been a
NodeJS fanboy for like 2 years-ish.

PS: I also increased my productivity too moving from PHP to NodeJS back then
years ago.

------
nerdbaggy
If somebodies primary language is JS I think node is a great choice. 9/10
times node performance will be just fine for what people are doing. Writing
real multithreaded code without a GIL is hard. I would think just scaling
horizontal or vertical would be easier.

And doing threading in Python is so confusing for new beginners. There are
about a million different ways to do it.

~~~
hamburglar
> Writing real multithreaded code without a GIL is hard.

I'm starting to think this is going to be a major dividing line in developer
skill going forward -- those who can write threadsafe code and those who
can't. There's an awful lot of Java, C# and Golang out there and if a
programmer can't reliably think through thread safety issues (which is _not_
that difficult in simple cases), they aren't capable in that realm.

One of the most frustrating things about my brief excursion into the land of
Ruby was that the community was full of modules written by people who had no
reason whatsoever to think about thread safety because they were programming
for Rails, not Ruby in general.

~~~
jashmatthews
This sounds very gatekeepy. The JVM and Golang have additional aides for
writing thread-safe code because writing multi-threaded code is fucking hard.
People at the top of our field working on browsers or VMs regularly fuck up
the simple stuff. If it was easy we wouldn't have Erlang or Rust.

~~~
hamburglar
I'm very gatekeepy about only wanting competent developers working on my code.

------
zaro
> Due to its single-threaded nature, Node.js was never a good choice for
> compute-heavy workloads, though, and now that capable nonblocking frameworks
> also exist on other platforms — some with elegant, modern APIs — performance
> is no longer a reason to choose Node.js.

But do these other frameworks give you the simplicity of sharing code and
using the same language in for fe and be ?

For me the performance of Node BE applications is just a nice bonus, for
having consistent development environment with huge library of radily
available packages.

~~~
Kuinox
A lot of langage have work in progress and or working GUI framework compiling
to webassembly.

So yes. And you know what ? You shouldn't share too much code between backend
and frontend.

The packages are node disavantage. You depends on too much packages it's a
security risk.

~~~
zaro
> And you know what ? You shouldn't share too much code between backend and
> frontend.

Yeah right :) I'll tell you what I like about it.

I defined my database models in Typescript[1], work with them in the backend,
send them to the frontend, and deserialize them back to the same Typescipt
model classes in the browser and continue working with them ( w/o the actual
database part) as data structures.

Are you trying to convince me this is bad ? Because I definitely don't believe
you :)

[1] [https://typeorm.io/](https://typeorm.io/)

~~~
Kuinox
That exactly what you shouldn't do, database models should not be the same
models than the one sent to the client.

------
orange8
It cites the reasons for Node overload as:

\- The convenience of using the same language in the client and server

\- The speed of Node.js

It unfortunately does not state why it shouldn't be used in the server, or
offer any more suitable alternatives.

~~~
arcturus17
Well it does mention that its single-threaded nature makes it a poor choice
for heavy compute workloads, which I agree with. I also think it’s fine for
pretty much everything else.

~~~
zumachase
I'm not sure I would agree with this. As with all things, it depends on the
task, but "compute heavy" these days means likely working with a distributed
framework that abstracts away the underlying process architecture, letting the
user define lambda-esque tasks which are deployed across a stream/batch
processing model.

I think a much better critique would be that the lack of fine grained
primitives, and the surrounding ecosystem, are not the best choice for compute
heavy tasks.

~~~
arcturus17
It doesn’t have multithreading, period. You can compute in parallel and work
around it by using serverless functions or worker threads or whatever, but
often it feels like you’re going against the grain and/or reinventing the
wheel.

I definitely see the merit in preferring another language with a clear, native
multithreading model - and with perhaps significantly better general
performance to boot.

If anything, the critique in my opinion misses how the Node web frameworks
tend to be really unopinionated and non-prescriptive which can be great for
some teams and projects but really bad for others (they do mention that NestJS
is a technology to watch and that they use it widely, so I actually think
they’re of the same opinion)

------
mmkos
The snippet about Node is confusing terminology. Node is not a framework, it's
a runtime environment in which JS can run. It makes a mention of other
"capable nonblocking frameworks", but is conveniently vague about which ones.

The argument about compute heavy workload also feels orthogonal to the whole
issue of Node on the backend.

------
kumarvvr
While having one language on the front end and back end might seem like less
of a burden, the cognitive context for both of them are very different.

Reasoning about the backend feels much easier in languages like C# and even
python. Because the majority of the code in the backend is about data storage,
retrieval, data modeling, rich and complex business logic, etc. While on the
front end, the focus is usually on data binding, immutable structures, etc.

JS in react is fine and in my view, for the notion of same language
everywhere, JS is a poor language.

------
js4ever
I have adopted node (over .Net C#) several years ago and the main reason was
NPM and the 1 million packages available. About performances ... With Workers
it's pretty good, I'm doing 700k RPS with node on 1 server.

Refs: [https://vms2.terasp.net/](https://vms2.terasp.net/)
[https://github.com/elestio/cloudgate](https://github.com/elestio/cloudgate)

~~~
romanovcode
If you felt comfortable with C# you should try .NET Core. It's amazing.

~~~
wayneftw
I have and I found C# to be somewhat painful compared to JS in some respects,
but good in other ways.

There are a lot of little conveniences that are missing. There is no
destructuring, no first-class functions (i.e. can’t declare functions outside
of a class), no easy way to loop over properties of a class and access their
values, no spread/rest operators and other things like that.

I think the C# 9 might address some of these shortcomings.

Some things that I liked about my .Net core project: I didn’t have to write
swagger documents at all. They just got auto generated from my API classes.
Dapper is better than any micro-ORM that we have in JS. I didn’t have to write
a bunch of tests to make sure I was using correct types. It works great on
Linux!

Everything’s got its trade-offs. I started my career with Microsoft Access, VB
4/5/6 and complained about moving to .Net. Then I did like 12 years of C# and
couldn’t imagine loving JS until I started doing _that_ full-time, since like
2013 or so.... I was glad to polish off my C# skills and to learn .Net core
though, just in case I want to switch back some day.

~~~
h_r
The things you cite as missing in C# can be found in F# on .NET Core. Have you
ever tried it? I find it hard to stomach C# after delving deeply into F#, and
you still get to use Dapper! Swagger though... not sure if anyone ever got
that working well with Giraffe or any other more functional web framework.
When I say "working" I mean automatically generating the Swagger docs for you.

------
tnolet
Totally speculative and 100% opinion: could it be that Thoughtworks is a bit
scared of JS taking over the world? My feeling is it totally does not fit
their model: enterprise heavy, high $$$ consultancy, Java all the things. I'm
exaggerating of course to make my point.

------
ajeet_dhaliwal
If you are more productive using Node.js for back-end and React/other JS
framework for front-end then don't worry about it and go ahead. Especially so
for a small business with few development resources. The performance issues
can be tackled when they arise and in in some areas you could use addons or
even just break down some work into another service/micro service using Java
or whatever. The productivity benefits can be massive and that's usually the
bigger issue if you're creating a general web/service. I work on tesults.com
and it's all JS.

------
rswskg
Thoughtworks are extremely fad driven. 10 years of that radar and it has
become slowly clear that they use it as marketing to appear relevant.

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

~~~
kumarvvr
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.

~~~
zumachase
> 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.

~~~
kumarvvr
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...](https://stackoverflow.com/questions/35457486/performance-and-memory-
differences-between-c-sharp-and-javascript)

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.

------
29athrowaway
If you don't understand the node event loop, don't use node.

------
valand
I'm a NodeJS fanboy and I partially agree with this.

Feel free to use NodeJS if it allows you iterate faster and your app doesn't
need much load.

If you're planning to serve a lot of ConcurrentUser with high RequestPerSecond
I suggest to carefully plan the execution.

I'm having trouble now. One of the projects I'm working on is using NodeJS
acting as React SSR server (I know it's heavy). It crashes under pressure,
with 10-ish CCU reaching only 12-RPS before crashing. The NodeJS server is not
clustered yet though. If it is clustered, it might reach a bigger number, but
I doubt it would be that significant. Scale up to 1000 users using Kubernetes
and see yourself how big the compute bill next month.

This is a fault in architecture and I'm telling you not to repeat my mistake.
There are enhancements to NodeJS. NAPI is one, WASM is being introduced too,
which is good news. You can utilize child_process and hire someone to write
some fast binary for computation-heavy applications and execute that binary.

Again, a lot of companies succeed with NodeJS. It's not to be completely
avoided. Just be careful not to use it for something it is not used for.

