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