I had an ideia a while back to generate js templates based on a EEx file but on the couple days I worked on it I couldnt get it working.
My plan was to keep using my server side rendered application as it was and “hydrate” it via websockets when needed.
cpgo
0
bjunc
There are a few being worked on (mostly in proof of concept / toy stages). I think Surface is one that is somewhat influenced by Vue. The bundling aspect is very important though. Without that, it’s a step back in time. Modern UIs are loading assets only as needed, sometimes even using Google Analytics and some simple data science to predict the user’s next page and loading those resources.
One thing that I personally feel is a mistake (one that React makes) is the whole “CSS in JS” concept. The respective languages should be as “pure” as possible. The LAST thing I want to do, is write some kind of Elixir / CSS / JS / HTML Frankenstein syntax.
No, definitely not. In-fact, the communication / protocol layer would actually need to be built up a bit to essentially expose an API (not just hooks). As I mentioned, you could even add a model layer (eg. using JS’s new proxy logic for reactivity) and / or a caching layer (eg. Apollo). But as I mentioned, it’d be important to be completely unopinionated / decoupled from the presentation layer. The current presentation layer could (should) be broken out as the “default” (but easily replaceable).
Per above, if these two things were done, I think the community would solve a lot (if not all) of the other issues. Currently, LiveView feels mutually exclusive. With some key tweaks, LiveView can be “incrementally adoptable” in ways that cater to the needs of the project and team’s comfort level with various technologies.
For me personally, I often work in Vue (Nuxt) for the UI. With a LiveVue™ adapter, we could make the UI even more “dumb”, but leverage routing, hydration, and complex UI components (eg. the dropdown example from above).
3
LostKobrakai
It doesn’t really make sense to decouple liveview from the presentation. 90% of liveview is the template compilation and being able to send minimal diffs to the client, so morphdom can do it’s job. It’s a feature of liveview to not need to send raw data to the client. The “protocol layer” you mentioned are exactly those diffs for morphdom. I doubt anything else could use that.
I can however see, that something akin to liveview processes, where a channel connection spawns a single process on the server for communication between client and server is useful. Before liveview I tried to build a svelte store around a channel connection, which sounds like a quite awesome thing. But as mentioned, this has hardly anything in common with liveview anymore.
You might want to try out alpine.js. It works flawlessly on top of liveview and can easily handle pure client side interactions like dropdowns for markup rendered live by liveview.
1
bjunc
I disagree. I’ve spent a good time reverse-engineering LiveView. Quantity != quality. Just because a lot of the logic is presentation layer oriented, does not mean that the remaining 10% (or whatever it is) isn’t powerful in itself. In-fact, that’s the part I think is most valuable and should be expanded upon to expose a front-end API (not just hooks).
But to be clear, I’m not suggesting LiveView send more data from the server to the client. Rather, you can take the data already being sent (probably even less), and decouple how it is presented to allow for more powerful UI layers (eg. shadowdom / reactive implementations that tie into advanced UI libraries like Material).
Even if morphdom was the best thing since sliced bread, the evolution of JS libraries over the past decade has shown adoption correlates to the library’s ability to be incremental. If you have a shadowdom / reactive app, it’s quite messy to throw in some morphdom into that. It’d be much better to allow UI developers the option to build their own presentation layer on the LiveView protocol.
That’s all just my opinion, but my prediction is a lot of unnecessary friction / resistance to LiveView until there’s a way to make it less mutually exclusive. Even the title of this thread “LiveView vs SPA” exemplifies the problem; which could be rewritten as “How much LiveView in my SPA?”.
0
LostKobrakai
I’m not sure how this should be possible any more that it is right now. The minimal diffs are possible only because liveview knows what the client has rendered (and morphdom irons over any inconsistencies). Take that fact away and you’re back to no optimizations. Liveview also can’t do the diffing job if the client should be able to retain client only changes the server doesn’t know of. Alpine.js only works with liveview in a comparable manner, because it basically reapplies its own changes to the dom after each and every update of liveview to alpine managed dom nodes. This would work with different client side tools as well, but alpine just has a one liner to do that.
0
harmon25
Sounds like you and I have similar concerns, or thoughts on how LiveView fits in with the last decade of engineering efforts made towards the JS ecosystem..
Wanted to add how an addition of a LiveData, or an API that allows a more incremental adoption of Elixir in a teams’ stack could mean wonders for Elixir adoption in the Node/React/Vue communities.
A team that has heavily invested in React (vue,angular) which, lets be honest, is a lot of teams; will not drop all of it for LiveView, no matter how amazing it is, imho.
Now if you could simplify their frontend code base with a really nice API that allow for them to move all that frontend state to the server, keeping the UI as simple and dumb as possible…now they might actually consider Elixir/Phoenix/OTP.
One thing I am experimenting with at the moment, inspired by @justinmcp efforts with taper and @methyl s LiveData - is an Elixir Redux implementation - that would be as close to the JS API as possible in Elixir.
My thoughts here is that a team of javascript developers could quite easily migrate their frontend Redux logic to Elixir without having to learn too many new paradigms like OTP. Just as webdevs can get going with phoenix without much knowledge of OTP.
Am curious of others thoughts on this.
Maybe a redux like API is a bad idea or wouldn’t work well in elixir?
I believe its’ not about how good the redux API is or how elixiry it is, if it makes it easier for JS devs to use Elixir on the backend, and thus creates some converts out of 'em - I think it is worth it!
Maybe we should break this discussion into another thread…
Its not LiveView vs SPA so much as LiveView <—??—> SPA. There is room for an abstraction that lies somewhere in the middle, allowing state in your SPA to actually be backend state. The API abstracts away 'where the state came from` and includes the ability of pushing the updates from Server → UI in a reactive fashion…
4
AstonJ
I totally forgot about Surface! It’s created by @msaraiva so I’m positive it’s going to be excellent! Hopefully it’ll mean I won’t have to use one of the JS frameworks after all (I do like what I’ve seen of Svelte tho).
I will also admit I was feeling a little depressed after reading these threads and looking at how far SPAs have come - it seems as though in the last 18 months or so they’ve really catapulted forward, and I was beginning to worry LiveView may not be enough for us to compete. Many of the comments (and the reminder about Surface) has definitely left me feeling more optimistic.
I think it might be a nice idea to have a number of threads dedicated to individual ideas (and projects like the one you posted). For anyone who wants to start a new branch or related thread, you just need to click on the timestamp shown with each post and then the + New Topic link 
1
damien
Hi,
I have been reading this discussion with great interest and have a suggestion to reduce the gap between the current LiveView and a SPA (I did not look at LiveData so I apologize in advance if this what you are already doing).
Currently, LiveView is:
On the server- side: (1) changing assigns following messages received from the client (or from the server), (2) evaluating which assigns have changed, (3) evaluating what are the changes in the templates following the changes in the assigns and computing a diff in terms of HTML, (4) sending the diff over the wire.
On the client side: (1) reading the diff, (2) passing the changes to morphdom to update the Dom, (3) reacting to user actions by transferring messages to the server side in order to change the assigns
What if:
- The diff was not in terms of html but a of data
- This diff would be used to update a framework agnostic reactive client store (e.g. Mobx)?
- All client-server interactions were accessible using js functions rather than bindings?
=> This would enable to have a client store which is reacting to changes of the state on the server side. It would also be possible to connect any js framework (react, vue, etc.) to this store and dynamically update the UI state when the store changes. It would also be possible to bind the framework events to phoenix events.
=> This would be, in a way, simpler than LiveView for many aspects on the client side (no need for phx-update = ignore/append, automatic addition of insert and delete, nice UI components and transitions) while keeping all the power of LiveView (abstraction over channels, state on the server, small diffs (including the idea of temporary assigns) and a simple client-server communication without controllers, etc.).
Is that feasible? I am not an Elixir nor a JS specialist but I went through the LiveView code and I don’t see why it would not be possible. I have the impression that all building blocks are already here and that an efficient diff (i.e splitting static and dynamic parts) of a tree of data could be done in the same way as a tree of html (diffing an ordered map and having the keys as static parts?)
What do you think?
Would that be an interesting option?
2
bjunc
UI library adoption has proven to be correlated to its ability to be incrementally adoptable / interoperable. To an extent, Elixir being able to run Erlang code is an example of that. Typically though, that paradigm doesn’t exist in the backend world, and is accomplished through service architectures where you can “incrementally” phase out legacy services with replacements built in new languages. That’s way harder than simply having jQuery and Vue dependencies running on the same page.
I’m not sure the juice would be worth the squeeze. You’d still be writing a lot of JS. Redux is essentially a uniform API that abstracts server and client state via exposing getters and setters (eg. actions / mutations). LiveView provides more value by going further than this by tying into user interaction in a more plug-n-play implementation. Unfortunately, it’s too opinionated and too rigid in its current form (IMO).
1
bjunc
I wouldn’t get depressed. JS really hasn’t made any major strides recently. Rather masochistically, they create all new libraries that require a lot of effort for very little value, trading an improvement in one area, for a decrement in another.
That said, the overall state of JS has matured over the last decade, and we’re not doing ourselves any favors by comparing LiveView to basic JS implementations while ignoring the incentive/constraint economics.
Per above though, spending a great deal of time on both sides of the equation, breaking the front-end of LiveView into two parts (API and UI) would be hugely impactful due to its ability to be incrementally adoptable via non-morphdom UI. I’ve done prototypes using Vue’s real-time vdom compiler to convert LiveView responses into reactive Vue templates, so I know it can be done.
4