Hyperview creator here. Yes, it sounds like the difference is that your project is directly rendering platform-native UI widgets, while Hyperview is built on top of React Native for the cross-platform layer.
Curious how you will handling the differences between platforms. For example, Android prefers top tab bars, while on iOS the convention is to put tab bars below the content.
The experience using Django & htmx is very similar to using Django & Hyperview. In both cases, you are primarily working with Django views and templates to build your app. You don’t need to touch JS using either library unless you want custom client-side interactions.
XML, as the name implies, is extensible. An important aspect of Hyperview is that developers can create their own high-quality UI elements that can then be referenced by the backend using XML tags. These are things we can't do with a subset of HTML. In the Hypermedia Systems book, I showed examples of extending the XML format to add things like swipeable rows and toast messages: https://hypermedia.systems/book/extending-the-hypermedia-cli...
Theoretically yes. Since Hyperview uses React Native, you can use React Native for Web to render a Hyperview app in the web browser. However, the resulting web app won't feel at home, the same way a webview-wrapped web app doesn't right on mobile. A better approach is to share the same backend, but have requests return Hyperview or HTML responses based on the client.
Yes, Hyperview was definitely inspired by Jasonette. Like others have mentioned, Jasonette is not maintained, and Jasonelle has moved away from the server-driven paradigm. Check out Hyperview if you enjoyed Jasonette!
It is possible. We've built apps this way (integrating Hyperview into an existing RN app). With custom behaviors, you can have actions in Hyperview screens trigger Redux actions: https://hyperview.org/docs/reference_custom_behaviors
Local interactions can be achieved with this approach by building custom components. However, a limitation of Server-driven UI is supporting interactions that update state across the entire app. For example, I wouldn’t use Hyperview or HTMX to implement a spreadsheet, where changing the value in one cell would trigger recalculations across the sheet.
Trivial UI updates can be handled client-side without hitting the server. Some things can be done with the standar feature if Hyperview, like hiding/showing elements. For filtering a list of items, this is possible using Hyperview’s support for custom components. We’ve built apps that do this, and I’d be happy to share our approach if you’re interested!
Hyperview probably isn’t the best fit for apps with deep platform integration. Given that it’s designed to be cross-platform and server-rendered, I think this use case would be better served writing code directly against the Android SDK.
That’s right. Under the hood, the Hyperview client is built on top of React Native. That means it can be easily extended by creating new RN components, and mapping them to a new XML tag: https://hyperview.org/docs/reference_custom_elements
That’s right, no native code is shipped dynamically. The dynamic part is the layout of components and styling. Many apps use this approach and refer to it as Server-driven UI (SDUI).
I’ve been thinking about adding something like this to the Hyperview client: if a response uses HTML content type, we can render the screen in a web view.
“Native” in this case refers to the fact that the interface is rendered using the system UI libraries. So you get a native feel for things like scrolling, navigation, gestures, etc. This isn’t possible (or really difficult) using web technologies (HTML and JS)
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...
Congrats on the launch! As a big user of Intercooler, I'm curious about which features you considered mistakes, or which ideas didn't work out as well as you expected. My own library Hyperview is heavily inspired by Intercooler, so I'm hoping to learn from your experience!
Nice work! I’ve been looking for a visualization like this. My only feedback would be to make the non-cumulative view the default. Given the name of the site, it makes sense to highlight the flattening of the curve.
Author here. The meta-point of my post is that different formats have their advantages and disadvantages, and it's good to understand those when deciding on what's appropriate for a given use case. So I'm glad to see a discussion weighing the pros and cons in the thread!
I see some comments saying that JSON can represent trees just as well as XML, which is technically true. However, XML natively supports a distinction between node metadata (via properties) and relationships (via child elements) that has to be implied in JSON. For pure-data, this may not matter . But in cases like UI layouts, it's helpful to have the format distinguish between node properties and child components. As others have mentioned, the document use case is also a natural fit for XML by clearly separating the content from markup.
Curious how you will handling the differences between platforms. For example, Android prefers top tab bars, while on iOS the convention is to put tab bars below the content.