[throwaway189262]

I use typescript a lot. It's way better than JS but the type erasure problem is far worse than Java. Essentially all types are erased, so bugs where typings don't match what you expect and everything blows up are common. This isn't possible in Java because it's statically typed at runtime.

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

[ht85]

> bugs where typings don't match what you expect and everything blows up are common

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

1. https://github.com/pelotom/runtypes

[salamanderman]

It's more about the ability to share programmers than the literally code, in my opinion.

[throwaway189262]

This library looks great! For cross language comms you can also use gRPC to avoid writing objects for both sides. We're not using it company wide but so far it works as advertised, minus the annoyance of having to use gRPC proxy to web endpoints

[watwut]

> Seem like is it a big deal based on the first sentence.

There is big difference between "this API can blow" and "it can blow everywhere".

[manquer]

Sharing same stack is more important when team / project is small.

[0xae4f5b]

> 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

Don’t Node.js worker threads solve exactly this?

[hota_mazi]

If erasure is bothering you so much, it means you are heavily relying on reflection / runtime type information retrieving.

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.