Hyperview – Native mobile apps, as easy as creating a website (opens in new tab)

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.

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.

Server-Driven UI is a very common architectural pattern.

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)

Making mobile platforms second class citizens was wrong.

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?

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.

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

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

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

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

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.

Underrated joke, did not expect a Title Fight reference when I opened this thread!

You'd have to run a server in the background which complicates things but otherwise it would seem to be feasible.

> frontend churn.

Frontend churn hasn't been as much of a thing for years now, see e.g. https://2022.stateofjs.com/en-US/libraries/front-end-framewo.... If you stuck with Angular or React 10 years ago, you're still good today. jQuery is even older but still on 75% of websites (https://w3techs.com/technologies/overview/javascript_library), and Bootstrap is on nearly a quarter.

Frontend churn is only a thing if you try to stay on the left side of the Gartner Hype Cycle.

> the post about HTMX not living up to its promise

You read that wrong.

I'm fairly certain the tone of the HTMX post (https://htmx.org/essays/future/) was positive about its future of becoming "stable" (as opposed to "stale").

Which post was that?

Server components + RN + Expo.... Could it get any more pointlessly complicated?

This is more of an HTMX native

What does this mean? There are plenty of big, native apps using React.

> Just build it on the web.

It takes a very insignificantly small amount of JavaScript to make a website a Progressive Web App, which iirc can be listed on app stores.

If you dont use React or any fancy frameworks, I believe last time I ever did such a project our JS was under 50 lines of code to have our PWA working fully offline. There were some odd hacks, like detecting network connectivity.

What I have learned after all these years, is either do a Web site that is mobile friendly, or go native, anything else is a kludge in the search of holy grail of cross platform development without costs.

However this is a lie, because after going after the dream of cross platform, one lands on the (N + 1) reality, with team having anyway to master the leaky abstractions of the underlying platforms.

This * 100. I have a lot of experience with these types of apps and the biggest issue I've encountered is the platform keeping up with native technologies and OS updates.

It sort of proves the point that certain technology choices are not the result of some monotonic "progress" towards a theoretical optimal but rather a random walk under stochastic influences in what we might call "conventions space".

Serious randomness is induced by the decisions of whatever entities happen to be influential, typically (but not exclusively) by having the most successful economic model. Causally that earnings model need not be at all related with the tech. After all, most 'big tech' is not actually selling the tech itself.

People mostly code for money so they are attracted and incentivized to use the more visible money-making conventions (be part of wining teams) irrespective of particular technical merit.

But there are additional more objective dimensions that complicate things. E.g. SPA conventions did solve a user experience problem at the time. It was not pure lemming behavior. In retrospect we know that it could have been solved otherwise but at that time we didn't.

I think webapps should be xml (with all the data to display) transformed into html on the client side with XSLT generated by framework templating system).

There's a really nice binary XML format that browsers haven't implemented yet: https://en.m.wikipedia.org/wiki/Efficient_XML_Interchange

Literally. I wrote a fair number of Konfabulator widgets in the early aughts this way. I did a bit of Adobe Air like this as well, everyone insisted it was THE FUTURE, it wasn't.

The web is, was, and forever will be stuck reinventing shitty versions of things that they could have had decades earlier if they stuck with XML.

Custom elements, client side templating, form validation against schemas, they had it all and threw it away.

Someone will inevitably create an app to create apps using Brainfuck encoded in Morse code running on a 16-QAM wireless protocol... just beam your app with your data.

I wonder what going back to the 90's will bring up.

JSON is same as XML.