I just wonder what happens in those other systems when theres a miscode and an infinite loop, or a panic.
Doesn’t shock me. PHP is a big ecosystem.
There are going to be lots of LiveView clones that will wrestle with the limitations of their platform though. I believe somebody is working on one in Python too.
Rails has StimulusReflex:
In his 2018 ElixirConf keynote, Chris McCord […] introduced LiveView, an alternative to the SPA. His presentation captures the same promise and excitement that Rails had in the early days […] We love Elixir and Phoenix. Elixir hits a sweet spot for people who want Rails-like conventions in a functional language. The community is terrific, but it’s still small and comparatively niche. Also, we just really enjoy using Ruby and Rails .
StimulusReflex was originally inspired by LiveView, but we are charting our own course […]
Reminds me that Redux is a lot more popular that the project that inspired it: Elm…
That’s a good thing for this guy, and a good thing for Elixir too. His project is successful and doesn’t hide Elixir’s influence, then some people will come to Elixir, at least to see what is it. And because it’s a great language and we are an amazing community, they will stay here.
Just to be clear – I’m happy for the guy and glad that Elixir ecosystem helped him as an inspiration. Always nice to read a success story like that
Great to hear. I’m sure the use cases of the much greater PHP-Community will have a positive influence on LiveView.
Hard to say but probably avoidable in practice. GitHub and Shopify seem to be doing very well with Rails. I know Laravel is based on PHP not Ruby, but it really comes down to either being Elixir or not in the end right?
LiveWire is also way simpler than LiveView. It’s using ajax instead of websockets and therefore is not stateful. It also doesn’t do any of the fancy static vs. dynamic template parts diffing, so it’s always sending complete chunks of html. Therefore I guess the failure model is also a bit simpler: either you get a response or you don’t (from the client perspective). If you don’t the next request will be served by another fresh php worker.
That actually sounds more like Turbolinks in Ruby on Rails - wasn’t that about ajax calls + history api?
Sure turbolinks is similar, but turbolinks only cares about whole pages and afaik doesn’t use morphdom to patch the dom, but rather replace stuff wholesale. It’s meant as progressive enhancement for page transitions and not for interactive components.
Livewire seems to use turbolinks
That reminds me of the age old ASP (no .net)
That’s got potential to give LiveView a bad name if people think it’s the same thing.
To be fair this section in the docs is about js integrations. So about using turbolinks with livewire. But I’m totally with you on the point of LiveView needing to make sure to highlight how much more it is compared to other solutions.
Thinking out load here,
The PHP community seems to be really good at monetizing open source.
The creator of Laravel has done it well.
And now so has Caleb. Most of his 100K is actually coming from premium content for LiveWire, he’s just using GitHub sponsor as a simple way to handle subscriptions (very smart).
I haven’t seen too many contributors in the Elixir ecosystem monetizing well, the one exception is Oban. Maybe there is an opportunity for Chris and Dockyard to monetize Phoenix and Phoenix LiveView in a similar way (with premium video content).
But maybe the difference is that the PHP community it much larger, thus a much larger market to sell to.
Great article! Thanks for sharing!
I think there are a lot of really good lessons here that we can learn from. While our community is smaller than the PHP community I think that many of the same ideas could be applied successfully to ours. Anything that helps people get rewarded for their open source work is great in my books
Turbolinks 6 is coming out soon and the folks over at Basecamp have built a really nice email client with it for hey.com Supposedly it’ll have a lot of new things for doing partial page reloads. DHH said they are working towards releasing it soon.
Made me thinking: if you remove 1. websockets and 2. absolute minimum DOM diffing from LiveView, you end up with TurboLinks basically, don’t you?
I mean one can close one eye and allow less precise diffing and more payload, but replacing the websocket with classic ajax call is a big difference, isn’t it? Or do I just completely misunderstand some of the main benefits of LiveView?
I’ve seen implementations of LiveView popping up in almost all languages, including Ruby and Python, etc. so I guess I’ll take a look what approach they took.
Ruby implementation seems to be websockets based: https://docs.stimulusreflex.com
Python version too: https://github.com/edelvalle/reactor
I think the key feature of LiveView which you’ve not touched on here is that that LiveView is stateful. The way you interact with (for example) the database can be radically different because state is held in the persistent process used for the live view.