9 ms·

What Is Server-Driven UI?

55 points by krzyzanowskim 5y ago

kitanata 5y ago
everything old is new again
- dragontamer 5y ago
  Once upon a time, a protocol called VT100 allowed a central computer to render colors to a remote terminal...
  - the-dude 5y ago
    In the 80s, our local library had terminals similar to VT100 for accessing the index. They were touchscreens ( I am not making this up ).
traverseda 5y ago
What? Why isn't it an embedded web app at that point?
- realusername 5y ago
  For performance reasons
  - marstall 5y ago
    doubt it's much faster for just rendering a list - and you get a lot less than webview offers - html, css, svg, javascript etc etc.
    - krzyzanowskim 5y ago
      web app won't integrate like native components can. here, it uses idioms of iOS and Android UI including navigation etc. It's just doesn't have this feeling of foreign component. In addition you get no-cost UI update for never/older system versions (since it uses platform components). Not trying to mimick platform.
      - smoldesu 5y ago
        No-cost UI updates are UB, not some gift that you should take for granted. If your program is liable to change without your consent or control in the foreseeable future, I'd consider that a bug.
        krzyzanowskim 5y ago
        I've meant platform UI changes, like when iOS changes how button looks from version to version etc.
- ruckstar 5y ago
  Embedding a web view has a ton of tradeoffs. A good implementation of SDUI will support all the native platform features like accessibility, dark mode, localization. Not to mention the user experience is much more natural when the SDUI implementation is rendered using the same frameworks as the rest of the app.
tootie 5y ago
This is a CMS isn't it? Haven't we been doing this forever? CMS for apps has been a bit behind where it is for the web, but it still exists.
- ruckstar 5y ago
  A CMS (e.g. Contentful) provides the content/data. SDUI is about using that same technique for the layout of the user interface itself.
  - tootie 5y ago
    You can still easily allow users to set layout from a CMS. It's been a core feature of platforms like AEM for over a decade.
marstall 5y ago
Son, let me tell you bout a little thing called the web
- ruckstar 5y ago
  Exactly. A website or web app can be updated as often as you want and you can be certain all your users will be seeing the latest version. Native apps have a different release cycle which brings unique challenges. SDUI is an approach to bring some of the benefits that web apps have to native. Of course you could just embed a web view in your app but then you lose out on a lot of things that make native great.
- marstall 5y ago
  now that I have the snark out of me - having a mobile app just be a web view that serves up a nextjs site or some such - which can then be used to power your website too ... is definitely a good idea now for many apps ...
- amelius 5y ago
  Let me tell you about mainframes and dumb terminals.
phpnode 5y ago
Now we just need a four letter initialism in order to describe this mechanism. Maybe JUDL? (JSON-based User-Interface Description Language), or if we were to switch the representation to something more SGML-like, maybe UIML (pronounced wee-mull)
- ruckstar 5y ago
  SDUI :)
- rzzzt 5y ago
  JAML, to the tune of XAML.
thrill 5y ago
So, a markup language and style sheet?
spyspy 5y ago
This is how the iOS NYT Crossword app works. We called it the Server View Model (SVM). The server and UI have "card" models that are described as protobufs and assembled and sent by the server when the user opens the app. The UI has tons of personalized data, so a purely native UI would require several fetches anyway. It allowed us to add features like "From The Archive" in a few days without a formal app store release. Admittedly it was a weird DSL and I can't say for sure I'd do it again.
- ruckstar 5y ago
  It's tough to get right, but very powerful when implemented well. It probably shouldn't be used everywhere but for certain use cases it makes a lot of sense and solves some problems unique to native apps.
