Native clients for hyperview

[whamtet]

Fantastic work on hyperview Instawork! I was very disappointed when I saw that you run on react native however. Would it be too much work to implement separate native clients running on IoS and Android and skip the leaky abstractions? Has react native been chosen to reduce development effort, or are there other benefits of the platform?

[adamstep]

Hi @whamtet . The decision to build on React Native was twofold:

1. Hyperview grew out of Instawork's existing mobile apps, which were already implemented in React Native
2. We wanted the Hyperview framework to work on both iOS and Android out of the box, with minimal incompatibilities.

Building on React Native has some advantages and disadvantages. But given our small team size and needs, it made sense to build on a cross-platform framework with a large existing ecosystem.

One benefit of the building a hypermedia-driven application: many client implementations can co-exist. I would be very excited to see a version of the HV client built using native iOS or Android. I've also seen some proposals to create an implementation in Flutter. In a sense, the client provided in the repo is our reference implementation, it's not meant to be the "one and only" way to do it.

We don't have the time or resources to do it ourselves, but I would happily support such efforts with time and guidance. At it's core, the Hyperview client is rather simple (parse XML, walk the DOM and instantiate components). One tricky thing would be to reproduce the styling controls, since Hyperview's spec relies pretty highly on React Native's styling controls. Luckily, Facebook has open-sourced their layout engine (written in c++), which could be reused in native iOS or Android clients.

[whamtet]

Thanks for the thoughtful reply @adamstep. Since Hyperview depends on server side rendering why not just use webviews? That way you can reuse all the browser technologies. What is the advantage of creating your own markup language?

[adamstep]

Using web views is a valid approach. In fact, in the Hyperview introdcution of the Hypermedia Systems book, I mention web views as a valid approach to build a Hypermedia-drive application. It's the right approach in many situations.

However, web views have a hard time replicating the navigation and interaction patterns of mobile applications. I go over several examples in the chapter linked above. Using our own markup language and client lets us reimagine "HTML" in the context of mobile apps, vs using a standard initially developed for document layouts. Even though React Native is not truly "native", it gets a lot closer to iOS/Android apps in terms of interactions, gestures, and integration with system APIs.

Once we started using Hyperview, we discovered another advantage over web views that I did not consider initially. Our web views tended to include large external JS and CSS resources, which slowed down parsing and rendering. Hyperview XML is declarative (no scripting support) and does not use external resources. On mobile, it was noticeable faster to download, parse and render than a web view, resulting in a better experience. It helps enforce a stricter separation between scripted components (custom components/behaviors that are shipped as part of the app) and the declarative Hypermedia (expressed only as XML).

[whamtet]

Very interesting. I see you wrote that book with Carson Gross, I'm also a big fan of the hypermedia approach and am building Clojure Apps on top of HTMX.

Have you ever looked at Yandex's Divkit? How would describe the differences between Divkit and Hyperview?

[adamstep]

Thanks for sharing, I was not aware of DivKit but I do see some similarities and differences.

Divkit seems to have native iOS and Android clients. The benefits as you know, is less abstraction layers. The downside is, code for components has to be written and maintained separately for each platform.

I also noticed DivKit uses JSON to represent the UI instead of XML. I've written in the past about why I think XML is superior for declarative layouts. Since you are familiar with HTMX, Hyperview XML will be a closer experience on the server (you can use template engines, etc). Hyperview's behavior syntax was also inspired by HTMX (or more accurately, it's predecessor Intercooler). So defining how parts of the screen get updated would feel similar.

[whamtet]

I agree XML is superior. Thank for your helpful feedback @adamstep. I'm not sure whether you should close this issue or not, other people might be wondering about native clients.

[adamstep]

No problem, I'll convert this to an open discussion.