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.<p>Admittedly it was a weird DSL and I can't say for sure I'd do it again.
I found this comment to be a thoughtful critique of Server-Driven UI: <a href="https://news.ycombinator.com/item?id=27708631" rel="nofollow">https://news.ycombinator.com/item?id=27708631</a>
Hyperview is an open source tool by InstaWork that leverages the hypermedia model for mobile development:<p><a href="https://hyperview.org/" rel="nofollow">https://hyperview.org/</a><p>They created it after seeing how effective the intercoolerjs/htmx approach was for their web application.<p>Hypermedia is a neat approach to building applications. We should look into it more.
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”.<p>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.<p>We’re cognizant it <i>could</i> 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”
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)
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.
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?
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.
We've been doing something like this since 2014 for an enterprise iOS application.<p>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.<p>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.
Whenever this idea is mentioned, I cannot resist posting this project: <a href="https://github.com/jasonelle/jasonelle" rel="nofollow">https://github.com/jasonelle/jasonelle</a>
Reminds me of <a href="https://jasonette.com/" rel="nofollow">https://jasonette.com/</a> which also uses serverside generated json to show content in a mobile app.
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