by marstall on 9/1/21, 5:35 PM
Son, let me tell you bout a little thing called the web
by spyspy on 9/1/21, 5:53 PM
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.
by hitekker on 9/1/21, 7:09 PM
by recursivedoubts on 9/1/21, 6:04 PM
Hyperview is an open source tool by InstaWork that leverages the hypermedia model for mobile development:
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.
by joshribakoff on 9/2/21, 12:03 PM
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”
by phpnode on 9/1/21, 5:38 PM
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)
by tootie on 9/1/21, 5:30 PM
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.
by chacham15 on 9/1/21, 7:02 PM
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.
by develatio on 9/1/21, 6:18 PM
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?
by thrill on 9/1/21, 5:52 PM
So, a markup language and style sheet?
by traverseda on 9/1/21, 5:30 PM
What? Why isn't it an embedded web app at that point?
by kitanata on 9/1/21, 5:29 PM
everything old is new again
by frazbin on 9/2/21, 10:34 PM
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.
by bob1029 on 9/2/21, 9:29 AM
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.
by handrous on 9/1/21, 7:40 PM
> Server-driven UI is new
Uh, no, not at all.
by m33k44 on 9/1/21, 7:54 PM
by Gys on 9/3/21, 9:24 AM
Reminds me of
https://jasonette.com/ which also uses serverside generated json to show content in a mobile app.
by syysilma on 9/1/21, 7:06 PM
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
by namanaggarwal on 9/1/21, 10:36 PM
Server driven UI - Fancy name for web browser ?
by filipo on 9/1/21, 6:56 PM
Turbolinks/Strada allows this as well…
by winrid on 9/1/21, 10:21 PM
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. :)