Hyperview: Native mobile apps, as easy as creating a website | Hacker News Reader

Hyperview: Native mobile apps, as easy as creating a website

hyperview.org

252 pointsksec74 comments

Other similar projects:

0. DivKit by Yandex https://github.com/divkit/divkit

1. AdaptiveCards by Microsoft https://github.com/microsoft/AdaptiveCards

2. dynamic_widget(https://github.com/dengyin2000/dynamic_widget) and json_dynamic_widget(https://github.com/peiffer-innovations/json_dynamic_widget)f... Flutter

Also: https://jasonette.com/ (Show HN https://news.ycombinator.com/item?id=12879179 )

LiveView Native

https://native.live/

https://news.ycombinator.com/item?id=32694668

Hyperview is an amazing piece of technology, bringing the hypermedia architecture to a native mobile environment in a way that HTML just can't. The crux of the system is that it provides not only a mobile hypermedia that takes advantage of mobile-specific features, but also it provides a client.

This client is key because it is what allows the uniform interface of HXML to function properly. I didn't appreciate how important the browser was (it's often forgotten in discussions around hypermedia on the web) until I saw how well Hyperview works and thought about why.

Parts of this are a distant reflection of Adobe AIR and Flex, both of which used xml for much of its functionality.

Of course this is more interesting because it’s modern and appears to work on the web. Maybe tires will be a worthy contractor of things like Flutter

Is this a new DSL reinventing WeChat's Mini Apps / Mini Programs?

https://web.dev/mini-apps/

https://github.com/apelegri/wechat-mini-program-wiki

https://developers.weixin.qq.com/miniprogram/en/dev/framewor...

reminded me more of Expo, but looks like it might be friendlier to newer devs, designers who want to make an app, or just someone who knows their app will stay within certain boundaries.

Another option I like, which takes some minimal custom native programming, is to use Android/IOS native WebViews load your mobile-web app and use it as a mobile app.

If it's too obvious that your app is just a web-app shell, you risk rejection from the iOS app store at least, and they'll tell you to just use the 'bookmark website as app' thing. Needs to still feel like a native app, which is possible but more work.

