Node.js 18 | Hacker News Reader

Node.js 18

nodejs.org

29 pointsWalterSobchak15 comments

I suppose I'll ask here: are there examples of node being used in large scale projects at reputable companies?

By comparison, we all know how common it is to hear of successful companies who got started with ruby on rails. I see many job descriptions from early stage startups asking for node specifically. For better or worse, I usually dismiss these companies as low-quality engineering organizations. The isomorphism argument for "Javascript on the backend" never grabbed me.

How large scale is "large scale" ?

Companies that use Node.js include the following:

  LinkedIn
  Netflix
  Uber
  Trello 
  PayPal
  NASA
  eBay
  Medium
  Groupon
  Walmart
  Mozilla 
  GoDaddy

https://trio.dev/blog/companies-use-node-js

Here are a few open source Google projects using Nodejs

- Angular https://github.com/angular/angular/blob/master/package.json

- AMP https://github.com/ampproject/amphtml/blob/main/package.json

- TensorFlow.js https://github.com/tensorflow/tfjs/blob/master/package.json

Thanks. Unfortunately I'm skeptical of the article: what I've heard from employees at Uber suggests much of the backend was python, and they have more recently mandated Golang-everywhere for backend services.

The other ones are more intriguing: I'm not sure what "the UI of Netflix" refers to. I understood they write native applications for all their different target platforms. Would be interesting to see how they integrate node

Plenty of people use node.js, including top companies etc.

It’s not necessarily used for long running processes or production services.

I would not use it for a production service without an explicit reason WHY I must as

1) there are better typesafe compiled options that generate machine code and don’t waste resources and scale suitably.

Go, Crystal, and Rust are modern suitable service coding languages, IMO

Plenty of people use node.js, including top companies etc.

It’s not necessarily used for long running processes or production services.

I would not use it for a production service without an explicit reason WHY I must as

1) there are better typesafe compiled options that generate machine code and don’t waste resources and scale suitably.

Go, Crystal, and Rust are modern suitable service coding languages, IMO

Node is often part of a build tool, or as a local service worker in an IDE or something

Regardless of backend, the majority of frontend tooling is in Node.

That is changing in quite a rapid pace, rust and go are getting more and more traction in these markets for obvious reasons; performance and speed.

Are you saying people are abandoning npm for rust in some way? Perhaps a build tool might be written in faster languages, but likely node is still going to be the way to interact with it.

You don't run JavaScript in the backend and even if you do, it's not a problem for a lot of common use cases.

JavaScript is also not the language people write in, it's the target. People compile there code into JavaScript more so that writing it.

The reason you have JavaScript on the server side of things is that it bridges the browser gap. You get to share some bits between your client and server code. Also, if you have hybrid rendering solutions it's really convenient.

You don't exclusively run Node everywhere just because you have Node.

It's a tool that can do some things really well. That's it.

Really? Personally, I've always enjoyed writing services with high I/O and low computation in Node.js. I usually consider Node.js first when having to create a new REST API (which usually just gaps between http and the database) or websocket server.

Depends on your use case but unless you really need JavaScript interop I think there are better alternatives. You are of course free to do whatever but neither JavaScript or Node is the answer to everything.

I think the Go concurrency model is a lot nicer, and it's considerably better throughput wise.

As much as I enjoy writing JavaScript is riddled with stupid stuff and lack sensible primitives but I do care about computational performance because I have a lot of code that I want to optimize and towards that goal JavaScript and V8 gets in the way. Even if it's a good VM it can get really ridiculous from a performance point of view.

Thanks, it sounds like we are in agreement.

The "share some bits between client and server code" screams unnecessary coupling and failure to separate concerns between backend and frontend. That's what I've seen in practice anyway.

Not at all. Rather you might want a tight coupling because it will allow you to integrate deeper.

Having the same code running on client and server when your application is split between running both on client and server is very convenient.

As an example, a React application with server rendering and then progressive enhancements on the client. Very common pattern.

Reply on news.ycombinator.com