To clarify my point, I think nodejs is great for the backend part of the view layer and to proxy requests to another backend service.

But for business logic, database interactions, calculations, etc, I really think the language construct is to clumsy and does not scale nicely.

> want back ends that can interoperate with those front ends.

You can ingest and emit JSON in any language. You can even compile backend-friendly code to run in JS on the frontend, via emscripten (and increasingly, Wasm), which will output very lean and JIT-friendly code. The usual "isomorphic" case for backend.js is no less 'presumptuous' or 'dismissive' than the comment you're pointing to and criticizing here.

  > You can ingest and emit JSON in any language.

How is this relevant? Serving a JS application to a client is not like serving a JSON API.

  > You can even compile backend-friendly code to run in JS on the frontend, via emscripten (and increasingly, Wasm), which will output very lean and JIT-friendly code.

Not in my experience. Compared to front-to-back JS, shipping your applications as WASM ends up with downloads and memory footprints that are several times larger than the same application in ordinary JS, and this matters a lot for slower networks and mobile clients.

Edit: not to mention that Go has a very limited WASM story, so your "realistic" choices for shipping back end code to the front end are C++ and Rust.

> How is this relevant? Serving a JS application to a client is not like serving a JSON API.

In some JS applications, the way the frontend code communicates with the backend is via JSON API endpoints. I believe GP was just pointing out that you can write that JSON API in any language you want.

> not to mention that Go has a very limited WASM story, so your "realistic" choices for shipping back end code to the front end are C++ and Rust.

Can you elaborate on this? How is it limited in comparison to say, Rust.

My understanding is that to get reasonable WASM file sizes, one must use tinygo (a C reimplementation). tinygo is a WIP, although I wish I could find a better updated description of what's missing than this page on their site: https://tinygo.org/docs/reference/lang-support/

This page[0] seems to have some good information(on stdlib support at least).

As far as file sizes go, you're right. It might be possible to get better results deploying a brotli'd or gzipped file instead[1].

[0]:https://tinygo.org/docs/reference/lang-support/stdlib/ [1]:https://github.com/golang/go/wiki/WebAssembly#reducing-the-s...

> The usual "isomorphic" case for backend.js is no less 'presumptuous' or 'dismissive' than the comment you're pointing to and criticizing here

> You can even compile backend-friendly code to run in JS on the frontend, via emscripten (and increasingly, Wasm)

Lol, you can't be serious

>>increasingly, wasm

If you are referring to something similar to Blazor (client side), yeah no imo it's pretty awful for anything other than internal enterprise apps. I couldn't imagine running a public facing product on that.

By using Typescript you can share types on the backend and frontend. Java stacks tend to do the same thing but for backend and database by defining data at the ORM level. You can connect to your database in any language, but most people using Spring don't write plain SQL.

Your comments tells me you are in the group who doesn't know better. Data is passed in json which is a format other languages can read and send back. If that's your reason for using it you do have other choices.

I could understand this reasoning but it is not the typical node backend I am seeing in the wild.