Replies: 3 comments 5 replies
-
|
Hi Ed, Glad you are considering using Hyperview! Based on what you said, I think it would be a good fit for your use case, especially if you already have an htmx-based app on the web. I'm guessing you are aware of the Hypermedia Systems book. In case you're not, there's a chapter where I describe how to port an htmx web app to Hyperview, and strategies for using the same backend for HTML and HXML. If you are worried about project support, Instawork maintains two mobile apps written with Hyperview, and we have dedicated engineers working on Hyperview bugs and support. There are a few major features landing soon like configurable navigation, client-side form validation, etc. The work we do on Hyperview is primarily driven by our own needs, so that's what we prioritize. But we are open to bug fixes / features from the community, as well as suggestions and sharing how we've customized the core to suit our app. Outside of Instawork, @terryatgithub has been building a big app using Hyperview, I know his team relies on custom components to deliver the rich UI features that are different from what we do at Instawork. If he has time, I hope he can reply with his experiences here. So while there are more companies than just Instawork using Hyperview, at this time there's probably not more than a handful of big projects. You would be an early adopter, but I would be happy to help you on the journey! Question for you: is a native mobile app experience an explicit goal of this work? It sounds like the app was previously implemented using Cordova, so an HTML-based UI was acceptable. The least risky thing for you to do would be to rebuild the web app using htmx, and wrap that htmx-based web app in Cordova for mobile. I would probably recommend that as the safe route unless the company wants a more native-feeling app. |
Beta Was this translation helpful? Give feedback.
-
|
Wow, thanks for such a fast and considerate reply! Taking it kinda in reverse order - long-term, richer native apps are going to be the goal. Pivoting later to support that would definitely be an option and we're considering that too. We've got a slightly nebulous fear about Apple's 'you can't just wrap up a web app and sling it in the App Store, you know' rule finally kicking in if we cut down what's wrapped up too far, but it's a little hard to say where the line is on that - there's not a lot of app-specific stuff in there already, so I at least wanted to explore the available options a bit. One of the app features we do need to replicate is definitely going to need some client-side form validation for user-friendliness, so it helps to know what is and what isn't available yet. Another requirement that's going to hit us quite soon is needing to hook into an external OAuth scheme, which would (probably?) be easier with a plain web wrapper for now as well. The other side of it is that there are a few bits in there we'd have to custom-reimplement by moving to SSR in a web wrapper, as the app does make use of native floating action buttons and has a limited shonky homebrew offline mode. Potentially some of that could be dealt with using HTTP caching, but I'm not sure about all of it. I've read through the whole book online, yes - I came into this job straight out of ~9 years frameworkless Java (inc. thick clients!) and was actually a bit disappointed with the front-end frameworks when I saw the pain of dependency soup/management. I expected it to be better, and all my biases were confirmed when I started reading more into the SSR model 😅 Accidentally hit send earlier so sorry if you saw this one half-baked! |
Beta Was this translation helpful? Give feedback.
-
|
BTW I am so sorry if you keep getting open/closed notifications on this discussion. I keep hitting the wrong thing and embarrassing myself. Highly technical career etc etc etc |
Beta Was this translation helpful? Give feedback.
-
|
...and of course I now notice that I just put all that as a separate comment and not a reply to you @adamstep It's apparently a pants on head day today |
Beta Was this translation helpful? Give feedback.
-
Regarding client-side validation, there is nothing available out-of-the-box at the moment, all validation happens server-side. I believe @terryatgithub created their own components for client-side validation. The general-purpose solution we are adding should address the common use-cases, see the example POC here. Note that we don't plan to support inter-field validation in this first version, if that's important to you. I don't have experience with hooking in to OAuth in Hyperview. If I was going to try it, I'd probably build a custom behavior action that trigger an oAuth flow using a library like https://github.com/FormidableLabs/react-native-app-auth. Like you said, with a plan web wrapper you wouldn't need to worry about it at all.
Regarding the offline mode, I just answered another question about this earlier today. This is something that Instawork is interested in as well, we've built an extra layer off HTTP caching using stale-if-error and stale-while-revalidate directives. These are not supported by iOS or Android, but they make offline mode much more robust. We plan to open-source this work as an add-on extension for Hyperview in the next couple of months. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the info! The offline mode in particular does some retry-later stuff for updates from the client, which is a bit beyond the normal case, but I have a sneaking suspicion that we could actually do away with that bit as it's retrying things I fundamentally don't think are important enough to warrant it... You've given me loads of food for thought, though - I don't think we'll be ready as a team to start tackling this bit for a few months yet, so there's some mulling over time before we need to commit to a path. I really didn't expect such a fast and detailed response to a late-night wall of text, so thanks very much for your time! I will check back with lots of interest on how things go, and probably try out my own little noodling projects with it in the meantime just to see 🙂 |
Beta Was this translation helpful? Give feedback.
-
|
hi all, sorry for the late reply. Yes, we've built and deployed several Apps based on Hyperview, some of them involved ~100 pages. The Function The Support is very timely The Support is very proactive Overall, I strongly recommend giving Hyperview a try, as it has proven to be an invaluable asset in our development process. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for your reply @terryatgithub! I really appreciate the information 🙂 |
Beta Was this translation helpful? Give feedback.
-
Hi all,
I'm considering Hyperview as an option for a rebuild of some native apps which are extremely, unmaintainably overcomplicated for their actual function - web app in Angular, with a React display component shoehorned in via unnatural acts, wrapped through Ionic and Cordova, mostly just doing straightforward read and update - almost no create, no delete at all.
We're planning to use HTMX for similar reasons for the web app itself and related administrative portals, and the parent company has some React Native devs so Hyperview looks like it fits our intended SSR model and we'd have the ability to extend it - all good!
However, there seems to be a lot more activity around HTMX than around Hyperview - more real-world case studies of successful implementations, more community interaction etc., so I'd really like to hear more about some more Hyperview success stories beyond Instawork. Even some problems too, to help me weigh up my decision - what's the support like, etc.?
For context, my overall situation: brought in to help sort out very eclectic tech stack caused by lack of clear direction and people just wanting to try stuff. Company ran out of investment money too soon to address. Messy acquisition to try to keep product running for existing customers, not everyone was retained, so I've gained absolute technical authority (yay!) but lost basically my whole dev team (boo) and am starting again with resources from new parent co. Most challenging situation I've been in professionally. HATEOAS principles intuitive, massive breath of fresh air to me after 18 months wrestling the beast and going backwards, fit our actual needs like a glove. BUT. Part of the reason the company got in the hole is because of people just 'trying cool stuff' so I've really got to do my due diligence 😅
It feels like it fits my situation and team's skills like a glove and could be transformative for my team's ability to deliver a quality and timely product, but it's juuuust quiet enough that I'm wavering and could use to talk to people actually working with the technology for real purposes.
Sorry for big wall of text! Hope I've not bored you to death 💀
Ed
Beta Was this translation helpful? Give feedback.
All reactions