> the only overhead is making sure objects were passing around match on both ends
Seem like is it a big deal based on the first sentence.
I've never been convinced of the single language argument. Sharing code between frontend and backend sounds good but as in practice there's little overlap... models have subtle differences, there's extra logic server side... All in all it's not very practical.
To me the most awesome part of a fully TS project is that you can use the same interfaces everywhere. If you take the time to define them for any input / output, everything is pretty much guaranteed to be sound.
> the type erasure problem is far worse than Java
Check out RunTypes [1], amazing to guard any incoming data.
There is big difference between "this API can blow" and "it can blow everywhere".
Don’t Node.js worker threads solve exactly this?
Which means you are second guessing the compiler, which provided you with such great guarantees.
You should do your best to minimize this kind of code.
JS also uses several times more memory, is slower, and has a terrible (non existing) threading model. Yes you can run multiple instance of node or whatever, but sharing objects between them requires message passing which is orders of magnitude slower.
Until JS has a good threading model I'm never using it for backend. It's too expensive to use a bunch of single core machines to make up for it.
All of our devs use Typescript and Java daily for front and backend, the only overhead is making sure objects were passing around match on both ends. The only advantage to using the same language for everything is hiring inexperienced devs that don't know both IMO