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
ps; I’m not sure what’s the scope of this thread, hopefully I say something useful. ^^
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.
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.
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.
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…
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…
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.
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.
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
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…?
), 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. 
