The general challenge becomes integrating the fractional front-end code written in your backend-language that compiles to JS with the rest of the JS ecosystem.
JaneStreet have a love of writing their own stuff from scratch so it doesn't apply to them but it might to you.
Hence most people end up with frontend-as-backend rather than backend-as-frontend.
There are TS constructs that require compilation into equivalent JS, such as enums and namespaces.
Namespaces are heavily discouraged. Some teams still use enigma but most people in the know us unions of strings.
I know the TS team regrets enums and I have not seen any plans for adding additional keywords that break type stripping.
And thank you for the correction! It was quite a few years ago that I used TypeScript, and I think the landscape was different then.
Making things even fuzzier in my mind, this was an Angular project, and it was hard to keep track of what was Angular and what was TypeScript.
It sounds like people these days actively avoid the parts of TypeScript that require translation into different JS code.
Disclaimer: I am very inexperienced at front-end development.
You need a JS trampoline to call your WASM and make browser primitives available to it, and IIRC calls into browser code incur some extra overhead, but those are pretty manageable.
Additionally: for high level languages, source code is _much_ smaller than compiled binaries. If your initial needs are simple, your users are likely downloading more than 10x as much code.
https://ocsigen.org/ in Ocaml too
https://websharper.com/ for fsharp and csharp. Really good when I used in in fsharp
Maybe https://melange.re/v7.0.1/ too? (Not sure)
Sarcasm?
Do you want to have a talk as to why JaneStreet wasn't built on JavaScript?