Let's discuss Phoenix LiveView



People are allowed to conceive similar ideas you know - remember Erlang and the Actor model? :lol:

The importance of having something like LiveView as part of Phoenix, to me at least, is incredibly clear.

There’s one thing being acknowledged, endorsed or linked even, but it’s quite another being part of a system that you know and are already invested in. That seamlessness is priceless, it drives adoption, instills confidence and has untold benefits in all manner of areas whether now or in the future. Autonomy is crucial too, being 100% aligned with the parent project is extremely important for something that (may become) so integral to it. Then there’s having very particular requirements or thoughts on how to approach and tackle things, which you generally want to do with little or no friction so that your vision remains undiluted.

There are just too many benefits to mention (think about all the books that are going to cover it, the screencasts, blogs, etc etc etc) and so I genuinely believe LiveView being a part of Phoenix is going to be better for all of us in the long run… just think, if it delivers on its promise it will not only be amazing for us, but could help take Elixir and Phoenix to the next level. I’m pretty sure that’s what we all want, right? :blush:


Not similar to jQuery even remotely.
You can get any reference on a page by building a name for it if you need

Ah, isn’t it selector something something

What do you mean by first commander?

I referred to the Shared Commanders example (your link) but,

though cross-commander talk should really always be done via broadcast messages and assigns.

you already got the point I was concerned. I don’t know what’s usual practice and it seems it embraces unidirectional flow which is better than letting user manually change each other commander context.

I watched the Phoenix.LiveView talk, and it seems its apis are not settled yet. Though def handle_event is cleaner than defhandler (it’s not that important but you know it’s another macro). It also doesn’t require extra template extension (*.html.drab) although a dedicate processing might be more useful for larger use cases. For now it seems ok to put more little stuff in eex project.

I understand your point about reinventing. And I think it’s ok (For example, ActiveStorage vs Carrierwave). Well people keep reinventing old idea maybe just because it’s exciting :slight_smile:

ps; I’m not sure what’s the scope of this thread, hopefully I say something useful. ^^


Chris was careful to explicitly state that it would NOT be part of Phoenix.

You do realize that’s self-contradictory???


I’m joining this a bit late but, as far as I can tell nothing about this intrinsically violates any boundaries. It’s our plan for example to hook these live views up to GraphQL queries / subscriptions. For all intents and purposes it’s just a GraphQL client that happens to have a particularly low latency connection.


Whether it is released under the Phoenix organisation or Chris’s own, it’s quite likely going to be seen by most as ‘part of Phoenix’ (and I’m sure many of us will campaign for the r/ship to be as close as possible because of the benefits as described in my previous post). In fact if you look at the comments around the web this is already how people are viewing it - I’m sure I’ve read comments like:

Phoenix has declared war on…

Sorry @reactjs , I think I’m in love with @elixirphoenix LiveView.

Phoenix has a real opportunity to advance the state of the art by making realtime views this easy

Did you see the Phoenix.LiveView demo at @ElixirConf?

etc. :slight_smile:

With regards to your other point, which part is contradictory? Parent project or main goals of the project equate to roughly the same in this context.


100% aligned with parent project is pretty much the polar opposite of autonomous.


By having complete autonomy I mean complete control - which is not something you would have if you incorporate or rely on a third party library.


Personally I don’t like that Phoenix have JavaScript-only solution especially that last time scenic was released.

I’m even curious if later it would be possible to convert scenic components into HTML5 document elements or even to canvas based application. If it would be possible then it making LiveView for scenic would have more sense, because it would be applied to canvas/HTML5 DOM as well.

Anyway here is how I imagine future advanced applications:

my_app # supervises other apps
  > apps
    > scenic # app which would be compiled to standalone GUI app
      > apps
        > offline
        > online
        > render
    > server # phoenix server
    > shared # for scenic and web apps
    > web # app which would be converted to WebAssembly app
      > apps
        > offline
        > online
        > render

As you can see for me my future projects there would not be any place to use LiveView.

Anyway good job for solving yet another front-end problem. :slight_smile:


The entire point of scenic is to build apps that run without a browser.