recursivedoubts 5y ago
Hyperview is an open source tool by InstaWork that leverages the hypermedia model for mobile development: https://hyperview.org/ https://hyperview.org/ They created it after seeing how effective the intercoolerjs/htmx approach was for their web application. Hypermedia is a neat approach to building applications. We should look into it more.
- adamstep 5y ago
  Thanks for the mention! We continue to invest in Hyperview to solve many of the problems presented in the article. One big difference: instead of JSON, we use XML to represent the UI. XML is a hypermedia format with built-in extensibility, which makes it a good fit for server-driven UIs. We wrote about this decision here: https://engineering.instawork.com/when-xml-beats-json-ui-layouts-53c7f1d3fdb7 https://engineering.instawork.com/when-xml-beats-json-ui-lay...
  - sdze 5y ago
    Thank you adam for your sane decision to use XML instead of JSON as hypermedia format.
    - nsonha 5y ago
      there are still people bitching about things that don't matter like this? They have the same semantics and choosing between them is arbitrary. Json can be enforced with a schema but I doubt this is your concern.
      - kiwidrew 5y ago
        They do not have the same semantics. JSON has a data model based on the lowest-common-denominator data structures available in programming languages, i.e. lists and dictionaries. HTML/XML has a radically different data model that's based on documents that are filled with content with intermixed markup/metadata. As a result, representing pure data is awkward in XML but straightforward in JSON, and likewise representing a document of mixed content is very very awkward in JSON but quite straightforward (and easily extensible) when represented as XML. It's one of those "use the right tool for the job at hand" kind of things.
develatio 5y ago
This is just plain HTML presented as some JSON-like format. How many times are web developers going to reinvent the wheel instead of using what's already there?
- ruckstar 5y ago
  This is a solution for native iOS and Android apps. Rendering HTML within a native app has a ton of tradeoffs. SDUI is about bringing some of the benefits of HTML websites to native apps without compromising on platform features like accessibility, localization, dark mode etc.
  - develatio 5y ago
    If I read the docs correctly, you're literally supposed to send a description of what the UI should look like (which is the same as HTML + CSS: declarative code). How is this any different from just sending HTML + CSS?
    - ruckstar 5y ago
      It's similar but in a format that is more conducive to rendering in the native frameworks on iOS and Android: SwiftUI and Jetpack Compose. HTML and CSS doesn't map very well to these native frameworks.
    - noahtallen 5y ago
      If the app transforms the server-provided “UI” into native UI elements, that would be significantly different from just rendering HTML in a webview.
      - mabbo 5y ago
        That sounds like a web browser with extra steps.
    - tomc1985 5y ago
      The "webview" it renders to is native UI this time? Kind of reminds me of Mozilla XUL (rest in peace...)
filipo 5y ago
Turbolinks/Strada allows this as well…
chacham15 5y ago
Basically React-Native with the html coming from a server. I dont buy the argument that this will fly with Apple+Google. They like to be in control of what your app experience is and this by definition is contrary to that.
- ruckstar 5y ago
  Apple is more concerned with the code your app executes and especially that it does not change after it goes through the review process. From what I understand, they verify this by reviewing the set of system frameworks your app uses during the review process and then periodically checking this against installed versions of your app on users devices. Downloading remote code from a server is different than downloading UI configuration. The code required for an SDUI implementation is contained within your app and goes through the normal review process.
  - joshribakoff 5y ago
    Whether it downloads code or not is separate from whether you significantly alter the UI (and/or content). If you start serving up inappropriate content, surely there is some threshold you’ll eventually cross
- manmal 5y ago
  Apple tolerates this usually. As long as you don‘t send code in binary form, it’s not against the rules afaik. JS code should also be fine.
syysilma 5y ago
can't imagine this is good for people on slow / no connection - the example given is for something that already obviously requires internet, but it's no panacea for slow updates
- ruckstar 5y ago
  Depends on the implementation. With a two-phased approach, the UI can be fetched remotely ahead of time in the background and stored on disk before the user needs to see it.
