Cool stuff! Thank you all for your hard work on this project and so much more.
Here are my impressions and thoughts after two hours of fiddling with the library and demo project and (mainly) thinking about its use cases. I think it’s impressive but also have some questions and observations. I assume that you are looking for feedback, so here it goes.
User CRUD example
The way the user CRUD templates in the demo almost looks like they could have been copy/pasted from the regular HTML version is very nice. The differences are most about routing and form options. Leaves you wondering what agnostic code exactly could eventually replace
Routes.live_path(@socket, UserLive.Edit, user) and
Routes.user_path(@conn, :edit, user)? But you chose to give these templates another file extension to keep them out of the eex compile step I guess? The (inevitable) coupling between phoenix_html_form and phoenix_live is very visible here. This could be a strength if you can keep them working together.
Image Editor/Autocomplete Form
Throttling and debouncing of client side events is so obvious that it should be built-in, good to hear that you are working on that, perhaps with something like
<form phx-change="suggest" phx-submit="debounce(search, 200)"> in the search with autocomplete demo. But my guess it that you’re heading for a more declarative approach like
<input type="range" min="10" max="630" name="width" value="<%= @width %>" phx-debounce="200" />. I noticed that the
phx-submit-every should already work for form submits, but not for value changes within a view.
How configurable or extensible are these attributes/behaviours?
<img phx-click="boom"> started me searching where
boom was defined, but of course it was just the name for an unkown event that made the server crash and recover to an empty form. It made me wonder what state you want to present to the user when things go wrong on the server. It would need a hellofalotta bookkeeping on the server side to mimic exactly what all those connected browsers keep as their own last known state. A full page reload is just too harsh, so creating a full SPA is probably out of the picture for phoenix_live?
Performancewise, the Rainbow demo did not convince me, sorry. With the browser devtools open it crashed my Chrome tab hard, but that’s understandable. With devtools closed it worked fine in the browser but gave me a 10%+ server cpu load (on an ubuntu vm with lots of headroom). So, while I get that this example is a bit of an extremity, it was definitely not a super showcase for connecting many concurrent users with up-beat computational requirements.
Where to now?
I can see that phoenix_live has a lot of potential, but what can become it’s real strengths?
Can you offer developers more than magic to socketify a CRUD resource, or is that what you are aiming for? Because (in this first/short review) I don’t see a lot of possibilities for quick extensions or escape hatches when it comes to fine-tuning client-side behaviour. Of course that can be a good thing, a goal, I don’t know. It’s definitely a certain state of mind when dealing with HTML forms and views. There have been many previous endeavours to ajaxify forms and views in all shapes and languages, I’m sure there is a lot to learn from that while socketifying.
So before everybody dives in and tries to rewrite their Meteor application into something phoenix_live (sorry @simon), think about how completely different the two are.
I’m really sorry if this sounded all too harsh because I enjoy thinking about this kind of stuff and I love the Phoenix framework. Let this late-hour rambling of mine drive you to higher heights!