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>
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'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.
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.
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.
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.
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.
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.
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?
I mean those 1st party integrations directly listed in WeChat services page are probably good examples of services that "feel" nice to interact, because they are used by millions of people everyday and they are need to optimized and polished to be able to serve millions of users.
Here's a screenshot of the list, if you want to Google and check out some of them: https://imgur.com/a/KKEdliE
There's a pretty big difference in what UX "feels nice" to East Asian audiences vs Western audiences. This video provides some insight into why this might be:
https://www.youtube.com/watch?v=WSMFnJnY7EA
The comments make it seem like it's more a case of users tolerating it due to the apps usefulness. Interesting video though, haven't had any contact with Chinese apps, so that was enlightening.
I agree that numbers alone might not mean much, but I do think B2C apps with millions of users have a higher bar in terms of design and polish compared to B2B/ERP apps.
It's not like you can choose in the West either, either :).
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.
You're making it sound as if the difference in choice between China and western countries is negligible. Surely that's not the case? If every VC company tries to pull you into their walled garden, I can still choose from among a variety of said walled gardens.
I could be wrong of course, since I don't know how many AliPay and WeChat competitors there are.
> If every VC company tries to pull you into their walled garden, I can still choose from among a variety of said walled gardens.
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.
The competitors at the consumer-facing super app level (with mini programs of varying awkwardness) include Meituan, XiaoHongShu, and to an extent, Toutiao, JD.com, and Baidu. But you don't need those gardens as a publisher if you're on Android--ironically because Google services are banned, there are over a dozen app stores to competing to fill the void. Compare that with the western duopoly of Apple App Store and Google Play.
We're in a thread talking about a technology that purports to make creating "native mobile apps, as easy as creating a website"; and the parent claimed that the Alipay/WeChats mini-app stacks are similar.
I don't think asking for examples of this resulting in an experience that's pleasant is unreasonable?
I think the point OP is making is that the relative pleasantry of the experience isn't as important for end users as it is for us developers. My anecdotal experience bears that out: I shudder when I see a web-heavy native app, my non-tech friends don't bat an eyelid. People learn UIs, no matter how janky, very quickly if the end goal is important to them.
I think my point was that an application that exists, is up to date and works is a better application than the one that doesn't exist or is stale because it's harder to write and maintain but feels (or would feel if it existed) nice and polished.
For practical purposes like buying stuff or accessing information I want practical applications that can be quickly iterated on.
Well, do those WeChat services have competition? That's where I've seen the push for better UX: it's a signal to users that your product is overall higher quality. So not so much 'pretty power company technicians' and more 'Is the lobby of the hotel clean?'.
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).
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.
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 ..
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".
>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.
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?
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)
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.
That’s only true on the surface: if you chose React, you had to rebuild and relearn everything about once every two years. Averages out to about the same workload as following the latest fad. Maybe more, since refactoring legacy code is 10x harder than building from scratch.
this is just not true. even the worst offenders (looking at you, react-router) do not require to "rebuild and relearn everything". What an unnecessary hyperbole.
I really do have to relearn react-router every time I use it, then I pin it to that version so it doesn't break later. Last time was v6, now there's v7 since Nov '24.
- 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.
From that list, I believe Server-Side Components is a big offender in terms of complexity.
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.
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").
This is a ReactNative app that consumes XML and maps it to ReactNative components, so you're still using those pointlessly complicated technologies, but through a proxy application that abstracts some of the complexity away (https://github.com/instawork/hyperview?tab=readme-ov-file#hy...).
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
Just because there are multiple technologies does not make it complicated per se. Indeed, something could evolve to a simpler model, which it seems RSC on RN is.
Keep dreaming man. Just look at what Next has become... It has taken "render component on the screen" and turned that into an experts domain. It's a nightmare for anyone who isn't the most skilled, for projects that are more than just toy apps and AI one-offs.
Not sure about that, it's gotten easier as time goes on, especially with server actions. Previously we used something like OpenAPI to map types on the frontend and backend and had to make separate HTTP endpoints for everything. Now I just write a function and it's all taken care of automatically, I can put types and functions in any folder I want and it just works.
Yeah, the moment I read "Serve your app as XML" my brain instinctively began to move on but it's really just HTML-like semantic snippets that remind me of WebComponents. Example:
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."
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.
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.
* 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.
The service worker thing is a weird amount of boilerplate. Every time I go back to making a PWA, I skip through 10 search results explaining what a service worker is (idc) until I just find whatever .js code I have to copy. And it's not some trivial one-liner.
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.
It is not a trivial one liner no, but you need 3 events implemented in your service-worker file, then in your main.js file you register it.
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.
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.
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.
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 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).
What a blast from the past. We did exactly this in '99-2000 (yes), and it was ridiculed as being over-engineered. At the time, it was the future because "XML will underpin all data transfer everywhere", and therefore we would be set up to run on any device, should any other device begin to exist. Needless to say, the winds changed way sooner than that became a real use case.
No it isn't, XML is an ecosystem with things like dedicated transfer protocols (EXI), schemas (XSD), transformers (XSLT) that JSON still doesn't have standardized/normalised even though JSON has been the norm for nearly 20 years. There's some projects of course (JSON Schema, OpenAPI), but they're separate and not part of the same standardization committee.
As someone who works with JSON every day and almost never deals with XML directly, it’s important to realize saying they are the same is like saying a pocket knife and a Swiss army knife are the same because they both have an extremely useful tool (and why would anyone ever use the thing with all that extra stuff I never use?). Not a perfect analogy but the one I think of for simplicity.
Back in my day, real cowboys wrote their papers in PostScript, making their papers as inaccessible as possible for user of consumer-grade devices. /s
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.
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>
</Alert>type stuff.
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.
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.
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.
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.
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.
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.
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.
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.
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/
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?
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.
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.
I mean those 1st party integrations directly listed in WeChat services page are probably good examples of services that "feel" nice to interact, because they are used by millions of people everyday and they are need to optimized and polished to be able to serve millions of users.
Here's a screenshot of the list, if you want to Google and check out some of them: https://imgur.com/a/KKEdliE
There's a pretty big difference in what UX "feels nice" to East Asian audiences vs Western audiences. This video provides some insight into why this might be: https://www.youtube.com/watch?v=WSMFnJnY7EA
The comments make it seem like it's more a case of users tolerating it due to the apps usefulness. Interesting video though, haven't had any contact with Chinese apps, so that was enlightening.
Minions of people use SAP daily that does not mean it's a nice thing to interact with.
I agree that numbers alone might not mean much, but I do think B2C apps with millions of users have a higher bar in terms of design and polish compared to B2B/ERP apps.
Also, fixed typo!
It's probably easier to switch jobs to avoid B2B apps you don't like than to avoid WeChat in China.
But it's not like you can choose in China either :)
It's not like you can choose in the West either, either :).
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.
You're making it sound as if the difference in choice between China and western countries is negligible. Surely that's not the case? If every VC company tries to pull you into their walled garden, I can still choose from among a variety of said walled gardens.
I could be wrong of course, since I don't know how many AliPay and WeChat competitors there are.
> If every VC company tries to pull you into their walled garden, I can still choose from among a variety of said walled gardens.
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.
The competitors at the consumer-facing super app level (with mini programs of varying awkwardness) include Meituan, XiaoHongShu, and to an extent, Toutiao, JD.com, and Baidu. But you don't need those gardens as a publisher if you're on Android--ironically because Google services are banned, there are over a dozen app stores to competing to fill the void. Compare that with the western duopoly of Apple App Store and Google Play.
That's all fine if the particular customers you want to reach are among the millions used to WeChat services.
It's a bit like asking which power company has pretty technicians.
We're in a thread talking about a technology that purports to make creating "native mobile apps, as easy as creating a website"; and the parent claimed that the Alipay/WeChats mini-app stacks are similar.
I don't think asking for examples of this resulting in an experience that's pleasant is unreasonable?
I think the point OP is making is that the relative pleasantry of the experience isn't as important for end users as it is for us developers. My anecdotal experience bears that out: I shudder when I see a web-heavy native app, my non-tech friends don't bat an eyelid. People learn UIs, no matter how janky, very quickly if the end goal is important to them.
I think my point was that an application that exists, is up to date and works is a better application than the one that doesn't exist or is stale because it's harder to write and maintain but feels (or would feel if it existed) nice and polished.
For practical purposes like buying stuff or accessing information I want practical applications that can be quickly iterated on.
Well, do those WeChat services have competition? That's where I've seen the push for better UX: it's a signal to users that your product is overall higher quality. So not so much 'pretty power company technicians' and more 'Is the lobby of the hotel clean?'.
FPL. Tone bodies with good tans. Don't see that with IP&L.
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.
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.
I believe Telegram has something similar too.
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).
When I was still using wechat (and in china); it was a mix; native buttons and payment integrations mixed with webviews for content.
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.
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 ..
Ah I've seen this before but then with JSON https://github.com/Jasonette
I am very unclear reading the documentation and clicking around, how do you actually implement the logic? Some sort of JavaScript runtime?
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.
Popular in 2022 (252 points, 74 comments) https://news.ycombinator.com/item?id=34137381
>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".
>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.
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?
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)
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.
Making mobile platforms second class citizens was wrong.
[dead]
How does this improve on w3c standard of xforms + CSS?
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.
> 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.
That’s only true on the surface: if you chose React, you had to rebuild and relearn everything about once every two years. Averages out to about the same workload as following the latest fad. Maybe more, since refactoring legacy code is 10x harder than building from scratch.
this is just not true. even the worst offenders (looking at you, react-router) do not require to "rebuild and relearn everything". What an unnecessary hyperbole.
I really do have to relearn react-router every time I use it, then I pin it to that version so it doesn't break later. Last time was v6, now there's v7 since Nov '24.
Maybe not React itself, but the ecosystem as a whole. I can list some of these changes that generated a lot of work from memory:
- 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.
Also, Typescript.
From that list, I believe Server-Side Components is a big offender in terms of complexity.
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...
Angular of 10 years ago... you mean the 1.0 framework that's wholly incompatible with 2+ because it was a ground up re-write?
React didn't have hooks 10 years ago, but at least they're compatible with classes
React churned itself.
> 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?
I'm more of a Floral Green person.
Underrated joke, did not expect a Title Fight reference when I opened this thread!
I'm wondering if they could get that to work with React Native for desktop apps
You'd have to run a server in the background which complicates things but otherwise it would seem to be feasible.
Surely this will be redundant with React Server Components on RN/Expo?
Server components + RN + Expo.... Could it get any more pointlessly complicated?
This is a ReactNative app that consumes XML and maps it to ReactNative components, so you're still using those pointlessly complicated technologies, but through a proxy application that abstracts some of the complexity away (https://github.com/instawork/hyperview?tab=readme-ov-file#hy...).
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
Less time spent building a stack temple to venerate oneself.
Well if you want to remotely update a mobile app UI from your server backend, it seems like the simplest option...
Just because there are multiple technologies does not make it complicated per se. Indeed, something could evolve to a simpler model, which it seems RSC on RN is.
Keep dreaming man. Just look at what Next has become... It has taken "render component on the screen" and turned that into an experts domain. It's a nightmare for anyone who isn't the most skilled, for projects that are more than just toy apps and AI one-offs.
Not sure about that, it's gotten easier as time goes on, especially with server actions. Previously we used something like OpenAPI to map types on the frontend and backend and had to make separate HTTP endpoints for everything. Now I just write a function and it's all taken care of automatically, I can put types and functions in any folder I want and it just works.
Doesn’t it require Expo’s servers for a development environment?
All these companies have given up on the gold rush long ago and are just slinging fancy shovels.
No, they can run locally.
This is more of an HTMX native
Yeah, the moment I read "Serve your app as XML" my brain instinctively began to move on but it's really just HTML-like semantic snippets that remind me of WebComponents. Example:
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/
A key distinction here is that Hyperview is free, which makes the offline capabilities or lack thereof a more than reasonable tradeoff IMO.
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).
If it doesn't do offline data or local computations what is the point?
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.
> 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.
Not on iOS. You gave to use this WebKit hack https://blog.pwabuilder.com/posts/publish-your-pwa-to-the-io....
That's specifically to be listed right? I mean I guess that's fair. Thanks for the link, saving that.
Is there a super simple tool for turning statically served websites into PWAs?
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
I would like a command line tool That worked like Which produced a PWA that downloaded everything on install and could be run henceforth offline.I thought this would be a common use case, but I failed to find anything that supported it without intruding on my workflow.
Three things you need:
* 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.
The service worker thing is a weird amount of boilerplate. Every time I go back to making a PWA, I skip through 10 search results explaining what a service worker is (idc) until I just find whatever .js code I have to copy. And it's not some trivial one-liner.
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.
It is not a trivial one liner no, but you need 3 events implemented in your service-worker file, then in your main.js file you register it.
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.
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.
"Serve your app as XML"
As someone who started his professional career in 2005: All the old is new again.
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.
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.
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 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
Symphony CMS [1] was based on this idea over a decade ago.
The developer experience was amazing, you could easily inspect the data backing any page. XSLT was hard but probably easier than React these days.
[1] https://getsymphony.com
What a blast from the past. We did exactly this in '99-2000 (yes), and it was ridiculed as being over-engineered. At the time, it was the future because "XML will underpin all data transfer everywhere", and therefore we would be set up to run on any device, should any other device begin to exist. Needless to say, the winds changed way sooner than that became a real use case.
I originally had this idea about 20 years ago. I still think it's good. At least better than brotli compressed json loaded with JavaScript.
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.
I wonder what going back to the 90's will bring up.
JSON is same as XML.
No it isn't, XML is an ecosystem with things like dedicated transfer protocols (EXI), schemas (XSD), transformers (XSLT) that JSON still doesn't have standardized/normalised even though JSON has been the norm for nearly 20 years. There's some projects of course (JSON Schema, OpenAPI), but they're separate and not part of the same standardization committee.
As someone who works with JSON every day and almost never deals with XML directly, it’s important to realize saying they are the same is like saying a pocket knife and a Swiss army knife are the same because they both have an extremely useful tool (and why would anyone ever use the thing with all that extra stuff I never use?). Not a perfect analogy but the one I think of for simplicity.
And XML is essentially lobotomized and extra verbose Lisp S-expressions, going back to the 1960’s
don't talk about my thesis, written in LaTeX, like that...
/j
Back in my day, real cowboys wrote their papers in PostScript, making their papers as inaccessible as possible for user of consumer-grade devices. /s
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...
Text is the same as JSON.
JSON is great in it's own regards but the features are not comparable.
At least with XML, you can have custom datatypes, not just strings and numbers and booleans.
In all seriousness, everything in JSON can be expressed as XML; but not necessarily the other way around.
For the love of God, stop putting "Native" in web frameworks. No, React will never be native.
What does this mean? There are plenty of big, native apps using React.
It's "native" in that the wrapper is a native binary, but it's still a webpage.
React is a web framework. You can put Native behind React, it'll never be.