Hacker News Reader

Comment by ehnto | Hacker News Reader

Ignore React and all the community specific acronyms, you're talking about a very fundamental problem that is technology agnostic and it's important to understand it from that perspective, so you can take this knowledge with you to any tool.

Whenever you try to precompile or even just cache an HTML file that relies on run time data, you are going to have to build your application in a way that is sympathetic to that. In most cases, you're going to have to figure out how to fetch the missing data on the client side and populate it into the template/runtime context.

This is an issue in Ruby, PHP, Javascript, React, Angular, Python... every single application with caching or compilation.

View on HN

This is one of the (many) reasons why I've started using Phoenix LiveView for all the projects, when I can, that need either partial or full client-side functionality.

By simply keeping all the state, logic, and rendering on the server, all sorts of issues are avoided and various optimizations are possible, and I get full server-side rendering for free!

The client-side, meanwhile, via websockets, only sends events to the server and diffs whatever chunks of markup are sent back. Most of this is via server-side provided attributes (phx-click, phx-change, etc.), but for the slightly more 'exotic' stuff I can add my own events.

Obviously there are cases where this solution isn't practical, but this hasn't been the case for the vast majority of my projects.

How does this scale? Having lots of concurrent websockets seems like it could be challenging. Any caching layers?

There are diff algorithms, but no caching layer.

Also Phoenix is written in Elixir which could easily handle millions of stateful connections.

interesting - reminds me of what meteor attempted with its data protocol.

Precisely. DDP is also based on WebSockets and does essentially the same thing - server side computation, client side optimistic UI updates, caching etc.

As with any stateful solution it has problems scaling. I'm not sure LiveView is the right answer.

From what I understand the number of open websocket connections is not really much of an issue, because this is one of the things Phoenix/Elixir excel at.

Memory might become an issue though, I suppose. Every user's state will be in-memory in 'their' LiveView process.

On the other hand, there's much less state needed than with a client-side solution like React, because it can be very quickly fetched when needed.

This is true but also the reason that abstractions that try to hide these issues from developers can have some surprising edge cases.

Next and Gatsby make it seem like you can just directly translate your front end React experience to SSR but in practice there are, as you say, some significant differences.

Reply on news.ycombinator.com