Hey, folks, welcome back to another episode of JavaScript Jabber.
This week, on our panel, we have Dan Shapiir.
Hello from a very warm tut a Beef.
We also have Steve Edwards, Hello from the sunny and clear Portland. And Dan, I must say that last week I was down in Arizona at my parents, and I think the weather is more like where you are.
Well, I assume Arizona is dryer. Oh yeah on the coast, so yeah.
Yeah, oh, I say, yeah, it's very very dry there, like one hundred degrees fahrenheit.
Yeah.
My son's on the mission in South Carolina and he was talking about how it gets hot there and I'm hot here and I'm like.
Yeah, and humid there. Yeah.
Yeah, when I lived in Italy that that was the case. Too much more human there.
I'm Charles Maxwood from Top End Devs and this week we have our friend Hadar here. Do you want to introduce yourself or does Dan want to introduce you?
I don't know.
Yeah, I can go for it definitely. My name is a Dargeva and I'm the cito and co founder of Mao Dotev, a pretty small startup company. Yeah, currently at Tel Aviv originally in the past year and a half living in Thailand, currently visiting family and friends here in Tel Aviv. Where have you been in Thailand in the islands, Samoikopanghan took some.
Break, just spent two years. My daughter just spent two years in Chang Mai. I went visited her there a little while ago. But that's not farther north.
Mm hmm, yeah, yeah, yeah.
It sounds exotic, which means I want to travel there someday.
You should, you should, and you actually about heat and humidity till you go there and got this time.
Yeah, but you know, it's really it's really nice when you're combining like our kind of jobs with the tech industry, doing what you know to do with these exotic places and like a kind of not so developed countries. I found it like a really nice.
Match digital nomad lifestyle.
Huh yeah, yeah, good, very cool.
So I don't know who wants to introduce the topic. We kind of had some back and forth on the title, So I'm gonna let somebody else do it because I think I would screw it up.
Now you wanna you wanna set the stage? I think that would be best.
Yeah, yeah, I think I think we can talk today about like a mix and match of technologies in the in the front end area, and with all what's going on nowadays with the AI, with the multi frameworks, with all the things that's going around with the vibe coding, and you know, the builders of the world, and this is also what they were doing in the company. So I found it like interesting, So yeah, let's dig in.
Yeah, it's it's funny because as it happens, I'm literally work dealing with that at the company that I'm working at at Size Sense, where we have this like an overarching framework or view that's like tabed view of shows certain parts of the application. You know, we are a business intelligence application, so you've got a modeling view where you specify the data sources and the data sets that
you're working with, you connect to various external databases. That's one view, and then you have an analytics view where you build all sorts of dashboards and stuff like that, and they're all implemented. It's like tabs in the main page, but in reality what they are are distinct effectively Web applications, and that main framework loads the when you enter a specific view, it needs to load that view on demand, and that view might be implemented in various different frameworks.
For example, the modeler is implemented in React, the analytics one is kind of legacy, where in the process of replacing it, the current one is still implemented in Angular, and there are other views implemented in other things, and even the customer can add their own custom views that they can implement in whatever they want. So that seems to be exactly the scenario that you're talking about.
So in that scenario that you're presenting, how you actually implemented it.
Well, you know, one of the reasons that I'm currently looking at it is that it was implemented in a legacy sort of way several years ago. So it was a hand built kind of framework, effectively built using native JavaScript and dorm operations. They kind of based it on the now defunct Google Closure library, but they mostly did it by hand. And I'm looking at ways to modernize it, and I'm thinking about effectively looking at the possibility of reimplementing the whole thing and React. Yeah.
Yeah, So it sounds familiar like a lot of companies facing these kind of issues, either creating like a manually bridges like you mentioned like understanding, all right, our host application is React or Angular, and now we need the other one. So let's reach between them, which lead to, first of all, a lot of time spending. Right, you need to invest in creating those bridges versions specifically most
of the time. Right when React nineteen or twenty published, you need to fix your API and do whatever things or Another variant of implementation that I'm hearing a lot is like loading kind of microphone and in iprams. Right, this is another things that are going on for.
The problem with microft we're using. So one option is, like you said, I frames, but that creates a really rough separation. It's more much more difficult to pass data back and forth. You don't just pass props into a component for example, but it does, like you said, it does create a much like more hard and clear separation between the container the containing. Another option that used to be talked about a lot. I'm hearing about it less is web components that you wrap the internal thing in
a web component. You create a separation that way, but they actually still live within the same frame, so it's less of a segregation between the two. And you can do all sorts of things with the module federation, I guess, and even the built in import mechanism that you have in modern browsers yea. And if you look and if you look at advanced loaders like VAT and stuff like that, they can do a lot of the heavy lifting for you as well. So I just to finish the code
that the legacy code that I'm looking at. They actually did this. They're kind of an old school way. They didn't go with iframes. Instead, they kind of forced up the scripts that you want to load to be placed in a very hard coded sort of way in certain folders and using certain names and that way. It basically just creates script tags on the fly and loads it this way. Yeah, Chuck, sorry for interrupting. No, it's fine.
The question that I have with this because it seems like, you know, these are all solutions to Okay, we kind of started in this way, you know, maybe using a framework or inventing our own framework, and then wait, you know, we realized that we might be able to be more productive or get more of what we want or whatever
from another framework. And then you know, maybe you're segregating between versions because there are reasons why you can't upgrade the one piece to the other piece, to the same version of whatever you're using Angular or React or whatever, and then you know, maybe you start to migrate to use another technology, and so I can kind of see
how you would wind up coupling this together. My question is is that are there people that do this on purpose without having all the historical stuff where they're saying, you know what, we need a little bit of this from React and a little bit of this from View or a little bit of this from you know, one of the other, maybe some of the smaller frameworks, and so you know, they blend them on purpose to get
some mix of what they actually need. Or is it almost exclusively the other thing, where it's we've got a ton of legacy code and we don't have the time to migrate at all.
So from my perspective, I think it's mainly the second thing. It's a not must to be legacy. But even companies that you know, both other companies are integrated with other projects or companies that decided a I don't know, to implement, like to move to a new new framework and the kind of a legacy is not too old, but now they want to share components and experiments and and yeah, and UIs between those two.
The one exception that they can be sorry, just to mention that it can even be different versions of the same framework, like if you're life you're large enough organization. One a group might already be on REACT I don't know nineteen and another one is still stuck on React seventeen, and it might be problematic to run them both in the same page.
Yeah, I mean I can see the same thing in the view world, where the transition from view to two to V three is fairly substantial, even though you know B three has backwards compatibility for the options API, but you know they're if you were going to make an upgrade like that, it would be a substantial thing. So it's perfectly you're not out of the question, you know, to think of you two versus Q three. You know that ecosystem.
So is there ever a reason to do this on purpose?
So the one exception that I can say in the area that we are now experimenting is that more people or more machines start generating code. And I'm referring to the AI, right, So let's say that now you have a view view JAS application and you are fine with it. Everything works great. But then you go to Gemini, for example, and asking to generate some component. Gemini exclusively said I cannot generate view components. I can do it in React or in pure HTML. And now what you are doing
you are stuck. You either get the output as an inspiration. All right, I generated something really quick, but now I need to rewrite it in my framework, which is View. And by the way, same go with Angular, Same go with swelt right, which can be a great choice for some companies in some projects, but now they I limit them. So I think in this scenario you can in purpose want to mix a match.
Wait a minute, so let me go back to you saying that there's some AA models that can write code in some frameworks but not the other.
Yeah, I was going to say. My experience with this is not that it can't. It's that some of the models do better with some languages or frameworks than others. And so if you're trying to vibe code yourself something and you want to do it in Angular instead of React since it's been trained on so much more React, since that's kind of the dominant framework, you may not get great results from the Angular and it may take
more work in order to make it work. If you're not familiar with ANGULAR, you may not recognize that it's giving you garbage or giving you something that won't entirely work. So I could see that being an issue too. But that's my assumption is that, yeah, it's not going to tell you I don't know Angular, It's just going to give you something that isn't as refined.
I've yet to Gemini situation. I've had to think, got to a situation where a model told me I don't know right. Usually it doesn't. Here you go and it gives me something totally wrong. Yeah, totally.
It'll make some things up. Yeah, it will make things up, rather than admit that it doesn't. I saw a news story, you know, along those lines. I saw a news story but recently, where a judge had to punish an attorney because he submitted a brief that was obviously written in AI and it had submitted. Rather than say, there's no cases here to back this up, it hit a generated cases from the past that didn't exist. There's like it was obvious that he just did this. Nay, I submitted.
It didn't even bother to do any research to make sure that these cases that were referenced in supporting documents even existed. Well, so you know, and it's like, so AI, it seems like it's programmed to not be able to say, sorry, I don't have anything here, but instead it makes something up. And that's not the first story I've heard about that.
Well, you have to realize that the large language models, they don't function by saying what do I know?
Then?
How do I tell you?
It functions by saying, you know, you gave me this prompt, Here's what I think the first word is going to be. Here's what I think the next word is going to be. And it just keeps going, Okay, given that I wrote the last paragraph, here's what I think the next word's going to be. Right, And so it takes what it's already written, and then what's the most recent thing that it's written, and it just kind of continues to build
onto it. And so what it essentially did in that case is it said, you know, it had been trained on all this stuff, and so it just assumed the next model or the next token in it is as stated by this case, right, and so then it it fills it in and so it gives you it makes it up because it's just predicting that next token and it's not giving you any real information because that's not how it works.
And that also means that when you've got more examples of certain frameworks, say React, right, fewer examples in another framework, say I don't.
Want more better examples, yes.
Or swelled or something like that. Sometimes it works the opposite, because sometimes you've got fewer examples, but all the examples are really good. In that case that actually that's actually a benefit. But in some cases there might not be examples of the actual thing that you're trying to achieve, and that might be a problem. It's sure I meant something.
I'm not sure I know to explain it. But the scenario that I mentioned actually happened to us a lot with specifically Gemini. Gemini refused to generate components that are not React and check all the things that you said are, yeah, we know them, like it's how the LLMS work. But probably Google or I don't know, put some extra layer on top of it in order to that happens to you, Yeah, don't give you garbage or something like that.
That's interesting because I just use Gemini to rewrite and view components or to create a you know, components with a specific style. And you know, I said, here, this is what I'm looking for, giving me this, and it did and you know, to tweak it, modified and stuff for my knees. But it's sped out.
You just I.
Think yesterday Angular So yeah, yeah.
So weird. But yeah, this is what happened to me yesterday preparing for some meetup talking about you go to Gemini, ask for pretty simple component like a video player, and it's refused. He said, I can give it to you in HTML or in React. I took a screenshot of it and presented it in their meetup later.
Is that what's called framework discrimination? And maybe I'll give that a delayed Sure, there we go.
We know that certain you know, in a different context, certain models have certain political orientations that can be amusing anyway, going back to tech, So we have a situation where we have a certain component in a certain framework, let's say, despite a lot of the you know, let's say the rest even of the application being a different framework, maybe because it's leg the code that we don't want to touch, maybe because we it's two companies merged and one was
standardized on one framework and another on a different framework, or maybe like you said, because I Vibe coded it and that's what the LLM gave me. Whatever the reason I've got, I need to connect code us that implement a component implemented in one framework into an app web application implemented in using a different framework. Okay, what do I do?
So the things that we found the most effective is again to mix and match, mix and match solutions, and you mentioned most of them, like you maytion the IPRAM which is limitation, which is the communication and the fact that you cannot pass non serializable object there because you need to use the post message API. And you mentioned the web component right, which up until recently like here, here andF or something like that, what's really really limited,
Like React didn't fully support it. View just supported it fully even a half ago. By the way, Angela was pretty good in it. But today with the release of a React nineteen, all the three major frameworks are support web component really well. Like you can really easy take your existing component and wrap them most of the time with the framework Helper View publish their own and Angular theirs to wrap it as a web component. Then you are eliminated a lot a lot, a lot of USSEL
because you are talking with pre bundled assets. We're taking care of all the loading, all the styling, all the isolation. You can define and we can deep dive into it into the different modes. Right, we shadowed on without shadowed, open shadow dome, closed shadow doome. But once you run this component, you can pass props in and out. The components still a reactive and can manage its own state.
And once you write a component as a pure component and not mess with global object or global states, you good to go and mix and match between them.
So you're suggesting, if I understand it correctly, to take let's say an existing Let's say I want to embed an Angular component inside of a React web application. What you're suggesting is I take the Angular component, wrap it inside a web component, and then host that web component within the React application. Is that what you're suggesting.
I'm saying it's a good way to start. Like, first of all, let's take your scenario. Angular support like wrapping it for you. You shouldn't do much Angular just expose a helper function called a web component. Then just give it your component existing Angular component with a string attached to it. To define the new tag name, bundle this application into a JavaScript. Once you load it, the component will appear every time that this custom tag will append
to the dome. It's not a bullet proof solution, and we can deep dive into the limitations and edge cases, but it's a good way to start.
I was going to ask what are the trade offs, because yeah, it sounds like you get some isolation and nice stuff out of it.
Yeah, so what.
So the downsuns that out of the box, you're not getting any model sharing, right because if you wrap some component with the Angular so it came, it's coming with the Angular. So the bundle includes the framework that it depends on. If you're loading only one bundle, it's maybe okay. But if you're trying to build like a robust system with a lot of sources for components, you may ended up by loading on seoul Are multiple times or loading React multiple times. Right, So this is one thing that
is not coming out of the box. Second thing that pop into my mind is that you need to dip a bit into in order to pass like complicated props, which is not strings because web components is domb elements dom and HTML is string based, so if you are passing string let's say name, last name, phone number, you okay, you just define it and pass it in the HTML. Once you want to pass functions, objects, call backs, things like that, you need to start and understand how the
mechanisms work behind the scenes. But again it's a gaps that those frameworks closed and covered in the past few months.
To be fair, you can pass like you said before, you can pass serializable objects by serializing the object into a JSON string. But yes, it certainly does limit you in what you're able to pass back and forth. If you want to pass some sort of a callback, which often you do because you usually want that particular application to somehow impact its container, that becomes tricky.
Yeah, first of all, totally right. When you're trying to press functions, stringify will not help you. And on top of that, with a large object you are not You don't want to always serialize them as a string and then de serialize them because you're going to harm the performance. Right, you want to pass the real object. So again it's possible, but it's something that you need to understand the mechanism
behind the scenes. Like it's a few lines of cod but you need to understand it, how React did it, how Angular did it, how View did it. And if you want it to be seamless, like I'm in React hosting Angular components and I just want to pest props in my J six, you need to understand like the mechanism behind the top.
Then so go Chuck.
I was just going to say, you know, so let's say that I do this right. And so I start setting this up and I start sprinkling some Angular in my React or you know whatever, and I start seeing, okay, you know, it loads the Angular six times because I've got six components in here, or I start seeing some of these other trade offs start to rear their heads. How do I start to mitigate that so that it's not so heavy on my application?
Mm hmm.
Yeah.
So you can start really simple and just define that your host applications support an API to load Angular and then on the bundles will depends on it, so they will they will arrive without Angular, without the framework asking the application to provide it. Once this is one one option, then you are keeping yourself the freedom that the ot application control everything. If you want to be more robust and agile e quid it, you can put in a solutions like federation right, which will do it for you
and wrap things for you. Again, not a bulletproof solution because Model Federation, even in the last versions, depends on some kind of notion what's going on at the bill time.
So episodes in the past about model Federation, but I think it's definitely worthwhile. It's been a while, so I think it's definitely worthwhile to explain, to give at least a brief explanation of what model Federation is and how it works.
You want me to go ahead or yeah, go for it? Cool? Yeah, So model Federation is a set of tools. It's a library set of tools that helping us as developers get into our build as a bill step. They supported they started with the webpack. I think that now they also supported the fit and they bring us set of tools to identify and federate models that may be shared or lazy load, identify them as like this, like that, and then extract them into common bundles, which, just like chuck ask,
can then be loaded only once. But again it's come with limitations because in order to do so at bill time, you need to know what's going on at bill time. So now if I want to mix and match components, I maybe need to organize them in one mono report, which really limits me.
Right, So, just to clarify, going back to model federation, perm my understanding and feel free to correct me if I'm wrong. Model federation is basically taking the concept of dynamically loaded modules and enhancing them with the sort of a global lookup table, as it were, to ensure that when I load a particular module, I only loaded the one time, and I I shared across all the code or components that actually need it, rather than having each
and every one of them load the module independently. So basically the module is loaded only once and then I just get the reference to the already loaded module, rather than each time loading it again and again and at the very least rerunning the initialization code and stuff like that. The other thing is that it's kind of supported by the bundler that I'm using, maybe with a plugin or extension or something, so that I don't have to think
about it. It's kind of done automatically for me, that it identifies this distributed reuse and hooks up everything automatically for me, that my code just assumes that it's a regular package that I'm us using and there's nothing special about it. Is that more or less and accurate description from your perspective? Yeah?
I think that by default they are not identified as globally. As you mentioned, it's an option that it's really easy to plug in. It's not a default behavior, but yeah, it's definitely part of your billstep running on your application while it's being bundling and replacing the imports, and instead of putting them inside your bundle, let you the ability to load them from remote right.
Okay, So you're saying that one option is to use model Federation in order to avoid the reloading of common resources and in this way make management easier because it also finds the resources for me. I don't have to worry about putting the resources with special names and special places. It does all the wiring for automatically.
Yeah. Yeah, yeah, And in the case that you are going to load a lot of bundles that may share dependencies,
it can bring you benefits. Yeah, definitely. Again, not so easy to get to get those results because you need to know in advance at build time what's going on, or to manage a lot of building hints for that if those cod chunks are not sitting together, you can still achieve it, but you're going to end up messing a lot with configuration and hinting Jason's telling the model Federation that assuming that, assuming this.
Okay, and model Federation is usually something that I get, well, not totally for free, but I get it from the bundle that I'm using.
Yeah, but in my perspective, it's far from free. It's really hard to integrate with like it's working, and it's working very well, but it's not easy to integrate. Developers that I'm talking to struggling a lot with putting model
Federation into their project and use it efficiently. So I think there are several several reasons for that, but I think that the deep understanding of what's going on on your bundler in order to use model Federation is something that most of the development developers nowadays are not in this time in right, you are creating the project, you're
putting the infrastructure. Maybe it's not even you that did it, and it's happened months ago, and then you need to do something, but you already have I don't know, tailwind plug in there, and you have CSS models and you have a bunch of things there and you need to come and reopen the infrastructure and understand the build step and the bunding steps. And as I mentioned, maybe you need to now reorganize your code into a big mono repo and share dependency between them. And maybe you don't
even understand how mono repos works. So developers that I'm talking to understand the benefits of model federation. I personally I think it's a great tool, right, but it's hard to adopt. It's not something that you know, you're just taken out of the shelf putting in your project and its walks.
So I guess the question that I have is, as we kind of go through how to do this, are we going to be talking more about Okay, well, you know, first, you know, you take the step to you know, wrap your stuff in web components, and then you solve this
problem with model federation. Then you solve this other thing that might come up with some other tool technique or thing, or is there another better way that I guess you know, you said your first step is to you know, separate things out into the components, But you know, is there like an alternative strategy?
That we're eventually going to bring forward.
It's where it's Hey, if you run into this or you get past this, then maybe you consider just doing this other thing altogether as opposed to this. So I guess my question is are we going to just keep fixing the strategy we're on or is there an alternative that we're going to eventually explore.
Yeah, so a great question, and I think, as I mentioned, there is several solutions. None of them are the golden one, but we found the mix and match the best approach. So web component is one really really.
Robust one.
Once you get into the right tooling around it. We can deep dive into the problem if we wish, and talk about more things there. But I can also talk about another approach that we are play with which work really nice and solving what done just mentioned before with the iprams. So don't talk about loading like a kind of microphone and or sub parts of the page in
an ipram, which give us a really good day isolation. Right, we shouldn't deal with global objects with sssss with everything, but then we're limited to the objects that we can pass between the sides. Right, due to the API of post messages and course, O region and all of these. But think about what if we can generate iframes in
our domain dynamically, right without selver involvement. If you can have something on the client side that can generate iframes or what I call local frames, which actually be an IFRAME on our domain with the uipart that we wish to isolate, right, So we're going to get the benefits of iframe, all the isolation, right, but without the limitation of not being able to pass data in and out because iframes in the same domain can be interactive both ways without serializing the objects.
Yeah, I think it's worth explaining the distinction. When you've got a page of hosting an I frame, that I frame can be a page from the same domain, and obviously it can be a page from a different domain. It's totally valid and legal and in fact something that
happens a lot now when page is from it. When the I frame is from a different domain, the containing window object cannot look into that EE frame, and the code in the eye frame cannot look out, and the only way in which they can send message back and forth is via the mechanism you mentioned before, that which
is post message, which is in an asynchronous mechanism. It's kind of similar to events two dominvance, but it's asynchronous versus synchronous, and you can you're limited to what you can send as a post parameter, which is essentially string serializable object or an air or in a byte array can also be a byte array, but that means that if you want to pass an object in or out, you kind of need to first serialize it either into a string or into some sort of area of bytes,
then send those and then de serialize the data and deal with it. It's kind of similar to how you send stuff back and forth between what's it called webworkers. If you send stuff into webworker, it's essentially the same restriction,
the same sort of exact same sort of mechanism. On the other hand, if the I frame is from the same domain, then you can look into that I frame from the outside and also from within you can look out, so you can, let's say, from within, you can look at the window dot parent, go get to the parent domaint domain and basically call functions directly and pass whatever you want. Now, it does create all sorts of interesting things like arrays are not necessarily always identified as arrays.
This funny stuff like that. But but generally speaking, you can pass JavaScript objects back and forth without a problem.
So this right the way, yep.
And it's synchronous, which is also important. Yeah.
One question I have with this is you said you could do it without involving the server.
So yeah, client, it's totally client side. It's it's it's code. It's one JavaScript function calling another JavaScript function. It's like JavaScript functions within the same page.
No, I think Chris is carrious. How you load an eye fram child? Sorry without selver involvement, And yeah, this is an interesting technique, but it's possible to actually if you already holding or have access to a document content. Let's simplify it to an HTML page. If you have the string on your hand, you can on client side create the frame and inject it to it right without selver involvement. Ie, frames that you will create on the client side automatically will be treated as self domain the
same domain. Yeah. Yeah, it's a technique that we used to use.
Yeah, it's a technique we used to use a lot in the old days when when the dome was not as dynamic and you had all sorts of restrictions and what you could do inside inside the page. The way to kind of get around it was to create eye frames and put whatever you wanted into them. So it's a reuse of an old technique.
Yeah, so I can kind of see that, you know. Yeah, the web component approach is kind of a quick and nerdy thing. It's definitely simpler than this other technique. So, yeah, is there a library that does this or is there some other Do I kind of go and invent it?
How do I do that?
Yeah?
So, as I mentioned, we're dealing with those issues a lot in my op our company, and we're providing tools also for that. We're suggesting different solutions for different needs and for I firm a treatment. Yeah, we have all those kind of tools. We solve the communication issue as we can paest data in and out with the same domain or with different domain. We're taking care of executing functions and automatically serialize the response and requests for you.
We also created a mechanism to create a component kind of API by under the wood, render local frames and register for things inside them. And I can mention maybe it's interesting in which use cases we see it's relevant to use, and I agree with that. This all kind
of all technique. I think that taking an HTML and just wrap it in a frame and then communicate with it can be really relevant when you want to take like the now pretty messy generated code that all those Vibe coding two can give you, right, all those gemin igpt a cloude and just in a matter of seconds turn them into components which you can first of all communicate in a safe way, right, but also you can be trusted that whatever day I did on the global object,
on the window object, on whatever will not affect your application, right because you wrap it inside an eye frame.
Yep. So main advantage when I compare this technique. So we mentioned before the technique of using just web components with the shadow down for example, for in enhance, if we need enhand segregation between the component content and the external web application. So what's the advantage of using this sort of self created eye frame over using a web component. Is it the fact that you've got more significant segregation between the code or other additional advantages as well.
Yes, so web components, even in the usage of closed shadow dome, are actually encapsulating mainly the dome and the CSS. The JavaScript is still running on the same realm and can still access global objects. Right, So if for example, I went to I don't know any outsource coder, it can be a developer that's not working in my company, and it can also be a I tool and I don't know he took the window door title and changed it.
Even if I wrap it in a web component, it will actually gonna change my document title, and once I wrap it in an ifram, it will be limited to the iframe that I give him.
Right, they can stay well. Obviously, if they do window door title, they'll update the iframes title, which effectively nobody sees, and that doesn't create any problem. But if they are malicious, then they can do window dot parent title and get at the actual title. So it's less about it seems to be less about malicious code and more about avoiding accidental functional leaks or am I missing the point? No?
No, you're You're totally getting the point, And this is why it's not so sympi between the two. Yeah, yeah, I can tell you that in our solution, of course, we tackle this issue, and the object and the access that we are allowing to execute inside these local frames is limited, limited to what the user configurates in our dashboard. So yeah, you're definitely right.
And again, so you create this kind of separation that might not necessarily automatically exist.
Yeah, yeah, again, there is no one under.
In something could do something like override the window dot parent I guess, or something along these lines.
Right, and allow to pass only what agreed before right, only what agreed to be the contract of the component, which later on wrapped nicely as props.
Right.
And then from the host perspective, I maybe know that it's an iphrame if I'm the one that created the component, or if I look into the dome. But in terms of the way that I'm writing my JavaScript, it's really straightforward.
It's component dot load and then I'm getting you a component, and I can pass props in and out right, And even if the component inside tried to do something malicious, again not one hundred percent, but in most of the cases we can block it because we already mopped a monkey patch the specific object that can lead to those issues.
Yeah, I'm imagining that they're probably a wide array of reasons why you may or may not need the tooling that you're offering from your company. I mean, if if it's all internal, and you know, I can mostly just use this technique with the developers work for me, and you know there's a certain level of trust. Then you know, maybe I don't need all of the isolation, and I can kind of build the tools in that I need.
And then you know, if I go beyond that and I feel like I do need some of these features, that I could go and pay for a product, which is something that I find with a lot of programming, right, And so at some point it's like, okay, look, the trade offs are just you know, it just makes sense
to pay for this. My question is, you know, so as I if I started implementing this myself and I start putting some of these features together, what's kind of the bare bones reality of using this, Like what what kinds of things am I going to have to build into it to get it to work without necessarily having to go to a paid tool.
And so I think we talked about some of those issues, right. We touch some of it, those things with the web components, so we touch some of it in the terms of fact creating I frams local frames and I frams, And I think it really depends on what you are willing to build, right, like, you will face or not face specific issues based on whatever you how advent event advent is your need, right, right, Yeah.
I think I.
Was specifically curious about the local frames and just you know, so if I if I decide to implement local frames, you know, yeah, so I can mention.
I can mention yeah, yeah, so I can mention some some like really really things that probably will need you to solve. So, as Dune mentioned, once you're implementing an eye frame that's sitting on the same domain, Yeah, you can access the parent and can access the inner document object, but you do not really want to write. You want to work with props and ref and types and everything.
Right.
You probably want some kind of a life cycle of a comp it, right, which may be different from the life cycle of the document inside the web page you loads. So you need to create some kind of an API and a mechanism to make it for you.
Right.
You want to have like a kind of mounted on mounted right, which is not necessarily the unloaded the document unloaded right inside the component. Maybe there is more things happenings there. Lazy load their states loading things. So you want to be able to have on mount function, and then you want to pass props and be able to catch them on the other side and right and react to them. Maybe you want to bind specific props input
props into elements on your screen. Right, So life cycle events on mount on unmounted things like that is something that you probably will implement by end if you will not use a library.
Okay, Yeah, So basically what you're giving it is a component like facade, the services that or the callbacks or the life cycle that we expect to see when working on a component, stuff like on mount on update or unmount, stuff like that, which, like you said, don't necessarily easily map into DOM events even if you're using an I fray right.
M Yeah, this is one thing that I can just you know, really straightforward. But I actually want to diep a little bit into what you said about the trust between the one that created the component and the one that used the component, and I want to put on the table something that I think is relevant for the Again, THEI ERA which maybe the other side that creates the component is not a developer, right, because you said if we trust the developer or not trust the developer, which
is kind of a solved issue. We need to trust the developers that we're taking code from. Right, we shouldn't go around and around. But what if we want to be able designers or product managers inside our organization, Let's start by that to create components, right, so they're not known how to code, right, the product manager will not contribute React components for us, right, but it can Vibe code something right. And while the Vibe code something, maybe
there is risk there. It can be performance risks, it can be security risks, can be global states a risk not necessarily malicious things, but maybe things that he made by mistake. Maybe it's something that the tool leading lead leading to do right, messing with I don't know, with the global object, messing around with the mocking critical functions, things like that. So the question of trust changing a bit if we want to put more roles into the ones.
That creating components, which I found really really interesting, is really something that's going to happen while they are becoming more and more because product manager and designer already creating mocking and things with Vibe coding. Right, a designer are using a figma to code and start animating and playing around with their designs. But maybe the gap between taking this mock into production is not that big as we see it if we put the right tools and write
checks on top of that. Right, because at the end they generated valid HTML and valid JavaScript.
Right, you're saying the greater isolation is required because the code that was VIBE coded by somebody who's not necessarily a developer, runs in the exact same context and the exact scope and the same permissions that the container code is running in. That can create all sorts of not even necessarily malicious security issues. It's more about potentially just collisions, because that's it's a question of the quality of the generated code.
Ye. And I'm suggesting this kind of model because we're seeing how the I is progressing, and it's progressing very very nice. But until we can you know, just put cursor into our ide and it will do everything. I think that we can already start using THEI output, not just for mocking or prototyping. We can start and take some of it output and use it in specific use cases in production.
Okay, And for that, in your opinion, the optimal solution are those self create to die frames.
No, so I already told like the mix and match in most of the cases. In our case, we're analyzing the component. Once we get a component from AI, we're analyzing it and then if it can fit the web component structure, we're preferring the web component, right, because web component several side, the web component can get better performance because they're running on the same realm. Web components can extract and extend their visual scope out of the rectangle.
Right.
There's a lot of there are several benefits of using web components. But we know, and I'm putting it on the table, that not all the outputs from AI can fit this specific model, and then we need to extend the solution and also in some cases use local frames.
So can you give like one example of where your analysis might look at the generated code and decide, hey, not going to use a web component, I'm going to use an I frame instead. Can you give you such an example?
That's what I was going to ask, m M.
Yeah, I think, like.
So the easiest I'm imagining that you could also have a confident developer do this in a lot of cases.
Yeah.
Yeah, So we're doing a bunch of checks and analysis there, but the easiest one to describe and talk about is like, first of all, We're looking for how much global object interactions is inside a component, right, how much touches of window document and things like that the component that the code is actually doing. We're also looking for an HTML tags which are not valid inside web components, for example
the HTML tag right, or the head tag. We're then looking inside those tags and try to understand what's going on there. If we had an empty head tag, maybe we can just drop it and the component will act the same. But if in the head tag there is style loading, phones, loadings or things like that, maybe it should be inside an IPRAM so the fonts will be loaded correctly.
Right.
Another technique that we can do, again, not in run time, but on analysis time, is render the component both in IFRAM and in web component and look for the difference and understand or right from the original inputs, what are the outputs when we render it in a web component and the browser already remove whatever is not supported, versus an iframe which support everything. Right, And this is even before we're asking AI to analyze the AI.
Right.
Of course, with this we can play for I don't know months, right, asking the AI to analyze the output of AI. But I'm just talking about analysis that we're doing like traditional way.
Right, Yeah, I love a AI inception. To take us off topic for a little bit. I recently created the rule files for some projects for use with cursor, and obviously the step before last is to tell cursor, hey, look at the rule file, try to make it better. It's the step before last, because the last step still needs to be you going over the rule file and making sure that it says whatever you wanted to say. But yeah, there's definitely that inception thing of using AI
to analyze the output of AI. So I guess that's definitely something that you can and should do as well. Is that what you described is code that was perhaps generated by I scan that using AI to make certain decisions and maybe modifications because you know that it's going to be using a somewhat different context, and maybe the original creator explained to the AI that generated that code initially.
So we're kind of coming up on our time limit. I just want to make sure that we're covering anything else that needs to be said. If people try to implement any of these strategies.
You know we can talk again. We're walking walking on it for for more than a year. Of course, we cannot cover everything. But I think if you want to to the audience to take some things to keep in mind from this talk is that don't be afraid to mix and match. Don't be afraid to try right, especially in the in the area that we are at. Rewrites are something that becoming less and less acceptable, right, and code start being generated really really quick, and so try and use.
Just not so Yeah, here's the thing.
It's interesting watching his body.
Yeah.
No, but I have two issues with what you said. First about the mix and match. Mix and match is a great idea when you're productizing it. When you're creating a specific solution, particularly for this problem, then you can definitely invest the effort in achieving a best of breed type solutions. But when you're building a homegrown solution, generally you'll just go with what works. It's fairly rare that I've seen people creating all sorts of sophisticated fallbacks for
homegrown solutions. So that's about that part. Other the other reason that I was nodding is that I actually think that in the age of AI, we're actually going to be seeing a lot more refactoring that we have seen in the past. It might be problematic refactoring, but it's still refactoring nonetheless. For example, I have used AI to refactor legacy class react components into functional components that use hooks instead, and the AI seems to be pretty good
at that. It's you can even tell it like take custom logic and move it into a custom hook, and even break a very long component into smaller components that are dedicated to particular tasks and stuff like that. So I think that refactoring is actually getting easier than in the past. Now you probably want to have a really good suite of unit tests before you do that, because the refactoring that the AI might do might be total junk. But the great thing is that the AI can also
generate unit tests for you. So before you start, you tell the AI, hey, look at this code, generate unit tests for it. Obviously, make sure that the tests actually passed, because I've seen situations where AI generate unit tests. Yeah, it generates unit tests that don't actually pass. Sometimes it's it's it can actually be smart enough to run the unit tests, fix them while they are not passing, tell
you hey, they all passed, and now they're good. And then you run it and you find that they don't all pass, which I've definitely seen as well, so be careful with that. But the process that I've seen about refactoring is first generate unit tests if they don't exist, make sure you've got good coverage, and then tell the AI, hey, refactor my code. You'll probably need to do a lot of manual refactoring afterwards as well, but a lot less
than you might have otherwise needed to do. So that's what I'm saying that That's why I was nodding my head when you were saying that we're maybe going to be seeing less refactory because I don't necessarily think that that's the case.
Yes, maybe I also want to just I want to add that the models are pretty good about picking out patterns and so, like Dan said, you know where you go from a class based component to using hooks, you know, it can pick those patterns out and then say this is the logic I need to keep, and then and then kind of rework the pattern around it. And yeah, some of your more complicated stuff, it's going to kind of gag on a little bit and give you something
that isn't quite right. Yeah, a lot of these tools and the other thing is is that I still I have yet to find an AI system that won't just answer my question even if it's wrong or partly wrong. And so if I if I want to stay in view or stay in Angular, or stay and react, I haven't seen any instance where that's been an issue at all.
Just to answer to to relate to what you just said, Chuck, I treat models like a very junior developer that has the confidence of a super senior developer.
That's so true.
Yeah, yeah, so but Hada, we were kind of of hijack the conversation. So what's what's your TAKEA yes.
Solar job, No, No, it's okay. So I'm totally treating AI and the models, as you said, done like a junior developer with a confidence. And this is why I personally and this is what I'm promoting, treating its output as something that we need to suspect and we need to isolate and we need to integrate in our products like he's like, as someone that we are not trusting. Yeah, trusted a.
Yeah.
And on top of that, and the reason that I'm suggesting to load it dynamically is that because I'm treating these components and this output as something that's gonna be changed rapidly. Even if we got a component that now work, probably it's gonna be changed again and again and again due to product requirement or due to issue that we will find later. Once we put it in dynamic loading, it's become really easy. And this is why I'm suggesting doing it outside of your project. It will be much
more quicker. The AI will have much smaller scope, so the results will be better. And this is what I'm suggesting that, this is my take on the current state, instead of just taking Cursor into our project and I don't know, vibe code with tons of prompts, just to get a small change with our conventions and ways of working.
And keep in mind also another another small small thing on that, remember that as better as Cursor become, it's still going to help us as developers and not the citizen developer that we talked about, right, the designer designer will not install ide and put commits for us, and it may be go to base forty four love a Bell Gemini and generate components. And in myp we're seeing it in life with customers.
Yeah, I really like what you're proposing and what you're saying the fact that we are much more likely to vibe code an actual standalone application than to vibe code a new component into an existing application, especially in existing legacy application. And if you can create a mechanism that allows us to safely vibe code components and then integrate them into an existing application without being afraid that you know, the whole thing will backfire and crash our entire thing,
then that's certainly something that is valuable. And I think that I'm finally really getting your value proposition at it work.
So, just out of curiosity, how is this different or is it different from something like Astro that allows you you know, it's a tool for statically you know, generating a site, but it has the quote unquote Islands architecture that allows you use a view component or an angular component, React component, orbelt or whatever it is. Just I mean, is there what's the comparison contrast between those two between what you're talking about and what Astro does.
Yeah, so there is similar parad to paradrigms there, but there is a lot of difference. Astro doing everything not lazerloaded, right, Like you're putting all your code together, you wrap it, you bundle it to ship it and it's handling fermals. Again, it's not and it exists much before. It's not treating AI outputs or treating a component as something that not a developer can create. Right with my op with first of all putting the lazer loading and the dynamically on top.
Everything is dynamically loading and run time loaded, resolve unloaded. We skip this part. We also support like segmentation and a bit test due to the fact that we're lazyloading everything, but we also support we're putting a really really efforts and look into taking components that's treating by non developers and turning into developers standard. Yeah.
I think the key difference Steve, because I think your question is excellent because certainly an overlap, Like you said, with the ASTRO, you can easily load things dynamically. It's just a flag that you put on a component in ASTRO. You can mix and match different frameworks within the same page. That's all. That's all good. What you don't get though, is that level of isolation between the components on the client side. They all they all just run within the
same page, within the same dumb context. There is no isolation and Consequently, if you've got you know, one one of those components being vibe coded and doing crazy stuff for the window object for some reason, or doing weird things with React that that might interfere with other React components on the same page, that's that's not something that that model can will necessarily save you.
So where okay, So then if we're dynamically running and you're talking about lazy loading, always side note that term always cracks me up. I don't think it's really accurate. But it's more like efficiently loading if you ask me. But I'm guessing that my.
Perce is I just to say that, you know, software development is that field that teaches you that procrastination is a virtue.
Doing things at the last minute. Right, But I'm going to guess that where does SEO concerns come in here? Because the whole point of something like you know, static the generated astrotype stuff is that it's available for the bots when they come around. And I know that we've talked to Devrell's from Google Search here on this podcast where I've asked that specific question and they will say, well, you know, it's complex and we really can handle that.
But that's always sort of the underlying issue for you know, if you want to be discovered on the web is is you know, the bot's got to be able to find your your content. So if you're doing it at the last minute, how does it impact that.
Yeah, so it's a great question. I can answer it shortly that we support also running our dynamically loading record it. It's not lazy loading. We also support dynamically loading things on the server side. Right if your component is something that can be rendered on the server side, for example, React bundle or just a pure HTMN that you took from one of the models, so we can render it on the server side and put it as part of
the document that we're sending. By the way, it's one of the last modifications and changes that made into web components that web components can now be streamed directly on the server and then hydrate it later. I think it's a year ago or something like that.
All right, I'm going to start heading us toward wrapping up because we're we're at the end of our scheduled time and I want to be mindful of if anybody has anything else.
That need to be which I do.
Are really quickly. What is it that your company actually offers. Because I'm imagining somebody's listening to this and going, Okay, I understand what you guys are talking about. I don't want to figure all this crap out. So what do you give people if they come and use your solution?
Yeah?
So my dev is offering like open source, a free meta frameworks decay that can be integrated inside any framework react View, Angular or legacy Pere JavaScript, and we offer a saasas solution, a dashboard to manage all those components with visualization, with ability to manage a B test segmentation, gradual rollout and roll back. And then we actually monetize on the dashboard.
Right.
For companies that are looking to run inside a closed network, we are offering an on prem solution. Yeah, so this is kind of the thing. A dashboard that manage and orchestrate microfont and operation in twenty twenty five, right, and a set of SDKs dealing with all of that and solving the issues that we talked about and much more.
Awesome. All right, Well that's myop dot dev.
I just went and loaded the page and looked at it, and it looks pretty cool. I think there's a video, right, there at the front, So if you want more information, you can just click that. Let's go ahead and do our picks and then wrap up. Steve, you said you have something you got to get to, so why don't you go ahead and go first.
Okay, let's talk got one serious pick before I get to the most important picks. We were talking about web components earlier, and I recently started last month. I started a new job doing some doing web development and view stuff at a new organization, but we do internet networking.
It's really quite fascinating. But one of the things we're running into is what's typical in a lot of larger organizations is that you have web properties all over the place done by different people, and you have different look and feel. I mean, the only thing I come in the sound of them is the logo in the top left corner.
You know different.
You know, one department and hired a contractor to do this, and somebody did it themselves. And so my department, we've created this whole really great tool for our network engineers to manage on the network infrastructure. And we're looking to expand and so one of the things my boss really wants to do is to sort of build one system to borrow from a lord of the rings, one system to rule them all when design system and in the
darkness behind them. And so some of our properties are like Grouple and WordPress and different tools, and so we want somethings generic. So we want to use web components. And so one of the things that we're doing is a new library. It's come out. I don't know how new it is. It's called web Awesome that's created by font Awesome. It used to be called Shoelace. So a couple of people from Shoelace came on and the fat Awesome organization created a web assome. They're basically web components
that you can drop into any framework. And so the idea of being as something that's somewhat generic that we can use across other frameworks and stuff. And I just started playing with it. It's pretty cool. Uh, there's a pretty comprehensive set of components that are available. And then we already used tailwind for the CSS, and so you can just drop sale and classes on top of your web components, which you have them in your view components in our case. Uh, and uh, it's pretty cool.
You know.
It's it's it's something generics and their web components, so just started playing with it. But so far, so good. The post list. There's a couple of things that would be nice. I would have had like a data tables, you know, or even just a generic table component, but there's other tools we can incorporate that use that, so it's that web as done.
There's first of all, obviously a g grid if you're looking for something really heavy duty.
But yeah, that's heavy duty. We don't need it for that. We're looking at something else. There's another one we saw that's generic JavaScript that we're going to try to wrap around that.
So there's also the ten stuck uh.
Yeah, we've talked to before. We looked at that, and there's a view a view port of that, and there's also shad Cyn. There's a few things, but this is what we're going for right now. So it's pretty cool.
Congratulations on the new job, Steve.
Thanks. Yeah, I'm really slacked to get to travel quite a bit and do some new stuff. Network engineering is a whole new world, man. The lingo is something, let me tell you. So for the dad jokes of the week, oh shoot, I had them brought up and then I lost them for a second. So I found out that I was recently diagnosed that I have a fear of being trapped in a small room with Santa. You could say I have claustrophobia.
Good joke, wrong season.
Well, there's a lot of believe it or not, there's Christmas in July exactly. My organization, just a club that I belonged to, had Christmas in July on Sunday. We do this, and I've seen other stores that do Christmas in July stuff, you know, the half year away. So it's somewhere relevant.
You know.
I used to believe in spheres, you know those round things are. Then I realized they're pointless. And then finally, fun fact Australia is I was doing some economic research. Australia's biggest export is boomerangs. It's also their largest import.
Yeah, so I've heard a variation on that about my son told me that his friend keeps on ordering boomerangs from Amazon and returning them.
I'll give that a rim shot.
Ice.
All right, Dan, what are your picks?
Okay, So one pick that I have. We're always on the lookout for good TV series, and the one that we found is called it's a an anthology actually on Netflix called Criminal. There's a Criminal UK, Criminal France, Criminal Spain, and Criminal Germany so and they're all in their native languages. It basically takes place in the entire episode takes place in police interrogation room. It's like this special unit that
specializes in the interrogation and every episode is standalone. It's the same interrogators, but it's stand alone in the context that it's a different person being interrogated for totally distinct crime. And the acting is superb. We especially enjoyed the Criminal U very good storylines, amazing acting, and I generally highly recommend it, So that would be my first pick if
you're looking for something to watch on TV. The other thing is I was recently, for some reason reminded of two excellent funny movies from the relatively early two one I'll go by dates. One is Tropic Thunder. To remember that one, the Ben Stiller movie with a whole cast of actors.
It had Robert claiming, correct, it probably couldn't be made these days. Yes, Tom Cruise has a great guest spot in it that he's pretty famous for.
You kind of spoiled it because a lot of people don't even Recogniz said it's him. Yeah, totally, just to give you context, but yes, it's totally politically incorrect. Just the fact that Robert Downey Junior plays the entire movie in blackface.
Yes, he's playing a black character.
Well, he's playing a white actor playing a black character, which is like funny an Australian white actor playing an American black person. But you know, he's a mathive actor, so he does it all the time, whether on camera off. It's really funny. I highly recommend that one. It's excellent. If you've not seen it, I highly recommend it. And the other one is the movie called The Other Guys from twenty ten, but Will Ferrell and Mark Wahlberg also,
it's a very funny. It's my favorite Will Farrell movie by far. It's highly quotable. It can it's a bit raunchy in some parts, so you know, but I highly recommend it as well. Have you seen it, Chuck One The Other Guys.
The Other Guys?
Now, I highly recommend you watching both these movies.
I see it on TV and replace a lot.
So yeah, it's it's like there's this part where where they're they're there are two police officers and they're paired together, and initially they obviously can't stand each other well, especially the character played by Mark Wahlberg. So he goes off and then he comes back and said, I was back there about to what did he say bad about you to to the other people? But my dad didn't raise me this way, so I'm going to do it in front of your face. But it's it's just this great movie,
highly quotable. Friends and I quoted to each other very often, and so I highly recommend these movies as well. And those would be my picks for today.
All right, I'm gonna get going on my picks. Then I usually do a border card game. This time I'm gonna do Gnoming Around. It's a Grandpa back game and it's basically a variation on golf if you've played golf, and in fact, it's got a golf theme to it, but it's a got a gnome theme to it as well. Let me see if I get a link here for people, I'll just link to Grandpa Beck's games. Actually, So it's yeah, you basically flip card it's over and replace the cards in front of you in a three by three grid
and you're trying to get the lowest score. So there are negative numbered cards, there are you know, plus numbered cards, and yeah, anyway, it's it's a fun one for sure. It's something that's simple enough that my kids can play it. I guess I better find the board game geek Weight, but I'm guessing it's.
Somewhere just above one. Yeah, one point two.
So you can play two to seven players, which is also great because you can play with a bunch of people and you can play it in like a half hour, fifteen minutes, half hour. So yeah, gnoming around Grandpa back game. There was another one that I played with my friends, but I can't remember what it's called. So I'll get that one next week. But yeah, as other picks go, one thing that I'm just going to pick, and it's
more of an approach than anything else. I've just been completely buried with stuff going on in life these days, and so what I did is I actually sat down and I've been making a list of all the things that I need to do, and that way I can start to prioritize things and figure out when I'm going to get everything done.
That's called the two do list. You should make an app for that, right.
Yeah.
The difference is is once I can see it all in front of me, then I can start making decisions. Okay, this needs to be done this week. You know, this can wait this whatever. So anyway, I'm gonna pick that. And then finally, tomorrow is a holiday in Utah, so I'm just going to shout it out.
It's Pioneer Day.
And Pioneer Day commemorates when the Latter Day Saint Pioneers entered the Salt Lake Valley. So you know, they come down out of Immigration Canyon. Brigham Young stands up. You know, he's sick in his wagon, but he stands up and looks out on the valley and says, this is the right place. So anyway, there's actually a this is the Place monument up there where he came into the valley and.
A bunch of my ancestors did that. It's it's funny.
On my dad's side, a bunch of them came over that way, and on my mom's side, you go back two or three generations and they all immigrated to the US after that. So anyway, but yeah, I'm excited for it. Probably lights some fireworks and it'll be fun. You're in Utah, So those are my picks? How are what are your picks?
Actually, didn't prepare for that, so I'm not sure.
Just anything you're enjoying these days, books, movies.
Hard to say, hard to say, I don't know. Didn't prepare for that.
All good, Yeah, no worries.
We got plenty between the three of us.
That's true for about two episodes. Maybe you can just give us this. Then, what's the best part of living in Thailand?
So the best part in living in Thailand is the weather, the views, the childing atmosphere, and you can focus on what you want to do and get rid of all the things that you need to do that you are not willing to. And I said at the beginning of the dep for people like us that you know, keep doing what they are good at tech industry. I found this combination really really nice. That you are living in a place which is not that developed, but you have
an Internet connection. You open your laptop and you know you're in the central of whatever civilization. You close them the laptop and you're in the middle of the nature.
Yeah.
So one other question I have, I'm imagining that you know, so I have kids, and you know, and so I'm thinking, gee, that sounds real nice.
But is that even possible for someone in my situation.
I don't know the ages, but I also have two kids one and a half and five enough, and it's working really nice. When they are at kindergarten, it's okay. Maybe later with schools, universities things like that, maybe less, but in my ages it fits us very well.
Yeah, very cool.
So chat my.
You know, my daughter just spent two years over there teaching, and she was teaching at an international school in chang Mai, which is that farther north than where Adar was. But there are a number of schools like that, by international schools where they're teaching primary and English, and you'll get a lot of you know, American expats there for missions organizations or other NGOs or stuff like that who send
their kids there. So when you're abroad, a lot of times they have schools like that where you can have your kids go to school.
Cool, good deal, All right, Well let's go ahead and wrap this up.
I guess one other question is where are you on the internet on social media and stuff?
So you can find me at the Mayo? Do dev that you already mentioned at docs dot maob do dev. We start creating a blog post there, so we're writing a little bit, and of course LinkedIn. You can week me a LinkedIn, send me a message and we'll be in touch.
All right, cool.
Well, let's wrap this up till next time, folks max out adios.
Thanks guys,