adamstep

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...

There is not, but the Github repo comes with a kitchen-sink demo app that you can try: https://github.com/instawork/hyperview#2-start-the-demo-app

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.

There is session storage much like in a web browser. So you can use the same cookie-based auth techniques.

Hyperview incorporates ideas from HTMX to make it easy to create dynamic apps without the need for developers to write client-side JS.

“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.

I totally agree, the benefit of NoJS comes from not needing to write custom code in order to implement a feature. Thanks for the link to that list of other NoJS libraries. If you have any questions about Intercooler, please leave a comment on the post.

That's right. By including the Intercooler.js library, we don't need to write custom JS when developing features in our web app. We can take full advantage of JS APIs like AJAX and EventSource by only adding declarative HTML attributes to our markup.

Like I mentioned in the article, our main motivation is increased productivity. By avoiding JS for feature development, we write fewer lines of code and ship faster. Better maintainability comes from a smaller codebase and no duplication of business logic between the frontend and backend.

Thanks! There's so much potential there, we're excited to push the limits.

That's right, check out https://intercoolerjs.org/docs.html for a primer on how it works. Interactions and AJAX requests are declared using HTML attributes, the responses are server-rendered and swapped on the frontend.

It's true we include Intercooler.js and jQuery in our web app. What I meant is that as developers working on our web app, we don't need to write JS to implement new features. All of the logic happens in the Django codebase.

Libraries like IntercoolerJS really help with page transitions and other dynamic interactions, while still letting you do all the rendering on the server.