Chris was careful to explicitly state that it would NOT be part of Phoenix.
You do realize that’s self-contradictory???
sribe
benwilson512
Author of Craft GraphQL APIs in Elixir with Absinthe
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.
5
AstonJ
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. 
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.
0
sribe
AstonJ
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.
0
Eiji
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.
0
sribe
Eiji
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.
2
NobbZ
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…
10
OvermindDL1
Of course, I was curious as to the differences though (as asked, no point making the same thing after all 
), 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.
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.
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..
3