Phoenix LiveView vs SPA

Sounds like you and I have similar concerns, or thoughts on how LiveView fits in with the last decade of engineering efforts made towards the JS ecosystem…

Wanted to add how an addition of a LiveData, or an API that allows a more incremental adoption of Elixir in a teams’ stack could mean wonders for Elixir adoption in the Node/React/Vue communities.

A team that has heavily invested in React (vue,angular) which, lets be honest, is a lot of teams; will not drop all of it for LiveView, no matter how amazing it is, imho.

Now if you could simplify their frontend code base with a really nice API that allow for them to move all that frontend state to the server, keeping the UI as simple and dumb as possible…now they might actually consider Elixir/Phoenix/OTP.

One thing I am experimenting with at the moment, inspired by @justinmcp efforts with taper and @methyl s LiveData - is an Elixir Redux implementation - that would be as close to the JS API as possible in Elixir.

My thoughts here is that a team of javascript developers could quite easily migrate their frontend Redux logic to Elixir without having to learn too many new paradigms like OTP. Just as webdevs can get going with phoenix without much knowledge of OTP.

Am curious of others thoughts on this.
Maybe a redux like API is a bad idea or wouldn’t work well in elixir?
I believe its’ not about how good the redux API is or how elixiry it is, if it makes it easier for JS devs to use Elixir on the backend, and thus creates some converts out of 'em - I think it is worth it!

Maybe we should break this discussion into another thread…

Its not LiveView vs SPA so much as LiveView <—??—> SPA. There is room for an abstraction that lies somewhere in the middle, allowing state in your SPA to actually be backend state. The API abstracts away 'where the state came from` and includes the ability of pushing the updates from Server -> UI in a reactive fashion…

4 Likes