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.
Doesn't apply as much to Clojurescript due to it being dynamically typed and its flexibility. Sure, you often write a wrapper, but it's more of an abstraction and a good practice, not a necessity in cljs.
Clojurescript not ClojureJs, and Typescript doesn't run in the browser, it has the exact same issues/limitations: it must be compiled to JavaScript first.
absolutely nobody used those outside of a language demo. We also got --erasableSyntaxOnly last year to remove them from the language. The TS team considers them “mistakes“ for a really long time now
Thanks for the correction! It was a long time ago that I used TypeScript, and making things worse (for my memory) it was an Angular project.
So today, most people and teams avoid the parts of TS that require compilation into different JS, and --erasableSyntaxOnly lets you enforce this, right?
Isn't that like saying the Internet is only written in English if you strip out all the non-English. All C-style languages are fully cross compatible if you only use semicolons.
I can't write Typescript into a browser without cross-compilation and "stripping out types" involves parsing and manipulating code. That's a different language.
No. 98% of typescript specific syntax can be replaced with U+0020 SPACE to yield runnable JavaScript. The runtime semantics of the two languages are congruent. the same cannot be said for any other language im aware of.
I'm sorry but if you need a transpiler to get it to run in a browser, character replacability and runtime semantics don't matter. Typescript doesn't run in the browser, it's obviously a different language.
WASM does not (yet) have access to the DOM or web APIs, meaning every direct interaction with the browser must first go through JS interop anyways, with a resulting performance penalty. There are proposals, and maybe we'll see it happen by 2035, but as of now WASM is best suited for heavier workloads where the edge in application performance outweighs the cost of JS interop with the browser rather than being a universal solution.
> Is there some limitation that WASM has that JS doesn't?
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.
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.