hitekker 5y ago
I found this comment to be a thoughtful critique of Server-Driven UI: https://news.ycombinator.com/item?id=27708631 https://news.ycombinator.com/item?id=27708631
- Zanfa 5y ago
  I can’t agree with most of the points, especially the ones relating to performance, at least as far as SDUI as a generic concept is concerned. If Judo is reinventing HTML, that’s one thing, but a sane approach to SDUI gives you native UI performance (including complex interactions and animations) with reduced network bandwidth requirements.
  - hitekker 5y ago
    Speaking from personal experience, I agree with most of the points listed in the linked comment The incompatibility of GraphQL and SDUI is obvious; the former dictates UI from the frontend, the latter from the backend. Poor performance stems from SDUI acting as a shim around as set of native component; another abstraction that introduces slowdown. As for the rest of the point, difficulty in hiring for the bespoke SDUI framework, loss of expertise on the platform of choice... those are all things I've in the tech giant I work at. To the point, that the GraphQL folks had to sit down with the SDUI folks to tell them to back off. For better or for worse, SDUI the buzzword disrespects mobile engineering. Bored developers leap at the chance to force an overengineered DSL on their coworkers, while upper management is sucked in by the illusion of a thin client offering complete control with no cost whatsoever.
handrous 5y ago
> Server-driven UI is new Uh, no, not at all.
m33k44 5y ago
Whenever this idea is mentioned, I cannot resist posting this project: https://github.com/jasonelle/jasonelle https://github.com/jasonelle/jasonelle
winrid 5y ago
TLDR; Basically a meta data driven engine on the client and a server that sends configuration to render the UI. Kind of like... a browser. :)
namanaggarwal 5y ago
Server driven UI - Fancy name for web browser ?
- deleted 5y ago
  [deleted]
bob1029 5y ago
We've been doing something like this since 2014 for an enterprise iOS application. I can't imagine us being where we are at today if we had to make a trip through shitty iOS toolchain every time we tweak a UI element. We have very complex & custom views per customer. If I had to do it all again from zero today I'd use pure HTML solution. The advances in open web capabilities give us what we need now.
joshribakoff 5y ago
My team is trying (something like) this pattern out. Initially I had the sentiment that many commentators here had, “this feels like re-inventing HTML”. After discussing more the benefits, I am in favor of us using the pattern because it means we’re moving a lot of complex logic about deciding which “tiles” to show off of the front end client(s) where it can be hard to maintain. We’re centralizing it one place in the backend and surfacing higher level decisions to hide or show the tile, rather than surfacing lower level data the clients need to crunch and reduce into a decision about a tiles visibility . Since the server is a single place to determine which tile to show, we can do things like quickly disable a feature for whatever reason. We’re cognizant it could become over complicated if we try to do something like reinventing flex box, but I think that using the pattern tactfully is sensible. We’re specifically only doing SDUI to decide which “tiles” to show, not to try to power things like the layout which we are hard coding on the client. I think of it less as SDUI (buzzword) and instead think of it as a helpful way for my teammates to understand “thin client fat API”
- Zanfa 5y ago
  We used this pattern a lot at my previous company with a lot of success over the years. Operating in almost 10 different countries, mostly running lower end Android phones and being able to slightly customize parts of the UI on the fly to suit different markets is really powerful. I've been hearing how webapps on phones are going to be indistinguishable from native apps soon(tm) since around 2012, but it hasn't happened and I don't see it happening any time soon. I think most people assume the granularity of control is the same as with HTML, which does make it sound like reinventing the wheel, so it's important to think about it in terms of components, not individual elements. For us, the level of granularity that worked best looked something like the different types of posts in a Facebook feed, where each post (e.g. video, photo, text-only, event) would be represented by a different server driven UI component. It also helps when the JSON you get from the server maps directly to the UI, so you can visualize the UI in your head. This means a lot of sum types / tagged unions that don't exactly map well to language constructs in Go, which we used for our backend, but work absolutely great in Kotlin & Swift. One thing we didn't find a good solution for is formatted text though, so we ended up supporting a bastardized subset of Markdown that got us 90% there, but it just felt wrong.
frazbin 5y ago
This is probably best understood as an advanced adaptation to the particular difficulties of deploying into a walled garden. That's certainly how the author frames it. The similarity with web comes because of shared restrictions (untrusted client application, deep server side data, document based layout). The differences come from the proprietaryness of app ecosystems-- the taint of unfreedom propagating from the platform into an app-specific DSL.
Gys 5y ago
Reminds me of https://jasonette.com/ https://jasonette.com/ which also uses serverside generated json to show content in a mobile app.

