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.
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.
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.
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 ...
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.
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)
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.
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.
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-lay...
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.
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.
there is only one difference which is that the so called markup has a special syntax for "children". It's just some arbitrary design decision hardly a technical merit. As a transport they are both crappy as they are text based, why don't you complain about the fact that we waste a significant chunk of the Internet's traffic with these garbage, untyped transports.
Hahaha. Worked at a startup that made something damn similar around 2010 (XML documents describing apps, which our core code drew as native UI). The docs for Hyperview are downright nostalgic. :-)
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 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.
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?
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.
I believe the objection is that "SDUI" amounts to re-implementing a poor man's "browser" except that it calls JSON.parse instead of HTML.parse, and it doesn't bother implementing a layout constraint engine. i.e. there's not much difference between `{"label": {"text": "Rocky Mountain", "fontSize": 11}}` and `<label text="Rocky Mountain" fontSize="11" />`
The general problem that arises from "reinventing the wheel" is that people implementing these SDUI things don't necessarily have experience with layout engine design. Case in point, look at the example:
This doesn't strike me as a schema that someone poured a lot of thought into, with regards to encapsulation/composition principles. It pretty much looks like a case of shaping things on a as-needed basis, only to later realize that a change to the rendering code is needed if, say, you need to tweak the space between the label and the image, or flip them around or bold/superscript some text or whatever.
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.
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.
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
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
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.
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.
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.
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.
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”
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.
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.
61 comments
[ 4.9 ms ] story [ 134 ms ] threadThey were touchscreens ( I am not making this up ).
Admittedly it was a weird DSL and I can't say for sure I'd do it again.
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.
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-lay...
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.
Kind of reminds me of Mozilla XUL (rest in peace...)
The general problem that arises from "reinventing the wheel" is that people implementing these SDUI things don't necessarily have experience with layout engine design. Case in point, look at the example:
This doesn't strike me as a schema that someone poured a lot of thought into, with regards to encapsulation/composition principles. It pretty much looks like a case of shaping things on a as-needed basis, only to later realize that a change to the rendering code is needed if, say, you need to tweak the space between the label and the image, or flip them around or bold/superscript some text or whatever.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.
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.
Uh, no, not at all.
Kind of like... a browser. :)
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.
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”
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.