Hacker News Reader

Comment by trymas | Hacker News Reader

OP probably talking about Phoenix's "LiveView" (https://www.phoenixframework.org/ check the video about it).

Phoenix LiveView is a framework where it keeps websocket open with the client and renders DOM changes server side and passes it to the client [0]. Thus with fully server side development without any JS you can have almost full SPA experience.

[0] Have no experience with it, and only read about it some time ago, so don't judge me on the details, but the gist of the "LiveView" idea should be like that.

View on HN

But you still need JS to update the DOM and handle the websocket stuff, right? Or is this all somehow done with JS disabled?

Right. It uses JS but you don’t write any. Or very little. Or in a custom DSL/framework.

Important distinction, as it wouldn't work when JS is disabled in browsers.

I don't see the point of going back to full server side, you have to scale more with more users.

The only benefit would be if it all worked without running JS in browsers, but it doesn't.

Yup, this is my thinking as well. If I go back to fully server side, it's because I can somehow instruct the browser to update without JS involved.

Don't you have to scale your api too ?

Yes, but now you have to scale both the data layer logic and view layer logic when doing server side rendering.

So now it's two times the hassle, two times the money spent

99% of the time no one runs into scaling issues and worrying about it is premature optimisation. I have to remind myself that all the time.

And no, same hassle, same money spent. Thought about from the start server-side rendered pages are almost as cacheable as API responses will be. If you can't cache you're in for a world of expense at scale whichever way you go.

I have (limited) experience scaling long-lived websocket connections and it _sucked_. It is _way_ easier to scale out little Node servers that are "stateless" than it is to ensure that Client A is connected to Socket A.

I would much rather scale out my REST/Graph/RPC API instead of having to scale out a WS API.

> as it wouldn't work when JS is disabled in browsers.

You can make it work when JS is disabled as well, you fall back to rendering regular HTML. It does require a little extra work, but it’s not insurmountable (e.g. using @conn instead of @socket).

>you have to scale more with more users

I might opt for additional optimizations once it gets bigger, but I’m not too worried about scaling Erlang processes.

It’s done with JS but that’s all written for you. But as a bonus, LiveView apps do work without JS (they just aren’t updated over web sockets anymore).

I assume you have to specifically design your site to work with both the request/response model and the LiveView model in order for this to actually work, as opposed to LiveView being able to plug that hole automatically for you.

Nope, all you need to do is make sure that everything has a route (which is very much encouraged in LiveView) and it works.

To be a little more concrete, here's an example:

  <%= live_patch "about", to: Routes.about_path(@socket, :index) %>

which creates:

  <a href="/about" data-phx-link="patch" data-phx-link-state="push">about</a>

The data attributes are read by the LiveView HTML and are otherwise ignored by a JSless broswer.

Edited to fix glaring code sample error.

You can design singularly for LiveView and it handles everything. But if you want both request/response and LiveView (e.g. to mix the two or fallback to r/r when no js) you have to be more explicit in your design. It’s mostly trivial though. I have authentication pages that use the old controllers but pages that use only LiveView without any hassle.

Reply on news.ycombinator.com