[obeavs]

Congratulations to the team!! I've been following for some time and love a good DX story.

I'd love to get some commentary from any active users on tradeoffs re: adopting tech like LiveView vs the community size and scale of JS land.

For example, JS land benefits massively from libraries like ProseMirror or even any of the more advanced CRDT libraries like Loro or Automerge. How about the AI story?

Is there a clear path to adopting this JS-based tech? Is it not needed? Would love to get a better understanding of the tradeoffs from folks who live in both worlds.

[tpdly]

It's tough because LiveView is really just the dessert at the Elixir dining hall-- you can't live off of dessert. It's (at least) an order of magnitude smaller an ecosystem than React and the like, and while average library quality is very high, you won't find ready-made solutions to all your use cases like you do in those big front end ecosystems. JS and LiveView do interoperate surprisingly well, so ProseMirror isn't off the table, but I still think there are important benefits in the big front-end ecosystems.

Nevermind front end though, the main course is Erlang/Elixir's concise, functional, concurrency paradigm that feels more discovered than invented. The default structures they provide for thinking about message-passing actors are so much easier than tangled webs of async functions. This means CRDTs, calling out to APIs, running jobs in other languages, realtime coms, all go very well in Elixir.

I think Actors are a paradigm shift somewhat akin to garbage collection. Increasingly complex programs demanded we abstract away memory management to stay sane, knowing we'd drop down to memory manage when needed. In this web-heavy world, we abstract into tiny statefull services (actors) to stay sane, knowing we'll drop down to sequential languages when needed.

[thomasfortes]

Integrating javascript with liveview and pushing and receiving events from client to server (and from server to client) is pretty simple using hooks: https://hexdocs.pm/phoenix_live_view/js-interop.html#client-...

The AI story is mostly centered around the Nx project: https://github.com/elixir-nx/

[sph]

Cons: you do not have access to the extensive scale of the JS ecosystem.

Pros: you do not need access to the extensive scale of the JS ecosystem. And you will not need to write as much JS, if at all.

If you do not have Stockholm Syndrome for Javascript, just switch to Liveview. And Erlang/Elixir is just a comfy yet secure platform to build serious apps.

[felix_starman]

Automerge wise, there's a ton of effort behind ElectricSQL which is written in Elixir and can also be run as part of an Elixir app, so you can get a lot of the same benefits of local first clients, afaict.

There's a langchain implementation that's fairly mature and definitely in production use (I saw the authors handle above actually :D ). Langgraph-style libraries exist (there's one called Magus that I've used) but I think that's where there could be some more efforts. Although it's important to note that building something comparable to langgraph isn't too hard in Elixir with its process model, and most Elixir devs could probably do it, but unfortunately that's not obvious to your average person searching "langgraph implementation in Elixir". There's no langsmith integration but the telemetry implementation in Erlang and Elixir is really nice so once some patterns around running chains and graphs emerge publicly (there's a few companies that I'd bet have private repos implementing their own equivalents of langgraph) I imagine integrating to langsmith would go pretty quick

[thruflo]

We've actually also implemented Phoenix sync using Electric: https://hexdocs.pm/electric_phoenix/Electric.Phoenix.html

So you can have local-first sync in a Phoenix app using Electric. And you can use Electric to sync data into a LiveView using Phoenix.Streams, which is a very natural fit.

We have a couple of example apps showing things in action:

- https://github.com/electric-sql/electric/tree/main/examples/... - https://github.com/electric-sql/electric/tree/main/examples/...