[mattste]

I agree heavily with this assessment.

I think there is room for a framework similar to Phoenix LiveView but also allows compiling certain interactivity to the client. Next.js and Remix are kind-of fulfilling this but they have downsides.

In the BEAM ecosystem, I think there is room for [Gleam](https://gleam.run) to be used to compile to both Javascript and the BEAM.

[ksbrooksjr]

I agree that there's room for a language that runs on the BEAM and also compiles to JS. Gleam looks great, and it's one of the up and coming languages that I'm rooting for. In addition to having a Javascript compile target, it's statically typed which is a prerequisite for me when it comes to productivity and correctness.

There was actually a developer working on a subset of Elixir that compiles to JS called Elixirscript[1], but development seems to have stalled. Another functional statically typed compile-to-js language which targets the BEAM vm is Purescript through the Purerl project [2].

If you're going to compile to JS though, there's an argument to be made that you might not want to target the BEAM at all. You could potentially run your entire backend on something like Cloudflare Workers, which has over 200 points of presence around the world, so latency is about as low as possible. The other CDNs have their own competing worker runtimes as well (e.g. Cloudfront functions, Netlify functions, etc.). These edge worker runtimes also have the benefit of not charging for each individual region in which you operate. You can also run any language which compiles to WASM like Rust, Assemblyscript, or Grain [3] on these edge runtimes. The only missing piece for me is a distributed database, but it looks like Cloudflare at least is working on that [4].

[1] https://github.com/elixirscript/elixirscript

[2] https://github.com/purerl/purerl

[3] https://grain-lang.org/docs/

[4] https://blog.cloudflare.com/introducing-d1/