55 points by krzyzanowskim 5y ago

kitanata 5y ago

everything old is new again

dragontamer 5y ago
Once upon a time, a protocol called VT100 allowed a central computer to render colors to a remote terminal...
- the-dude 5y ago
  In the 80s, our local library had terminals similar to VT100 for accessing the index. They were touchscreens ( I am not making this up ).

traverseda 5y ago

What? Why isn't it an embedded web app at that point?

realusername 5y ago
For performance reasons
- marstall 5y ago
  doubt it's much faster for just rendering a list - and you get a lot less than webview offers - html, css, svg, javascript etc etc.
  - krzyzanowskim 5y ago
    web app won't integrate like native components can. here, it uses idioms of iOS and Android UI including navigation etc. It's just doesn't have this feeling of foreign component. In addition you get no-cost UI update for never/older system versions (since it uses platform components). Not trying to mimick platform.
    - smoldesu 5y ago
      No-cost UI updates are UB, not some gift that you should take for granted. If your program is liable to change without your consent or control in the foreseeable future, I'd consider that a bug.
      - krzyzanowskim 5y ago
        I've meant platform UI changes, like when iOS changes how button looks from version to version etc.
ruckstar 5y ago
Embedding a web view has a ton of tradeoffs. A good implementation of SDUI will support all the native platform features like accessibility, dark mode, localization. Not to mention the user experience is much more natural when the SDUI implementation is rendered using the same frameworks as the rest of the app.

tootie 5y ago

This is a CMS isn't it? Haven't we been doing this forever? CMS for apps has been a bit behind where it is for the web, but it still exists.

ruckstar 5y ago
A CMS (e.g. Contentful) provides the content/data. SDUI is about using that same technique for the layout of the user interface itself.
- tootie 5y ago
  You can still easily allow users to set layout from a CMS. It's been a core feature of platforms like AEM for over a decade.

marstall 5y ago

Son, let me tell you bout a little thing called the web

ruckstar 5y ago
Exactly. A website or web app can be updated as often as you want and you can be certain all your users will be seeing the latest version. Native apps have a different release cycle which brings unique challenges. SDUI is an approach to bring some of the benefits that web apps have to native. Of course you could just embed a web view in your app but then you lose out on a lot of things that make native great.
marstall 5y ago
now that I have the snark out of me - having a mobile app just be a web view that serves up a nextjs site or some such - which can then be used to power your website too ... is definitely a good idea now for many apps ...
amelius 5y ago
Let me tell you about mainframes and dumb terminals.

phpnode 5y ago

Now we just need a four letter initialism in order to describe this mechanism. Maybe JUDL? (JSON-based User-Interface Description Language), or if we were to switch the representation to something more SGML-like, maybe UIML (pronounced wee-mull)

ruckstar 5y ago
SDUI :)
rzzzt 5y ago
JAML, to the tune of XAML.

thrill 5y ago

So, a markup language and style sheet?

spyspy 5y ago

This is how the iOS NYT Crossword app works. We called it the Server View Model (SVM). The server and UI have "card" models that are described as protobufs and assembled and sent by the server when the user opens the app. The UI has tons of personalized data, so a purely native UI would require several fetches anyway. It allowed us to add features like "From The Archive" in a few days without a formal app store release. Admittedly it was a weird DSL and I can't say for sure I'd do it again.

ruckstar 5y ago
It's tough to get right, but very powerful when implemented well. It probably shouldn't be used everywhere but for certain use cases it makes a lot of sense and solves some problems unique to native apps.

recursivedoubts 5y ago

Hyperview is an open source tool by InstaWork that leverages the hypermedia model for mobile development: https://hyperview.org/ https://hyperview.org/ They created it after seeing how effective the intercoolerjs/htmx approach was for their web application. Hypermedia is a neat approach to building applications. We should look into it more.

