Drab and Liveview community oddities

phoenix
drab
troubleshooting
liveview

#1

Since Drab has been developed for a while in the open, introducing the Liveview functionality in a way it happend appears to undermine the Drab efforts and in a way contradicts the ElixirConf 2018 moto that the future is in the hand of the community.

Am I missing something obvious with their differences?


Elixir Forum 2019 Update!
#2

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.


#3

Got it. Thank you for your reply


#4

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.


Weighing in on Drab and reflections on longevity of software libraries
#5

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!


#6

Thanks, I actually forgot about Drab.Live - you mentioned it to me in our conversation a couple months ago. :smiley: 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. :heart:


#7

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


#8

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 :slight_smile: . I was doing Drab mostly myself, I can’t compete with you guys. I hope some Drab ideas will live in the LiveView!


#9

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.


#10

Sure I am willing to help.


#11

:049:

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! :003:


#12

I’ve been using Drab for a few months (in the “React on the server” manner that José described) and I love the dynamism it gives my pages without any JS on my part. So, thank you @grych for your hard work with Drab — I really appreciate it :heart:️


#13

I understand it must feel demoralizing, but please keep the project alive until this functionality actually exists and is as good or better than Drab. We already have something that works and is good and I’d hate to see it die even before LiveView has actually proven itself.

I can’t help but feel like LiveView seems to have been started because people aren’t in touch with what’s going on, so they’re just plowing through. Did people even take a good look at what Drab can do before doing this?


#14

After a reconsideration, I will not stop completely, but rather hold on on the new features, see my other post:


#15

Actually I had never so many visitors on the Demo page, see presence list. Probably Drab is now better announced than ever…


#16

I hope you keep in mind that some of us actually rely on drab and we can’t just switch to LiveView since it isn’t out yet.


#17

This is exactly what I’ve said in the other thread: Drab is going to be supported, I will just hold on with new stuff until LiveView is released.


#18

I can definitely imagine a situation where LiveView will be the sort-of-built-in tool for dynamic pages, and Drab continues as the powerful alternative for those who want/need more.

Furthermore, Drab could be (or is?) a bit more experimental, and over time the stuff that shakes out as stable could be integrated into LiveView.


#19

Drab is almost stable now, the existing version may be treated as pre-1.0.
The only thing it is missing, and I am working on, is the testing framework.


#20

I am sorry but this irks me way too much.

Maybe people were actually familiar with Drab and decided to try different approaches? Or maybe, based on Chris talk, this is a problem that he wanted to tackle since 2013, but first he had to create and maintain Phoenix before he could take a stab at it? And even if they had no clue about Drab, how is that even a problem?

I got a lot of flak over the years (and still do) for creating a new programming language. Some called me out of touch, others called me borderline irresponsible, etc. But you know what? “because I wanted to” is a completely valid and enough answer to starting a project. There are some projects in the Elixir community that I don’t agree with but that’s totally fine (hey, they wanted to!). As long as people can discuss the trade-offs clearly, people are not being mislead, etc, I am not going to lose sleep over it.

I know this sounds counter-intuitive, as we do need a community to push those ideas forward, but that should be conciliated with everyone’s “right” to tinker and experiment. Then those experiments should be conciliated with the efforts already happening in the community.

So let people experiment, prototype and try things out. Once the ideas have consolidated, the proof of concept is ready, etc, then everybody can sit together and have a reasonable discussion about trade-offs. For all we know, LiveView could be dead in 2 months, because all of Chris’ choices turned out to be bad.

So let’s not make any rash decisions on a proof of concept that isn’t even released yet.