Would you mind sharing those prototypes? I think they can be a first step to materializing what you’re proposing here. The further we push this discussion forward the higher the probability of someone getting curious enough to elaborate and come out with a proper ‘bridge’ solution.
I completely agree that incremental steps are best so the easier we make it for existing projects to leverage LiveView with more confidence, the better.
@chrismccord what is your take on this?
Not sure how much is ‘alot’ of JS…
Lots of UI challenges people have with LiveView for example require writing JS.
It’s a bit of a false promise live view eliminates the need to understand and write JS… To some extent it is true, but at which point is it too much?
If all you have are a bunch of mostly stateless React/Vue components, is that alot of JS?
I think what quantifies as a lot of JS is all the code in your front end that isn’t just a stateless view…
Think we both are on the same page that reducing the amount of JS required to make a compelling app is what we are after.
The time I have spent looking at LiveView code it appears to me is highly coupled to the concept of a DOM, and the DOM hierarchy. It’s pretty much a virtual DOM in the BEAM. Not sure how the current implementation could be broken into API vs UI bits. That is the motivation to Redex as it is just a composable state graph/tree. Doesn’t know or care anything about DOM.
EDIT:
This sounds pretty cool - I have experimented with server rendered React from phoenix - works well. Was not all that efficient in terms of diffs or anything just plain old server rendered React. I am not all that keen on having to run Node as part of the backend to make this kind of thing work though…
I wasn’t counting “library” code towards the code count (in this context). I was referring to the amount of code needed by the developer to interact with the library code.
If I understand what you’re proposing though, you’re saying that this “server side redux” is the first half of what I am suggesting LiveView be broken out into; with the acknowledgement that you’d either need a UI library that talked to it (eg. something morphdom driven), or build your own. Yes?
If so, I think that has merits (even outside of LiveView), but it feels like a pretty different approach to the LiveView problem/solution. I wasn’t personally suggesting an entirely different approach, simply breaking the current approach up into more modular libraries.
Yeah, I think that might a fair way to describe it (as far as I can see), but I’d disagree in the feasibility to decouple them. Even in cases where markup is sent from Elixir, a real-time compiler can convert this markup into framework code (eg. Vue, React, etc.), allowing your Elixir code to use Vue/React/WebComponent tags (eg. Material components).
Further, by separating communication from presentation, you can create components out of each “view”. These components can have their own markup, styling, scripting, and even JS dependencies. This opens up the ability to do a lot more than just hook in, but rather swap out entire render logic. If there were “single file components” that represented each view, some of the component would execute on the server, and some would execute in the browser. You don’t really get that with the current LiveView implementation.
For simple / static sites, it might feel overkill (warranting a “basic” UI using something like morphdom). But it would solve for many (if not all) of the SPA requirements.
I used Nuxt, so the rendering is done as part of the “UI” code (but technically a separate “server”). Essentially, some of the work is done on page request (UI server to Elixir server), giving you the SEO benefit and hydration performance. Subsequent diffs are done in the browser. This isn’t required though. You could send static markup from Elixir. The browser might re-render since it doesn’t know if it can trust hydration. With a little work though, you probably could do that. Not sure if that all makes sense.
Yes exactly!
It is only different from LiveView imo in that it is not coupled to the DOM or any UI layer, be it HTML, React, Scenic, or some other VDOM - instead of phx-X events that are synonymous with(coupled too?) the DOM - with (arguably) difficult to reason about bubbling characteristics - the only event Redex cares about is an action with a type and optional payload… your reducers are responsible for translating that action into a state change (like a state machine) - this change can be broadcasted as a diff to wherever, instructing your UI to update! All reducers receive the action - they do not need to act on it though - this is done via pattern matching in elixir as apposed to a switch statement in JS…
Yea I’m using this for React - GitHub - revelrylabs/elixir_react_render: React SSR Framework for Elixir · GitHub - it runs some node processes in a pool on the same server as phoenix for invoking the necessary JS to render the HTML over stdio - its pretty rough - getting it all wired up and everything…and doesn’t help much reducing JS bloat, it has just about the same bloat, now on the server AND the Client 
And dealing with the initial render is a nightmare - like now need my API on localhost to access from within these local node processes to make the initial render worthwhile…
Interesting that using something like Clojurescript allows one to use all this ecosystem. There are even wrappers for all these React Based UI toolkits.
I am OK with modern JS, typescript is also not bad.
The idea of transpiling to JS is interesting, especially if it allows a nice full stack experience without any context switching like closure/closure script.
I am of the opinion JavaScript is well suited for what it needs to do in the browser. Just like Erlang was built to solve a specific problem, so was JavaScript.
Right and I find that most theme authors or toolkits like Tailwind UI are catered towards Vue, React or AlpineJS.
There’s a bunch of stuff that’s best suited towards client side JS like menus, drop down menus, sidebar menus, tooltips, popovers, copying to clipboard, the visual element of drag / drop, accordions, toggling visibility on simple elements without state and a ton of other little things like maybe wanting to show the character count of a field that’s being typed into or showing the preview color of a hex value where you might not necessarily want to make a server round trip.
And even if you follow the pattern of server rendered templates with sprinkles of javascript, even those sprinkles add up to be enough JS where you want something besides a jumbled mess of jquery and bare bones ES6 features. I think even with LV you’ll end in this same spot.
I’m doing a Phoenix + Custom Elements frontend right now. It’s not messy, really. Except for the part of having templates split between phoenix and js. That disconnect can be hard to tackle.
To be more concrete, say you have a blog article:
<article class="blog-article" data-article-id="<%= @article.id %>">
<header>
<!-- some user data -->
<some-custom-menu></some-custom-menu>
</header>
<section class="article-body>
<%= @article.body %>
</section>
</article>
Now imagine that some-custom-menu has an option that modifies the structure of the article to a variant that is also specified in phoenix templates(it adds tags, it changes some setting(like “sensible content” on a tweet), you get the idea). Even if you use a builtin extend(like article is="my-article-component">, both component and phoenix need to know about the template, which doesn’t seem like a big deal, but when you have a good bunch of them and you need to update them in two different places, it’s really easy to mess up.
With an SPA you don’t have this kind of issues(your page just works HORRIBLY in a low end device or a pc with outdated hardware, althought this also varies notably not only with complexity, but with the ammount of content you need to update -ie infinite scrolling-), but then you need to run an additional node backend to render it serverside or you lose SEO benefits(googlebot is not the only crawler ot there). And that’s hacky.
The “data diffs in the backend and spa or whatever on the frontend” sounds interesting, but the point would be to close that disconnect while letting the server render stuff, which LiveView achieves in many cases.
Personally, I wouldn’t have “pre-made components like material ui” as a metric, because when I started with VueJS the complain was that there was a lack of component uis and it wasn’t wise to pick it for a new project. Same for svelte until a few months ago. First comes the solution, only then one would care about component libraries if they’re so important.
Most of that comes down do the problems of distributed state. If article is modified by both the server and the client you need some way to consolidate state. Ultimately you either need CRDTs or some other means of getting rid of conflicts between concurrent changes. While there’s e.g. automerge on the js side of things I don’t know of any CRDT implemented in elixir and js besides maybe phoenix presence.
That’s also the reason why I personally don’t see the problems with dropdowns and other similar UI components. Their state doesn’t overlap the state on the server. Say I have a dropdown, where the list of links is handled by liveview. The state for list items is completely separate from if the dropdown is open. The open/close state should imo never be handled by liveview, while the list of items needs the server for getting updated. That’s why the alpine.js integration with liveview works so well – whenever liveview updates alpine does apply it’s local changes on top. One likely could do the same with react or vue or whatever, but there’s just not many people using those libraries like that.
I think the emphasis on SEO, and it being an argument against using an SPA is not at all universal.
Depending on the target audience for the application, I.E a business app vs something like twitter, github or a forum…SEO is not really important. If the app is behind a login page, sacrificing UX for the sake of SEO is not really defensible.
That is the purpose of a marketing site, which promotes the features, and problems your app is trying to solve. The marketing site will be completely static, and have the SEO nobs dialed to the max, with a link to login to the actual app.
In my case, this is pretty much 100% of what I build…so moving rendering to the server for anything but improving metrics like Largest Contentful Paint is only costing the business compute - as mentioned before, client side rendering is free distributed computing…
And if you think the app you are building is going to be Twitter, GitHub scale, and actually see meaningful organic growth from SEO - you are already a bit of a unicorn, imho.
One way I have dodged the slow paint and abrupt rendering of an SPA is to apply some full page inline CSS animation on the served HTML. Allowing the browser to immediately show some indeterminate loading screen. This is pretty common for say a desktop/mobile application to require a loading screen or indicator before actually launching - I do not think this is bad UX, and actually expected if the App has enough data/interactivity…
EDIT: Also, pretty sure LiveView would not work that great for an App like Twitter, or GitHub - or at least at that scale. So say you did build the next Socially Responsible Twitter with LiveView - wonder how the engineering would evolve…I imagine the thought of an SPA would come up in the board room because the servers are starting to cost a bit too much. This same argument applies to the Redex library I have posted about - there is definitely a threshold of scale that likely means server side in memory state is a bad idea…