Talking LiveView Native with Brian DockYard

[Music] hello yeah hey folks ah I'm even live works hey folks let me know if you're there um I'm just waiting waiting for Brian also to to join our call and uh then we will discuss life you native and maybe code a little bit together let's see I got my my phone here and everything hello thanks for joining hope you're doing fine how you doing today almost weekend eh so that's that's exciting yeah I'm just setting up my phone here let's see okay ble apply visual effects interesting yeah thanks LVN is exciting indeed yeah I mean I oh well yeah you can hear me but the call can't hear me yet but yeah I uh I like life un NE too like you know still we need to write a lot of Swift Code which was surprising to me um but it's it's okay like uh Elixir still makes it very easy to just like create an application update application that kind of stuff well let's see uh oh I'm in spaceship let's see what Brian has to say see all right I'm in a spaceship with a 10 with a oh there you go now those AR that great though all right what is happening Moonlight oh wow fun I should do this all the time was this a strawberry oh I'm a talking strawberry now H that's hilarious all right I think I think I will use this filter I can also be a puppy okay oh man this is amazing cool I can also gave give myself a second like yeah if I don't have a hat ready now I have a a cool tro head yeah awesome oh wow it's a whole 3D thing what's happening here I don't know okay no I like the story the best yeah awesome yeah oh man this is fun this is too much fun yeah I'm just waiting for uh I'm just waiting for Brian to join here we go that's me all right yeah and how you doing everything everything all right stream this is running I think right excellent have you switched to Blue Sky yet you should all follow me in Blue Sky we should all just move from Twitter over to Blue Sky that would be great yeah also don't forget that next week membran is going to have their live streaming week where they have really exciting stuff coming up like y for example he's talking uh Chris mord is also talking let's see the 2024 agenda um no that's a conference they're hosting but uh where is it here remember in stream where's the the live streaming week okay Brian isn't here it sorry about that he uh he's a little delayed he has to he just dropped off his kids at school and is trying to set up his uh his um audio whatever setup bu hey on where where's the the live streaming thing come on organizer yeah this one the stream week ah it's from uh web RTC this one yeah so next week it's going to be the membrane stream week I can highly recommend it go check it out it's free it's right here um Y is going to talk on Monday it's going to be exciting then Matos one of the core the creative membrane actually uh he's going to talk about boom box which we've used for our previous project then Chris mord is um live coding a twitch clone so but he's using web RTC not what we use we use boom box and like an rtmp and hls stream we got yatan creative Life Book so it's going to be interesting as well and we got my good friend and ex colleague philipo he's talking about real time at super base which is also very exciting because they have a lot of people um yeah I'm just waiting for Brian here I don't know they have a lot of people using real time and all of that is powered by by Elixir so that's exciting too yeah so that is next week I think you can also sign up for updates here although I haven't received any yet maybe they're in the spam folder I don't know um but yeah they do have some some emails there but yeah next Monday 700 p.m. all right that's Brian let's hello hey Brian um give me just a moment no problem my headphones hold on yeah no worries I'm also dialing in still the audios levels here as a question to the chat let me know when you can whether you can or cannot hear brownan when you talks I uh it should work but I'm 100% sure see I got four people on YouTube Hello to YouTube all right I'm press on Twitch hello to Twitch course 35 people on Twitter I don't believe that hey Peter hey Brian yeah I think I may go without video okay sure might just be easier yeah all right so let me see yeah how you doing Brian good how are you I'm fine thank you um all right I think the yeah the chat can hear you that's great well thanks for joining me today um you we wanted to talk about live view native a little bit right we we played around with it on Monday and already got quite far and my understanding is you watched the live stream afterwards and uh yeah so so just one watching the live stream like how how did you feel about life you native and uh and what you created over there I mean as uh as someone that's been attached to it for this long it's always good to see people start to use it and adopt it um but I felt some of the kind of like blockers you were running into yeah and I was like just do this while I was watching it and I was like okay yeah we could probably be improving parts of the documentation um that's fine I think that there you know a big part of like live you natives adoption story I believe is just a fundamental um educational process on what it is we're trying to achieve because from what I understand um I I've heard that there are a few other like big fan companies that have done some server driven UI on Native but no one's released a framework like this and nobody has um kind of form ized it in a way that we have right so one of the things that you said I I I took time stamps so we can go back if you wanted to like play back your video but I just want to be able to like reference certain things yeah sure sure go ahead um but there was um let me just hold on my organization my time STS isn't great yeah uh let's see here where was it okay so at like 5739 you said exactly what it is that we're hoping people walk away from live you native was which is you said it seems like web development but it's not and that's exactly what we're aiming for that's the design of live you native because we're not trying to reinvent everything right we don't like one of the earlier versions actually up until about almost a year ago live VI native was a very different framework um it was not achieving the goals that I had set out for it to achieve which is that a live view someone that is experienced building live view applications should be able to easily start building live view native applications because we were just kind of using live view for a little bit of the State Management stuff but all the organization of the templates and how those got rendered there's all these deviations on how layouts were being rendered that just was not it was atypical for how you're used to doing it in Phoenix and in what way um so first of all um we got a PR well Jose wrote a PR for for live view um that I think was sitting there since uh about four or five months prior to um us using it and it's called render with what that does is in the on Mount hooks for a live view you can um declare a function uh reference okay and say instead of using render uh one like in inside this live view you're going to use this other function reference to actually delegate uh rendering to and so that was a huge thing that we needed unlocked because otherwise everything was happening inside the same live view right I see and you would have um uh we would be doing pattern matching like out of the assigns um in the render function and for some people are like oh yeah that's easy that's nice and light but and and this is I won't look like reference the Tim stamp on the this but you did uh kind of raise the question on why it is we have so many templates for different things like why why is it that we have a format folder like Swift UI that the templates are going into instead of the templates sitting alongside the the live uh the render component exactly and the reason for that is because live view is hard-coded for HTML and like through through and I've been trying to like push a nudge and get that relaxed as as much as I can get away with with um but imagine this for a moment like you have your live view and then you have a template for HTML you have a template for Swift UI but then you have a you have a swift UI IO like iPhone template you have an iPad template you have an Apple TV template you have a you have an Apple Watch template you have apple Vision Pro template and then you have all the templates for Android it's going to turn into a nightmare where it's just like a ton and ton of template files that you could theoretically start adding in and so that's the reason why we decide to pre- optimize like the actual directory structure there yeah is to like force people towards an organization I mean that's also how Phoenix uh the controllers now work more or less right got it from yeah exactly so I I like that actually I always uh used to like you know move all my templates into one subfolder so to say um so I think that makes sense yeah it it was just interesting to me because when you generate the Life View native like native Life View whatever you call that um it generated like a folder with only one file in it so what you said makes total sense but only that appeared to me later that uh you do like the plus you know iOS uh watch whatever um so so we have a blog post on that and it's covered somewhat in the documentation the uh like the the naming convention around the the format segment of the file names the templates um we could go in ahead and generate like in the Swift uh folder a template for all those different device types yeah but you won't need that maybe yeah like like keep in mind that Swift UI can kind of work in two one or two ways um it it has and Jetpack kind of the same which is Android's uh composable UI framework so um Swift UI an application written in Swift UI can theoretically run on any uh Apple device m but there are going to be different ways that you want to style and represent information on the screen but you could take like an application that you've built as is in for an iPhone and then go and run it on an Apple TV like the views that some things just won't look right a lot of things won't look right because it's a completely different form factor but that's where we kind of were like airing on is that like look we don't want to overwhelm you when you first install it with a ton of templates like here's your single thing and odds are your problem going to be building for iPhone immediately yeah and and so it's kind of like a you know there was a decision there on which way do we go and I'd like to air more on the side of Simplicity than just saying hey you're new to this let's overwhelm you with everything yeah no that that makes sense to me definitely I mean one I think the biggest learning I took from the live stream is a little bit that although you write the code in you know like a well a NS template but you know which kind of looks like a heeks template and you you kind of reuse your live view and everything so everything filed very much live vi v but then what I realized eventually is that actually you're writing a swift UI app so the code you're writing the Styles you're writing nothing of that is in any way related to you know the usual web development like just HTML and and Tailwind CSS you know um well so so you had that comment on tailin as well and what the the the purpose of the sty sheets um that we have in there is yes to break apart because in in a swift UI view typically if you were to look at actual Swift UI code you're going to find that every single view has these modifiers which is Swifty wise version of like CSS styling or styling and they end up being a lot like you can some views in a very complex or uh mature application can have like 30 40 modifiers applied to it and um breaking those out into individual classes that we can like dynamically call and actually do some sort of interpolation into is very powerful but this actually sets up the framework for someone to go and create a Tailwind like framework on top of it right so we have an entire uh stal she import system as well and the way that we modeled um the retrieval of class names and style names out of templates is exactly what Tailwind does so much so that I actually stole the Tailwinds uh Tailwinds Rex for actually parsing in and um an earlier they have a like a I mean my re X fu is pretty weak at this point but um they like the modern Tailwind library has a extremely complex reject system and so I went back to one of the earlier ones where it's just like a catenation of like 15 different rexes and that works for us for now right um but similarly to Tailwind you can't break up uh class names like you can't have Dynamic class names defined in the template they have to be whole strings MH and in our stylesheet that sheet sigil that you're writing into yeah this get that's a macro that gets compiled down to an actual function and so what what gets emitted is just a class function and the arguments are a pattern match on how you defined the uh the class name in the sheet itself and so we rely upon the lection know pattern matching we we extract all the single like the uh um you know the whole name names of class names and uh style well modifier Styles out of the templates and then we just iterate through them and pass them into the class function it whichever one matches gets dumped into our Styles sheet and then we have a fallback at the end that just is it ignore and so this is a way that we can actually not just um have a nice clean stylesheet per format in our uh projects but someone can go and write entire styling Frameworks similar to tailwind and distribute that and then you can just do an at import at the top and we use add you know we kind of bized the uh uh the module attribute in the at import um uh function but it's to kind of again lean into what's familiar we don't want to go out and say Hey you have to learn everything from top to bottom here we like we know that most uh web developers in the Phoenix ecosystem are probably using Tailwind um at the very least it's fairly familiar to them we know that most people at this point are fairly uh they understand a lot of the ways that live views work and so every time that we deviated like away from those in favor of what may be a little bit better in like certain cases it ended up biting Us in the ass and so like my my my I I prototyped live VI native like early on back in uh 2021 or so and then I handed it off to the team I kind of managed the team from there but then it wasn't really going like kind of I I sometimes as a I have a hard time getting like my thoughts out sometimes and expressing them and saying hey this is like my vision for it or sometimes that the you know individuals just aren't getting it um either way it just wasn't working and so that's why I part of the reason why it took so long to get it out um because there were a lot of lot of kind of feeling things out in particular directions seeing what worked but it just took time to kind of get the project realigned to where I felt like it was something that had value that was easy to learn um but was really where I wanted the framework to be yeah well I mean it it it feels I mean I also followed along the the development at least from what you shared at at different conferences on on Twitter and everything uh so yeah I also saw that you took a you know different um like directions every now and then you change direction but I like from how it felt uh working with it it it felt like once you get behind it that what you're actually building is a swift UI app and then you just kind of um what do you call that like uh hydrate the the data in there you know so so you have like a separate live view uh gen server running and then that connects with your so to say Swift UI app and the only thing that you do that you you know what you what you um exchange then the messages you exchange exchange between these two is kind of just like updates to the data and the same way that morom updates the HTML on your browser the same way life you native then updates your Swift UI app right yeah and and that that was an interesting understanding because yeah for me as a web developer it always felt okay like it kind of felt like magic but whatever change I'm made so the the browser HTML always felt very much in sync with my live view and for me it was never like I never realized that actually these two things are two separate things and if I change my HTML on the side it might go out of sync with my life view State because I mean why would I why would I change my my browser state right or like the HTML I I would never change it manually sometimes with JavaScript but in general I would not change it but on Swift UI that becomes much clearer where we had that issue with the table view uh Sor the tab view um where like we we we build a tab View and then in Swift UI actually the tab changed you know when we clicked on the second tab it actually went to the tab but that change was not uh sent back to our life view so these two states at that point they deviated and that was an isue why um so you were looking at one of the cookbook examples and there was the PHX change event that's on the tab view exactly so we had a conversation with Chris about that and PHX change in Phoenix um we like what we didn't want to do was introduce a separate set of like bindings like LVN Dash whatever because now you'd have a mix of PHX Dash and LVN Dash so we wanted to lean into what Phoenix already offered but there are just things that you're going to be doing on Native environments that those type of interactions don't exist on web and so PHX change is more or less um kind of owned by the form bindings in live view on the web yeah but in the case of the tab view like you are changing a state there like locally and we wanted to be able to trigger that and like as an event uh server side um and so the pH exchange event will trigger event server side and then that can allow you to conditionally render into any of the actual tab view bodies but what you trying to do is actually something that we're currently blocked on um you were trying to represent each of the tab view bodies as separate live views yes like know routing to them directly so uh we uh Carson who's the lead Swift DOI Dev uh he and I just had a call with Chris on uh Wednesday about this so what's currently um like live view can't support like because the browser has one URL bar like what what you're treating it as a separate like separate browser tabs where there would be separate live views being instantiated and you could technically do that you could like inside um you you could instantiate a separate live view but that would then get a separate socket going a separate web socket connection you don't want that that's not performant like that's how you can overwhelm the server if everyone has like six seven websocket connections going on everything should be over the same socket um and so so live you does not support a method uh where you can manage multiple kind of navigated two states um rendering multiple live views what you can do is you can call a live view from a live view like a sub live view yeah um or you use a live component we don't support either live components or sub live views just yet and and so I think that the way that we kind of ended the uh discussion was live components were the most likely um best choice for rendering into those tab views those bodies of those tab views individually um the uh but we have some work to do on on live components like I I held back on live components for a couple we we support function components I held back on live components for a couple reasons the first of which was I didn't know what direction I wanted to go with it so if I were to treat them similar to what we did with the live views where the idea is that you're sharing event handling in State Management for all connected clients and there's significant like optimizations you get from that right like if you already have a a live view a pretty fairly mature uh live view web app built MH I think you could probably see now like adding a native application to that and just leveraging all the existing state management and vent handlers that that are there means that you you're going to be able to build a native app pretty quickly yeah definitely provided that you know how to design for the Target yeah Andi yeah yeah that that's all I mean that so as aside for a moment um that's something that we just can't get past in terms of like being able to make it simple uh it it it has to be I believe this way like we could have just like puted to say hey we're just going to do a web view or like cheat the way like Hotwire uh Native did or phone Gap but they always feel kind of crappy like those type of solutions don't feel right they don't feel like they were meant for that device and um and so I knew I wanted to lean into a well for a couple of reasons I wanted to lean into what the first class UI Frameworks was providing MH because you know dockyard is uh I mean we're not a very big company um we try to take on big challenges but we don't have like a ton of money to throw at these projects all the time whereas like something like react native that could be done because meta has billions and billions of dollars that they can actually toss at these things and they can reinvent the wheel and then they own it and then they own you more or less true like you are now in the metaverse for like your development experience and you're towing the company line there um the uh uh but uh for us we need to actually try to be as I'd say cost efficient in this as possible and that means that we can't we don't have the the ability or resources to go out and reinvent the UI framework from scratch Apple's already done that Google's already done that Windows Microsoft's already done that and so if we can abstract those UI Frameworks and represent them in a way that works for live view that was going to be what works best for us yeah and I also I I think there's an argument there that that is actually what works best in the end for the customers of your applications as long as it feels native it it's going to have that same experience as you're expecting like when I'm on a when I'm on an Apple device I have certain expectations as to what the experience feels like I'm on an Android device same thing and you're not going to catch me on a Windows device sorry do they even exist yeah yeah exactly but it's just the way that it goes like we there's the whole like design language that goes with these uh with these device families operating systems that make the average users kind of clue them into like okay I know how to do this because I've done this on another like natively built uh like apple thing before and you you carry that over but when it comes to these like build on Run Anywhere Frameworks you lose that it's always like a compromise on hey I'm gonna uh be more productive in how I like build this because I have to do it once and then I can send it to any Target well the compromise there is that not only compromising experience but as I mentioned earlier like you like how you design within that like device family how you design for an iPhone is very different from how you're designing an Apple TV product so how many react native like Apple TV apps are there like none how many like flutter uh like Vision Pro apps are there there's none because they're not even they're not even compiling for those platforms because they'd have to go out and all this money to design a whole new UI framework around it to Target those individual platforms like your your reach on going with those build ones Run Anywhere Frameworks is actually significantly limited they kind of paint you in a corner to a degree um so that's kind of like why we decided to wrap these UI Frameworks to begin with but let me go back to live component thing for a second I want to finish that thought yeah so we could have uh treated live components just the way we do with the live view in that um the live components can manage State and events um and if we wanted to share that amongst all of the particular formats that can render it we could have done that but we would have requested another Upstream change in live view to do render Del excuse me render delegation but um Justin tormi who wrote The Lax application he was one of our like really early adopters in this and we worked with him to deliver a uh live you native um app for it so this is the chat app if you recall the whole like live view ceiling talk and Justin spent the weekend like here's a chat app it works yeah and I'm like oh we'll do like let's do live unated for that um it was a good use case because it exposed a lot of like bugs that we had like there's only so much you can actually reasonably um anticipate When Something's Cooking like you got to get it in front of people to actually realize oh that you got to change that or that's something we need anticipate and one of the things that we didn't anticipate at the time was uh that you're likely to have like device specific event handlers like there's just going to be reasons for that that you you may want to handle something differently on a native device or you need an need to handle something differently on a native device than you would on the web um and so to get lacks done we had a lot of kind of namespaced like swiftui Dash event handlers in LAX and I went through it later I was like you know what this feels like an anti- pattern to me we shouldn't be having these format specific handlers and that's where I started to think like maybe the live components is where we kind of deviate from the the convention of the live view so the live view permits you to handle and manage State and events but then just delegates the rendering to a format specific render component or in the case of HTML you're rendering within the live view okay but with the live component what if you know those are just entirely just specific for that format the same way that a function component would be specific for that format anyway so so um there are still some things that we need to do within the clients in order to enable support for live component but this is a much bigger project than just the live components because what we found along the way is You know despite so live view was actually invented at docyard when Chris was here and it's been I've seen it kind of from birth to where where it is at this point and um despite that there's still a lot about live view and despite me like building live view native there's still about live VI I'm like oh I didn't realize that was in there and so like there's uh there's moments where in uh slack or Discord or on Twitter someone will hit me up and say hey can it do this like does it work with this PHX are uh uh attribute or whatever type of live you feature I'm like I had no idea that existed so it just at some point it felt like whacka where we were constantly kind of gathering requirements from the community and things that we were overlooking or didn't have insight to or just forgot about and this felt like a bad way to develop like we were kind of like playing catchup um on little like Tic Tac things all over the place yeah May so yeah let me just finish this this one thought because it's going to bring it to conclusion um there is a uh I don't know if everyone follows the live VI project on GitHub but last February uh I think it's Stefan or Stefan um who joined the live view team and he's primarily tasked with kind of taking all the JavaScript work off of Chris's shoulders he built an end-to-end test suite for live view yeah which uh launches playright and it will launch a bunch of headless browsers and it'll actually like launch a phoenix live view server in the test suite and it'll run through and assert that all the behaviors for live view are correct through all these browsers we've done is we've taken that end to-end test suite and well so in live view itself we have two aspects of it we have the client code that's written in the native language so in the case of Swift UI Swift jetpack it's cotlin but everything that isn't directly related to that individual client we've extracted out into a common Library called live un native core and live un native core handles the network layer it handles like all the live view programming model stuff the merging the like the the diff patching um like events flow through it so basically everything that is if you want to go out and create a new client you can leverage live native core and get 80% of the work done for you automatically without having to just redo everything again right and so what we what we've done is live native cor is written in Rust we can compile this Library down to wasm and we wrote a Dom implementation and we swap out the JS files in the live view test suite and we replace it with our won compiled file and now we can actually run Phoenix live View's own endtoend tests against our own core implementation and it's giving us effectively just a task list of where we're incompatible or where we don't have something currently implemented and so just like two or three weeks ago uh sebasti who's doing that work he got it up and running uh same thing with the unit tests for the live view JS file um and then we're going to do the same thing with the Phoenix Channel unit test in Phoenix itself um and now it's just a matter of him just going through and uh satisfying the tests which at that point we're going to be fairly compatible with the live VI API and then the last mile there is us taking those end to- end tests and reimplementing them in the UI integration test suets for the clients themselves so we actually run the individual Swift UI client the jetpack client Etc through those test Suites so that when we're at that point then we have a very high level of confidence that we're as compatible as live viewers telling us we are and if we find any places we incompatible it's because that test doesn't exist and we just add it and then we get better okay yeah that's very interesting that you also managed to get these entry tests running against your own uh call basically against your own library and it's written in Rust St um yeah so I mean currently you you already do you already support uh IOS and Android or only iOS so far uh so the jetpack client is um I'd say it could probably have been released by now but we're kind of just trying to get it or finally tuned so it feels a little bit more complete the way the Swift UI client does um for example uh Nelson who's doing that work he's writing all of our components right now and so all the views are covered the Evan handling all that stuff um and there's been a few uh I'd say brave people that have gone out and started to use it yeah and we see it from time to time I think that's great I it's you know it's a double-edge Shore because we haven't officially released it and so I I I feel a little bit odd or it feels like a mismanagement of time for us to support something that we've been clear that is not yet released right because time on that means time we're not spending on something else that is released and um but at the same time it's also rewarding to see you know people using this Nelson's been like great he's been I'd say uh probably a little bit um underutilized in the sense that we've held it back for so long because my focus has been on well in part because I have all Apple products so it's easier for me to personally test it um but also like if if I was Nelson I probably would be not too happy because I've held back the his side of the project for so long um but he's been you know just doing what we can do to get it done and get it ready um but it's been a uh I'd say I think he's he's he's been on the client work for over a year at this point but jetpack itself has been under development from three different Engineers for over two and a half years oh wow now okay um and and so but there's there's trade-offs too so live VI native was developed primarily with swift UI as its use case but now that we're expanding to Android we find certain areas where some of our assumptions on live you native are being challenged and in part that's because of just can I swear on here do you care if I swear I'll just say fing Google I'll just say F and Google and like fing Google's like like means of development where they're just like ah whatever ship it and it's not like it feels incomplete in certain places so jetpack compose is a li UI framework that is in the name supposed to be composable and that's how because HTML is composable markup Swifty Y is a composable view tree that is how like live view uh Works in that we can represent it as a composable markup and then we can do the diffing server side and recompose it right uh in the client but in typical Google fashion despite calling the framework composed there's all these imperative things that happen all over the place where for example if you wanted to do string like a like decoration uh decoration on a text element so you wanted to make it look different like it's not just like the wrote text it's like I want to give it a color right you have to like you have to go down and start coding it like you can't just assign like particular style it's called annotated text and it's a it's a class it's not like a view struct in um in Jetpack yeah and so we went over this over over like Nelson had because it's used all the time Nelson had just kind of baked it into the like our representation of the framework and taken something that was a class and represented it as a view M and that works but it breaks our kind of convention here the line that I've held is that the client itself doesn't go the API scope is only what is represented as a view in that framework okay and so like in the Swift UI client we don't have map kit baked in we don't even have camera access baked in because these are done in other libraries outside of uh Swift UI okay Swift UI is only about like building UI layout and and decoration okay and and so for so we have add-ons for those uh uh for those capabilities but in Jetpack it's just it's a mess it's like it's it's all over the place in part it does feel like it's still actively being developed which it is and so maybe those things come into views in the future but we had to kind of I like I just held my I put my foot down and said look we're only going to represent what can be represented as a view in this framework I acknowledge that this functionality is necessary and so we we took that stuff and we broke them into add-ons as well so like annotated text is add-on but it's an add-on that comes with the jetpack client now so from the from the users perspective it's like indifferent but it it's just kind of like this convention that I want us to hold the line on as hard as possible it's G to make it easier for us long term so the line you're you're trying to hold is basically that you say well uh we have our life you native um jetpack client and that one is only going to implement the as you said the views so the the UI views basically the same as in Swift UI where you only can create like um yeah components so you can only create the UI with it right if you want to have a text or if you want to have a table or a button uh that you would do with swift UI um but then well the yeah so like annotated text is a way to do that but it's not as a proper view like we like so when you were looking at the Swift UI stuff like the text element for us was the text view in Swift UI right like vstack is vstack there is no annotated text view that exists in Jetpack so we would have to invent it which means that future if Google adds an annotated text representation in their uh their uh view composition then we we have a deviant API right we've diverged there where we we no longer able to rely upon the convention of saying here is how it's represented for us and then you can go easily mindmap that and like find the original documentation for that view Upstream in the UI framework because it doesn't exist for for that type of thing but you still need to be able to do that in order to make your application look nice so it's all these like really annoying things that exist in the Google world and it's like if anyone from Google's watching like what the hell like I'm sorry but like Google just Google Drives Me Crazy in this way that they'll have not just I mean I'm going so for a second not will they just kind of just do tire kicking on the community in this way they they'll ship incomplete products they'll um they'll have multiple conflicting projects going on at the same time under the same roof and then most of the time those all go away it's I I ironically of all the three major kind of like device Builders between apple like the Google Android landscape and then Microsoft M Microsoft looks to be the easiest one for us to build for interesting because um wi ui3 has a template markup already called zaml xam ML and to design and style Windows applications with the wi ui3 in zaml is just elements and then attribute values that's it and so it's already built like it looks like it was designed for to be wrapped by live view um like they thought about that yeah yeah it's like there it's a little bit more than that but like in the case of swiftui the modifiers um that that ended up being a really really difficult uh place for us to get to eventually I like I actually really like where we landed with it with the Styles sheets but what it was originally was we were just going to do like element names and attribute values and like oh we'll just add like uh you know color background attribute value equals this and then we'll collect them and then we'll apply them well as you saw yesterday order matters right order of the modifiers that can apply matter yeah which is a bit strange coming from the web space because in the web space you're you are uh changing the aspects of a single bounding box on that element whereas in um I forget how you put it you actually put it probably better than I'll articulate it right now but in Swift UI you're like putting layers onto that existing thing and that layer can like can change that aspect in color to anything it wants exactly um which it's a different way to think about it and I mean not not to say that's wrong but it's coming from web it's a bit bit of a learning curve definitely yeah because that that's a parts me as well because yeah with HTML like with CSS and HTML you you always design the whole thing and it doesn't matter which way you design it um or like in which order but then on Swift youse always you add layers on top of layers on top of layers uh Style so to say I I had a question order does matter slightly with HTML in that you can override prly but that's effectively it later rules they override earlier rules but I mean those will also be caught by your editor usually and but in Swift UI it's a built-in idea you know if you like yeah create a certain um like a text of a certain width and then you color it and then you make it smaller and then you color it again then you have two different uh layers and yeah I I had a question because you mentioned that earlier and and that's something that I remember you saying but it I just realized it and it surprised me a little so you you said that you created all these elements for Swift UI uh that basically like text for example a text component you call it and that one is basically a swift UI text component and I just looked it up on the um on life you native Swift UI in the in the GitHub and it's true like I I just realized that you actually have your own sort to say text component and then if I create that my nck template it just render well just uh in quotes it it renders a swift UI text element actually yeah why why why did you make that decision instead of using the actual Swift UI one yes I don't know what yeah what is the W it in certain ways so that we can actually have the attributes being applied um we can't so a couple things number one um there is no no reflection in Swift so we can't um we cannot do something where if we parse AC apart a document and we find an element name we can't then dynamically say that is likely to be this few okay so everything in Swift has to be declared and we do that through a registry system where we have a dictionary and dictionary is a swift version of a map key Value Store and all of those uh like every single tag name is the key and then the actual value is the struct that we have and so like text is probably the most um simple example of a view that we're just wrapping but uh the thing to understand in Swift UI is that it's not like a shell that the UI uh vew tree ends up representing like what actually gets emitted out there is the result of that function which is an actual Swift uh UI text uh view but we needed a way on our own to control what's going into that so that we could uh have it play nicely with the way that we intend to be used so like there if we had just simply done like a a wrote copy of attribute values in um yeah I think that would have been very limiting for us in especially some of the more complex uh VI that we're representing because then I don't like we can't we can't reach into already defined code so like we can't add to the existing Swift UI uh views in any way so if we wanted to extend them to respond to event handlers like PX click events right that wouldn't have been possible right so we need ways to to represent that but it's still a one to one parody right and so a tab view in our live view native implementation just is going to render a tab view swiftui oh interesting okay yeah so and and also the the syntax that I use in in my NS templates is different from what I see here in in swiftui like how you would actually write it for example the the style attribute as you said you know in in swiftui it's a style column and then you write your Styles and in NS it is rather yeah like a almost like an HTML attribute where you write style and then equal sign and something something right yeah so so what we found what we had early about maybe six months ago the style attribute didn't exist for us and um because we don't have a Tailwind framework yet we found ourselves doing these kind of onetoone uh class names where like we would declare like like we want to put a modifier onto a view and so we'd have to go and write the class name for it and then the class name would look just like the modifier to the extent that Carson actually wrote a uh a stylesheet library I think we called it utility Styles at the time and it was a pattern matching library that you could write any class names within the convention and actually have them dynamically compiled down to Swift UI modifiers okay and so with with modifiers you mean Style modifies or what does the modify in in Swift UI Swift UI modifier does this is part this a bigger thing too is that modifiers in Swift UI uh can affect the look of something but also the behavior okay and they can modifiers in Swift UI can render uh Swift UI views as well and that would be the equivalent of a HTML well a a web CSS like styling rule being able to render HTML from it okay and and so going way back to the beginning this was a dis like when we realized that we realized that our approach on modifiers was a dead-ended in various attempts because every single time we tried to fully represent what Swift UI modifiers could do we kept running into that issue of oh and this this modifier which is used pretty frequently now needs to render a swift UI View and so now are we just having to write those like that view mark up within the modifier definition and what like technically it could be infinitely recursive like you can have a view that's inside that modifier that has its own modifiers and those modifiers could have views and so on so forth so we had to find a way to do that and represent that properly um I don't know if uh I actually didn't watch the last 20 minutes of the of the video um but I don't know if you ever got to it but we have a whole kind of like sub templating uh mechanism where we can pass in a template reference into a modifier and then within your markup if use a template attribute equals and has the same reference name when the view is being mod when the when that when swiftui is building out the view tree it will parse the modifiers and then it will look at its immediate children and then if they're is a matching temp like if there's a matching element with that template reference it will inject that as the modifier like the view that gets dumped into the modifier and then it will take it out of the view tree if none of the modifiers have a matching template reference and there's elements immediate children that have template references then we simply ignore them so they don't get uh they don't get rendered okay and this this is flexible enough to allow us to do that infinitely recursive uh nature um but uh yeah I see some modifiers here yeah I I'm I'm looking at the scratchboard uh GitHub repo I think no no I got to delete that sorry I I thought scratchboard is old scratchboard yeah I you know what I'll go do that right now yeah I just I meant to do it last night but I just remember there was another example thing where we also looked at the um the tab view example but I can't remember where it was now uh I'm change the visibility but the the yeah so we have a lot of kind of uh Legacy stuff on um uh in our org and oh what is going on hold on because those Legacy projects were representative of misdirection or a a deadend direction that the framework went into at one point and then we just haven't cleaned them uh them up yet but um didn't you have an example repo somewhere I I remember looking at one The cookbook yeah that's one okay The cookbook is a better representation of where the framework's currently at and I'm convinced that where we're currently at is where we're going to be at forever now okay um the uh what like the foundation is set and our goal now is just to like increase scope uh fix bugs and then work on performance issues and you saw some of the performance issues M um the other day like that was a really strange one because as you noted the data coming out of the server was in micros seconds yeah um the the thing I'm convinced about and we and we we spoke about this briefly on slack the other day um we need to implement instrumentation into the render cycle of the swiftui client so that we can start to identify and uh fix the some of the performance rendering issues that were running into um but I'm also convinced that as much as you know the kind of common belief is that web is slow I actually suspect that uh the web is faster than native when it comes to the way that this is working because on Swift UI like it it assumes that it's in a compiled state that we are getting like a UI built and it pre-compiled it and it's all this like the Clara of stuff that's happening at runtime to keep it fast MH and to keep the rendering fast whereas what we've been doing is we've been kind of treating the clients like browsers we swap out HTML for Swift UI we swap out CSS or like modifiers and we swap out runtime language of JavaScript for Swift and we compose and build a view tree and then we push that view tree into the Swift UI like runtime view tree and it merges itself in mhm um and like the the two like the two projects that exist on this planet that probably have had the most money poured into it is Dom rendering and V8 and so like for performance and and so that's where we're kind of come up against at this point is that once you get past like the idea that like JavaScript runtime sure it can be slow but when it when it starts to work like with the browser API that's technically browser native land at that point and that's going to be as fine-tuned and as fast as Google Apple like all the browser vendors can possibly make it because they've been deal like dealing with hearing that the web is slow for 20 years now right whereas Swift UI for Apple's purposes is already very fast so what what we need to do is find where our performance overhead is it may not even be Swift UI could be an like live you native core M um where the actual like parsing and building and merging of the uh uh the markup um is and the the building of the view tree is uh gonna have some performance overhead possibly and we end up send we end up building that data structure in Rust and we send it over to the clients us using UniFi and so that you don't have to reconstruct a view tree in the client itself what do you mean what's the difference there between the the rust back and so to say and the client you mention is isn't it running all on the on iros on the device no like all the all the core functionality is running in a in Rust itself on device but it's not in Swift Code okay like it's it's running as a dependency of the project okay um and so rust itself is going to be plenty fast but what we don't know is if UniFi are are you familiar with the UniFi project uh no no okay so UniFi is written by Mozilla and it's a it's an ffi implementation and so it allows you to actually interact between languages over a bridge right and um so like rather than sending like a uh like a a data structure that has to be repared in the Target like language you're sending data into you send it over the bridge and when the target language receives it it's already in the natively assumed like types okay so in this situation you would have a a domum representation in Rust and you like whenever a change comes in you modify that representation and then you kind of convert that rust representation using UniFi to a swift UI representation and that actually updates the Swift UI um front and the client so to say yeah is that correct it yes more or less and the so but what I was getting to is that we don't know if maybe UniFi is the overhead right that's happening there okay it's interesting I mean and and you did you choose for UniFi so that you could easily change like Swift y for cutland for example yeah yeah so it's we needed if we're if we're going to be extracting all of this common functionality into a single library in Rust because rust is fairly portable um we could have gone with C but either way we would still need some way to get that out of rust land in to the target language itself and UniFi um was it seemed like a very good option at the time and it probably still is a very good option uh it has MA major backing by Mozilla it's being used in a lot of um uh I actually don't know the the the the projects off hand that's being used in but it's fairly well trusted at this point even for being fairly new in the ffi space um but we've never measured it like we've never actually determined if the uh um if unifies the overhead or if there's just overhead in how like with swift UI it's a close source project we don't have any insight into what's happening there we have we can make assumptions based upon the behaviors we see like Swift the language is open source with Swifty is closed source and so we don't know what happens when we h hand that off to Swift UI like we don't know where the optimizations could possibly be like if we represent the view a different way is that going to be more performant that that's where we are I've been trying to knock on the door of Apple devs for a while now like apple as docyard is an apple vendor but we can't just go and like start bothering people with an apple with our stuff and so I try to go through official channels yeah and by Design Apple's kind of really shut down any ability for outside people to interact with the Swift uui team mhm okay so so with swift UI you mean the language is open so so I you know I can download it and I can write Swift UI in my X code uh but then what it actually does behind the scene when it compiles my code and everything and the apis that offers me like you don't have visibility into that is that what you mean with close Source yeah yeah there's none and and the whole like rendering engine that it uses you also can't see that right exactly okay and that might be the issue here like it might be in Russ it might be in h UniFi or it might be in Swift UI and you just didn't know where we don't know until we measure it right and so we're going to instrument um different parts of the render cycle and see where uh like what's nice with live view on the web is that there's a um I don't know if people I know most people probably know about enabled to bug on the live socket there's also enable performance and if you do enable performance on every single uh diff merge it will show different parts of the render cycle MH and how much time it took that's that's my goal is that I want us to be able to achieve the exact same performance in the web because right now um what you and I went through the other day after your uh after your video recording on Monday is I asked you to kind of like reimplement that counter on the web yeah and you know on your phone the web was more performant like it felt faster yeah and so that tells me it's not a network issue that tells me that it's somewhere in the Cent rendering side and that's fine with me because network is out of our hands like if this was a network lag issue we'd be screwed but it's not and because it's somewhere in our code we can fix it interesting yeah makes sense I mean also when we spoke about it I I also said like you know it's it's 0.3 for Life your native right now so you know you got the basic uh the foundation down but now the optimization STS right this is just the way I am like I I am maniacal about like details on these type of things and so that's why when I was going through your video I was like ah God damn it I forgot that I forgot that or like like your point on the documentation where kind of dead ends is true the thing that like so to explain that for a moment um you know where your confusion was was you were going through the live view heeks documentation and it's just like oh there's no more paths forward how do I build the application yeah because we put all that documentation in the Swift UI docs because you're building a swift UI application right I wanted the live view native Library itself to be agnostic as to the implementation of the client and then there's guides and all this stuff but what we should have at the very least in the live dat of docs is okay now you've set it up which client are you using continue here yeah exactly something like that would even even just a link to life you uh LVN go you know say Hey you want you want to do Swift UI development the easiest way is just download this app and point it at Local Host 4000 and you're done or not Local Host 4,000 actually your local IP 4,000 um it's always interesting watching other people use it because it all like as similar to our setups that we sometimes think that we are there's always these differences so like I do you have two Wi-Fi networks in your house what was one on there okay well I have my office one and I have my like living room bedroom one and you've bridged the subnets there so that the different subnets can ping each other they all go through one server yeah gotcha okay all right so when we gave a uh we gave a workshop at Elixir conf and we were running into so many just setup issues I knew this was going to be a problem because conference like Wi-Fi is a pain but um the first issue was that when you were like people had their we had just built LV and go like three days before and um we were first going to just have people running on their phone and then like as you did yeah but the conference Wi-Fi for electron was putting devices on completely separate subnets and so they actually couldn't talk to each other um some people were like oh let's do Eng Ro I'm like that's a great idea but I haven't used enrock in a while at some point over the past like five 10 years it's now a paid model yeah I like I'm not gonna ask everyone to buy engro that's crap um we had a uh a Wi-Fi router but here like this is where it gets really annoying is that we set up the Wi-Fi router we didn't plug internet into it because uh the conference venue wouldn't give us like an internet back blone to plug in and there's this like weird thing in um on Apple devices that they will they will report in being offline mode if they don't detect outbound like outside global internet and so in live you native itself we have a um we have a state that it's basically just a state flag that when the when Swift UI goes into offline mode we render out a locally declared like offline view to say oh there's no connection at the moment okay and that's so that it doesn't crash right and that's assuming that you don't have a connection but in this particular case you everyone was working off of local network and it should have been fine and we couldn't get the damn application out of the state even when we like we so we kind of I I was just I had it I just like ripped open a wall I I pulled out out a a catfi cable it plugged into the router and so we technically had internet at that point but that value got somehow cashed in the application oh and there was like this weird it was like about 45 minutes of just chaos trying to get it going yeah but again these are just like things that you run into that you don't anticipate because we're building in a controlled fashion all along and then it's like oh damn like that that is different than what we thought we were GNA I I do know that but I mean also you know um to be fair I mean in my last video I also said that I Remember The Time Of Life View version 3 0.3 like I I think I already worked with that back then and it was very very rough back then so it already worked and I used it but you know like I'm just saying like 0.3 for life you like what was it like five years ago it I thought it was in a much more rough State at least for my like for my memory than life un native is now in the 0.3 version like actually like once you get over these more like um well skill issues really you know because I didn't know how do I actually run this app on my phone okay and then I figured it out and you know then we we kind of got started pretty well I mean it's it's that's why like my experience with life native was pretty op like positive once you got over that bump of okay so this is not a website so I can't just go to Local Host 4,000 so how do I how do I run this thing you know oh yeah no no I I I definitely appreciate that and I'm not trying to excuse anything away I actually like I was try what I was getting to is that I like when these things come up because I kind of look at it as free QA yeah it's like okay you know how how much longer would we have gone like incubating this before we run into that issue yeah and it it's just like you know because you've been working on it for so long and you know exactly the flow to get to a certain point and then somebody new comes in and ideally like they also tell you about it you know other people they just like touch it and they're like I don't know how to do this thing okay I'm going to move on you know they they don't actually give you feedback on it so yeah that's why I try to do that interesting but Brian so I mean you already touched a little bit on the next topics here a little bit like the next steps for life you native I mean you're still working on a jetpack for cotlin and now you're looking into like performance um uh tweaks and you know debugging tools for for Swift UI like are those the next steps for life you native or what what what are the big next topics that come up so I I'd say that the the big things for live you native in terms of development are going into what we hope coming out of that end to end like testing capability because this is going to start to like despite the fact that we are actually emitting and building a native application like it's not native light it's not a web app that's doing a GS Bridge it's like this is actual native UI that's being built uh latency can kill that perception that it's native like that's just flat out true and any type of Jank can kill that perception and it's also fodder for I mean I'm like I've I divorced myself almost entirely from the javasript ecosystem after uh like I stopped doing Ember Jaz and I'm starting now to kind of like tap back into it because I'm I'm curious to see like okay who's the competition like react native is going to be a big competition here and I mean that world is just I mean despite all of the the typical jokes about JavaScript but I mean they are they they are very very good about calling out like quality as like quality issues on libraries okay and I think that that is a huge uh that's something that we typically have not been as good at speaking about or identifying what's going on would live you or like in elixir in general to communicate to these other ecosystems so like the whole like Ryan Florence uh Live use ceiling conversation debate call debate yeah going on a few weeks ago Um this can all be summed up to just a miscommunication as to like what the perception of what live view actually is yeah like from us within the Elixir ecosystem we know that live view is yes it's it's server rendered but it has this whole optimistic UI aspect to it that allows you that escape hatch to give you a as good or better performance in many cases than what a lot of like react or other like JS libraries do on the front end and like our methods are more reliable in that sense nobody knows that it's like like so like they they just dismiss live VI and just say oh we know that server side rendering doesn't work for client side application framework we've been down that road before no need to revisit this topic but it's like no no no that's not what live view is live view is a stratling of both of these worlds it's more nuanced you have to understand that and that's also what live view native has to be like we are going to be subject to the network latency lag issues from time to time and the only way to get around that is through optimistic UI and and so like right away even on the LAX application we saw cases where if you're loading up a um a chat room for example that had like you know I don't know how many um messages in it yeah there was latency with loading that but the late like the perception of latency goes away as long as the user is immediately seeing UI render in and it's okay showing skeleton UI like it's like okay yeah there's messages here they're coming in but the The Lax application I think currently like the mount function for the chat room will load in the messages from the database and then render them in the template and what you really want to be using is like a assign async or async assign I always forget what order that goes in assign async yeah yeah assign async and so you you you render out the Chrome of the chat room immediately and you get that as fast as possible over the network and then you just show skeleton UI like a loading indicator that they that these messages are coming in that's what users want that g that gives them the perception of speed we um we discovered an issue yesterday actually with navigation stack so in Swift UI navigation stack is how you navigate between different views and there's a modifier called navigation title and navigation title um you can apply it to any view that is within a navigation stack and it will put a title at the top and like when you navigate from one pane to another it will take the previous navigation title and shrink it down and move it to the upper left and it'll this will become the back button right it's a common pattern that you've seen and then new yeah as the next page is animating in that navigation title will be be available and going to the like place that the previous navigation title was right so what we found was that with live VI native actually we saw this before but we figured out what the problem was fortunately haven't figured out the solution um is that because we have a um when you when you kick off a navigation event M navigation link We immediately render out a connecting vle View and it's up to you to Define what that connecting view is that connecting view I think by default shows a progress view which is like a little like spinner okay and that's actually not great like we're gonna have to refactor that because it it feels too webik when it shows that spinner yeah um and then when the uh when the next view gets uh built in live view native and then injected into the view tree it replaces that connecting view immediately and usually this is fast enough that during the during the transition of the animation for navigation that view body is swapped out fairly fast M but if that view body includes a navigation title modifier what you'll see is that the prior navigation title gets pushed up there'll be no navigation title coming across during the animation but you'll see the new body immediately in the navigation and then once the navigation animation is complete the view the navigation title will pop in and then push the the content down so it's this J and what we what we found yesterday was that um that swiftui when it kicks off the navigation event it immediately looks at the view that's being injected in for the next page and if that view has a navigation title that will be injected in as navigation title that comes across that like is taking up that space But because our connecting view doesn't have one it ends up being a nil okay you need to add that title and then you could but you don't know how to do that because that's actually that's in the client it's not being served up from the server in any way because you still need to you need the network to go out and get it right and but this is like a feature of Swift UI or feature of bug however you want to call it where it will cach that value in the navigation title and it doesn't allow replacement of the navigation title value until the animation's complete so you can't just put loading in then once the view is loaded you can't replace it with the actual title yeah so I I submitted a bug I submitted a you know bug to Apple I I don't expect to hear back on it but it's it's one of those things that we don't have a good solution for it at the moment what we could do is we could delay navigation until we get the view tree from the client but this is GNA make navigation feel slow um we could um we could I I believe you like I I'm looking forward to you Solution on that uh I just if you don't mind I I have a question from Zack that I would like to ask you um so he asked Zack Daniel asked is it possible to have some amount of UI like your shell SL layout shipped with a native AI with a native app I've been wondering the same thing for life you is it uh as if we can have a classic CDN delivered static page as the entry point is that possible so yes so um we just like with live VI itself um live you native can be done in a hybrid fashion so you can mix you can have a pre-existing Swift UI app and then just like the live view live view native view is just a swift UI View and you can drop it into any point like if you were to uh bring up whoops if you bring up the EXO project um that you had yesterday you could look at the content View and you can put anything in there that you want and just put live view wherever in that like somewhere as a child in the view tree and wherever that live view is that then is where live VI native kicks in so you could wrap it any way that you want you could um if you have a like a five-year-old Swift UI application that's been built up over time and you're sick of like only like one aspect of it is making API calls for remote data you could replace that one like view with live view native and then keep the rest of it on device natively okay that all works so so yeah in the content view you just wrap the live view and uh that way you could add some static content while the live view is is loading for example yeah so sounds like you're trying out right now but I I okay are you are you streaming your screen because I actually don't see it on the meet uh it's not on Meet no it's on the it's on the stream okay yeah I can but I can send you a link to the stream then you can just well you can share your screen here too right I think I can yeah true uh wait this one yeah so I can't see anyone uh that may be asking questions uh hi Zach uh I have to Firefox is adding asking me for some uh permissions all right never mind hold on I'll just open up your stream that's much pain um let me see here real quick that is it on the same YouTube channel uh yeah p on code okay but it's a it's a little bit delayed um I'm just GNA I guess I just have to restart my Firefox and then it should work but uh h on it's always that thing I'm hearing myself from like 5 seconds ago all right okay yeah so if if like right above that so that little uh hashtag at the beginning denotes a macro in um in Swift UI which is why you had to do those whole like trust and enable right which is really annoying and The Trusted enable is there because there is no um trusted source of dependencies in Swift at the moment there's no like heex equivalent right and so so anyone can deploy an application and if it's a macro that's doing some type of code gen at compilation time Apple wants you to say okay yeah I'm fine with that and that's really what the macro system does but if you were to put like a um like a text element just above it just like write text and then whatever and then you could drop it into a view stack that will all work it'll look uh I mean at that point it doesn't own the entire screen but um it works just fine the um the this actually brings me to a question you had yesterday regarding the LV and go app and some of your struggles with getting disconnected MH so you had suggested that we could put like a back button up top if we do that that actually pushes down the UI of the application you're building right so it' be like so I I think Constantine's the one that mentioned it but like we just have like a shaking interaction at the moment yeah um on different platforms like on um on desktop uh it will keep a uh the connecting like screen as a separate window open and then it'll open up a new window for the native application so you can always have separate Windows managing it but we're going to be shipping LVN go we have it for iPad iPhone and Mac OS at the moment but we're going to be shipping in Apple watch Apple TV and apple Vision pro versions of it and then probably sometime before the end of the year we're going to start working on the jetpack version of LV and go as well that one's going to be interesting because I mean how many Android devices are there out there an infinite number so I'll have to make some decisions on what we build for that yeah that's true I I I'm not sure about uh if you build it in what is it um uh the one Studio thing Android Studio where you build that kind of stuff like I'm not sure where how many platforms you can Target at the same time yeah it's it's turning into like we've run into interesting problems between the two different worlds between jetpack and Swift UI because in for xcode the project that we built um when generates a project we rely upon this Library called exco genen that will actually like build your exod project for you um but then there's these weird issues that occur where so what we generate is called a multiplatform Target and so you can build for any of Apple's devices and that you'll see two projects in your xcode project one for Apple watch and then one for everything else M because Apple watch because of Legacy needs like older Apple watches required a companion application so they have to have you like have two side by side but then randomly I don't know why sometimes people report that when they open up their generated EXO project it will default to Apple watch okay and we don't have any control over this like there's no flag that we can say here's your target like here's your default Target that should be opened up um it to the point where I'm considering removing Apple watch from the like generated project just because no one wants to build an Apple Watch like when they're trying out xco uh liveat for the first time probably not no but I mean make it easy to enable it eventually that would be good but don't have it enabled right away yeah yeah true interesting I I also have another question like um I mean since docyard is developing this technology uh have you also used it in client projects already in production uh we don't have any clients with it at the moment no um MH I mean this is a bigger problem that exists outside of dockyard but uh consulting's been really tough over the past few years it's been uh like docyard has unfortunately had to do uh uh layoffs um and it's been a shitty few years like there's no way two ways around it that's about as you know up front as I can be um we are Downstream of a lot of stuff I um I mean first of all uh majority of Doc's clients historically have always been uh organizations that are taking out loans to do projects or are being funded and with inflation being what it has been over the past few years that's been kind of a non-factor um so that all to say that I think that uh my goal is to at least land one live un native client um sometime over the next six months but ironically I think that there are actually two consultancies I know of that are doing live native projects for their clients I don't want to mention who they are not have competition I just don't want to they they asked me in confidence you know about certain things so I didn't want to say anything but I think too that the like these are like kind of individual consultants and in those uh in those type of Arrangements you typically have more control over the technology stack whereas a typical doctor client is usually a uh you know a wealth founded startup a um uh coming in with some like Tech uh technology already and opinion on it so there's like a big part of what I've been telling the team all along is like building it and getting to this point is probably like 25% of the work it's like education building trust uh marketing Etc that's like the real work on adoption when it comes to anything but you know for this project because we're not just introducing something new we're also a fairly small company and so we're saying hey like trust us with your application sta yeah kind of and also I think that we actually yeah I think we have something that can be trusted yeah and you need to be able to maintain it I mean it's not you know if it was re native they could also find a different uh contractor eventually but uh yeah with live you native there aren't that many out there I guess um but that takes time yeah you're now a live you native developer yeah basically I can put it on my CV here um I mean that's also that also brings up a bigger question I mean you as somebody who has been working in the Elixir space especially as a consultant for quite some time already and you said that the market isn't that great uh yeah how do how do you look at the Elixir system the ecosystem right now like in in terms of underperforming we're underperforming like is it easy to sell Elixir is it hard to sell Elixir should we do things differently what's your take on that uh that's like a two-hour discussion but I I mean so this to say I um I mean I don't mind pissing people off when it comes to these type of things because dockyard and me personally I mean I've put in a lot of my own money my own time into helping build and as have other people but I I feel like I have a stake in the game at this point and I feel like I actually have the right to you know speak about areas in which we're underperforming and adoption is certainly one and it's not because of the technical expertise um there are multiple uh reasons for uh underperformance um I'd say if there was like one specific thing that we can be doing better it's stop going to Elixir conferences and go to other conferences and talk about Elixir period And so Zach who's I assume it's Zach Daniels that you're referring to Z been probably one of the best people about doing this as of recently uh he and I have had conversations about this I've been pushing people to do that I'm going to start doing it like the only outcome we get from going to Elixir conferences and talking to other Elixir people is that at the end at the end of the conference there's less Elixir people because the the only outcome is attrition like there's no higher level of do we don't like have an Elixir conference with all elixir people and then end up with more Elixir people at the end of the conference like the only possible outcome is a someone's like oh I gotta go get a different job now I mean it depends right because some people might be interested in Elixir and then they come you know uh to check it out but I mean they might not if that's the case it's not working right and so the um like what we should be doing is going into the lion's den we should be going into like I I would love to get live view uh uh live view presentations into react conf because that that's a hostile audience yeah but there's fairly smart people where I think now especially like what we're starting to see happen in the react space and just the general like client side application space is buyer remorse like more and more I'm seeing this happen uh where there are people actually saying you know what like maybe the complexity of building out these applications at this point is just too high MH that you see this has been this is if I had like one like real Stone to throw at the JavaScript ecosystem yeah and this is this is a fact is that there are too many of these people that go into an organization they evangelize like we got to move over to this new thing right and then they bounce out within six months before the before the job becomes crap right where it becomes like a complete nightmare to maintain and then they say good luck everyone I'm going to go over to someplace else and do a new Green Field project and they they're just leaving this wake of Destruction behind them and that's absolutely true and why when I say destruction I mean in terms of cost overhead bloat so I um I had this like kind of uh I'm adoption is like a really I for many reasons it's it's really important to me because I want Elixir to succeed because I love writing an Elixir but I'm also financially like tied to the language yeah like significantly I've put all the eggs in The Elixir basket so to speak and and so I I've been speaking with like a lot of people over the past few months on the topic of adoption within different market segments within different like industry levels of companies and I've I've run into all these really weird stories that I would otherwise dismiss but I heard them multiple times from multiple people and so for example like one of the um one of the big selling points of Elixir that we've been pushing in the community for a while now is that it's faster it requires less people to build and maintain projects like building with Elixir is cheaper less expensive I'm like okay let's is that true and like I feel it's true but in many ways I feel it's really more accurately defined like applicable to the last 20% of a project right now what do you meaning yeah what are the last 20% what do you mean with that just Ju Just Not in terms of time just in terms of complexity like like so like Phoenix presence for example this is like a a technology that doesn't exist in other ecosystems that would cost like millions of dollars to reimplement right like if like it's necessary and it closes that like 1% gap for certain companies but it's a very expensive technology to reproduce and we can just drop it in right distribution managing distribution like these performance things at scale are these really important problems for people that are starting out in Elixir probably not the most important problem for someone starting on Elixir is how do I build my MVP as soon as possible right and we're actually pretty bad at that I think like we don't have enough tooling or enough kind of like pre- big things to actually move people along at the start of projects and we're starting to do it like the rise of the the the UI component Frameworks like Bloom and some of the other ones that are coming along I think is excellent because this accelerates that process quite a bit uh Zach's project igniter I think can be a key part of that because he and I have spoken about it um where the idea of being able to just like build out a SAS application in five minutes like that should be possible in Elixir without any issue but we don't have it and the reason for it is almost because Elixir is so easy like how often have you seen someone come into a chat room and say like how do I do this or is there a library for this and then someone replies oh you don't need a library you can write it real really easily yourself yeah that's technically true but it's a stupid thing to say stop saying it people like stop telling people that and if someone's asking for the library go ahead and build it I I um like we need these things because Elixir has attracted a certain level of engineer over like its lifetime it's primarily like senior level people that are transitioning over from other Technologies and so you know people at that level have seen it all they they they know like where the bodies are buried on certain projects and yeah I think that they kind of understand that bringing in too many dependencies can be a problem but if I'm a junior engineer and I'm exploring a language where I'm a mid-level engineer and I'm starting to like poke uh kick the tires on Elixir then I don't want to start from zero like get me like the 15minute blog thing like get me up and going as soon as possible um this is this is one of the bigger issues I think that exists for us and there's it's something that um I've recently identified that doc a wants to start like really helping on as well so um we actually have uh a little bit of a solution for this in house that we haven't released yet there's two projects uh one of which is a UI framework that's a very different UI framework than what other people have built like the UI Frameworks of that are currently out there the UI like function component Frameworks um they kind of I think that they're uh great if you want to go with like a pre-baked like styling solution right what we've done is that we built like the functional side of it and have like almost a like Bland styling because they're saying like you know your styling is your decision you're going to build on top of this but here's something that works that looks okay but functionally it provides all this functionality that you're going to otherwise have to be writing from scratch every single time right okay and uh there is a small project to like get other projects up and running really fast but we had written it before igniter came out and I think we may want to rewrite it igniter or let Zach do his version of it and just end up using that so that that's where uh these type of optimizations at The Upfront side of building an application or building a project or a product is a huge like Market gap for Elixir at the moment that absolutely needs to be addressed so like we need and also like some of the progress that occurred recently um is really great but our lack of like a unified language server is a huge problem for us right um just like the the issues that have existed amongst the language server projects like so when you have someone trying out Elixir or any technology they're bringing in their predefined institutionalized knowledge right and so if they're coming from a typescript or JavaScript background or rust background or wherever like I'm going to try to Elixir like where's the language server and they start to install it Eng just breaks they're like what the hell like this is like that for them ends up being the point which they jump out they don't even really get to like some of the real value propositions of the language so I'm really glad to see that effort taking off um I agree there are yeah but there's like so for example going back to the point around the like the cost or the number of people that we require to build an equivalent application with um I heard from three separate startups and this is this is going to sound like complete yes but because I heard it from three people I kind of I I'm led to believe that there's something there but like companies going through startup funding rounds they have requirements that they have to meet okay and just because they get promised a certain like windfall of money and around they don't have access to all that money right away there's like certain kpis key performance indicators they have to actually achieve over time to unlock different parts of that funding round VCS private equity Etc they have their idea on how to actually get Roi and part of that is we need to scale this we need to get it up and then in their heads because of their experience they have an idea on how much scale and where that scale should apply within the organization that they're funding okay to achieve that and their minds they're divorced from the technology they just know we need a team this size to achieve this right okay and so I heard this story where they started out with Elixir they started out with Phoenix and during funding they had to change their technology stack because they didn't need as many people as they were told they had to hire in order to unlock another funding rout which is insane yeah a backwards also they couldn't have found that many Elixir developers maybe that I that wasn't the issue they only needed like three or four devs and they had that team in place right yeah management was convinced that they needed a team of 20 engineers in order to achieve the skill like no we don't and then we're moving over we're moving the Tex stack just so so so that we can hire 20 people instead of three okay exactly yeah that's that's that's the way it was communicated to me at least but I think that is a solvable problem in that there is that that tells me that there's a knowledge gap for those that are like kind of giving those terms in what is actually necessary and what is currently a weakness we can flip into a strength because if we can actually prove and show that Elixir requires less people less cost to build out these applications these are people that are primarily motivated by Finance they're primarily motivated by burn R right and this is where Elixir can shine but we don't have anything at the moment we don't have any way to interface with these people yeah true actually we don't haveone to actually go out and actually like sell that aspect on our behalf you know uh Jacob LOF The Elixir Mentor yeah he says also he had a buddy and this happened to his team with a VC as well what mention exactly so validation right there it's insane yeah it's insane that that's the case oh my okay just I don't know High some re developers and make it a a backend front end divide maybe well so I I think that especially coming out of the past few years that VC's should be especially more concerned about the burn rate like even going back to my own history like I I've been programming since I was 14 and like I saw like the rise of the web and you know the early 2000s the tech crash and then when rails came about you had this whole kind of like new culture of startups that came about from it because rails was going out there and competing with PHP it was competing with Java it was saying we can build the same applications in half the time and half the cost yeah and this is like like people with money are like yes we can like build something with less money we need to actually get back to that point now whereas the whole kind of culture of the past 20 years has been about spend spend spend MH if we can actually convince these people that they don't need to spend as much and actually come up with a better product at the end that positions Elixir into a world of its own that no one else can really touch that's a difficult thing but I I think the only way to do it is we have to find a venture capitalist or someone in that space that's like a thought leader that actually has influence there that is already talking about the need to bring down costs to build startups true I mean if we could find that person that would be the right person to talk to and start to educate but we also need to prove it right so we need these upfront optimizations on application building too true yeah I I agree with that I mean it's it's interesting now that we don't have a zero interest rate anymore like these kind of things might also become more important again also something else that that Bruce Tate said um which I agreed with a lot um so he said that Elixir it can avoid company Killers that's what do you call them like sometimes you have a problem that it becomes so big that your company just dies because of it because the tech technology doesn't support a certain use case you scale to a certain size and out of a sudden you're you know whatever no JS backend can't scale with the number of users you have and your company actually dies because of that you know um I thought there was that happens but for those companies like that happens much further along yeah in their like maturation process where they've already like they're so deep on their their Tech choice at that point asking them to change is really tricky yeah because like and that that's another issue that exists at the moment with live view that if you want to sell someone on like nextjs versus another like JavaScript framework the the sell the sell of that is a little bit easier not like let's move the aspect of like the individuals on your team already like if you have Js developers it may be easier but you're not asking someone to swap out your entire Tech stack no if you want someone that doesn't use Elixir at the moment to use live view it's an all or nothing decision yeah and and that that can be a bit of a tough sell interesting so so maybe so the value propositions that we're currently talking about yeah we need to be moving over towards order of magnitude value propositions as opposed to like Road bump value propositions right okay so so just you know to to reiterate like you said okay we should be getting better at getting started quickly with applications in in phix so like a UI framework for example the the def uh experience must also be better with the better LSP um but then sorry you also mentioned something that we we need to focus on certain kinds of companies that might uh benefit from from Elixir which ones were those again um no it was more that there are different reasons why Elixir has been difficult to adopt based upon the company type and so I'm spoken about like uh you know startups right now on the Enterprise level on the complete opposite side of that Spectrum there are you know other issues so for example like nobody at the moment is selling Enterprise support for Elixir right nobody and this like when when an Enterprise company is adopting a technology their list of requirements can be pretty deep but they're also kind of like just like there's a lot of them but they can be just like basic stuff like checkbox type stuff so for example an IT department typically in an Enterprise company is the one who has say over whether or not technology gets adopted or whether it can be used internally like it will do a risk assessment and part of the risk assessment is does the language have long-term support technically elixir does because it's stable since 1.0 and it'll be stable indefinitely yeah but because none of the versions have that LTS sticker on it that's what like an IT person that's not familiar with Elixir they don't want to get into the Nuance of it they're just like you know what it doesn't have LTS okay moving on to the next thing um they're is no like first class support for Oracle or Microsoft SQL databases right um and I I've spoken to Jose about this and you know you come to it he has a different opinion on it like there is an Oracle database driver but it's not first class and there's like so these are like the things that give Enterprise cause for concern because they don't understand that in Elixir the issues that you have in other languages are not the same that it doesn't require like a team of 20 to maintain a database driver it can require a single person just to do like the Ecto version of it right but they don't they don't get into the Nuance of that they're looking for like they they have a mental model on what they know they can reject and elixir seems to not be answering these questions properly for that level in many different ways um the hiring question I think is just kind of there for everybody in terms of you know chicken or GRE who's going to are you going to go out and learn Elixir before there's a job available or you going to get a job and learn Elixir we tried to solve that to a degree with Dr Academy I think our timing was not great because like we hired Brooklyn and then like two months later like everything went the [ __ ] and so and and so like our whole Vision there was that we wanted to create more Junior developers and get them into the market and start doing job placements with them that we would and also for dockyard sake like we make like our margins are really really difficult at the moment because uh salaries have been going up companies are just fighting back on rates and so we we're getting squeezed out and so we need higher margin employees to actually continue to survive and continue to invest in ways like this like between live you native you know all the support that we gave for years for Phoenix development for live view itself um Beacon and some of other projects like I I don't want to you know Pat myself on the shoulders too much but I I do feel like if it wasn't for Doc Air's Investments The Elixir ecosystem would look very different than it is today definitely yeah I mean you you're known for more than one or two very interesting projects for sure um interesting I mean what do you think about like elixir going into the the width of different Technologies now like we go into nurse we go into um AI you know we already have Phoenix so that's web development um what do you think think about that like is that a a good adoption uh thing or should we maybe just call all all in on web development for example no no no so I I think that Elixir reputation in the larger world is a perception that it is a web language and that was good early on I think that it's limiting now and part of live view native is actually to try to expand upon that perception of it like not to say hey you can only build web apps with with Elixir and heard this from many people that I've spoken to outside of Elixir like about Elixir like oh yeah it's just it's like Ruby you know like no no no it's like it's way way more than Ruby yeah um and so like projects like nerves I think are amazing I I've done some nerves work I'm actually so I I am uh Halloween's coming up and I don't have a lot of time to continue to do it what am I looking at oh there's your nervous device I'm also playing around with it that's the um Rasberry Pi zero with a okay with a p hat for quick and that's a just a temperature sensor like a CO2 sensor there yeah but I'm I'm just playing around with that currently as well yep so um in the United States we have this place called The Home Depot I don't know if you've heard of the Home Depot and so every like usually late August the Home Depot just gets like they have an entire Halloween display setup and they have these like really kind of they still kind of expensive now because they're they're so popular but these animatronics and like it'll dance around and it'll sing um so I bought a few a few years ago and I I hacked them with an Arduino um two years ago but this year I have this project I I've been trying to get back to I bought a bunch of Raspberry Pi zeros um and I want to actually uh there a central control unit on the animatronics that you know and then just like sends power to the Sur on like the arms and tells it when they move I want to like UNP the the the wires going to the servos clip them into the raspberry pie board and then be able actually control the servos individually and then have the individuals dance as I declare so I want to have a whole Army of dancing animatronics with nerves and like it's actually not a complex thing to do with nerves because you can just like turn on you know the switch or not yeah um but I just haven't been able to get back to it uh I have one of them and it's like it's like a weekend right it's so weekend worth of work and I have all the hardware here I need to get to it yeah um I have to back I I just keep buying I just keep buying stuff for uh forber your place looks clean compared to mine like my office my wife hates it yeah it is Nightmare of like half baked ideas oh I'm gonna build I only I I only keep this space clean everything around it is just chaos exactly so just for the camera yeah that's why I keep telling my wife I'm not the only one other developers are the same way we don't have enough space in our heads to keep all the Clutter so it just gets like into the world exactly people crazy but my my development environment is nice and clean yeah um but the uh I I do think that those type of projects help build the utility of Elixir but they need like there's certain things that that they need to kind of bridge the gap and when it comes to nerves um the world of like embedded um th this is why we had the Lumen project a few years ago we were trying to compile erlang Elixir down to web assembly because the real goal of that was to get to wazzy compilation wazzy compilation is the specification to run like pre-built binaries on command line like as part of like a it's portable as a binary okay that can run on any system um and we actually got to the point where we can compile our we can we could like read an Elixir project and pil it down um and it was less than 5 megabytes and so compared to nerves that's like roughly 20 megabytes those type of footprints do matter in the embedded space and the the the smaller and smaller and smaller you can make your embedded applications the more places it could potentially be used so some of the utility of of nerves is somewhat limited just by how fat like llang is like how much gets B into there I actually bought a a Raspberry Pi Pico too I'm sorry it's the other way around this way um and that one is a microcontroller and you can't run NS on it because it has only I don't know like 100 was it 100 Koby or maybe one megabyte of r or two megabytes but there is another project which is called atom VM yep and uh they support the the Pico so I'm quite interested in in you know playing around with that stuff because I didn't mean to check them out yeah atom VM and uh so so the thing is you know you have your your animatrons that you want to program I have my own project which is a little boat that I want to build with Elixir I heard about that that interests me quite a bit Yeah well you know I just have yeah exactly and I just have all the the stuff here you know I have like um like little uh what's it rotary engine so I can you know uh move like a propeller or something and my my idea is because I I am also a sailor I used to be with my parents at least until I moved out and uh I want to build like a little RV not RV RC I think you call them uh both you know maybe it's a 3D printer add like you know the the the motors uh you know for the propeller and for the um Rudder and then maybe I don't know connect it to some like controller and send it over the canal SE that that's an idea that'd be cool I mean the when we start it's always interesting when we take our digital kind of experiences and try to bring them into the analog world yeah and things don't work quite the same sometimes like so we um we built these projects with nerves um we I I have this like in Do's R&D Department which I run we have live native we have Beacon and then I have my passion project which is uh I bought the domain named racing. org a few years ago and we're building out a comp computational fluid Dynamic simulator which is a way to actually simulate the flow of uh a fluid over a body oh cool um and the reason I'm doing this is because I race sailboats and I have what's called a sport boat sport boats are different than what are called heavier displacement sailboats and the rating system that's typically used for a handicap is uh Antiquated and there's no like real uh incentive to update it so we get handicap we get handicapped in a way that is unfair like we can beat everyone else in the race for like five minutes and they get time corrected to being like third or fourth and that's kind of a kick in the butt oh okay interesting and and it's mostly because they're using these older um algorithms to determine the boast performance but all those algorithms were written about written for boats before this style of boat was even invented right and so like the the the physical aspects are not being properly taken into account a cfd is the way to do it but cfds are very very expensive to run in terms of time and money like doing a single frame for a fairly complex cfd um SIM can sometimes take weeks to months to actually render out Jesus but there have been a lot of uh improvements to some of the methods and so not to go go too deep into it but one of the major improvements is moving over to another method calculation called L boltzman that can leverage floating Point calculations and so we can use gpus to accelerate it further okay and then and this is where it ties back into Elixir right is that Paulo who works at docyard is on the NX team um what I want to do is actually distribute the work of rendering the cftd scene and I want to use NX to do it and so the sharding work that he's currently doing in NX is primarily motivated because of what's happening with the cftd simulator in in uh the boting dot uh in the racing. org project within dockyard because if we can pull that off we have the potential of having a order of magnitude performance Improvement on cfd simulation to speed it up significantly so that like using a cfd to rate boats currently is Not Practical because it would take just too long too much money but if we had a practical way to do this now we have a rating system that's going to be trusted open fair and it's going to piss off a lot of older people because their boats are gonna be get but I'm fine with that yeah but the um so so we actually uh like we kind of ideated over this for a while and the solution was always sharding and then this um Mozilla announced that they were doing a artificial intelligence um like uh support like program and so we applied to it's a grant system and we got in and we're the only like the only Elixir like group in there there's about 30 other companies they're all trying something like with local Ai and our approach has gotten a lot of attention within there because it like I don't know if if people follow Paulo on on Twitter just the other day he tweeted out uh some of the progress he's made on the sharting uh work if this actually delivers on where we think it can get to MH this is like the first time that the project is technically ahead of where python is because like NX has been catching up and kind of like covering the pre-existing Works in Python to a degree saying like you know they've they did all the hard work of like figuring out what works what doesn't and we're just kind of leveraging that that stuff but there have been kind of like toy uh versions of Distributing machine learning um in Python but doing it for real doing it at scale and doing it in a meaningful way requires is the work that Paulo's doing and it's leveraging the beam it's leveraging all the existing stuff in llang to to manage the distributed system yeah yeah and so it's not simply a matter of like python saying okay we'll just copy what they did they have to like rewrite python in order to like really pull it off properly true um and what this is gonna permit though is that like language models are becoming bigger and bigger and more complex to the point where only Nvidia machines realistically can hold them in memory to run upon and so Nvidia has the market locked up in terms of that Hardware like AMD Apple they're all trying to catch up but what if you could actually Shard your job up into smaller chunks that can be run on that machine because I only have 64 gigabytes of memory but it's 100 gigabyte language model like that like in my house alone I have multiple Apple products with most of them Apple silicon uh gpus in them at this point that are going completely unutilized so what if we could actually distribute that work locally amongst what I already have I don't have to go out and spend a million dollars on an Nvidia closet at that point this makes this democratizes machine learning to a degree yeah where people trying to break into the space now no longer have to actually get that huge amount of money just to even prove out their product they can use Hardware they already have and the the other things my like if you can just of multiple gpus you could also buy cheaper gpus that don't need to have 100 GB of RAM but smaller you know then that might also make it cheaper to run these models yep and and there's there's always trade-offs though right so like presumably nvidia's Hardware is going to be the most efficient in terms of electrical use and so there could be some waste that occurs um Network latency is also a consideration um I believe some of what Paulo is doing though is actually taking the network topology into account so like even Within These Nvidia like boxes the physical distance from like transistor to transistor matters like that's what they measure sometimes and so if you have a if you have like two boxes physically separated from one another the network like distance at that point does impact like times of execution but if the if the job is charted correctly and you take the network topology into account beforehand uh po believes that this is something that can be accounted for so cool we're we're we're still going to see um he's been very excited about the progress that's been made MH and it could be something that sets Elixir apart in the machine learning space yeah interesting definitely does that also tie into what I saw ya tweeting the other day that he was looking into the uh High Computing uh HBC yeah HC performance Computing high performance sorry but HBC those are like the big superc computers right yeah yeah okay so it it certainly can and I think that this came about Jo we we spoke about it briefly um I think that I don't know if he came to the thought independently or if there was someone that pinged him about it and said like oh because of this it plays in it dovetails like perfectly into hbc's the issue I think in that space is just how do we even access one I I so part of the Mozilla grant program we're gonna we get access to like a larger network of people uh collaborators and stuff and what's really nice is that Mozilla wants to take an AC of hand in promoting the NX project so uh the the the grant program ends sometime in December Paulo myself and I believe that's Sean morard we're gonna be going out to San Francisco and doing the demo day at Mozilla about this um Sean and Paulo will be doing most of the talking I'll just be know because that's like that the mching stuff that's like that's beyond me um but I I want I I recognize the value of it and I try to do what I can to enable it as much as possible yeah um great and and also the the grant by Mozilla help with that I hope well they they are helping with marketing they they want to like make sure success they want to get Optics on the project but one part I was hoping that they could kind of help with is maybe putting us in touch with someone that has access to HBC machines they kind of do because there's somebody from the AI Alliance um that is at IBM um that I've been chatting with uh he emails me back like once every two weeks so the you know the the through rate's very low but I'm trying to poke away and I think he wants to see the outcome of the the sharting work first um to like really see where we're at because these machines are there's few of them and they're pretty much all spoken for in terms of time and so if they're be donating those that time to somebody it's time that they're not directly making money off of it right so they they want to make sure that the time that is put into those machines is going to be like high impact high value um so I believe that he'll be at the demo to day I'm going to have Paulo and Sean I'll connect them there and hopefully we can get access to an HBC machine at that point interesting okay yeah that's that's it reminds me of the old days my dad he also worked with computers in his PhD like 40 50 years ago and he told me that he always ran his research um like what was a punch card projects He had literally Punch Cards and he always had to run them through the night because you know during the day the the system was used for by the company that owned and then during the night he could rent that machine for free or for very little money and then he was running his programs during the night that you say that I was actually thinking about those stories the other night because like my like my history in programming like I was telling my son like back in my day like we had discs that we put stuff on I'm like this sounds exactly the way that my CS teacher in high school used to talk about that they would have Punch Cards and the story I always remember is that he he told me that he spent like a week or some like significant like part of time because you have to put them all in the right order they all have to be perfect and he was walking with the machine he tripped and dropped all like that's that's clearly not a problem we deal with today but just sounds horrible yeah I I still remember when when I was a kid like I had a computer my dad he always had to reinstall Windows from the floppy discs every couple of weeks because I was destroying the system with my viruses yeah now we still back in in that time where actually you have to kind of fight for access to a Sil computer in that regard to computing power yeah I mean that was usually through University level too you know they would have uh universities would lend out their computing power to organizations During certain hours and then students would always have access to it during other hours um but it's uh yeah I don't even know like what that I'm assume that these hbc's have some sort of like fixed cost per hour right at this point like just saying here's what it costs us run it or here's the opportunity cost for you to use it and I don't even know what those numbers are like they could be very very high well I mean I have a PhD friend and she works with the AI like machine learning models and she has access to one at her University and for her it's free but it's you know run by the university so of course there's a a cost calculation and not everybody gets like access to it but uh if you're in that program actually you know they they give you certain uh computation slots or so they call it right right so maybe universities might be a better approach than uh than commercial um offerings it could um I just don't have any immediate contacts and I think Jose is trying to as well I think he has contact at universities um uh definitely more than my zero contacts but I think that if anyone out there that's listening happens to say hey I have an I have a high performance Computing machine right behind me in my my garage great reach out like first of why he'll become your best friend immediately my first question is why and the second question is like can we use it well here's the answer why not why not yeah that you know that's just I need a 3D printer some people need an hpvc you know like exactly okay interesting all right well cool Brian I you know it's just it's been two hours already so um I think we you know should wrap it up a little bit I also don't want to keep you too long um but thank you so much for coming over you really answered so many questions it was really interesting with you to dive so deep into life you native and the work you do at doya and uh I also in the chat there were quite some people who um thanked docyard a lot for their work on on Lumen and uh everything so yeah thank thank you Brian for all your your good work you're uh contributing to community yeah I mean this project for me both bringing live native in Beacon in landro is the lead develop on Beacon but yeah you know seeing it through the release I tweeted this out was kind of like my way of making up for not getting Lumen done um I mean there's multiple reasons why Lumen failed but I think the the most important one was I don't think doer was ever the right company to actually bring it to Market in the first place it's too big of a project I think that a Wazi and WM compilation are important but I think that this should be in erlang and we need to find a way to convince Ericson to take that on yeah maybe they have a use case for it and then it might be interesting to them too yeah but interesting I mean also one thing that we mentioned earlier where like I asked you you know is it bad that Elixir goes into all these different um areas and I I also agree that it's actually good for Elixir uh because what what I love to tell people when they start with Elixir is like yeah sure you can build websites with it but you know it's what what about like what if you want to add an AI model to it and you don't want to use an API you want to run your own model right oh yeah here it's just like a library you can use and then oh yeah you want to play run with nerves you want to control some you know some whatever machines from your application well no problem you can do it in Elixir right like well it's like Sasha uri's table right exactly like that is I I've always said that that is the most game-changing like graphic that has ever come out of the earling Elixir space and we need to update it too because there's been a few more rows we can add yeah definitely yeah and and it it keeps on growing I mean there's flame where you don't need Lambda functions anymore like you know it's I already started like double rowing every row so every every row becomes a second row now because there's so many things that I have to add to this table and and uh yeah know who hates flame uh sorry no know who hates flame who hates flame I don't know if they hate flame but but but like the whole like server list stuff yeah took off when all of the cloud like uh providers realized that they can make a ton of money off of it right and so they start pouring marketing money into it and then Along Comes Chris of flame that's saying hey you don't need to spend as much money they're like whoa whoa whoa hold on wait yes you do you need to spend a lot of money with us well I'm happy I'm happy he works for fly and not for AWS yeah yeah no no I 100% I agree with that I I love I love the direction that's taking it's just that I I think that that's those are the type of conflicts we're going to start running up against right is that the world of like like software development over the past 20 years has been highly optimized by people that have found ways to make a money off of inefficiencies right yeah and when we start to introduce the inefficiencies we we [ __ ] up their business and and so you're going to find that the there there's going to be push back on these type of things yeah yeah yeah true but I mean maybe we can use that push back you know and and make marketing out of it no we can it's just like it's Engineers are not good at marketing that's what it comes down to sometimes that that is something that I've experienced uh as well like I'm always thinking like in The Elixir space we we like if you look of if you look at dhh you know of course he's a I guess a good engineer I don't know I I don't know rails but he is he's an excellent engineer okay he's an excellent engineer but I know for sure that he's an excellent marketeer and yes you know like a person who really brings out the message and and you know he of course like people love or hate him but he really always knows how to sell rails and and Ruby with it so I feel like so like I I adopted rails pre 1.0 I know that you know we're trying to wrap up let me just tell the story real quick but I I I was early early rails adopter and that's like how I got to know Jose and stuff I didn't actually know Jose and have a conversation with him until after Elixir but I I got aware of him and that's you know his experience in rails kind of pulled me into Elixir as did a few other things but and also why I went to Ember because of Yehuda was on the real score team but like Jose like there's a few like Tech fluenc out there right now that are throwing shade at dhh because they don't like like the way that he says things or because they can get a response from him and you know it's father yeah the thing is is that like DH H was like Babe Ruth in his Heyday like in terms of like being able to just articulate points in a way that technical people and business people could could get to and no I w't say bab he was Mike Tyson like he was Mike Tyson in his hey day and it it seems my perception is that he kind of took a break from that for a few years and now he's coming back to it and I'm really excited about it I think it's excellent the other thing too is that I think that the Direction and some of the things he's currently talking about if you go out and watch rails world yeah this year it's a really good presentation is keynote but rails World 2023 is amazing his keynote he speaks to all the problems I think that we actually have in Elixir space too and I I think that Elixir and Ruby you know at least from a highlevel perspective should team up in that we're both trying to push forward the same ideas on operational complexity red reduction we don't need these insane front end with JavaScript it's just that we have differences on like you know scalability and you know one language versus another but those are implementation details the high level concerns I think that our both of our uh ecosystems are in perfect alignment on and he did an amazing job of articulating them and and so for those that doubt dhh I'd say watch out because I think that like it seems to me that he's starting to like come back into the fold and he's like okay I'm going to start like really turning on what I can do again and he's amazing at it he's he's great I mean you know the points he's make he's making he makes them really well and they're accurate you know like running your own I mean just like just doing the thing that you say well I'm going to move away from all the club providers I'm going to run it on my own machine you know like a lot of people talk about it but he actually just does it and he shows to the world that it works and he saves money with it I mean you know like is it good or is it bad for your company well it depends on your company right I mean there were other people who also said well I if I hire one engineer uh to run the devops here in my machine you know I already lose all the the benefit that I get from not being on AWS or something but still like the point he's making is like it is possible like you have that option you know you don't always have to run everything in AWS you can also have other options and and I think that is important there and the irony is that rails enabled that whole like ecosystem to come up right so like through Platformers of service uh architecture with Heroku uh cloud-based uh Computing really took off under rails and at the time it was significantly less expensive but then you have some you know idiot with an NBA in a spreadsheet come along and say hey we got these this whole like ecosystem by the balls let's just start bringing our prices up while we're not investing in the hardware and now it's completely lopsided it's gotten to be more expensive in many ways and he's completely right yeah true one fun story that I also would like to add is like um what was it um wall wal right Walmart is one of the biggest cloud providers in the US I didn't know that but they they all build they build up their own infrastructure in their own Walmarts and in their own Regional centers and everything and then they realized oh we have so much infrastructure so so many servers we don't really use we can just rent them out and now you have the Walmart Walmart Cloud that is know that is competing with AWS and so on and you know you can literally host your servers with Walmart if you wanted to you know something seems wrong with that though right it feels weird but you know that that is some stuff I mean if they hadn't invested in their own infrastructure now they wouldn't be able to sell that out and actually make a profit with it you know so it's kind of the same with fly like fly isn't just reselling AWS or they're not doing that at all they built their own data centers yeah exactly and I was at first like first I thought is that really you know what you should be doing but now they also have all these options where you know they can add them all together to private networks because they have access directly to the machines and everything so yeah um yeah that I just wish that their database tiers were better yeah well I mean they have super base now but uh it's already better than nothing yeah definitely all right Brian well again thank you so much for for joining us today it was really really insightful and uh yeah maybe one day we have the pleasure of racing boats against each other be excellent that would be great right time all right all right Brian thank you very much and have a great weekend you too thank you bye bye all right folks that has been the interview with Brian I hope you enjoyed it and yeah if you want to rewatch any of this it's on YouTube twitch still has it we even streamed to Alor uh for the first time and a here that's me I'm live right now um and I'm yeah this is written elixia Alor actually we looked at it for our little project with the twitch clone and and they are pretty cool people so yeah go watch them and that also brings me to the end of this live stream it's been a bit more than two hours and I hope you learn a lot I hope you had some fun and uh yeah it was great to have Brian on right I mean like I wasn't 100% sure how it would go with having a like an interview live so to say you know but I think it went quite well and I certainly learned a lot and I hope you have a better understanding of Life your native as well and what doyo does and everything and it's just cool to see and like how many many how many projects they involve right I mean life native is one of them but then you also have the NX project with Paulo and you have Beacon which is a CMS um actually here the beacon CMS and uh that also hopes to be you know a way of quickly creating your own block and everything so yeah anyway that's all from my side for this week I wish you all a very happy weekend thank you for uh stopping by and yeah follow me on all the socials you can buy my video courses on Indie courses.com I also have a Blog at p.com and I will see you next Monday again for probably life you native again um you know let's just see like let's continue to work on that a little bit you know build our little habit tracker let's see how far we get um but yeah I I feel pretty good about it now talking to Brian he seems to really know what he's doing so yeah I will see you again on Monday have a great weekend and thank you for joining to

Let's code a Habit Tracker together using Elixir and LiveView Native.