8 ms·

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

by trymas 5y ago

OP probably talking about Phoenix's "LiveView" (https://www.phoenixframework.org/ 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.

beardedetim 5y ago
But you still need JS to update the DOM and handle the websocket stuff, right? Or is this all somehow done with JS disabled?
- dgb23 5y ago
  Right. It uses JS but you don’t write any. Or very little. Or in a custom DSL/framework.
  - hunterb123 5y ago
    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.
    - dqv 5y ago
      > 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.
    - beardedetim 5y ago
      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.
    - deleted 5y ago
      [deleted]
    - BoumTAC 5y ago
      Don't you have to scale your api too ?
      - hunterb123 5y ago
        Yes, but now you have to scale both the data layer logic and view layer logic when doing server side rendering.
        BoumTAC 5y ago
        So now it's two times the hassle, two times the money spent
        porker 5y ago
        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.
      - beardedetim 5y ago
        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.
- sodapopcan 5y ago
  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).
  - bcrosby95 5y ago
    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.
    - sodapopcan 5y ago
      Nope, all you need to do is make sure that everything has a route (which is very much encouraged in LiveView) and it works.
    - sodapopcan 5y ago
      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.
    - dqv 5y ago
      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.

by trymas 5y ago

beardedetim 5y ago

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

dgb23 5y ago
Right. It uses JS but you don’t write any. Or very little. Or in a custom DSL/framework.
- hunterb123 5y ago
  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.
  - dqv 5y ago
    > 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.
  - beardedetim 5y ago
    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.
  - deleted 5y ago
    [deleted]
  - BoumTAC 5y ago
    Don't you have to scale your api too ?
    - hunterb123 5y ago
      Yes, but now you have to scale both the data layer logic and view layer logic when doing server side rendering.
      - BoumTAC 5y ago
        So now it's two times the hassle, two times the money spent
        porker 5y ago
        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.
    - beardedetim 5y ago
      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.
sodapopcan 5y ago
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).
- bcrosby95 5y ago
  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.
  - sodapopcan 5y ago
    Nope, all you need to do is make sure that everything has a route (which is very much encouraged in LiveView) and it works.
  - sodapopcan 5y ago
    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.
  - dqv 5y ago
    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.