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.
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.
As someone who started his professional career in 2005: All the old is new again.
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.
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.
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.
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.
Volt looks great, but $15/mo. for the basic plan, $37/mo. for the pro plan that you likely need for the ad hoc builds alone (unless you test in prod).
<body myattr="yeah">
<thing>hi</thing>
<thing thingattr="cool">hi2</thing>
<otherkindathing>hi2</otherkindathing>
</body>
{"type": "body", "attrs": {"myattr": "yeah"},
"children": [{"type": "thing", "content": "hi"}, ...]}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.
In all seriousness, everything in JSON can be expressed as XML; but not necessarily the other way around.
Like that time there were hundreds of forms to build, refused, held a silent protest until a reasonable way presented itself.
Enter "XML Form Template" or "XML Form Definition.", A form is generated from the XML in html, filled in, and on submit, the XML is filled back in.
Built one form renderer and done. Never got old watching it.
XForms (W3C standard)
XML makes sense for open-ended, human-written things like documents or apps. It doesn't work so well for APIs and other machine-read/written things where you'd normally use JSON.
/j
PS won on human readability and editability but lost on portability to Adobe's own internal competitor, PDF, and because it fought and lost to (La)TeX -> PDF & (La)TeX -> DVI -> PS.
PS: I once printed out and bound the PDF 1.3 spec[0] on 24 lbs. bleached dead trees on an HP LaserJet IIIP with over a million page count. Some of the nuclear engineers and scientists an office containing <50 people routinely printed thousand page documents every week.
0. https://opensource.adobe.com/dc-acrobat-sdk-docs/pdfstandard...
All these companies have given up on the gold rush long ago and are just slinging fancy shovels.
* Manifest file
* HTTPS - for localhost I dont remember the workaround, browsers have made this increasingly more complicated from recent experiences
* Service Worker - This is where I said I had maybe 60 lines of JavaScript.
If you have these three things, a browser should pick up that your sites a PWA and server running it should be irrelevant... So you MUST have a minimal amount of JavaScript, but I did it using pure vanilla JS, you dont need a fancy framework.
On that same note, there might be a tool that could inject the bare JS necessary for this, but I dont think it exists, certainly could be built.
I want the manifest to be automatically generated from whatever is in the directory. The service worker should download everything from the manifest at first launch. I'm ok with a download-on-demand build option, but by default it should grab everything needed. If a user installs something, it should be assumed that they can use it offline.
I feel like the tool should already exist. If it does not yet exist, it seems like there must be a reason for that that I am not aware of.
I get that in theory a PWA can do offline stuff and whatever, but 99% of the time someone is only making a PWA to make the app installable on a phone home screen.
Service workers are just JavaScript that runs in the background in their own process in a browser. Could think of them as separate threads. Anyway, all of that can be done in less than 20 lines of JS?
I consider it simple compared to people building React apps and making the process more complicated than it needs to be just to build a PWA.
I was able to build a PWA out of a bootstrap HTML5 web app, with minimal JS for REST calls and ag-grid population.
- the move from in-browser JSX compilation to build tools / webpack
- the move from class components to functional components and hooks
- all the changes related to ES6 classes and modules + build system
- server-side components
- Flux -> Redux
- Redux -> MobX -> Relay -> Redux Toolkit -> Context API -> Zustand / Jotai / Recoil -> react-query (next: zero?)
- Next.js and Remix, 7 react-router versions (latest with major breaking API changes again)
- Signals and more SSR stuff (I stopped looking at this point)
And this is ignoring all the React Native churn over the years as I imagine not everyone is involved with that.
Even if your particular project didn’t go through all of these migrations, you had to relearn things to be able to work in other/newer projects.
It’s impossible to measure, but having written and used a ton of different frameworks, I really do feel like the overhead of keeping up with the changes was equal to or larger than learning a new one every couple years.
React Router changing its API so often felt unnecessary too.
I wouldn't call all of that churn though, as I believe most devs only had to deal with a subset of those. Some who got into React in 2019 could be writing the same kind of code today.
Frontend as whole, on the other hand...
Besides that, React churn isn't too bad. I have to fix builds, but I don't have to relearn everything about React. Unlike Angular.
Here's a screenshot of the list, if you want to Google and check out some of them: https://imgur.com/a/KKEdliE
I don't think asking for examples of this resulting in an experience that's pleasant is unreasonable?
For practical purposes like buying stuff or accessing information I want practical applications that can be quickly iterated on.
Also, fixed typo!
Number one goal of any software service today is to make its offering exclusive in some way - exclusive content, exclusive deals, exclusive integrations, exclusive set of participants (network effects), going super-broad super fast because infinite VC money lets you keep operating at a loss indefinitely, etc.
I could be wrong of course, since I don't know how many AliPay and WeChat competitors there are.
When they play it right, you're forced to choose all of them, or at least a significant subset of them, so that their partially overlapping offering add up to the actual thing you need.