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 And

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.