Let's discuss Phoenix LiveView

The main reasons:

Over a websocket it’s faster.

Rendering on the server to do this was a really inefficient idea in almost any other language but the shocking speed of Phoenix rendering makes it plausible.

People are really tired of Frontend JS framework Hell when it’s not necessary.

Handling how to deal with each structure of data that can be sent to the client is how it grows big enough that people start asking for frameworks. Not doing that avoids it entirely.

Basically, this makes sticking to server side in a world of overzealous JS entirely feasible with virtually no negative trade off (and a lot of positive ones). Aside from the case where you actually need a fully in browser application…this could bring balance to the universe.

This is my main fear too… The demos we’ve seem are running with no network delay, which can make you forget that you’re in a distributed environment (between client and server).

When I tried to implement something like LiveView last year, I ran into this theoretical issue and stopped working on it (I’d have had to implement OT or CRDTs, which was too much. But these demos have made me want to try a quick and dirty solution which ignores the distributed aspect completely.

In my opinion this is just about as misguided as isomorphic JavaScript.

Why is it simpler to have the client manage the view changes while the server manages the initial view?

Boundaries - which are a consequence of cohesion probably the most important design principle but yet apparently the least understood.

• This is why DDD introduced bounded contexts
• This is why Phoenix introduced contexts

I see the server generating representational fragments of the client’s page as a variation of inappropriate initimacy - one of the worst forms of coupling.

To me it’s simpler if the server manages everything.

The server should generate and then deploy the page - after that the page starts a life of its own. Otherwise there will be tight coupling all over the place. Granted tightly coupled systems are easier to first build as long as they are reasonably small but they are hell to maintain and grow.

At least it allows you to use only a single programming language (elixir) and a single build pipeline (mix).

The era of monopoly languages is over and it is not coming back and ironically its the Web that precipitated that.

Bruce Tate 2014:

Same here which is why I’m asking. But I’m thinking there should be a more disciplined effort to exploring how to build effective APIs based on web socket technology.

Mmmh.

First thing that comes to mind is that you are describing something that is easier, not simpler.

It’s the distributed systems fallacies all over again. Sure, the naive view looks simple.
But as stated in other comments, complexity due to the usual suspects of distributed systems might kick in if you push the envelope.

I am not saying that this is a dead end, I think it’s a good technique to explore and try to characterize in terms of applicable scope, scale, potential optimizations, etc. I am curious myself. But it’s definitely not something that is going to be simple.

Just trying to understand what would involve reducing the data sent over the wire by having the option to do the DOM diffing server-side while retaining the advantages of client-side diffing makes my head hurt. And this feels like one of the first thing people using this technique at scale might want to try.

I agree that separating frontend and backend leads to lower coupling, but it also leads to complexity and duplication of logic. If the project is small, not likely to change etc., doing everything with one codebase can be an advantage. In general, I think SPAs are overused today, and I say this as a primarily frontend developer.

I’ve actually started avoiding SPAs and heavy use of JS for personal projects. So far the most productive I’ve found is Rails with Turbolinks — gives you a lot of SPA responsiveness with just one language and one framework. I see Phoenix/LIveView as promising in that regard.

Also, regarding DDD, isn’t that more about dividing an application into “well-bounded problems”, i.e. things like presentatation vs. data layer are details inside a domain? (I’m not very into DDD, but that’s my rough impression of it.) Think about how Django organizes a project into apps — a user app, a blog app, etc. The apps themselves contain both a view, a controller and a model. The division is not between layers (technical), but between stuff that give meaning to non-technical domain users and can be talked about in laypeople’s terms.

“As it grows” is really where the conversation shifts.

I see this on the same level as a jQuery style graceful degradation approach. Everything works without JS but JS provides some usability improvements. This really just makes that style more polished and simpler without all of the jQuery needing to be added.

But I don’t anticipate it replacing an SPA where an SPA is actually what’s needed. There’s a line that you cross on an application design where you need an SPA and all of the stuff that comes with it. IMO this just helps push back that line.

I share a fair amount of skepticism. I’m curious to see where this leads and I am keeping an open mind. I get the “just because you can doesn’t mean you should” feeling here.

I think it depends on the organizational and team operating requirements.

I understand the benefit of having a front-end team be able to work independently of back-end in a larger team at a more mature point in the project. The organization may need dedicated front-end developers to work unblocked with the back-end. LiveView is probably not targeting that use case.

LiveView, as it’s described, would definitely make sense in a smaller organization where developer resources are scarce and everyone is full-stack. Development time to learn the stack is really costly. The product is still taking shape and iteration time is crucial. We can’t afford the time to learn a new Javascript framework when we need to get to market! The less moving parts and dependencies the better. I think in the smaller/startup team we’d want the capability of rebuilding any given piece in a couple weeks and iterating quickly more than the benefits of free-moving front-end developers. The longer I can get away with the costs of bringing in React/Vue + Apollo/Redux/Mobx and what-not is a big win from a “required-knowledge-to-operate” point of view. If we’d be using Phoenix for a JSON/GraphQL API anyway, and our logic is still re-usable, why not just use Phoenix for rendering the front-end too? Building a JSON/GraphQL API after the fact isn’t that costly as long as our business logic is decoupled.

I don’t really see how LiveView changes how we’re already using Phoenix. To me the coupling between using Phoenix as a JSON API, HTML server, or HTML + Liveview server, or even a GraphQL API isn’t really that different. The logic/model and view separation is what’s important. I would consider Phoenix part of the view layer regardless of the mechanism that gets UI to the client.

We’re just going to have to wait and see what the real world trade-offs are. Speculation is only so useful.

I wasn’t actually thinking about SPA’s specifically - any page once in the browser is a separate application which uses the browser as a runtime. Sending form data back to the server is an application using an interface.

duplication of logic.

That duplication is often pursued because it’s synchronization costs effort and therefore money. But it ignores the fact that the rules serve entirely different effects on both sides - on the client how client state is presented to the user, on the server whether or not data is allowed to modify server state. So it can be argued that is is necessary duplication - as inconvenient as that may be.

I see Phoenix/LIveView as promising in that regard.

I see nothing wrong with the server providing information via events to the page that allows it to change its state - but I draw the line at sending page fragments which essentially boil down to the server monkey patching the page - it violates the page’s (application’s) autonomy.

At the core Elm/React/Cycle.js have the right idea:

• Events change the state of the page
• The new state is transformed to the visual representation presented to the user

That is simple. Monkey patching all over the place, “mutation heaven” not so much. Now the quality of the frameworks themselves - that is an entirely different discussion.

isn’t that more about dividing an application into “well-bounded problems”,

My point was that when it comes to design, boundaries have an impact everywhere. They are a line in the sand where you have to watch carefully:

• What (shape) of data am I exposing to the outside that is going to limit what I can do in the future on the inside?
• What dependencies am I pulling in from the outside that are going to have a permanent or future impact on the inside?

Nobody can deny that there are separate boundaries around the server and the browser. The same is true for the applications that live on them. Drawing a bigger boundary around both of them and calling it a web application doesn’t eradicate those boundaries - they are still relevant.

I don’t see much room for graceful degradation - it’s going to still require some form of JavaScript to work. Given that “Progressive enhancement” (which doesn’t seem to be that commonly practiced) requires are lot more work and planning (and therefore more complexity) I simply don’t see it happening. As it is service providers seem to have accepted the client being DOA if JavaScript is disabled on the browser.

In my view tearing the page apart and constantly flinging bits of it over the network increases the moving parts and dependencies. I’m sensing the shorter time-to-initial-success effect here.

I evaluate it based on a few things:

• Will it make my life easier as a developer for the majority of apps I might create?
• Will it mean I can build rich/cool user experiences without having to write much JS?
• Will it mean it might take less time to build my app/s?
• Will it mean I don’t have to keep two (or more!) languages in my head while building my app?

I don’t think I’m the only one who loves the idea of LiveView either, Drab, the Phoenix library that is similar to it, actually has the largest thread on this forum in terms of total number of posts (plus loads more in threads tagged with it)… which tells me that there is a lot of interest in this type of library