3 ms·

Yeah you can definitely pull in Alpine for UI updates that don't require any server side interaction, but then your app's logic is fragmented between different

Yeah you can definitely pull in Alpine for UI updates that don't require any server side interaction, but then your app's logic is fragmented between different frameworks (Alpine and LiveView). It's definitely doable, and I know the PETAL stack (Phoenix Elixir Tailwind Alpine) is super popular, but it's nice (and perhaps less error prone) to have all of your UI logic handled by a single framework. This consolidation of UI code under a single framework was one of the killer features of SPAs initially. Prior to that lots of sites were built with a server side templating framework with jquery sprinkled in for client side UI updates.

mattste 4y ago
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 https://gleam.run) to be used to compile to both Javascript and the BEAM.
- ksbrooksjr 4y ago
  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 https://github.com/elixirscript/elixirscript [2] https://github.com/purerl/purerl https://github.com/purerl/purerl [3] https://grain-lang.org/docs/ https://grain-lang.org/docs/ [4] https://blog.cloudflare.com/introducing-d1/ https://blog.cloudflare.com/introducing-d1/

mattste 4y ago

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 https://gleam.run) to be used to compile to both Javascript and the BEAM.

ksbrooksjr 4y ago
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 https://github.com/elixirscript/elixirscript [2] https://github.com/purerl/purerl https://github.com/purerl/purerl [3] https://grain-lang.org/docs/ https://grain-lang.org/docs/ [4] https://blog.cloudflare.com/introducing-d1/ https://blog.cloudflare.com/introducing-d1/