I use Expo everyday. Expo is more like a supercharged React Native + SaaS. This is apparently also built with React Native but somehow does not expose RN to user (didn't look into docs too much)?

This is so elegant. It has that rare quality of making you go: “Aha! This is the obviously correct paradigm”. Web and Electron apps are inevitably marked out by distinctive UX jank. In the iOS ecosystem - just the one I’m most familiar with - I always felt that Apple was pushing them more as a sop to App Store regulators than because they are a real, viable alternative to native.

I still don't understand why this type of native app exists. If it can be a website, it should be a website.

Tech really does obey "worse is better" in the weirdest ways. Don't "web apps" exist to solve the "problems" of native apps? Yet 30 years later we're back to downloading native apps despite all of the downsides, but ironically these native apps are basically just showing a website anyway, but with none of the web advantages.

What's described here is not a website; it's not even HTML (it's "HXML" [1] )

Ignoring that, and addressing your question: there are several things apps can do that websites can't, even if the app is really just a wrapped/packaged website (and actually HTML):

Native notifications

Background tasks

Full access to sensors

Access to file system and contact lists

Handler for system actions

Offline support (though this requires more work beyond a mere 'wrapper')

Also, don't underestimate the marketing/branding impact of having an app icon that's always there. Sure, you can get users to bookmark a site, but it's a very different action from having an app icon, and it opens and works in a different way. To techies this is a rather pointless distinction, but to most users this is huge.

[1] https://hyperview.org/docs/example_index

Sure, it's not exactly HTML, but looking at the examples it might as well be.

But what prompted my post was the opening section of this page https://hyperview.org/docs/guide_introduction where they complain about their web developer and mobile app developer productivity. Why have a mobile app at all in that case?

> Sure, it's not exactly HTML, but looking at the examples it might as well be.

The language itself doesn't really matter; that's not the interesting part. The fact that the UI is rendered natively on each client platform is what makes this project interesting.

> ...they complain about their web developer and mobile app developer productivity. Why have a mobile app at all in that case?

Because the business requires it? I'm not sure how that has anything to do with productivity.

Most apps should be websites, but the only reason many of us build apps is to get into the app store. Most normies, for better or for worse, like applications to be launchable applications from their home screen. And for most normies, that concept is synonymous with applications they downloaded from the app store. If Apple allowed PWAs in the app store, 99% of apps could just be websites.

Blaming it on the user is a cop out.

At the end of the day they're using the system that we created, and they use it the way we tell them to, so we can hardly blame them for the design decisions we made.

For example, there's no technical reason bookmarks can't be added to the home screen via the app store, and appear more or less identically to apps.

Seems interesting and is apparently built on top of React Native. Obviously this is billed as a “server side streaming UI”, but it’s already possible to chunk the React Native bundle and deliver portions on demand (per route/screen, for example). Of course that’s a bit different than generating the XML for the screen on the fly, but more or less gives most of the benefits this would offer in terms of small initial downloads and OTA updates.

It's often known as Server-Driven UI.

It's basically a generalization of Server-Side rendering.

I'm interested in knowing the limitations of that approach besides the connectivity requirement.

Are complex data-based interactions easily implementable?

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.

Q: Since this is built on React Native, is it possible to build pages using Hyperview and then supplement them with stateful UI component trees using common RN libraries (eg, Redux)? Like, mix approaches?

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

Great work on this! Seems very commonsensical and futuristic to me.

I wonder if there is some mechanism that could achieve app wide state updates by performing a “refresh” after a mutation, and hyperview/HTMX handles the integration of the the changeset.

Cool - extend this to just be a new browser that supports Content-Type: text/html and Content-Type: text/hyperview or something rendering either using a Web View or a Hyperview. Allow links between Hyperview documents within and across domains. Add user-driver permissions per domain for native APIs. It's been time to have a better alternative to HTML/JS for building rich applications on the web that still fit as web technologies.

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.

I came here to upvote and second the suggestion.

This is great! I think Facebook Lite already uses something like this. Great work.

https://engineering.fb.com/2016/03/09/android/how-we-built-f...

As an established JS-only web/mobile/desktop developer, don't really understand why it is better than just React Native. On the landing page, there is no straight value proposition, but instead there is something like "Now use Y instead of X".

I don't see why i should serve my app as XML, I can work with any backend technology i like using just React Native, as well as updating it instantly over the air. And the bottom table looks misleading too – no native elements in HTML5? why? ios safari surely provides native ui for HTML5 elements. no offline data for HTML5? this is not true, PWA exists

Scenes to be used are limited. It's only fit for table/list page, any custom features will make you surfer.

Does it have any limitations wrt accessing Android's API? For example, can I create a Hyperview password manager that would draw over other apps and fill out fields using Android Accessibility features? Can you access sensor information or list running processes?

Looks like you have do that via React Native components: https://hyperview.org/docs/reference_custom_behaviors

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.

It does seem imaginable to have Android-specific browsers support a common superset of the "nominal/desktop" browser js api. Reference to Hyperview not specifically required, but an enabler for such.

Security issues of course, so specific pages/sites might need permissions, as with webserial etc.

Won’t it cause problems with Google/Apple stores?

No, this isn’t shipping native code dynamically, just content. Crudely, will the fetched bytes go into executable or non-executable memory? If non-executable, Google/Apple are usually lax

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

How does login/auth work with Hyperview if there's no local storage?

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

Reminds me of https://jasonette.com (also AMP, sigh)

I used to love jasonette! I think the project was abandoned a while ago but in digging into it from this comment it looks like it was forked just for iOS and is now actively maintained at https://jasonelle.com/

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!

This is neat, but why does it need a new XML schema? Why not bind a subset of HTML controls to native controls?

Question: I have been looking for a way to use htmx to build mobile apps. What I iterated too was just cordova + css framework of choice + htmx. How is hyperview better/worse? Does hyperview let me use htmx or does it just share the same htmx philosophy?

Doesn't mean that every trivial UI update has to load over the wire? Can you do client-side processing at all, like browsing or filtering a downloaded list of items on the client itself? And can you download new data without new UI code?

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!

Not you parent comment, please share more details. Thank you

I'm a bit curious why invent a new XML format rather than a subset of HTML+HTMX

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

Are there any example apps that I can point the Expo client at to try out? I mean ones with servers running, not the example that I can develop myself.

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

TLDR: Serve XML from a server and get "dynamic" native apps

“Dynamic” “native” apps

I was hoping this would be like Hypercard (without much real hope, of course), allowing users to create their own native 'apps' with perhaps some safety limitations. That would be both dynamic and native, though any scriptable actions would be performant.

So it’s a web app with new syntax.

People who use the term “native app” incorrectly like this should… face difficult circumstances.

It is native though. You misunderstand what this is.

My perspective is that if an app is not directly using a platform’s APIs, it is not native to that platform. Feel free to explain to me and others how this take is wrong and how something written in XML could be a native app on, say, iOS.

It is using the platform's API directly and renders native components. The XML is just an abstraction layer on top of that and not a web wrapper like you're implying. It's not using any WebView.

I’m not saying it’s a WebView, but obviously it works extremely similarly. It is not a native app framework.

It's native by all definitions of it. It calls native APIs, renders native system elements and what you get is indistinguishable from an app written in Swift or Kotlin down to the machine code displaying it.

The "XML is just an abstraction layer" part is exactly what makes it not native. It's a big abstraction layer, it uses React under the hood, it's not native.

It's easy, instead.

It may render native components, but those components are still controlled by the non-native runtime, thus extra baggage.

So you think "it’s a web app with new syntax" is an accurate description? That's what we're discussing.

No, I don't think it's a web app at all.

It would definitely be using native UI components, which a normal web browser won't give you via the rendering engine.

But that's as native as it gets. The control logic for how those components operate outside of how they're internally built is likely done w/ React / JavaScript, instead of native.

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

This is the same B.S. definition-stretching that you see in a bunch of React Native posts.

How does this differ from XUL?

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

Wasn't basically this just posted under https://news.ycombinator.com/item?id=34134545?

What's the difference between this and a PWA?

Looks like this uses the native UI toolkits under the hood, making it closer to something like React Native, whereas a PWA is just a chromeless webview with a home screen icon loading a web app.

So many options under that spectrum now. I'm not sure how to decide what to use in the future, hmm.

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

Can this be used to create a web app too?

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.

Makes sense for B2C where discovery is done through app stores I guess. But no B2B decision maker is idly browsing google play for expensive SAAS products to use on a whim. Best there to focus on a web app that does everything well until you get into time/cost luxuries like mobile app - unless you really do need something only native can do.

Reply on news.ycombinator.com