Hyperview – Native mobile apps, as easy as creating a website
136 comments
·January 7, 2025recursivedoubts
toddmorey
I'm curious about the limitations that prevent these apps from writing / caching local data. It doesn't seem like the paradigm would have to change entirely to support that.
recursivedoubts
There aren't any, with hyperview you actually own the hypermedia client as well as the server and you can write and cache local data in the form of custom extensions you make to it.
I think that needs better documentation though.
smackeyacky
So, basically it's like every other non-native development environment for mobile: basically useless when you want to use any feature of the phone.
These things always implement the easiest bit of mobile development (the UI) and then make everything else harder, so it's useless for anything non-trivial.
YuukiRey
I overlooked it at first even though it’s right there on the landing page but this is ultimately still React Native with all the baggage that entails.
strogonoff
I briefly investigated using React Native on a project. Obscure installation and linking process which no one seems to understand exactly, no SPM support on iOS, incomplete documentation that from the start pushes to adopt yet another layer on top (such as Expo, and I suppose Hyperview is now another option)… It felt like I am adopting some rusty legacy software, and not in a good way (more full of quirks than mature, well-documented and time-tested). Judging by discussions, most people would somehow get it working and then not touch it again until it breaks. My intuition was to stay away and to recommend, if PWA is not an option and resources are limited, to go with a native app for one platform (whichever more familiar) & later pay someone to port it for the other.
iforgot22
Probably has changed since then, but I remember the RN docs telling me to use Expo. I was wondering the whole time, do people actually use Expo or no. And why is it uploading my code to some website? Soon I had a clear answer; I had to "eject" from Expo to do a prod build or just add any native components. Not a good first impression.
That said, RN was a win in the long run. It was a lot less baffling than the notorious Xcode/Swift/ObjC/UIKit ecosystem I'd used for years.
strogonoff
For what it’s worth, the RN investigation I did was just last month, and impression was not good.
On the other hand, regarding iOS in particular, SwiftUI docs improved a lot recently. I remember them being baffling indeed from a few years back.
robertoandred
That hasn’t been true for quite a while. No need to upload code to build or submit, though it certainly makes it easier.
tarentel
If resources are limited and you plan on charging any type of money for the app, either one time or as a subscription, it's almost always better to go iOS first and port to Android later. I obviously can't speak for the ecosystems as a whole but anecdotally of the last few companies I've worked for a strong majority of paying users came from iOS.
mijkal
In my xp, React Native was far more fragile a few years ago, but it has improved immensely since then. I quite enjoy working with it these days.
biosboiii
As a reverse-engineer tinkering with iOS this reminded me of some system apps.
E.g. in the app store you click a button, send a request, receive the response which contains a xml-like structure describing the UI mutation to your action.
<Alert>
<Header>iTunes Login</Header>
<Body>We could not find a user with those credentials.</Body>
type stuff.
LudwigNagasena
Server-Driven UI is a very common architectural pattern.
paradite
Ah finally the Western tech ecosystem has caught up with WeChat/Alipay mini programs.
https://developers.weixin.qq.com/miniprogram/en/dev/framewor...
China had this DSL for building mobile apps for years. Those these apps are initially embedded inside WeChat/Alipay, there are now frameworks that allow it to run outside, like uniapp.
klausa
I've had very limited exposure to Alipay mini-programs (took a daytrip to Shenzhen from HK); but anything I had to touch (couples of restaurant menus; buying tickets for metro) was _screaming_ "this is poorly constructed webpage", not native-like experience.
Are there some you would recommend to see as an example of it being done right?
nsonha
> poorly constructed webpage", not native-like experience
yes "poorly constructed" is the key here. Poorly constructed "native" apps are not better.
Let's not pretend that all apps need native capabilities. The vast majority of them, or the vast majority of their functionality, can boils down to showing lists and images. Pretty wasteful to make apps in native languages just to do that if you ask me.
paradite
You can buy plane tickets, railway tickets, book hotels on wechat via popular 3rd party booking platforms.
I think there are first party integrations in wechat app, go to Me - Pay and Services, you can see a bunch of them.
klausa
Sorry, just to clarify — I meant examples of services that "feel" nice to interact with in the app; not examples of what they can be used for.
lolpanda
Those mini apps are built on the same web stack. I believe the main advantages of creating mini apps are that the platform provides identity (allowing you to know who the users are upon permission approval) and payment APIs.
paradite
They use a mixture of web rendering stack and native rendering stack. See my other comment.
There are also more architectural diagrams thst illustrate the layers in the links I posted in my original comment.
aquariusDue
I believe Telegram has something similar too.
flohofwoe
Aren't those just web apps running inside a webview widget? What's "native" about that? (but tbh, at first glance this Hyperview thing looks like it's just re-inventing web browsers too).
anonzzzies
When I was still using wechat (and in china); it was a mix; native buttons and payment integrations mixed with webviews for content.
paradite
I think the key idea is not the renderer layer, but the concept of DSL so that it can run on multiple platforms natively.
To go back to your question. WeChat actually has two sets of renderers for mini programs, one based on webview, and one based on native iOS / Android components. But you are right that most mini programs are using mostly webview to render, with only a few things being natively rendered.
aa-jv
The "Western" (whatever that is) tech ecosystem has long had this technology out there .. its the "Western" marketing ecosystem that has been squashing it - for example, Apple quashing any and all use of JITs and VMs in order to keep their native platform relevant ..
null
happytoexplain
>as easy as creating a website
This strikes me as odd - I have a much easier time making a well-functioning native app (iOS or Android) than the equivalent website. That's not typically a checkmark in the web column for web vs app pros and cons.
Unless we're including distribution when we say "creating".
LVB
>Unless we're including distribution when we say "creating".
I think it has to be included given how much traffic I see from mobile devs I follow about getting stuck in some review blackhole, running afoul of a TOS or payment rule, etc. Getting the app built is in your control, but getting it to end users has a big dependency on others, potentially. The idea of being able to push code to a server you control and deliver instant updates is appealing.
strogonoff
Engineers have vastly different definitions of “well-functioning” and “easy”. Once I saw an app that used accelerometer API to determine in real-time whether the user is walking. It was done as a web app (native was considered too difficult) and the data was sent to GCP for processing. Even without the GCP code, which involved a custom ML model, it was in the hundreds of LoC. I don’t know how well it would function in real use, since it did not really reach mass production, but I do know it is possible to do completely on-device with very little bespoke logic and a very small LoC count on iOS (and I’m sure on Android) where APIs would give you exactly that (and even movement speed, if needed).
bplaat
Ah I've seen this before but then with JSON https://github.com/Jasonette
gnabgib
Popular in 2022 (252 points, 74 comments) https://news.ycombinator.com/item?id=34137381
donatj
I am very unclear reading the documentation and clicking around, how do you actually implement the logic? Some sort of JavaScript runtime?
VagabundoP
Its a client/server system. So the logic is done by the server and snippets of HXML are served:
https://hypermedia.systems/building-a-contacts-app-with-hype...
That's an example using Flask. There's a demo client bundled with the repo, but I assume you can customise and deploy it. I'm not familar with Expo.
null
SillyUsername
How does this improve on w3c standard of xforms + CSS?
globular-toast
Any "app" framework that isn't offline-first seems broken by default to me. It seems ridiculous to me that client-server architecture is considered the easy thing now. Where did it all go wrong?
vincnetas
When companies decided that they need to know as much as possible about the end user, and don't want to care about backwards compatibility (old version apps, all users are using latest)
mihaaly
And consequently when they started to give no f about if users like or not the new version of the app forced on them. So before the Enterprise Oriented Design.
Hilift
Making mobile platforms second class citizens was wrong.
owebmaster
[dead]
Hyperview is a very interesting mobile-oriented hypermedia system created by Adam Stepinski.
He talks about is in the third part of our book, hypermedia systems:
https://hypermedia.systems/part/hyperview/
I have said before that I regard his work as much more innovative than htmx in that he developed an entire hypermedia client and format for his system.