I realize you are critical of that viewpoint, but point 2 seems really wacky to me.
Current big project at work has a back end that is not in JS, but we still have a way to run the same validation code on both sides, which is run in an embedded JS interpreter on the server.
I'm not sure I would want to write a complete back end in JS or not (even if I'm not in love with Java, lately), but reusing this part makes a lot of sense.
---
We currently serialize (sync block) validation requests on the server through Nashorn, rather than having multiple instances (per thread or a pool). But, it's not like the requests wouldn't be serialized through Node, though. The rest of the request processing happens on independant threads normally. Not overly fond of threads, but I don't think I could get my team to by into Erlang or Elixir :-)
For that matter, my primary partner on this project is a big Scala fan, and we couldn't even get the rest of the group to go for that :-(
> Makes a difference: Same people can maintain it without too much friction.
For a very small team, I guess it makes sense. I would still prefere to be able to use Java/Kotlin/C# on the server and on the client then. Or even Dart. Not Javascript...
> Why not? It's nice, for example, to export your validation logic to a separate library and consume it from both sides.
Then they are couple together. And then you will tend to design your API in a way this particular application is well deserved. But if one day you have to consum the same service from another application, a native iOS application for instance, then you may start to realized that your API is too bound to your first consumer.
But I guess it's not that important if your backend will only be consumed by this particular application, ever.
> Then they are couple together. And then you will tend to design your API in a way this particular application is well deserved.
We have a server which exposes validation logic as a generated JS library (no server-side JS yet but we plan switching to Typescript) and that is used across many (more than 10) clients. I don't see any coupling. Changes in your models break the API regardless of you sharing anything.
1) It makes no difference at all if is the server is implemented using a different language than the client.
2) You shouldn't share any logic/code between the server and the client, even if they are using the same language.