adamstep 5y ago
Thanks for the mention! We continue to invest in Hyperview to solve many of the problems presented in the article. One big difference: instead of JSON, we use XML to represent the UI. XML is a hypermedia format with built-in extensibility, which makes it a good fit for server-driven UIs. We wrote about this decision here: https://engineering.instawork.com/when-xml-beats-json-ui-layouts-53c7f1d3fdb7 https://engineering.instawork.com/when-xml-beats-json-ui-lay...
- sdze 5y ago
  Thank you adam for your sane decision to use XML instead of JSON as hypermedia format.
  - nsonha 5y ago
    there are still people bitching about things that don't matter like this? They have the same semantics and choosing between them is arbitrary. Json can be enforced with a schema but I doubt this is your concern.
    - kiwidrew 5y ago
      They do not have the same semantics. JSON has a data model based on the lowest-common-denominator data structures available in programming languages, i.e. lists and dictionaries. HTML/XML has a radically different data model that's based on documents that are filled with content with intermixed markup/metadata. As a result, representing pure data is awkward in XML but straightforward in JSON, and likewise representing a document of mixed content is very very awkward in JSON but quite straightforward (and easily extensible) when represented as XML. It's one of those "use the right tool for the job at hand" kind of things.

develatio 5y ago

This is just plain HTML presented as some JSON-like format. How many times are web developers going to reinvent the wheel instead of using what's already there?

ruckstar 5y ago
This is a solution for native iOS and Android apps. Rendering HTML within a native app has a ton of tradeoffs. SDUI is about bringing some of the benefits of HTML websites to native apps without compromising on platform features like accessibility, localization, dark mode etc.
- develatio 5y ago
  If I read the docs correctly, you're literally supposed to send a description of what the UI should look like (which is the same as HTML + CSS: declarative code). How is this any different from just sending HTML + CSS?
  - ruckstar 5y ago
    It's similar but in a format that is more conducive to rendering in the native frameworks on iOS and Android: SwiftUI and Jetpack Compose. HTML and CSS doesn't map very well to these native frameworks.
  - noahtallen 5y ago
    If the app transforms the server-provided “UI” into native UI elements, that would be significantly different from just rendering HTML in a webview.
    - mabbo 5y ago
      That sounds like a web browser with extra steps.
  - tomc1985 5y ago
    The "webview" it renders to is native UI this time? Kind of reminds me of Mozilla XUL (rest in peace...)

filipo 5y ago

Turbolinks/Strada allows this as well…

chacham15 5y ago

Basically React-Native with the html coming from a server. I dont buy the argument that this will fly with Apple+Google. They like to be in control of what your app experience is and this by definition is contrary to that.

ruckstar 5y ago
Apple is more concerned with the code your app executes and especially that it does not change after it goes through the review process. From what I understand, they verify this by reviewing the set of system frameworks your app uses during the review process and then periodically checking this against installed versions of your app on users devices. Downloading remote code from a server is different than downloading UI configuration. The code required for an SDUI implementation is contained within your app and goes through the normal review process.
- joshribakoff 5y ago
  Whether it downloads code or not is separate from whether you significantly alter the UI (and/or content). If you start serving up inappropriate content, surely there is some threshold you’ll eventually cross
manmal 5y ago
Apple tolerates this usually. As long as you don‘t send code in binary form, it’s not against the rules afaik. JS code should also be fine.

syysilma 5y ago

can't imagine this is good for people on slow / no connection - the example given is for something that already obviously requires internet, but it's no panacea for slow updates

ruckstar 5y ago
Depends on the implementation. With a two-phased approach, the UI can be fetched remotely ahead of time in the background and stored on disk before the user needs to see it.

hitekker 5y ago

I found this comment to be a thoughtful critique of Server-Driven UI: https://news.ycombinator.com/item?id=27708631 https://news.ycombinator.com/item?id=27708631

