Node.js Overload | Hacker News Reader

Node.js Overload

thoughtworks.com

45 pointsorange859 comments

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.

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.

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.

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.”

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

Your analogy is wrong. You said, “ when I switched to only eating polenta.” but it should have been “ when I switched to only cooking polenta.”

Only eating one type of food is crazy. Nobody does that and if they do, it’s not fun.

However, as a chef, streamlining the types of meals that you cook sounds like a great way to free up time and have a lot more fun in your life. It doesn’t sound weird at all, not even in the slightest degree.

If I had 2 knives in my kitchen that behave quite differently, but achieved the same goal as efficiently, as long as you know how to use them, then I would be tired of cutting myself. I would drop one really quick.

If you are not a restaurant, and eating polenta is fine for you, and make you save time and increase fun, then go for it!!

My business is not programming, is to provide a service.

I understand the right tool may make a tremendous difference in a big team or someone coding full time, but not for me.

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.

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

> those who can write threadsafe code and those who can't

This, abstracted, those who can write distributed software and those who can't yet.

Dealing with shared resources is similar to dealing with shared memory if you zoom out a bit.

We need more people to move from the latter group to the former, for reasons. The more people aware of distributed software and its challenges, the better.

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.

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

> Writing real multithreaded code without a GIL is hard.

A GIL doesn't help developers. It only keeps the internal state of the VM consistent. You still need to to use locks, thread safe collections etc. That's one major reason why some people feel that OS threads + GIL is a poor trade-off.

https://github.com/ruby-concurrency/concurrent-ruby#thread-s...

Never knew that thanks!

Writing multithreaded code without a GIL is hard, but there's really good workarounds for a lot of cases. For example, Boost ASIO's "strand" pattern. You can define a set of coroutines that never run concurrently, so synchronization is much easier, while you can have many strands. I use this model in some of my Rust code - I associate clients to a producer, meaning I don't have to work out a suitable contention-free bus.

This is essentially equivalent to running N single-threaded processes, except that when I do have to share data across the system (e.g. a database connection pool), or if the lifecycle of the client crosses multiple strands, I have more tools in my toolkit.

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

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.

> 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/

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

Any examples? Given that WASM can't manipulate the DOM, I'm suspicious of this claim.

There is blazor that does this in C#.

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.

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.

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.

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)

Not sure if you read it fully or not:

> When Node.js became popular, it was the first major framework to embrace a nonblocking programming model which made it very efficient for IO-heavy tasks. (We mentioned this in our write-up of Node.js in 2012.) 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.

I did read it, just looks like I failed to fully parse that long winding sentence. So it is not a good choice for compute-heavy workloads, like a webapp that does video/image processing?

Multi-threading could be added to the runtime for back-end applications (https://news.ycombinator.com/item?id=15498219)

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.

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.

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://github.com/elestio/cloudgate

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

True, but NPM vs Nugget ... Still the same story

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.

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.

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.

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.

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.

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

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.

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.

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.

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

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.

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

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.

Reply on news.ycombinator.com