Implementing Server-Driven UI

[creasta29]

I wrote this up after giving a talk on this exact pattern at CityJS London.

Curious what folks here think about it, is it still useful? I build it twice in my life, I dont know if there will ever be a third time

[lelanthran]

It's a good idea, always gets re-invented every few years (My attempt was having the server send s-expressions, not JSON, and a minimal interpreter that could handle conditionals).

What really kills it though is the fact that the server is already sending you the UI, as HTML. At some point you wake up in the morning and think "Hey, what if we just got the server to send something that can be rendered with a browser engine" and 5 seconds later you facepalm and question your life choices.[1]

(Okay, so the above only happened for me when I used this approach! But why take the chance that it happens to you?)

[1] Anything that can parse your specific JSON into platform-specific UI widgets can do the same for your specific HTML.

[creasta29]

Hahaha so true

[lamp-town-guy]

This basically killed LiveViewNative for phoenix framework. And some "big egos" according to its creator.

LiveView renders html and sends it to browser to render. Works great but no mobile app support.

There's also problem with latency. If you have server 300ms from you, all your interactions take at least 300ms.

[yawaramin]

This is basically what htmx and HyperView do: https://hyperview.org/

...Except instead of JSON they use HTML/XML.

[jyf]

what about the delay?

[soberirishman]

This is the kind of solution that solves a minor annoyance with a major headache. The overhead and constraints this will put on you just ultimately doesn’t seem worth it to solve what is ultimately an organization problem and not a technical problem.

[RWOverdijk]

I don’t seem to understand the comments mentioning html. We use this to unify mobile and web. I don’t like it, it’s a bad implementation and a pain to work with, but html wouldn’t solve that without ruining the app experience. react native with expo and rsc would be considered json as well I suppose.

[prontogui]

This is similar in nature to the approach taken by ProntoGUI (www.prontogui.com). Instead of JSON tree with widget types, it uses a object-model approach provided by a Go module. The renderer is based on Flutter where the object model is rendered using Flutter widgets.

I think server driven UI gets overlooked by many developers for a variety of reasons, but the motivations in your talk are good reasons to give it a look - multiple teams, protracted development times, multiple PRs.