A 7KB AWS lambda Node.js library with zero runtime dependencies

Not knowing this myself, could someone explain the attraction in using a web scripting framework for stuff like this? I get that this particular example makes the whole thing seem fairly straightforward, but have never really heard why people like adapting Node.js and similar to non-web environments beyond "you can". Is there anything more to it than that?

Golang is about as far from single threaded as you can get, and I find it much easier to understand than Node. I actually switched from Node to Go on a Greenfield project, and I find myself much more productive now, and when things need to be done in parallel, Go is much easier to read, write, and maintain.

Edit: to respond to the GP, I think sharing a language between front end and back end can enable people on either side go full stack with more ease. That's a benefit I guess, but not one I considered of particular value.

It’s handy having a single language and toolset for programming. There’s less friction when switching between codebases. I’ve been paid to program in a whole lot of languages over my career, and personally preferred the environments where I didn’t have to switch languages all the time when working in different layers of the stack.

These days, I’m mostly paid to write web applications. So, I default to JavaScript. That said, there are plenty of problems where JavaScript is such a poor fit that I’ll reach for something else.

Main strengths:

* The ecosystem is pretty strong and constantly evolving. Lots of companies and individuals are putting a serious amount of work into making high-quality tooling and libraries. (Although with that also comes a lot of lower quality stuff and its sometimes hard to tell)

* The language isn't owned by any single company and is well specified

* TypeScript provides a powerful and flexible type system with advanced dependant-types like features. Lets you gradually evolve from a messy JS prototype to well-organized code with fairly strict type checking

* Fastest dynamic language. The performance is also quite comparable to statically typed GCed languages. (For example, you can probably get to 50%-90% of Java performance on most single-threaded workloads)

* wasm support in the runtime a promising escape hatch to the integration with other languages should that become needed. (Similarly not owned by a single company and well-specified)

* sharing code and types between client and server, including interfaces, validation and data models.

* particularly well suited to handling heterogeneous structured data due to how cheap it is to define new object types (even in typescript)

* Async-IO-first (in fact, async-only IO for the most part)

Main weaknesses:

* Poor standard library with an anemic set of classes, anemic set of implementable protocols/interfaces (more stuff like Symbol.asyncIterable needed) and lacking convenience functions. E.g. see https://api.dart.dev/stable/2.7.1/dart-async/Stream-class.ht... and compare with... well nothing in the language! The official node streams have a terrible API.

* Combining lack of both protocols and standard library leads to pretty bad userspace library fragmentation. (What is the go-to stream library?)

* Restricted data sharing between threads (only SharedArrayBuffer) makes it quite limited for multi-threaded problems.

* (mainly TypeScript) - Insufficient reflection capabilities

* Rigid (non-configurable) node_modules resolution algorithm accepted as standard limits flexibility when organizing projects

Mythical weaknesses that don't matter that much:

* Implicit conversions - largely irrelevant since TypeScript

* DOM/Browser related weirdness - often attributed to the language but actually problems with browser APIs

> The performance is also quite comparable to statically typed GCed languages. (For example, you can probably get to 50%-90% of Java performance on most single-threaded workloads)

Citation needed, please. I disagree with this. I recently was able to achieve a massive speedup in a Node application through writing a native C++ module... and implementing Garbage Collection is required for N-API.