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.
I think that needs better documentation though.
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.
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.
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.
Are there some you would recommend to see as an example of it being done right?
I think there are first party integrations in wechat app, go to Me - Pay and Services, you can see a bunch of them.
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.
There are also more architectural diagrams thst illustrate the layers in the links I posted in my original comment.
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.
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".
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.
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.
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.
You read that wrong.
When you hit the boundaries of what Hyperview can do, you're going to need to dig into some of the details, but mayhaps you don't need those features. Either way, it's an interesting project, but like everything else it's going to have _some_ drawbacks
https://github.com/Instawork/hyperview/blob/master/demo/back...
However, this warning statement should be in bold at the top: "If your app relies on offline data or local computations, Hyperview won't be the right choice."
For that reason, I lean toward https://volt.build/
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.
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.
Last time I looked all of the simple tools had been deprecated in favour of complex tools that do way more than I need.
If I had a site in a directory that works fine from
>cd MyWebApp
>python3 -m http.server
>becomepwa MyWebApp
I thought this would be a common use case, but I failed to find anything that supported it without intruding on my workflow.
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.
As someone who started his professional career in 2005: All the old is new again.
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.
There's a really nice binary XML format that browsers haven't implemented yet: https://en.m.wikipedia.org/wiki/Efficient_XML_Interchange
The developer experience was amazing, you could easily inspect the data backing any page. XSLT was hard but probably easier than React these days.
Custom elements, client side templating, form validation against schemas, they had it all and threw it away.