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.
Recent Elixir Mix podcast with Chris McCord discussing LiveView among other things:
https://devchat.tv/elixir-mix/emx-020-phoenix-and-liveview-with-chris-mccord/
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’ 
Karma is funny 
I know, I shouldn’t laugh really 
Another podcast on the topic from Elixir Talk:
https://soundcloud.com/elixirtalk/episode-128-phoenix-liveview-the-next-five-years-of-elixir
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!”
That was a nice podcast 
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
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 
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.
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.
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
edit again: I mean chris in the podcast, not chris mccord in his conference talk xD
I would be inclined to agree with you Dan
The funny thing is, millions are being spent on moving things to the cloud so that cheaper/dumber devices can ‘run’ far more complex things …in gaming no less! 
Perhaps that’s the sort of thing we need to look at for inspiration?
Edit: Just thinking out loud here… we may not need look far to see where this could be useful - Nerves devices! While smartphones have become incredibly powerful of late, the IoT will, I guess, rely on far more affordable/less powerful hardware. Exactly the sort of scenario where SSR might reign supreme…?
Let’s please keep in mind how that particular example is motivated - it isn’t based on technical merit.
Sony is more interested in being able to harvest a recurring “service subscription fee” out of their customer’s pocket rather than providing the best possible experience that technology can offer. To that end they need to be able to lower the barrier-to-entry for their gaming service - i.e. the cost of purchasing a current gaming console. Ideally they want to be able to make it possible for their service to be consumed with “hardware you already have in your home” (e.g. smart TV) or at least for the necessary hardware to be so cheap (i.e. disposable) that they can afford to give it away for free with the purchase of a one year subscription.
The streaming model works for Netflix because most of the information flows one way - from Netflix to the consumer - and most of the information isn’t time sensitive, i.e. many networking rough spots and variabilities can be ironed out by simply buffering a sufficiently large amount of information.
Game streaming targets what is usually referred to as the “casual market” - the games in that space typically don’t have a lot of ‘time sensitive’ interactivity; who cares if it takes 1/2 second between a click and a change in the display for a puzzle game? However there are genres where input lag plays a significant factor in the game’s playability. For example enthusiasts of Shoot 'em ups will often choose CRTs over more modern displays in order to avoid the display lag that is introduced by the typical image processing pipelines.
Given the nature of network latency, “game streaming” will likely never serve certain markets.
Sony also acquired OnLive which was active back in 2011 but was then discontinued in 2015.