Yeah, I mean something else. Look that scenic works on OpenGL and there is also similar standard for browsers, so (without checking scenic source code) I though that in future it would be possible to convert it to “web version” with HTML5 or canvas + WebAssembly.


A fully agnostic GUI description language, which can either compile into HTML or into GTK, Scening, QT, etc and also automatically a translation unit from those targets events to an underlying “server” would be nice…

Thats a dream of mine for so many years…


Of course, I was curious as to the differences though (as asked, no point making the same thing after all :wink: ), and the other thread demonstrated that, Drab focuses on the client being the Store and LiveView is focusing on the store being local to the server ‘somehow’ rather than the client. :slight_smile:

I’m curious how these different styles will play and which will end up better overall. The client store is more memory efficient and makes it easier to update the client distributedly, but local store could potentially be faster and able to rebuild client state if something happens, though eats more memory, so I’m curious to see both models and the differences between. :slight_smile:

Honestly I’m more of a fan of server-storage, a dedicated actor for each page, as that is what I’m used to with past-language frameworks, but Drab was an interesting change in it and there are definite benefits on it too (like being able to interact with client-side frameworks in ways that a server ownership model can’t really) so both are fascinating styles and I don’t know which is better…

I think that would be called Lisp, lol. ^.^

Honestly though, QtQuick2 in Qt would probably work very well for working on about everything everywhere…


I’m wondering what the roadmap will be for adding phx-* DOM events.

For example, with React, for a <TextInput>, you need an onChange event. However, a normal <input> tracks its value.

By contrast, an onDrop event isn’t self-contained by a DOM element.


In Drab, I did like this:
Most popular events have a drab-eventname shortcuts, like drab-click=event_handler_name, but there is also a long version, drab=click:event_handler_name. The list of shortcut forms is configurable.


Recent Elixir Mix podcast with Chris McCord discussing LiveView among other things:


That’s a really good podcast - listening to it right now!

I did not know Chris applied to work at 37 Signals (DHH’s company who is the creator of Rails) - so glad that didn’t ‘work out’ :lol:

Karma is funny :044:

I know, I shouldn’t laugh really :icon_redface:


Another podcast on the topic from Elixir Talk:

I’m much more in agreement with @desmond than @cjbell here - Desmond: “You can sail on your JS ship, I’ll wait for a better ship to be built!” :lol:


That was a nice podcast :slight_smile:

I think @cjbell and I are actually mostly in agreement. I think all the points Chris made in the podcast jive well with what I said in my keynote, ie LiveView isn’t for all use cases, and we are starting by tackling a handful of specific usecases where we know it can work very well. Likewise, some UIs and experiences absolutely require a client-side framework, and that’s what those frameworks are great for. So if Chris watches the my keynote, I think we’ll be mostly on the same page.


Yep, it certainly felt like he was reading a list of points that you made in your talk a little later on :lol:

However it seems he’s happy with React (and much of the JS landscape) in which case I am in far more agreement with Desmond :smiley:


I feel like people aren’t giving SSR the full benefit of considering the possibilities - chris bell in the ~talk~ podcast mentions he didn’t believe there was any way SSR could work for certain things in project he is/was working on. What parts couldn’t it do? I’m curious because I believe if people really thought out all the possibilities, they’d maybe realize there isn’t anything that SSR can’t do inside the bounds of showing mostly still views (that is, you’re not playing a video game or similar that requires heavy client rendering).

and further I don’t think SSR can just do it with less application code/complexity - I think it can do it with better run-time for a couple reasons.

  1. If you’re writing client-side logic, that’s basically the definition of ad-hoc. It’s very difficult to make the transport opaque if your client implementation is ad-hoc. If your transport isn’t opaque to the application developer there are productivity hits to not using a readable transport like JSON. With SRR techniques it’s quite simple to implement a serlization/deserialization generic pattern and take advantage of better compression techniques.

  2. first page load is extremely important for SEO purposes. Client rendering will always require 3 round trips to display meaningful data. SSR will always be able to win here because it will always be able to ship less data over the wire and require less round trips to get the data to the client.

edit: man I need to be a better forum user - didn’t mean to reply to you directly aston :smiley:

edit again: I mean chris in the podcast, not chris mccord in his conference talk xD