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