WingNews logo WingNews
top | item 42620565

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

245 points| brickers | 1 year ago |hyperview.org

140 comments

order

recursivedoubts|1 year ago

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.

toddmorey|1 year ago

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.

YuukiRey|1 year ago

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|1 year ago

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.

biosboiii|1 year ago

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>
</Alert>

type stuff.

LudwigNagasena|1 year ago

Server-Driven UI is a very common architectural pattern.

globular-toast|1 year ago

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|1 year ago

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)

Hilift|1 year ago

Making mobile platforms second class citizens was wrong.

paradite|1 year ago

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.

https://en.uniapp.dcloud.io/

klausa|1 year ago

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?

lolpanda|1 year ago

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.

flohofwoe|1 year ago

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

aa-jv|1 year ago

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

happytoexplain|1 year ago

>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|1 year ago

>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|1 year ago

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

donatj|1 year ago

I am very unclear reading the documentation and clicking around, how do you actually implement the logic? Some sort of JavaScript runtime?

SillyUsername|1 year ago

How does this improve on w3c standard of xforms + CSS?

tjmtjmtjm|1 year ago

I'm more of a Floral Green person.

latortuga|1 year ago

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

sirjaz|1 year ago

I'm wondering if they could get that to work with React Native for desktop apps

openrisk|1 year ago

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

ipnon|1 year ago

Not even a day after the post about HTMX not living up to its promise! There are only two certainties in life, death and frontend churn.

Cthulhu_|1 year ago

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

JodieBenitez|1 year ago

> the post about HTMX not living up to its promise

You read that wrong.

mpweiher|1 year ago

Which post was that?

dbbk|1 year ago

Surely this will be redundant with React Server Components on RN/Expo?

sibeliuss|1 year ago

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

benpacker|1 year ago

This is more of an HTMX native

captainepoch|1 year ago

For the love of God, stop putting "Native" in web frameworks. No, React will never be native.

dbbk|1 year ago

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

trey-jones|1 year ago

Using web technology to build "native" mobile apps has been around almost as long as mobile apps themselves. I used Appcelerator Titanium and Phonegap to do this beginning in 2012 (maybe even 2011) before eventually trying Native development later after finding these options underwhelming.

I have a reasonable amount of experience doing both, and my opinion is that development tools aren't really the problem. The biggest pain point is the platform specific deployment and maintenance requirements (including legal and technical documentation) that will be needed regardless of what technology you use to actually build the product. Because of this I always advise clients that they don't really need a mobile app. Just build it on the web.

If you absolutely must have a mobile app, you need to fully commit and hire an internal development team and be prepared to keep paying them as long as the app is going to be in use.

giancarlostoro|1 year ago

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

pjmlp|1 year ago

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.

etothet|1 year ago

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.

jsiepkes|1 year ago

"Serve your app as XML"

As someone who started his professional career in 2005: All the old is new again.

openrisk|1 year ago

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.

scotty79|1 year ago

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

donatj|1 year ago

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.

Devasta|1 year ago

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.

magic_smoke_ee|1 year ago

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.

j45|1 year ago

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

revskill|1 year ago

JSON is same as XML.