Comment by flufluflufluffy
12 hours ago
> And because Bonsai is written in OCaml, it becomes possible to use the same language and types on both the backend and frontend.
Finally! I was waiting for this to become possible!
12 hours ago
> And because Bonsai is written in OCaml, it becomes possible to use the same language and types on both the backend and frontend.
Finally! I was waiting for this to become possible!
Why wait? It’s been possible since forever. I wrote UI in OCaml eight years ago. https://github.com/kccqzy/drawing-guessing/blob/master/clien...
There's also Fable for F# but I believe this commenter is being sarcastic. Javascript is a common backend language.
A really great place to reach for this is Elixir/Phoenix now that the set theoretic type system is in place with LiveView. I have been doing some pretty large/complex codebases gradually working towards fully integrating working this way for the past 5 years and it has been great.
Similar attempts include Scalajs.
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.
KotlinJs and ClojureJs too. You always end up having to write wrappers or dealing with problems that would just work if you just used normal js/ts.
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.
7 replies →
Yup, and Clojure/ClojureScript!
Couldn't WASM solve that problem once and for all? Is there some limitation that WASM has that JS doesn't?
Disclaimer: I am very inexperienced at front-end development.
> 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.
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.
Such attempts are quite common. Some I remember:
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)
I took this as a joke in reference to the popularity of JavaScript on the backend for the last two decades.
2 replies →
> Finally! I was waiting for this to become possible!
Sarcasm?
Do you want to have a talk as to why JaneStreet wasn't built on JavaScript?