Zanfa 5y ago
I can’t agree with most of the points, especially the ones relating to performance, at least as far as SDUI as a generic concept is concerned. If Judo is reinventing HTML, that’s one thing, but a sane approach to SDUI gives you native UI performance (including complex interactions and animations) with reduced network bandwidth requirements.
- hitekker 5y ago
  Speaking from personal experience, I agree with most of the points listed in the linked comment The incompatibility of GraphQL and SDUI is obvious; the former dictates UI from the frontend, the latter from the backend. Poor performance stems from SDUI acting as a shim around as set of native component; another abstraction that introduces slowdown. As for the rest of the point, difficulty in hiring for the bespoke SDUI framework, loss of expertise on the platform of choice... those are all things I've in the tech giant I work at. To the point, that the GraphQL folks had to sit down with the SDUI folks to tell them to back off. For better or for worse, SDUI the buzzword disrespects mobile engineering. Bored developers leap at the chance to force an overengineered DSL on their coworkers, while upper management is sucked in by the illusion of a thin client offering complete control with no cost whatsoever.

handrous 5y ago

> Server-driven UI is new Uh, no, not at all.

m33k44 5y ago

Whenever this idea is mentioned, I cannot resist posting this project: https://github.com/jasonelle/jasonelle https://github.com/jasonelle/jasonelle

winrid 5y ago

TLDR; Basically a meta data driven engine on the client and a server that sends configuration to render the UI. Kind of like... a browser. :)

namanaggarwal 5y ago

Server driven UI - Fancy name for web browser ?

deleted 5y ago
[deleted]

bob1029 5y ago

We've been doing something like this since 2014 for an enterprise iOS application. I can't imagine us being where we are at today if we had to make a trip through shitty iOS toolchain every time we tweak a UI element. We have very complex & custom views per customer. If I had to do it all again from zero today I'd use pure HTML solution. The advances in open web capabilities give us what we need now.

joshribakoff 5y ago

My team is trying (something like) this pattern out. Initially I had the sentiment that many commentators here had, “this feels like re-inventing HTML”. After discussing more the benefits, I am in favor of us using the pattern because it means we’re moving a lot of complex logic about deciding which “tiles” to show off of the front end client(s) where it can be hard to maintain. We’re centralizing it one place in the backend and surfacing higher level decisions to hide or show the tile, rather than surfacing lower level data the clients need to crunch and reduce into a decision about a tiles visibility . Since the server is a single place to determine which tile to show, we can do things like quickly disable a feature for whatever reason. We’re cognizant it could become over complicated if we try to do something like reinventing flex box, but I think that using the pattern tactfully is sensible. We’re specifically only doing SDUI to decide which “tiles” to show, not to try to power things like the layout which we are hard coding on the client. I think of it less as SDUI (buzzword) and instead think of it as a helpful way for my teammates to understand “thin client fat API”

Zanfa 5y ago
We used this pattern a lot at my previous company with a lot of success over the years. Operating in almost 10 different countries, mostly running lower end Android phones and being able to slightly customize parts of the UI on the fly to suit different markets is really powerful. I've been hearing how webapps on phones are going to be indistinguishable from native apps soon(tm) since around 2012, but it hasn't happened and I don't see it happening any time soon. I think most people assume the granularity of control is the same as with HTML, which does make it sound like reinventing the wheel, so it's important to think about it in terms of components, not individual elements. For us, the level of granularity that worked best looked something like the different types of posts in a Facebook feed, where each post (e.g. video, photo, text-only, event) would be represented by a different server driven UI component. It also helps when the JSON you get from the server maps directly to the UI, so you can visualize the UI in your head. This means a lot of sum types / tagged unions that don't exactly map well to language constructs in Go, which we used for our backend, but work absolutely great in Kotlin & Swift. One thing we didn't find a good solution for is formatted text though, so we ended up supporting a bastardized subset of Markdown that got us 90% there, but it just felt wrong.

frazbin 5y ago

This is probably best understood as an advanced adaptation to the particular difficulties of deploying into a walled garden. That's certainly how the author frames it. The similarity with web comes because of shared restrictions (untrusted client application, deep server side data, document based layout). The differences come from the proprietaryness of app ecosystems-- the taint of unfreedom propagating from the platform into an app-specific DSL.

Gys 5y ago

Reminds me of https://jasonette.com/ https://jasonette.com/ which also uses serverside generated json to show content in a mobile app.