Drab and Liveview community oddities

The fact two things tackle the same problem do not mean they are the same. I believe Drab put the focus on events, as they say, it is about accessing the browser User Interface from the Server Side. I believe LiveView put the focus on the state and re-rendering the same template when the state changes, sending diffs to the client instead of events. It could be seen as React on the server.

The two approaches are very distinct on how they solve the problem. The closest to LiveView is Texas VDOM, which was also announced at ElixirConf 2018.

Regarding the future is on your hands, there are two things to observe. First of all, the fact we have now three tools tackling the same problem shows the power of the platform. Once you make solving hard problems trivial, different solutions exploring different trade-offs will show up. The other part is that LiveView is equally part of the community as Drab.

We should not be worried about people exploring different solutions in the same space, regardless of what comes first and what comes last. Sometimes those experiments fail, other times multiple suceed. For example, if anybody stopped working on a type system because I was working on one, then it would have been a mistake, since my approach to the problem completely failed. If Chris did not create Phoenix because I was working on Dynamo at the time, it would have been a mistake. Even if LiveView already existed, we should have equally welcomed Drab too. Etc, etc. Let people experiment.

Got it. Thank you for your reply

LiveView is actually very similar to Drab with Drab.Live, as I understood.

In the first clock example, the difference is that when you return:

{:ok, assigns(socket, data: :calendar.local_time())}

from the msg handler, and Drab.Live uses function poke with side effect. In this case, with Drab, Chris would write:

poke(socket, data: :calendar.local_time())

The advantage of Drab.Live is that it is not sending the whole page, just a changed part, but as Chris said, it will change in the future.

Also, the phx- event bindings are similar to drab- bindings, the difference is just a semantics - I am using named functions as the event handlers, Chris uses general handle_event, so for his plus/minus example in drab it would look like:

<button drab-click='inc'>+</button>
<button drab-click='dec'>-</button>

defhandler inc(socket, _sender), do: poke(socket, val: peek(val) + 1)

Thus, there is no point to develop Drab anymore, as most of its functionality will be built in the Phoenix.

I might take the part with direct manipulation on the DOM (Drab.Element, Drab.Query), and develop a small library with this functionality.

I just watched the video of Chris’s talk last night and he indicated that LiveView would be developed independently from Phoenix and therefore wouldn’t ship as a dependency or as part of Phoenix itself.

But I do see your point though. The focus will probably shift to developing LiveView.

I think I speak for many of us in this community when I say THANK YOU! @grych for all of your hard work and effort in developing Drab and paving the way. You proved that the idea was a solid one. Great work!

Thanks, I actually forgot about Drab.Live - you mentioned it to me in our conversation a couple months ago. I believe it also renders a template then? Is the template rendering happening on the server or client?

I think my original point still stands though: there are three different approaches right now and I would suggest the cross pollination of ideas to continue. You probably won’t all agree on the APIs and trade-offs and you probably want to try different ideas out (for example, how much data to keep on the client vs the server, which template engine to use, etc). If you want to take a break until the other tools get more mileage for a more in-depth discussion, that is totally fine too, especially because LiveView is completely vaporware at this point. And I already said this earlier but it doesn’t hurt to repeat: thanks for Drab.

There is just one little thing that bugs me about this. Is the drab page or an equivalent going to be ported to Phoenix.LiveView once that hits the ground. It would be an incredibly useful piece of documentation.

Also thank you for Drab, It’s easily been the best phoenix library I’ve ever used

Yes, exactly. It just do not sent the whole html back, but rather the small portion and modifies only the required element. Elements to be changed are analyzed and marked during the compilation process (this is why I introduced custom eex engine), so Drab exactly knows which assign is in which element (and where in the element: in body, in attribute or even in property).

There are probably few things LiveView may borrow from Drab, as it was a lot of discussion on API and features in this forum. For example, element properites. I did it with @ mark before attribute name:

<button @style.backgroundColor=<%= @color %>>

this preserves type, so you may assign any jsonable stuff.

Let’s be realistic: it will grow in a moment because of the characters behind . I was doing Drab mostly myself, I can’t compete with you guys. I hope some Drab ideas will live in the LiveView!

It sounds like you have a ton of real world experience with this problem area. I can’t speak for everyone but I would definitely appreciate if you put your knowledge towards making LiveView better once it’s been open sourced.

At the end of the day, having a bunch of library choices is cool but really, having a library that most people are on board with (such as Phoenix when it comes to being a web framework) really makes the development experience and community better in the long run.

When undertaking a new project, no one really wants to sit around for 4 days bikeshedding and researching whether to use intercoolerjs, drab, unpoly or stimulus. We just want to make kick-ass apps.

Sure I am willing to help.

Thank you Tomek for all your hard work and continual effort in helping push the boundaries - I can’t wait to see how your experience will help LiveView and what groundbreaking project you’ll be working on next!