Hyperview: Server-driven mobile app development
Alright. So, I am joined today, by Adam and you are the creator of HyperView. Is that, accurate? And co author of Hypermedia Systems. Right?
Adam:Yes. Sounds correct. Yeah. Thank you for having me.
Lazarus:Yeah. No. Thank you very much for taking the time. I really and it's, Stepinski is the last name. Right?
Lazarus:Is that pronounced correctly?
Adam:Correct.
Lazarus:Excellent. Yeah. So thank you for joining. I I was I've been actually trying to, reach out to you for a few months now. I like, you know, I can't couldn't message the hype review Twitter account, and and then, I wasn't I don't know.
Lazarus:I just couldn't find you. So, I appreciate Carson Gross, getting us in touch.
Adam:Yes. Yeah. I'm I'm quite bad at Twitter, but, I think the best way for hyper view questions, you know, we're always monitoring GitHub.
Lazarus:GitHub. Okay. There's a
Adam:Reddit, there's a subreddit someone created as well. And, yeah, we're on the, on the Discord server for HDMX.
Lazarus:Awesome. Okay. Yeah. I really I haven't I know I created a Reddit user and stuff, but I I haven't got into Discord, and I just go on the Reddit, like, every couple of months just to, like, see. But I I'm just not you know, Twitter is new for me too, so I'm kinda trying to, like, dip dip my toe into this world.
Lazarus:You know?
Adam:Yeah. Hopefully, you know, we have some, younger engineers on the team now, so, hopefully, we can get I can get one of them more interested in social media since,
Lazarus:it's not my forte. Alright. Alright. Get the Hyperview, account going.
Adam:That's right.
Lazarus:Nice.
Adam:Yeah. Memes are not my strength like like they are for Carson.
Lazarus:Yeah. Yeah. Yeah. So so I'll just, like, I'll just say my understanding of Hyperview and, like, you know, you know, I I have read not the whole part of the book that had to do with it because I kinda, like, tend to not absorb information unless I'm actively working on something that is related to it. So, you know, but I I so so my understanding of hyper view is sort of taking this concept of, you know, hypermedia approach to the mobile world where you are trying to get a build something that is set up for server first development, but in a native, you know, mobile, mobile app.
Lazarus:So it's just so that you have it's not just a a fake website on the phone. Right? Is this sort of, the big picture of of Hyperview?
Adam:That's right. Yeah. So, you know, if you think about, Hypermedia on the web, there's 2 components. There's the format HTML. Right?
Adam:That's kind of the standardized stuff. And then there's the clients, the various web browsers, you know, Chrome, Firefox, or whatever you prefer. And so to create a hypermedia system for mobile, there is no kind of equivalence to, you know, the hypermedia formats that is native to mobile in terms of understanding the types of interactions and ways that people would like to build apps. And ways that people would like to build apps. And there's also no client equivalent to to consume that format.
Adam:So Hyper V as a project, I really think of it as 2 parts. We've defined a spec of a format based on XML that we think does a good job expressing the UI and interactions that users expect on mobile apps. And we've also created a client that's built on top of React Native and can be, you know, used to build cross platform apps for Android and iOS and distributed through those through the stores, the Google Play Store and, Apple App Store.
Lazarus:Nice. Nice. So, I'll just let me just I'll just say one thing before, before I ask any more questions. I so I was watching your talk, which, you know, you, Carson posted, but I think you at the University of Montana, you know, you talked there a little bit about Hyperview. And I had to stop it, like, halfway through because, you know, for the last for a couple of years, I have been, you know, I I I had to build a mobile app for my company.
Lazarus:Mhmm. And I just wanted something simple, and I was like, okay, you know, I wanna figure out how to do this and starting from scratch. And, I use Flutter, you know, which is kind of a similar like maybe to react native sort of setup where you kind of The concept is that you build it once in Flutter and you can kind of export it to anywhere. So that was appealing to me. And I started building it and it was just like a nightmare, and I was like, I'm not gonna finish this.
Lazarus:I don't I'm gonna If I ever have to make a change, which I do all the time as a web developer, you know, I like I like to have these quick changes. And I started to realize all the problems with iOS, you know, with building this. And like I was gonna have to submit it to Apple every change, like 4 days from now, I'll get a response. Anyway, my sort of, like, revelation while doing that was to build a bunch of reusable components in Flutter and then have my server tell it what to draw, what data to use, all this kind of stuff. So so I have been building for myself this, like, I I didn't know what it was at the time, but I was listening to your hyper view and I was like, God, like, I don't wanna be influenced too much by this by this talk, by what you're talking about because it sounds it's like similar to what I'm building.
Lazarus:So so like how did you come up like what was your sort of, you know, are you like a web developer by trade or how did you sort of come to to building this?
Adam:Yeah. I would call myself, a full stack engineer and for the last half of my career about 15 years, I've been more actually also working as a manager and leader of software teams. And over that career, I pretty much always have managed teams that built mobile applications. And, you know, that started early on when the best practice was you have your separate set of team your separate team for Android development, they work on the Android app, and then another team for Ios. And then maybe you have a team that works on the back end and creates APIs for both of these.
Adam:And, you know, that definitely has its pros and cons. You need a lot of engineers to ship a product. You end up kind of with a fragmented experience, which is more of a problem for maybe the company than the users. But, you know, if the iOS and Android apps are different, that can be very hard to manage internally because now maybe they require different APIs and that requires extra work and so on. So, you know, I think I was pretty early to embrace later on on, React Native as a cross platform solution that not only meant that, we could have one team creating the mobile app that ran for both iOS and Android, But we could also leverage, you know, the pretty widespread knowledge of React.
Adam:And, you know, you can if you're comfortable with React, you can pick up React Native pretty easily. So that kind of opened the possibility for more of a full stack development approach on mobile as well. And then, you know, once we're using React Native and, you know, talking to kind of APIs that return JSON, that's then when I started making the connection, like, wait a sec. This is essentially the same as, like, spawns on the web. And, you know, I'm not gonna preach to the choir here, right, since people listening to this already, I think, you know, understand some of the benefits of hypermedia.
Adam:You're probably, at least interested in using HDMX. We went on that same journey, so I started, using Intercooler, the predecessor to HDMX on the web. I said, well, this is so much better. We have, you know, server control here. You know, our front end was a lot simpler.
Adam:We're not maintaining these APIs. Why can't we have that for our mobile apps as well? And I would even posit that the problem, you know, the problem with SPA is on the web. It's actually a lot worse in the mobile ecosystem because of the nature of distribution. Right?
Adam:Like, if you're writing a SPA on the web, you can deploy your back end and front end sort of at the same time. Right? Like so if you need to change the front end and change the APIs, you can release that at the same time so your users can be using the new API with the new front end. But on mobile break your caches and stuff. Yeah.
Adam:But on mobile, you know, your apps are you don't control the distribution. Right? You have to go through, through these app stores, which means you have multiple versions of your app out there. You can't control, you know, what version of the app is running on user's device then, user's devices. Like, maybe you can force them to upgrade and things.
Adam:But, software controls the rollout. Right? And we've seen in our own metrics, there's a long tail of people on various versions of the app, and those versions of the app because the logic of interacting with the API is bundled in there. If you don't wanna break those, you have to maintain a support's compatible API or version your API and maintain it for a long time. And that was the situation we were in.
Adam:You know, perhaps we would ship a version of our app that had some kind of bug in it, and we would try to hack around that by modifying the API, but only for that version. And then when we re released a new version of that, we needed a new API for it. So I think the problems of, like, kind of the spot, architecture was actually we felt more pain with using that on mobile than we did on web, which is how I started thinking like, well, you know, how do we bring hypermedia, to to our approach for mobile app development?
Lazarus:Yeah. I mean, I just I cannot imagine living in that space for a long time, where you have a bunch of apps. Like like in the way that I have a bunch of web apps out there right now that I am responsible for that I maintain. If I had you know, if working with the existing ecosystem and if I was building in Swift, you know, or whatever, you know, some even Flutter or, like, whatever it is. If you're not using a hypermedia approach, like, it just feels like you're just it's everything's cumulative.
Lazarus:Like, everything you do, now you have to support every step along the way, and it's like and you have to the the feedback loop is so long. Yeah. So, I mean, I just, like, I I don't I was looking I was feel like I was facing that when I was building my app, and I think, you know, it's like I don't know how you don't come to that. Cannot that, like, you know, everyone should figure should do that, but it's like that's what else can you do? Like, just live with that?
Adam:Yeah. And it's funny. I think in in the industry, you see basically anyone maintaining a large number of apps or a very large complex app kinda coming to the same conclusion. Like, if you look at the, engineering blogs for Airbnb, DoorDash, Uber, they all have the post where they talk about their mobile apps, and this architecture that they developed. They call it, like, server driven UI.
Adam:They don't call it hybrid yet because I think they don't they haven't conceived of it that way. But, essentially, everyone is doing this idea that you talked about, you kind of found on your own. It's like, oh, you know, how do I have my server control which UI elements are showing? I you know, I'm biased, but I think Hyper Vue is a better approach than what these other companies are doing because they've they've tended to tie their, server driven UI frameworks very tightly coupled to their to their server architecture and to their kind of networking art architecture. Whereas HyperView, I think because it you know, I kind of had this idea from, HMX and intercooler first.
Adam:Like, I always thought of it as a hypermedia approach, and therefore, you know, we're kind of agnostic to the back end. You can use any back end technology as long as you can render an XML response. Yep. And because we've kind of standardized on the spec that uses XML and is extensible, you know, I think it's a format like, if someone wanted to use Flutter to create a Hyperview client, there's nothing stopping them, and, you know, that would probably actually have some benefits over the client that we provide on GitHub
Lazarus:right now.
Adam:Mhmm.
Lazarus:Oh. So so how do you, you know, it like, when it comes into your app, you know, so so you've you've got a React Native setup. So, I mean, I'm just I'll just save the sort of setup that I have in Flutter and and maybe Mhmm. Does is this somewhat similar? You've basically built a bunch of components inside, using React Native, and so you've got kind of a list of these, you know, components that can be mixed and matched, and then they match with your x you give an XML tag that matches the name of the component or something along those lines.
Lazarus:Does that sound about right? And then each one has a set of attributes that you can add.
Adam:Perfect. Yeah. So what happens when you launch an app written in Hyperview? The you know, it took the very minimal amount of effort you need to do to create a app built with Hyperview is download our client and change one configuration of the URL, which is the entry point of the app. Like, this is think of this as, like, you know, the first URL you enter to to open a web app.
Adam:This has to be kind of, like, hard coded into our app for distribution. But once you do that, you know, you you configure that, and then you basically say when you open that app, launch Hyperview with this URL. The Hyperview client will make that HTTP request, get that XML, and then it parses that XML into a DOM and just, you know, starts traversing it. And we have a registry where each name corresponds to a React Native component. So essentially, we're creating, you know, the tree of React Native components dynamically based on what's specified in the XML.
Adam:And those React Native components will get a prop passed to it, which is the element. And from there, you can look at the XML attributes or even the children if needed, or you can delegate rendering to hyper view for the children. So in this way, yes, we we kind of ship the core library with the most basic components that we think someone would need to, to render a mobile UI. And, yeah, then it's just kind of walking the XML doc, parsing it, mapping to React Native components, and then rendering those to screen.
Lazarus:Yep. No. I mean, that makes that's that that makes a lot of sense. And it it's funny because, you know, what I found kind of working on a on a similar project is that you the the the the data map that you get using, in your case, XML, in my case, a sort of version of HTML, you know, it's the
Adam:Mhmm.
Lazarus:It's basically HTML. I just have the the names of the components or the tags, you know Mhmm. Which is maybe almost exactly what the XML setup is. Mhmm. But it's like that mental map.
Lazarus:It's not just because I know HTML and I like HTML. It actually works for almost everything. You know, it's hierarchical. You start at the top. You have a page and, like, I kind of was like, well, I don't know if this setup's gonna work.
Lazarus:And it's like, it does work. Right? I mean, it's like, what can't be described in that format on a mobile app? Have you found anything yet? Like
Adam:Well, I think the key is, extensibility. So, you know, I often get a question about usage of XML. Some people think that's kind of old fashioned. Why not using JSON to represent this? But I think you're right.
Adam:Like, I think XML and in fact, I I wrote an article, a blog post about this about why I think XML is a more natural way to express, UIs in general, you know, kind of like the nested tree nature of it and kind of a clean separation between elements with attributes, versus, like, a parent child relationship is Yep. A more natural way. You know, JSON does not have that built in, so you end up having to define a spec on top of JSON to represent that. So that's that's one reason why I think XML, HTML are are kind of great universal ways of describing UIs. But the one thing that I ended up embracing in XML that, I sort of discovered, while writing HyperView is the x in XML, extensibility.
Adam:Right? So XML has this concept of namespaces. So you can, define a namespace with a URL, And then within that namespace, you can have your own elements or attributes. And to me, once I realized this, I said, okay. Well, we have to build in extensibility into the HyperView client because mobile UIs can be quite complex and require quite a bit of, you know, interaction or kind of detailed work, to have the experience that users expect.
Adam:And there's no way that the core HyperView library can cover all of those use cases. But if we make it extensible, then anyone can kind of add their own elements to describe some of the more unique or complex, you know, elements that they want to use within their mobile apps. And, I think that ended up being a real game changer for us and something that, the companies that use HyperView, like, I know pretty much everyone ends up creating some of these, custom elements and custom behaviors. And I think it really sort of extends the sort of quality of UIs and experiences you can deliver while still kind of fully embracing hypermedia and kind of, like, this declarative syntax, in the XML. And I'm happy to talk more about that.
Adam:I think that's something, you know, I wish I had more time to go into in the lecture that I just did at Montana State University. But, I think there's a lot of power there. And in some ways, we've been able to, I think, more cleanly capture some of the ideas that on the web people are trying to do with web components, or, you know, like in HTMLX, various plug ins and and scriptability that has to inevitably, find its way into into kind of the declarative sentence.
Lazarus:So so, like, when you say extensible, is it are people this is just sort of the way I'm imagining it. Like, they would you know, they they'd have your basic entry point app, in in the whatever their programming language that, you know, whatever system they they have to use the react native setup, and would they write their own React Native component, and then they would give it a name that then would be referenced by the XML just like all the other components that are part of
Adam:the library? Yeah. Right? Yeah. There's nothing special about the components of, like, you know, basic text and labels and inputs.
Adam:Those ship with the core HyperView library. There's nothing really special about them. Right? There again, we register a namespace and an element name. And when we're parsing the XML, if we encounter that namespace and element name, we render that React Native component.
Adam:So anyone is free to create their own React Native component and register it with the system as well. And then if the XML parser encounters that, it will map to to the custom, React Native component that that's been added. And, I know, like, a lot of people in the hypermedia community now, you know, they don't wanna sort of touch JavaScript at all. So I feel like I should stress, you don't have to use this, you know, out of the box. If you just set up the the HyperView client, you can do everything you need, and have a mobile app with multiple screens and forms and all of this, and you can feel very comfortable just writing XML on the back end.
Adam:But if and when you're ready to take it to the next level, you don't have to abandon hypermedia on mobile. You can just extend the new client. And some some ways of, thinking about it that I like to tell people is, like, well, you know, your app is sort of like your own, browser. Right? And, like, what if you didn't have to worry about the, like, you know, web standards, and you can go and, like, extend the browser in any way you wanted?
Adam:This is kind of the plan that you can have with with, the Hyperview client. Feel free to add any experimental tags or new interactions and things that make sense for your app because you don't have to create a universal browser. You don't have to consider all those cases. You can really customize it just for your use case, which helps it kind of stay declarative and avoid kind of hacks that sometimes need to be added through scripting.
Lazarus:Yeah. And, like, that's not even mentioning, like, all the power you can tap into, like, the fact that it's a phone. I mean, you've got, like, accelerometers and location and camera and, I mean, just like a wealth of these sort of things that as web developers, you know, just not part of the experience most of the time.
Adam:That's right. Yeah. And so, the company I'm at right now, InstaWork, this is where we created HyperView. And, Yeah. We need access to a lot of those things.
Adam:So we have integration with cameras, photo libraries. We do a lot of things with geolocation, so users can give us permission to, to get their location right. And, we based on that, you know, on the back end, we do various things. And, we support all of those things with hyper view and hypermedia and just writing some of these extensions. So, in order to tap into all that, developers are still just writing XML.
Adam:You know? Yes. There's a little bit of JavaScript rerun upfront to create these components and and behaviors, but once they are there, you know, it can be used anywhere in the past just by dropping in a a tag in the XML.
Lazarus:Yeah. So so this I mean, you know, you said you work at Instawork. So is the what's the primary app that you sort of developed Hyperview for? And and, like, I guess I'm just the I think the big question that I had and then, you know, probably people listening is, like, what sort of apps are you building with it? Can you build do you see any limitations of the approach or of react the actual limitations of this, you know But mainly, like, what what are some apps you're building?
Lazarus:I guess, is the first part of that.
Adam:Sure. So, yeah, InstaWork is a, staffing marketplace app. So we have, sort of people are looking for sort of temporary short term jobs, physical jobs, so they have to, like, you know, go to a to a worksite to do it. So you can think of, like, a warehouse or a hotel or something like that.
Lazarus:Yep.
Adam:So, main app is it's the work for professionals, which lets them sign up, kind of upload their experience and credentials, and based on that, they can get approved to work various positions in their local area. And in the app, they will see, okay, what are the various jobs or shifts available to me. If there's something that matches my skills, I can book it. I get all the details about where the shift is happening, when do I have to go there, clock in, clock out, get paid. So that that's kind of it in a nutshell.
Adam:And we have also an app for the business side to actually post these shits and make them available. So the the first thing I'll say about this app is, in a marketplace, it's very important that everyone is kind of getting the same experience and getting the same data, you know, because if if we launch a feature, for example I'm just making this up, but if we launch a feature that, is doing a promotion and giving people a $50 bonus if they work on a certain day. Well, if you have a version of the app that doesn't know that we're doing this bonus, you're at a disadvantage. Right? And someone who know who has a version of the app where we've coded in the bonus, you know, they're gonna be more motivated to work.
Adam:But I can create imbalances in the marketplace or lower the efficiency. Hypermedia is great for that because we're doing the bonus. Okay. We code it on the back end. We start showing the bonus everywhere.
Adam:Everyone gets that same data. It's on the same playing field. So for a marketplace, it really helps us with the efficiency of the the product we're building and making sure that no one is kind of disadvantaged based on being on an older version. So I think apps where people are connecting and it's important for them to have the same experience, we found, you know, that the hypermedia approach is really good for that. The other thing about this app that I'll say is that, you know, the core service we're providing is matching professionals with local businesses.
Adam:So it's really the core logic is on the back end, and the app is useless without the Internet because you can't get, you know, you won't get the list of jobs that people are posting live if you don't have an Internet connection. So for us, it's an assumption that the app only works when you have a network connection. If someone is building an app that that is primarily offline or doesn't even need a network connection because all of your data is kind of local to you, then this approach probably doesn't make sense. And I would probably advise someone like that to still kind of, you know, create an experience, get where, you know, you're just using kind of the native frameworks or even you can use React Native with the local storage. But, in our case, I think, Hypermedia is a great fit because of sort of the, aspect of connecting different users together.
Adam:They need to kind of have shared state and a shared experience, and the fact that it's, kind of always online.
Lazarus:Yeah. Yep. No. That makes sense. And so so that's your, you know, the primary one.
Lazarus:It sounds like there's a couple different apps. You have, like, different versions, you know, you're probably all hitting the same database, but you've got different apps for different versions of clients, which I think makes perfect sense.
Adam:Yeah. Yeah. For people yeah. Like the the business side, you know, if they're the ones posting shifts and seeing, okay, who's coming to, like, fill my shift? You know, that's a different experience that they need than someone who's browsing or looking at a map and trying to find shifts, that they wanna work.
Adam:So we have 2 2 different apps for that. But they are both, pretty much now a 100% converted to Hyperview. And one interesting thing we've talked about is now that these are both kind of completely Hyperview apps driven from the server, are both of our apps are pretty much just shells. Right? There's absolutely no logic in here.
Adam:We could combine them. Right? Or there could be a switch in the app that says, okay, now show me the fitness interface and we just change entry point URL
Lazarus:and all the stuff. The user. Yep.
Adam:The full other app. Yeah. Because we sometimes get issues if someone downloads their own app, you know, or something like that. So we we haven't really got that path, but it is a interesting thing that, you know, we can essentially combine these two things and, splitting them off is almost more of a marketing decision than than an engineering one.
Lazarus:Yeah. Yeah. And do you and, like, feel free to not answer this question if you don't want to. Do you do you think there's any is it against the spirit of the app approval and store and all this stuff to because I and this, you know, the stuff that I'm working on right now, my vision for it is literally you put one line of code and that's your app, and it's just what you said. It's you you just point it to somewhere and then that's handling everything.
Lazarus:And so, you know, in terms of the Apple Store, you know, it's like what are they really reviewing? Like, I could Yeah. Chain you know, so maybe this is not it's just something I I've been thinking about. Like, do they have
Adam:a process? Have you seen
Lazarus:this? Mhmm. Yeah.
Adam:Yeah. So, a couple of things I'll say about that. You know, I think first, you know, there's a lot of apps in both app stores that already kind of work like this. Right? Like, any app which is a wrapper around a web view, like a Cordova app or something.
Adam:Right? It's the same sort of thing, and there's a ton of apps like that out there.
Lazarus:So Elektron or something? Is that one of the ones that does that? Is that or maybe Yeah.
Adam:Maybe? So, yeah, basically, you know, there's a lot of apps like that. You know? And sort with Hyperview has been out there for a long time as well. And, and then I mentioned before, all these companies, you know, the biggest apps out there, Uber, DoorDash, Airbnb, they're all doing server driven UI as well.
Adam:You know, from Apple's perspective, when they're reviewing the app, of course, someone is looking at the UI, but, you know, let's say they have a proxy. Well, they're just seeing, you know, an app making API requests. In our case, it's XML. In other cases, it's JSON. But, ultimately, it's just data that's coming, across the network.
Adam:What they're interested in preventing is, kind of shipping executable code. Right? Because they're worried, I think, about, apps breaking out of a sandbox or things like that. Right? So what they don't want you to do is sort of, like, ship code that accesses system APIs in a way that they're not aware of through static analysis.
Adam:But in the case of hyperview based app, right, like, if we have created a custom component that, for example, needs access to the camera, That is in the binary that Apple is reviewing. Right? And their sonic analysis will show, they're kind of requesting this entitlement. You know, there's some code here which is accessing the camera. There's nothing that you know, if we didn't have that in the initial version, we can't push some XML that all of a sudden enables camera access.
Adam:So from that perspective, you know, from the security perspective, yeah, we're not kind of shipping code that gets compiled and can access, SDKs or APIs that Apple's not aware of. And then from the perspective of kind of what you said where, hey, someone could do an App Store review, And then when their app gets approved and the end users can completely switch the UI. And the cats out of the bag on that, like I said, everyone's doing service redesign, they can do that. And in fact, over the years, we've seen Apple's policies change from being enforced through technology to enforce now in spirit. So I think their, rules have changed a little bit from kind of saying you can use this tech and not this tech.
Adam:And I think they've realized, well, anyone can, like, call an API and activate a different path in their code. So it's not really about the tech. It's about the spirit of you shouldn't do a bait and switch app where you show us one thing and then do something else.
Lazarus:And they may
Adam:have some way
Lazarus:of finding that maybe that we are not even aware of.
Adam:Yeah. I think it's I think it's much harder for them to enforce, but they probably rely on user reports and yeah. I don't know how how they do it. But, yeah, that that's kind of been my take on the situation.
Lazarus:Yeah. So so if you were to, you know, if someone builds an app with hyper view and they're Mhmm. They never touch the camera, you know, they're they're the way they're building their app, they're never gonna use the camera component. But they may have to, like, because the hyper view library has somewhere in it the potential to use the camera, you you may have to sign on the iOS sort of like what does your app do. You'd have to sort of say all the things that Hyperview does.
Lazarus:Is that is that accurate?
Adam:Yes. That is accurate. So our approach has been that the client is a very small core. Right? And we're trying to, not include kind of features that, yeah, require some of these, like, special permissions or entitlements.
Adam:Right? So, like, the core Hyperview client, it mostly can do, you know, render text, show screens, models, form inputs, that kind of stuff. And, of course, everything can be styled to to look as you want. And then, you know, we use the extension so that you only have to include something that accesses the camera if your app needs it. One kind of recent development that I would love to talk a little bit more about is, we've always kind of added this extensibility, but, I think a lot of developers coming to Hyperview may not want to, like, necessarily write the code themselves because, you know, in some ways, they're attracted to hypermedia because they don't like React or React Native.
Adam:Mhmm. And internally at InstaWork, we've written dozens and dozens of these kind of components, and we realized we can start sort of giving them to the community. So very recently started, open sourcing, not just the core client, but now some of these, we we we we got a section and a repository for, like, community contributions in the first 5 dozen or so components that we've done there have been pulled out of our Instawork app and shared, to to the community. Hopefully, that makes it easier, more a plug in like way where someone can say, hey. I want to show a Google map that I can drag and pinch in my mobile app.
Adam:Well, NC work has done that. You don't have to write that yourself and figure out how to do it. Just, you know, import, you know, download this from MPN, import it, register it, and now, you know, here's the XML syntax you can use to show them the specific coordinate. So that's a recent development that I'm excited, hoping to see contributions from the community as well because I know there's a lot of developers out there who've written, components that I think could could be shared and reused and appreciated by everyone else.
Lazarus:Yeah. I mean, that's awesome. I think that's like I mean, that's that's just a that's a really cool way to do it. And I I don't know, like, I'm kinda like I'm curious, like, what was the decision like to open source Hyperview for you? Like, is this one of your is this do you have you done open source projects before or is someone else involved?
Lazarus:I don't know. I I was it developed with sort of the team and then you lead the team, so you made the decision? How did that sort of play out?
Adam:Yeah. I had never done, like, a large open source project like this before, and I'm certainly not the expert. You know, I'm learning. I think we, you know, we saw that this technology was really helpful and applicable to a lot of other developers and companies, not just InstaWorks. So I think our general philosophy is like, look, if we've developed a technology that is not kind of like a trade secret for us, but we think is beneficial, then we should share it back.
Adam:And it's only fair because we rely on so much open source technology to develop things, you know? So like, I feel like we need to be good citizens and not only contribute to open source projects, but open source things that we built ourselves. So that was kind of the initial sort of take. And I thought, you know, maybe as someone who's a manager and always looking at ways to get in touch in the hiring market and kind of build a brand for engineering team. So I kind of said, you know, maybe this is a good way to, you know, just make a stamp and, like, you know, get our name out there as, like, an engineering team that is doing something new and interesting.
Adam:I should mention all of this was happening before HTMX was out. So this was still when
Lazarus:Oh, really?
Adam:Intercooler was there. Right?
Lazarus:Oh, yeah.
Adam:Okay. The the best decision I made, you know, was so, yeah, like, you know, reach out and engage with, Carson early on when we were I think, InstaWear kind of the largest and probably still has the largest, built on Intercooler in terms of number of attributes and kind of pages that use it. So I'm interested to him because I was so interested in it. And when I started developing Hyperview, I shared it with him, and he was very much encouraging me to go down that path. So the best decision I made is, like, you know, he decided to to release HDMX and kind of break the jQuery dependency, and that took off.
Adam:You know, I kind of see myself as riding his coattails in the wave of, exciting production of HDMX and bringing attention to to hyper view as well through that. So, yeah, I have a I think I have a lot to learn from him and other projects around nurturing an open source project that's been mostly organic. You know, we're just trying to ship and improve the code, engage the communities some more. But, as as you can see from our Twitter account, I think there's probably we we could use some help in in some of these areas that, we've been invested
Lazarus:in. Well, I mean, it's an I would say I mean, it's it's an amazing project, and I just the the vision for it, you know, so so before I I kind of you know, I've been looking into hyper view. So, like I said, I've been building my own thing that I'm now realizing is like you probably have done all of it and in a more complete way than, what I'm working on, but it, you know, I think I'm I'm too deep in to to, to switch gears now. I'm gonna go forward with my my thing, but it's still like, you know, this concept of of building it like this and then also offering, you know, like community driven plugins and having it be open source, and it's just kind of, you know, it's ambitious and just kind of a very cool project. So I don't I'm just it's I'm impressed.
Lazarus:That's the way it's coming together. It sounds it sounds really cool and I
Adam:You do.
Lazarus:Yeah. I wish that I had, you know, my my for my own purposes I I was considering kind of like should I give this a shot with my own thing? But I one of the barriers for me was the react native and not because I have anything against react. I mean, I just I don't know it. I've never sort of compiled anything in it.
Lazarus:And and I had used flutter back in 2019 and I built that app and I'd used sort of the the the nascent version of of hypermedia approach, you know, which I I sort of thought was my my big, revelation while building the app, but I guess is is getting more and more common. Yeah. But, yeah, it's like I I think this is something it sounds like there's not as many, you don't have to worry that much that you won't be able to do things as I was sort of concerned about when I first started looking at Hyperview.
Adam:Yeah. I mean, I it really depends, you know, I don't know the exact thing about that you're building, but, you know, because the same as, like, you know, if you're using h tmx on the web, some things will be a lot easier. Some things will be a lot harder. Right? And, like, even I think Carson would say, like, sometimes it is appropriate to use, you know, a lot of JavaScript on the client.
Adam:Right? And but you don't also have to, like, pick and choose and, like, only use one sort of technology. What I would maybe suggest for yourself, Renu, since it seems like you're pretty deep into, Flutter and developing things that way. But I think maybe you could even, take inspiration just from, like, the spec in in HyperView for, like, you know, using XML, kind of creating this registry of components to to run new things. I just think it's a very, like, kind of more universal way of expressing UIs from the server.
Adam:And, you you know, yeah, React Native is the client we shipped, but I sort of I can see HyperView developing a little bit like the down project. I don't know if you're a markdown user or if you're aware
Lazarus:of that. I mean, I I have used markdown just as, like, you know, just for a few times, but I will say it's I don't use it regularly. Yeah.
Adam:But I think the, the key, why I mentioned markdown is, you know, this was a project John Gruber released and he also essentially created a spec for markdown and the reference implementation and Pearl that he's very much sort of said, this is what it is. He's people sort of take it, you know, evolve the syntax, you know, so you end up with like GitHub has their own like GitHub flavored markdown. And of course, probably no one's using that initial Perl implementation of converting it to HTML. People have written their own sort of implementations and every programming language out there. And I think, you know, to me, there's a I see a lot of analogies to hyper view.
Adam:Like, we've created this stuff. It's meant to be extended. Use you know, like, you should I encourage people to extend it and make it their own, right, for for their use case. I think that's one of one of the powerful things in it. You don't have to wait for you don't have to file an issue and wait for a select time to have your feature.
Adam:You know, you can go ahead and add it yourself and then maybe contribute it to the community. Likewise, the we're not tied to a specific, you know, client. So, like, if if you just like these ideas for how we think about structuring UI and behaviors, the interactions, we haven't really talked about that. But, Yeah. Like, you know, feel free to be inspired by those and take them and like, you know, don't use react native if, if you don't, if you don't like it or you're not familiar with it.
Adam:So I think I'm totally happy to see people embrace the ideas even if they're not necessarily downloading and using their pain.
Lazarus:Yeah. Well, I mean, that's I feel like yeah. You've got a, you know, I think it's a, very sharing, open source kind of attitude about the project, which is cool. And yeah. So so how do you, like, you know, I'll just I'll just say more about my thing because it's on my head, you know, it's on my mind, but, I've kind of embraced taking some of the tailwind kind of approach to, to to doing UI stuff in Flutter.
Lazarus:So, you know, I've kind of developed, not not trying to recreate tailwind, you know, but some of the the basic ideas of, like, these are basically classes. I don't call them classes, call them styles, but you add on to each, component and every component has, you know, is wrapped in a style container that sort of allows you to that's your styling container. When you add classes, that's what gets the style. So does that sort of sound kind of what, you know, what you guys are thinking for, you know, what Hyperview sort of does for UI? How do you guys sort of handle that?
Lazarus:I don't really know how React Native handles it. So it's a little hard to about
Adam:styling, like, specifically?
Lazarus:Yeah. I mean, like, you know, text color, padding, margin, like, all these things that would just sort of be part of any UI, borders, background, all that stuff.
Adam:Right. So HyperView, in this case, like, we pretty much took what React Native offered in terms of styling and, mapped it 1 to 1 to Okay. Some other syntax. So unlike on the web, you have HTML and then CSS. You know, CSS is a different format.
Adam:In our case, we just have everything in XML including the styles. So, you know, you're just definitely in a style tone. It's a little less formal than CSS, but I I think in a way that makes the right trade offs for, styling an application versus CSS HTML, which, you know, has its origins more in, like, a document layout and formatting. Yeah. But yeah.
Adam:So we hyperview mostly just, maps to what React Native offers. And what React Native offers is, I think, inspired by styling in CSS. For example, in React Native, all layouts are sort of done using the Flexbox paradigm. Yep. So that's what we expose as well, and that works pretty well.
Adam:But, again, yeah, all the kind of styling around colors and things like that, Yeah. It's supported in hyper view and the XML syntax. You define your styles by ID, and then you can reference those, on the elements that you're rendering, and those sales would get applied there. Yep. I think we've taken, like, a pretty low level approach.
Adam:And it's what what I've seen some other companies do is, you know, there's, this notion of, like, design systems. Right? Like, where, I'm just gonna build my app with I've already defined that, you know, there's 3 sizes of buttons. Right? And they can be these colors and things like that.
Adam:So you could do that with hyper view. You could ignore all of the sort of low level styling we have and just sort of create your own custom components that, you you know, maybe they wrap the, text component that HydroView provides, and it builds in some attributes for doing different sizes and things like that. So I've seen some companies go that route. You lose some flexibility in how you do the styling, but, you don't have to, like, be writing the styles style rules each time. Your XML can be a little more concise.
Adam:So, yeah, I think there's there's different approaches, and, the syntax and client is flexible enough to support both.
Lazarus:Yeah. And and so you you do feel like you've sort of tried to tap in as much as possible into the react name. So, like, if react native were to add something, is it almost like do does hyper view sort of hard code everything from react native, or is it like is it almost like it could is it dynamic, I guess, is what I'm saying. Or or is it sort of you you have to keep up with what React Native is doing, or is it almost like you can, if there's a new react native thing, now you can access it in the attributes.
Adam:We we have a layer in between. So we try to like only explicitly expose the things that make sense. Yeah. Sometimes they don't. And, you know, I, I always keep in my head like a little bit of this trade off.
Adam:I don't want us to be too tied to React Native. So if there's something that I feel is like a little too specific to how React Native does things, We may not want to expose that because, you know, I would love for someone to create a Flutter version, you know, or something like that. And if we're, like, too tied to React Native, that makes it a little bit harder. So, yeah, anytime React Native has a new version, they release some new styling controls. We consider each one or someone on GitHub will write an issue saying, hey.
Adam:Can you expose this? And we'll think about it. We say, you know, is this kind of universal enough? Could this be done in other frameworks? And if so, we will expose it.
Adam:And sometimes the mapping is not entirely one to 1. You know, we will, you know, try to, like, create an abstraction that we think would be, you know, easier. It it it can support the feature in React Native, but it would also be, more universal to reimplement in a in a different, framework.
Lazarus:Yeah. Yeah. And I mean just one, like, big picture thing about UIs on the phone is, like, it's so much easier than it is on the web because on the web you have to plan for mobile. On the mobile it's, like, you don't have to plan for some big screen, like, you've got one UI and that's, like I mean, there's different sized screens but like Yeah. You know, it's it just is and it's so much more solid feeling than I don't know how to I don't know how to, like, describe that any other way than solid but, like, when you have something that's working on an app, it and it's not a web page, somehow it just feels more solid.
Lazarus:Yeah. I don't know why.
Adam:Well, one thing I'll I'll say also on the subject of, like, you know, differences between web and mobile. And this was a challenge that where I felt we had to, you know, obviously inspired a lot by HTML and just HTML, but there are kind of fundamental differences between how a web app or web pages work in a browser versus a mobile app works. And the biggest one for me is navigation and kind of like the concept there. Right? Like, but at most basic in a web browser, you just have a page and let's say you click a link.
Adam:The page you are on is sort of gone. Right? It's destroyed. The new page is loaded, and you see the new URL and the address bar. You know?
Adam:Yeah. So conceptually, of course, you can have multiple tabs open with different things, but, you know, at its most basic fundamental level, you're only ever looking at one page and, like, all the context is there. But in a mobile app, you have, like, a much more sophisticated and customized navigation hierarchy. Right? So when you tap a button in a mobile app, likely, another screen is kind of sliding, over that other one.
Adam:Right? It's sort of like a new context, a new screen. The other screen is still there. Right? And it's still
Lazarus:it, basically. Right?
Adam:Yeah. They stack. Right? And you can see if you sort of use your thumb to, like, navigate back, you can see both screens at the same time. Right?
Adam:Then there's a difference between, well, when do I show a stack versus I open a new model, right, which is kind of a new context where I've opened a model. Now in this model, I can have a separate stack. Right? So I can go back and forward in that stuff, or I can dismiss the model to close all of those screens. But, again, like, you can get into a situation where all those screens are in memory, then there's tabs, right, which is, you know, I'm switching tabs, and I'm getting, like, a whole different context of, the stacks and models there.
Adam:So Right. Whereas, in the web browser, you know, you basically just press a link. It's gonna reload in in that page. We needed to get a little more sophisticated and nuanced. We define the navigation and then how when someone interacts with an element.
Adam:Yeah. What are we doing? Are we pushing a new screen on the stack? Are we opening a new model? Is something else happening?
Adam:So, that was one place where I think yeah. Going with our own syntax, not just trying to, like, reuse HTMLs and web views gave us the ability to create something that, you know, to your point, feels more solid. It feels more like a mobile app should because it it's, embracing those paradigms versus trying to shove just a web page into a mobile app wrapper.
Lazarus:Yeah. And then this is like has been sort of my guiding principle on this also. Like, I just don't I don't want it feel like a web page put into Mhmm. You know, it's just I've used plenty of those and you can just you can tell and there's, you know, there's something about it that is just not quite right, and Mhmm. When you have that kind of and you, like you said, embrace it and you embrace the navigation and the swiping of stuff, you know, like if you want to edit something you can like have a swipeable hidden stuff and and the way the modals work, you know, it's like using these tapping into these native things.
Lazarus:There's just Yeah. Mhmm. It's great. Like it's as a web developer who spent all this time fighting with this stuff on the web for so long, seeing one of your apps seeing one of your sites or your ideas sort of come to life in a real, like, mobile app, I mean, it's it's awesome. Yep.
Adam:Mhmm.
Lazarus:You know?
Adam:You just mentioned, the swippable thing, so I'll just do a quick plug for, the Hypermedia Systems book. In it, there's, a couple of chapters that I wrote. So the first one introduces sort of this concept of hyper view, the format, and a little bit about the client. And then the second chapter goes through and reimplements the contact app that, in the earlier chapters, Carson described, built using HTML. And then in the 3rd chapter, I say, okay.
Adam:We just kinda did a straight port of this contact app to mobile, but it doesn't feel, you know, like it's mobile first because it's still essentially, like, tapping things. Right? And, so then I get into, okay, let's extend the client and bring mobile capabilities to it. And swiping is actually one of the examples. So there's a list of contacts.
Adam:How can I kind of, like, swipe on it? Oh, yeah. Sorry. I just
Lazarus:I wanted to make sure this was, I I use this underneath my computer at all times. Nice. Just to make some plug. Anyway, I am listen so that yeah. So you you got the swipeable
Adam:So, you know, a a conceptually, if you're thinking about just, like, declarative, like, let's say, you know, in the HTMLX, oh, I wanna do a swipeable thing for mobile web. Well, you have to start thinking, oh, I'm gonna have to, like, do all this JavaScript stuff and, you know, it's gonna get complex and, you know, my beautiful declarative HTML is gonna start to look a little bit messier. Right? So in in the book, in that chapter where we talk about swipe, I basically show how I would design starting with the XML to represent something that's swipeable and, like, maybe the actions that get revealed. How would those be represented?
Adam:And then how do you create the custom component in React Native but hook into, like, you know, all the, like, behaviors and interactions to support it in a way that is very extensible. It's not tied to any specific feature, so you can reuse it across the app or, you know, have this as a community thing. So, I'm glad you brought that up because I do think, yeah, swiping to reveal actions is, yeah, like, something that people expect on mobile. We don't put it in the core because, again, it might be, like, a little too sophisticated for that, but I think it is very easy and kind of shows the power of the extensibility in Hyperview.
Lazarus:Yeah. So so, I mean, like I said, when I I've, you know, I've read the the Hypermedia systems book, but the Hyperview stuff, I I feel like at the time I didn't have the context in my head of like, okay, what is this? So now it's like, I'll be able to read this with a totally different mindset. Also, I'm like, you know, like I said, I don't I don't want to be too influenced by it until I've kind of worked through the problem myself also because I think Yeah. You know, my my approach to some of these issues, of like, oh, yeah, how do you it sounds just similar where you're thinking from the XML first.
Lazarus:Like how do you how do you model the data in a purely, like, conceptual way? What's the ideal conceptual way to model this data, you know, a swipeable feature or, you know, something like that. And I just think that's, you know, this UI can be thought of, you know, hierarchical and and with attributes and with variations and all this kind of stuff. And so starting there, starting with the API, it just seems so smart. Yeah.
Adam:You know,
Lazarus:I mean that that's really kind of just and then from there, hopefully, the the way that you implemented in React Native or whatever, you know, Flutter or whatever, it's like, that will feed from it, but it's like if you have that API correct, that just is a huge benefit.
Adam:Yep. So So pretty much any time, you know, I'll give you an example. If someone wants to check out some of the discussions on our GitHub repository, there's one, but I I think has been kind of the most challenging and interesting for me is, client side form validation. Right? So this has been typically, you know, something that the kind of SPA, you know, React JS kind of systems, they're quite good at this, right, because they have a model of the data and they can kind of define, you know, whatever logic they want to happen as you're, like, you know, typing into an input field.
Adam:Right? And they can do kind of hindsight validation. Really, if you're using HTMLX Hypermedia, the default is to say, well, send it to the server and let the server validate, you know, kind of replace the form in line so you can see those those errors. And, you know, we do that, and, of course, that's good. But, you know, there are cases where getting kind of more as you type validation is just a better experience for users.
Adam:Right? And I think, in the book, I think, Carlson touched on some ways to do that. With Hyperview, we kind of are running into the same issue. We think, yeah, it would be great, but how do we sort of stick with XML and be able to declare validations in a way that is very declarative? You know, start with XML.
Adam:How do we think about defining these things here, without having to, like, build any logic into the app and, again, how to make it extensible? So we're very close to, I think, shipping something, but you can see the conversation just going on for a long time. We were looking at, like, okay. What syntax makes sense? Do this.
Adam:How is this extensible? You know, what are other people in the community doing? Let's make sure that that's kind of fits in with with this model. So to me, that's been one of the features that has been, yeah, the most interesting to work on. And starting kind of first with the XML, what we want to, you know, what we want to be able to express with it and then working backwards to how to implement it.
Adam:There was, yeah, was very interesting.
Lazarus:Yeah. I'll I'll see if I can if if I can find that or if you can send me that, the link to that that GitHub issue because I think I'll put that right in the in the notes on this. Yeah. So so I guess, like, in the in the big picture, if somebody was, like, listening to this and they've been thinking about maybe building a mobile app or like and and the thing I what I've been calling them, these sort of apps that I've been building along, you know, it's like you have a web app. I've been calling these companion apps because I don't necessarily wanna put my whole web app into, you know, depending on what your business is.
Lazarus:Some of it's all gonna be mobile first, but my stuff is web first. That's the thing that people sit down, they do their work, but I want them to have a phone with some some additional info. So I've been calling companionals. But if someone wanted to, you know, create a mobile app, like, can you describe the process from starting with nothing that you know they just they they go to the hyperview.org site and and so what's what's the whole process look like from like 0 to you know having an app on in the app store?
Adam:So yeah. And I I wish, this part can be simplified, but, what I would tell people now is, yeah, go to our website, download the HyperView repo. That repo contains kind of the core library, but it also contains a demo app that showcases pretty much every feature available and the community contributed. Nice. That demo app is built using, the kind of a framework in the React Native community called Expo.
Adam:And the way to think about Expo is that, you know, they're trying to, yeah, simplify the process of getting started with React Native. So rather than us developing our own system, you know, just kind of trying to piggyback sort of what XPEL is doing. So, you know, so you have an XPEL app, which has a lot of niceties in terms of packaging the dependencies and having a command line for building the apps to to release for iOS and Android. So, if you download our demo app, you can start all you can do is, like, change that entry point URL, point it to your server, and then follow the expo instructions to build iOS and Android. You know, that's kind of the minimal amount of work you would have to do, starting with our demo app, which is already configured with some React Native stuff, by using expo to do the release process.
Adam:So, you know, there's, like, a little bit of a a pickup there that you have to start with Hyperview and then transition to, like, the Expo docs and follow their docs to to, you know, figure out how to publish. And of course, their docs will also cover well, if your intention is to distribute through the stores, you'll also have to, like, you know, kind of sign up for the Google Play Store or the iOS App Store, become a developer, jump through some of those things there.
Lazarus:That that's sounds a little bit less
Adam:than the one time thing. I'll just
Lazarus:I'll throw that in there, like time thing. Yeah. I've done that before and Mhmm. And you have to keep up with it, pay $99 a year to be an iOS developer. You have to create your app in iOS first, and then you can get a actually, I don't know if that I assume that's true for this too, but you get a bundle ID and then you can bring that into your project and only then will it sort of compile.
Adam:That's what I think can can help when, you know, once you have these IDs and things like that. So, you know, I wish the upfront, story was a little bit simpler the way, like, you can just drop in, to the HTML script tag and get started. Yeah. Unfortunately, you know, there's gonna be some upfront to actually get the app into the hands of users. But I think
Lazarus:A lot of it is not your fault.
Adam:Yeah. Yeah. Yeah. We can't really avoid that. I think we could probably improve our documentation though on, on how to make that work.
Adam:You know? Gotcha. Yeah. Of course, I I tend to focus on, like, the cool parts and the unique things and, you know, maybe downplay the, release process a little bit. But, you know, I think that the good thing is, like, once you do get that app out there, you know, and it has that entry point URL, then you can really do a lot just server side just by updating your back end server that that URL points to.
Adam:You know, you can new screens, you can completely adjust your styling, you can change those interactions, then you only would have to update the app and release a new app through the stores if you're adding some of these custom components in React Native. But if you're not doing that, you can, you know, release and iterate on your app as much as you want.
Lazarus:Right. Using using just the XML and not even sort of you know. Yeah. No. I mean that's the beauty of it.
Lazarus:That's that's the dream and and it is a lot of work to get that first app up in the store and to figure out the bundle stuff and all these other things and you know I haven't done any of the x what was it called? X, x, shoot, the system to no. Not x code. But I mean, you have to do that too. But, but yeah.
Lazarus:You know, getting the demo app up and running on the that's probably involves installing node and sort of, is that is that like a node based package, like use NPM to kind of bring in the That's right.
Adam:Yeah. Yeah. Okay. So in the demo app, yeah, there's just, you know, some instructions. Yeah.
Adam:You use, NPM to kind of download the dependencies, and then, you know, there's some command lines to run to to start everything. So if you just wanna Yeah. Develop locally, you don't have to do all the stuff we talked about. You just need to,
Lazarus:either
Adam:have an Android emulator or iOS simulator locally. And then, you know, using the XPO commands, you'll be up and running and iterating pretty quickly.
Lazarus:Nice. Nice. And that's all, you know, for the most part, a one time thing. You know? You you get that.
Adam:That's right
Lazarus:get that in place and then you've got your sort of hyper view, stuff there and then you can build as many apps as you want from there once you have that sort of development environment set up. Sound right? Yep.
Adam:That's right. Mhmm.
Lazarus:Nice. Awesome. Well, I mean let me think. Is there is there anything you feel like that we didn't sort of touch on for, you know, anything you want to sort of mention with with Hyperview in general? Do you think people would be interested to hear?
Adam:So one thing yeah. So I think, you know, I think a lot of the listeners are probably, you know, pretty familiar with HDMX. So I will say, you know, like, HDMX and intercooler were a big inspiration for the, ways to do interactions. So I think a lot of our conversations so far has
Lazarus:been actually
Adam:why we haven't talked as much about, well, what happens when I press this thing? Right? So a lot of
Lazarus:the
Adam:ideas from Intercooler and HTMLX around, well, you know, I'm getting a fragment of HTML. Do I append it? Do I swap it somewhere else? All of that is built into the sentouts in hyperview. So, you know, all of that is kind of possible and sort of native.
Adam:It's not, like, a separate library. Like, HTMLX has to be on top of HTML. In the hyper view, these are sort of first class concepts.
Lazarus:And So do you have, like are you giving things IDs and you have targets and you have sort of, you know, different types of triggers and and that sort of same Exactly. Same mentality.
Adam:All of that would feel very familiar. Yeah. All of that is there. So one thing that,
Lazarus:actually
Adam:in the, lecture I gave, Carson pointed this out. So, initially, because I was just taking inspiration from them, we were doing the same thing in hyper view where you would just add extra attributes to the elements that you want to make interactable. But Right. Then I realized, like, well, that's just kind of the limitation in HTML because you can't easily define new elements. And it causes some problems like, what if when I press this thing, I want multiple stuff to happen.
Adam:HTML kinda struggles to express that by just adding attributes.
Lazarus:Interesting.
Adam:I realized in hyper view, well, let's just create a new element. We're gonna call this tag behavior, and we're gonna you know, the behavior tag will be directly nested as a child under the element that we're interacting with. And then we can say, okay. This behavior says, you know, when someone presses on trigger, load this content from this h run and then swap it here. Well, we can have multiple behaviors now.
Adam:Right? So maybe when I press, I want 2 different things to happen, or maybe I wanted to find that if I press on something, this happens. But if I do a long press, something else happens. So we have this, behavior syntax, which was initially inspired by HMX, but has evolved to be more painful in that, you can have multiple behaviors attached to the same element that can either have the same trigger or different triggers, and that gives a lot of flexibility. And much like the UI, these behaviors are also extensible by writing some React Native or, JavaScript code.
Adam:So, you know, you could define your own behavior to start a phone call, for example, or to, switch to another app or to, you know, show some kind of push notification. So that's another good point of, extensibility that we didn't talk about, but I wanted to mention because I think, it's site it's, like, at the same time, you know, probably familiar to someone who's an HTML developer, but also, I think, you know, pushes what a chypremedia based format is capable of expressing in terms of interactions.
Lazarus:Yeah. That's cool because then you can I mean, you know, besides tapping into all those sort of new triggers and new possibilities on the phone, also because I've I've come across that with using h t m x where it's not that uncommon that you need 2 things to happen, you know? Yep. And and so I you know, you get you figure out workarounds and stuff. Yeah.
Lazarus:I don't remember what they are right now, but I mean, you know, whether maybe you're sending using like a swap OOB or something to, like, send data back in 2 places, but, like, really what conceptually, you just want 2 things to happen. So I think that's a that's a really interesting, you know, way to think about it is is sort of so so so you just you can have, like, I'm trying to, like, picture the syntax and, like, you know, maybe that's too in the weeds, but, like, you said you you define behavior. So is this an attribute and you just like behavior and then you add an attribute and that behavior name of the attribute has to match Yeah. One of the behaviors that you have in similar to a trigger but you can sort of just do as many as you want.
Adam:So let's say I have a text, right? So I, in hyper view, text is, an element, right? So it's like, you know, open, open tag for text that I say, click me and then I have the close tag for text. So after the open tag for text, you have another tag in there called behavior. And that behavior can have, like, trigger press, load this h ref, you know, append it to some other target ID.
Adam:Right? So it's like and nested in that text, tag is a behavior tag. And because it's a direct child of the text, it's gonna apply to that text. So, you know, the behavior is what's, defining that interaction, and you can have as many of those behavior tags in that text, element as you want.
Lazarus:Because they're not an attribute.
Adam:Same trigger, they can have different triggers. Yeah. So that's that's
Lazarus:something to
Adam:it. Yeah.
Lazarus:Interesting. Yeah. I'm trying to think how that would work in in HTMX, you know, because you it's but everything is sort of attribute based. You know, you don't necessarily have any sort of tag processing in HTMX. You could, like, probably hack your way through it and, like, you know, have a a tag with a certain attribute on it would count as a behavior for the parent or something.
Lazarus:Like, you could do something crazy like that, but
Adam:Yeah.
Lazarus:It's it's not exactly set up for it.
Adam:That's right. Yeah. And I think it's a little bit of a limitation. I mean, I think the HTML 5 spec and, browsers are kind of lenient if you wanna create your own nonstandard tags to do things, but, you know, you can get into a little bit of a dicey territory there. Whereas in Hyperview, it's, like, fully supported.
Adam:We also have a full scheme of the validation for these things so you can make sure that you are writing, like, completely correct, XML, including representing these nested behaviors.
Lazarus:Yep. Yep. So so how much of your, like, just percentage wise, like, how much of your time is sort of, like, working on hyper view versus like working on, you know, company stuff that's completely separate and its own business? You know, is it sort of like a big part of your day to day, or is it now that it's built, it's sort of you the community has taken over some of it?
Adam:Yeah. So we have, you know, we're big enough now, to, in store that we can have, like, a dedicated team we call our client platform team. And there's a couple of engineers that support both kind of our front ends for web and mobile. And a big part of, what they're doing on mobile is supporting the HyperView library. So if you see if you go through the commits, you'll see a lot of contributors who are not me.
Adam:And most of that is like the the great engineers on that team who are taking you know, they're leading this push to pull things out from our main InstaWork apps, and putting them into the community. We recently did, like, a huge redesign of our demo app to better showcase all of the capabilities. They're fixing bugs. We have a bunch of features that we've been working on, like an upgrade to navigation. So, you know, I talked about all the complexities of defining navigation and, it gets even more complex if you think about, we want to be able to like deep link a user into a certain place that opens the app into like some nested screen.
Lazarus:Oh, interesting.
Adam:We had an engineer who kind of completely redesigned and created a XML syntax for defining, okay, here's how the whole navigation structure works and lets us kind of, you know, lets users customize things a lot more. So yeah. So I think we're doing a lot of work. You know, my day to day is I I I try to advise and kind of steer the direction and keep the spirit of Hyperview in terms of having a very lean core, making sure it's extensible, and addressing comments from and issues that arise on the GitHub repository. And then thinking through some of these bigger fundamental changes, like, I mentioned client side validation, which I hope will be landing, in a release in the next month or so.
Lazarus:Nice.
Adam:So that's that's kind of where I've been doing. But, you know, I think I found, you know, sort of how you said you learn best by doing and then, like, extracting from that and, like, you know, coming up with your theory of how something works. I think for us, it's also been good to focus on developing the InstaWork apps. And when we run into an issue, like, we wanna do something in our apps that's not really possible or easy with Hyperview, then we say, okay. We can't do it with what we have now.
Adam:Can we create an extension to do it, like, either a custom component or a custom behavior? If we can, that's great. If we can't, like, maybe with client side validation, then we say, okay, how would we do it in the library? And I think this, you know, development is being led by our own problems and needs. And I think that's helped us, come up with solutions that I think a lot of other developers would encounter, just in a practical way versus, you know, being sort of driven purely theoretically by things we think are nice to have.
Lazarus:No. I mean, what I think that's that's really a great model, for open source in general where you are you're building a tool to scratch your own itch, you know. And and you've and not only that, there's a monetary, you know, component of it where, like, there's people who just, like, toil endlessly on open source projects, and they devote their light you know, a large portion of their life to it. But if it's not directly tied to something that's helping their business or helping their income, it's sort of I don't wanna say doomed, you know, but it it has this, like, cloud over it. And so I I feel like this model of, like, you have a successful business, you're building a tool, but, like, putting that back into the community, like, I'm gonna build this tool so that it works for us in a great way, but I'm gonna separate it so that I can now open source it.
Lazarus:You know, that's actually how Laravel, got started the guy who created Laravel. Mhmm. You know built built it first for his company, but he he had it
Adam:in mind.
Lazarus:I'm gonna use this separately for other projects. Yeah. And you know eventually Django was saying, Jazza. Jazza. Mhmm.
Adam:Yeah. I mean, it's it's a group model. Like a local local newspaper. They were using it to run their, like, news website and pulled out the framework from there.
Lazarus:Yeah. And it's like you come across things and and you know, it's like, you don't just wanna fix them because, oh, it'll be good for people, like, no, I need this. I need this to work and I need it to work in a good way. And so it's like Yeah. It really makes it makes it work nicely.
Lazarus:Yeah.
Adam:That's right.
Lazarus:Very cool. Alright. Well, so I mean I think, you know, I think maybe, I want to respect your time, and I I just want to sort of, thank you very much, like first of all for putting this project out into the world. I think it's super cool, and, you know, I haven't I haven't used it yet because I and now I'm kind of deep in in my own thing, but I think I'll probably continue that and then sort of take a closer look at some of the concepts because you it sounds like you've solved so many of the problems that I'm about to encounter, doing my own project. So, it's gonna be super cool to, to look into those more.
Adam:Oh, thanks for having me and, you know, shining some more light on the project. Like, I, you know, I definitely think it's cool, and I I think, more people should be using it. So I hope, yeah, more people can find out about it. And like I mentioned before, we're pretty active, in discussions and issues on GitHub. And, you know, also if people just wanna learn more, hopefully, we can share the link to the lecture, Montana State, and then also the link to the hypermedia systems book, which, you know, is completely free to read online.
Adam:So you don't have to buy a copy. You can get all the content there.
Lazarus:Yeah. Though the copy is cool.
Adam:Yeah. But, yes, it is what
Lazarus:you can totally buy everything. It's all free online as well.
Adam:Yeah. I I realized, yeah, I should be promoting selling the book.
Lazarus:No. Actually, I like the way that has sort of been handled. It is like if you are the type of person who would like to just read it online or can or don't have the money right now, like the information is there. But you know, if it's helped your life and, you know, it's nice to have a physical copy, so then it's available as that too. So.
Adam:Yeah. Yeah. You could probably do a whole other podcast about that decision and the process of, publishing and self publishing, might be fun to talk to Carson about as well.
Lazarus:Yeah. No. I think that would be fascinating. But, but, yeah, so thank you very much for talking today. And, you know, I'll I'll include all the the whatever links we can here.
Lazarus:And, you know, I I think So I'll just like the big the big picture for me, I think, is like, the the onboarding of the the hardest part right now for hyper view when I was looking at it is probably the onboarding and sort of what you've sort of described from it. But, I mean, I'll just like the plug for this the hypermedia way of doing mobile, like, you know, I've had a small taste of it working on my Flutter project and, like, to anyone listening, like, Hyperview is obviously much farther along and and is gonna have, like, a lot of stuff and has active apps out there in the world. People are using them. If you if you as a web developer get a chance to build an app, in this manner, I think you will love it. Like, it's gonna be a complete game changer.
Lazarus:So, anyway, that's my plug for for Hyperview also.
Adam:Thank you. Yeah, and yeah, I totally agree.
Lazarus:Yeah. Alright. Well, thank you very much for joining and, I will I will talk to you soon.
Adam:Thank you.
