How to Use Web Components, Iframes, and Module Federation for Multi-Framework Apps - JSJ 689 - JavaScript Jabber

Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Speaker 1 (00:05):
Hey, folks, welcome back to another episode of JavaScript Jabber.

Speaker 2 (00:09):
This week, on our panel, we have Dan Shapiir.

Speaker 3 (00:11):
Hello from a very warm tut a Beef.

Speaker 4 (00:14):
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.

Speaker 3 (00:24):
Well, I assume Arizona is dryer. Oh yeah on the coast,
so yeah.

Speaker 4 (00:29):
Yeah, oh, I say, yeah, it's very very dry there,
like one hundred degrees fahrenheit.

Speaker 2 (00:34):
Yeah.

Speaker 1 (00:34):
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.

Speaker 4 (00:41):
Yeah, and humid there. Yeah.

Speaker 2 (00:44):
Yeah, when I lived in Italy that that was the case.
Too much more human there.

Speaker 1 (00:48):
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?

Speaker 2 (00:56):
I don't know.

Speaker 5 (00:58):
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,

(01:21):
Samoikopanghan took some.

Speaker 4 (01:23):
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.

Speaker 5 (01:31):
Mm hmm, yeah, yeah, yeah.

Speaker 2 (01:33):
It sounds exotic, which means I want to travel there someday.

Speaker 4 (01:36):
You should, you should, and you actually about heat and
humidity till you go there and got this time.

Speaker 5 (01:43):
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.

Speaker 3 (02:02):
Match digital nomad lifestyle.

Speaker 2 (02:04):
Huh yeah, yeah, good, very cool.

Speaker 1 (02:06):
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.

Speaker 3 (02:16):
Now you wanna you wanna set the stage? I think
that would be best.

Speaker 5 (02:20):
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

(02:41):
is also what they were doing in the company. So
I found it like interesting, So yeah, let's dig in.

Speaker 3 (02:47):
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

(03:08):
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,

(03:33):
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

(03:57):
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.

Speaker 5 (04:17):
So in that scenario that you're presenting, how you actually
implemented it.

Speaker 3 (04:21):
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

(04:42):
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.

Speaker 5 (05:00):
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

(05:21):
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,

(05:44):
this is another things that are going on for.

Speaker 3 (05:47):
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

(06:12):
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

(06:35):
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

(06:58):
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

(07:19):
just creates script tags on the fly and loads it
this way. Yeah, Chuck, sorry for interrupting. No, it's fine.

Speaker 1 (07:27):
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

(07:47):
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

(08:09):
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

(08:30):
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.

Speaker 5 (08:36):
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

(09:00):
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.

Speaker 3 (09:11):
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

(09:32):
the same page.

Speaker 4 (09:33):
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,

(09:55):
to think of you two versus Q three. You know
that ecosystem.

Speaker 2 (10:00):
So is there ever a reason to do this on purpose?

Speaker 5 (10:03):
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,

(10:26):
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.

(10:49):
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.

Speaker 4 (11:04):
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.

Speaker 1 (11:11):
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

(11:34):
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.

Speaker 3 (11:57):
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.

Speaker 4 (12:10):
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

(12:31):
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.

(12:52):
And that's not the first story I've heard about that.

Speaker 1 (12:54):
Well, you have to realize that the large language models,
they don't function by saying what do I know?

Speaker 5 (13:00):
Then?

Speaker 2 (13:00):
How do I tell you?

Speaker 1 (13:01):
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

(13:21):
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

(13:42):
it's not giving you any real information because that's not
how it works.

Speaker 3 (13:46):
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.

Speaker 2 (13:56):
Want more better examples, yes.

Speaker 3 (14:00):
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.

Speaker 5 (14:20):
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,

(14:44):
don't give you garbage or something like that.

Speaker 4 (14:46):
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.

Speaker 3 (14:59):
You just I.

Speaker 1 (15:00):
Think yesterday Angular So yeah, yeah.

Speaker 5 (15:06):
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.

Speaker 4 (15:26):
Is that what's called framework discrimination? And maybe I'll give
that a delayed Sure, there we go.

Speaker 3 (15:35):
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

(15:59):
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

(16:21):
a component implemented in one framework into an app web
application implemented in using a different framework. Okay, what do
I do?

Speaker 5 (16:31):
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

(16:54):
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

(17:19):
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

(17:41):
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

(18:03):
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.

Speaker 3 (18:16):
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

(18:38):
within the React application. Is that what you're suggesting.

Speaker 5 (18:42):
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

(19:02):
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.

Speaker 1 (19:23):
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.

Speaker 2 (19:31):
Yeah, so what.

Speaker 5 (19:34):
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

(19:55):
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,

(20:17):
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

(20:40):
mechanisms work behind the scenes. But again it's a gaps
that those frameworks closed and covered in the past few months.

Speaker 3 (20:48):
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

(21:10):
to somehow impact its container, that becomes tricky.

Speaker 5 (21:15):
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,

(21:36):
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

(21:56):
mechanism behind the top.

Speaker 3 (21:58):
Then so go Chuck.

Speaker 1 (22:00):
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.

(22:21):
How do I start to mitigate that so that it's
not so heavy on my application?

Speaker 5 (22:27):
Mm hmm.

Speaker 3 (22:27):
Yeah.

Speaker 5 (22:28):
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

(22:50):
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

(23:11):
some kind of notion what's going on at the bill time.

Speaker 3 (23:14):
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.

Speaker 5 (23:35):
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

(23:58):
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,

(24:20):
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.

Speaker 3 (24:30):
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

(24:54):
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

(25:15):
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

(25:36):
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

(25:58):
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?

Speaker 5 (26:08):
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

(26:32):
to load them from remote right.

Speaker 3 (26:34):
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.

(26:57):
It does all the wiring for automatically.

Speaker 5 (27:01):
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

(27:24):
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.

Speaker 3 (27:41):
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.

Speaker 5 (27:49):
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

(28:10):
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

(28:33):
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

(28:56):
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.

Speaker 1 (29:15):
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,

(29:38):
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?

Speaker 2 (29:50):
That we're eventually going to bring forward.

Speaker 1 (29:52):
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.

Speaker 5 (30:07):
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.

Speaker 2 (30:22):
Robust one.

Speaker 5 (30:23):
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

(30:45):
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

(31:09):
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

(31:30):
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.

Speaker 3 (31:45):
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

(32:05):
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

(32:27):
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

(32:48):
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

(33:12):
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

(33:36):
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.

(34:00):
This funny stuff like that. But but generally speaking, you
can pass JavaScript objects back and forth without a problem.

Speaker 5 (34:10):
So this right the way, yep.

Speaker 3 (34:13):
And it's synchronous, which is also important. Yeah.

Speaker 2 (34:17):
One question I have with this is you said you
could do it without involving the server.

Speaker 3 (34:20):
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.

Speaker 5 (34:35):
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

(34:56):
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.

Speaker 3 (35:15):
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

(35:35):
a reuse of an old technique.

Speaker 1 (35:37):
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?

Speaker 2 (35:53):
How do I do that?

Speaker 3 (35:54):
Yeah?

Speaker 5 (35:54):
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

(36:16):
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

(36:38):
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

(36:59):
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,

(37:19):
on the window object, on whatever will not affect your application,
right because you wrap it inside an eye frame.

Speaker 3 (37:25):
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

(37:49):
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.

Speaker 5 (38:03):
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

(38:24):
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.

Speaker 3 (38:43):
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

(39:05):
to be less about malicious code and more about avoiding
accidental functional leaks or am I missing the point? No?

Speaker 5 (39:16):
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.

(39:40):
So yeah, you're definitely right.

Speaker 3 (39:42):
And again, so you create this kind of separation that
might not necessarily automatically exist.

Speaker 5 (39:48):
Yeah, yeah, again, there is no one under.

Speaker 3 (39:52):
In something could do something like override the window dot
parent I guess, or something along these lines.

Speaker 5 (39:58):
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.

Speaker 3 (40:09):
Right.

Speaker 5 (40:10):
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,

(40:33):
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.

Speaker 1 (40:44):
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

(41:06):
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

(41:28):
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.

Speaker 5 (41:45):
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

(42:11):
is your need, right, right, Yeah.

Speaker 3 (42:14):
I think I.

Speaker 1 (42:17):
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.

Speaker 5 (42:28):
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,

(42:49):
but you do not really want to write. You want
to work with props and ref and types and everything.

Speaker 3 (42:56):
Right.

Speaker 5 (42:57):
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.

Speaker 3 (43:13):
Right.

Speaker 5 (43:13):
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

(43:34):
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

(43:58):
not use a library.

Speaker 3 (43:59):
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

(44:23):
map into DOM events even if you're using an I
fray right.

Speaker 5 (44:28):
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,

(44:51):
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

(45:12):
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

(45:33):
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,

(45:58):
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

(46:20):
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

(46:43):
they generated valid HTML and valid JavaScript.

Speaker 3 (46:47):
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

(47:09):
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.

Speaker 5 (47:25):
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

(47:46):
just for mocking or prototyping. We can start and take
some of it output and use it in specific use
cases in production.

Speaker 3 (47:53):
Okay, And for that, in your opinion, the optimal solution
are those self create to die frames.

Speaker 5 (48:01):
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

(48:24):
because they're running on the same realm. Web components can
extract and extend their visual scope out of the rectangle.

Speaker 3 (48:32):
Right.

Speaker 5 (48:33):
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.

Speaker 3 (48:51):
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?

Speaker 2 (49:04):
That's what I was going to ask, m M.

Speaker 5 (49:07):
Yeah, I think, like.

Speaker 1 (49:11):
So the easiest I'm imagining that you could also have
a confident developer do this in a lot of cases.

Speaker 3 (49:17):
Yeah.

Speaker 5 (49:18):
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

(49:42):
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

(50:06):
should be inside an IPRAM so the fonts will be
loaded correctly.

Speaker 3 (50:10):
Right.

Speaker 5 (50:11):
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

(50:33):
an iframe which support everything. Right, And this is even
before we're asking AI to analyze the AI.

Speaker 3 (50:39):
Right.

Speaker 5 (50:40):
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.

Speaker 3 (50:53):
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.

(51:15):
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.

(51:37):
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.

Speaker 1 (51:58):
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.

Speaker 5 (52:07):
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

(52:29):
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.

Speaker 3 (52:43):
Just not so Yeah, here's the thing.

Speaker 2 (52:48):
It's interesting watching his body.

Speaker 5 (52:50):
Yeah.

Speaker 3 (52:52):
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

(53:14):
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

(53:37):
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

(54:00):
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

(54:22):
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

(54:46):
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

(55:07):
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,

(55:28):
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

(55:48):
that's the case.

Speaker 1 (55:49):
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,

(56:11):
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

(56:34):
haven't seen any instance where that's been an issue at all.

Speaker 3 (56:38):
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.

Speaker 2 (56:50):
That's so true.

Speaker 3 (56:52):
Yeah, yeah, so but Hada, we were kind of of
hijack the conversation. So what's what's your TAKEA yes.

Speaker 5 (57:01):
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

(57:22):
to isolate and we need to integrate in our products
like he's like, as someone that we are not trusting. Yeah,
trusted a.

Speaker 3 (57:32):
Yeah.

Speaker 5 (57:33):
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

(57:53):
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,

(58:13):
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

(58:35):
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.

Speaker 3 (58:55):
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

(59:18):
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.

Speaker 4 (59:42):
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,

(01:00:03):
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.

Speaker 5 (01:00:11):
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

(01:00:33):
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,

(01:00:55):
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.

Speaker 3 (01:01:08):
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.

(01:01:28):
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

(01:01:49):
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.

Speaker 4 (01:02:07):
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.

Speaker 3 (01:02:20):
Perce is I just to say that, you know, software
development is that field that teaches you that procrastination is
a virtue.

Speaker 4 (01:02:28):
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,

(01:02:48):
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.

Speaker 5 (01:03:03):
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

(01:03:24):
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

(01:03:46):
a year ago or something like that.

Speaker 1 (01:03:47):
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.

Speaker 4 (01:03:57):
That need to be which I do.

Speaker 1 (01:04:00):
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?

Speaker 3 (01:04:16):
Yeah?

Speaker 5 (01:04:17):
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,

(01:04:38):
gradual rollout and roll back. And then we actually monetize
on the dashboard.

Speaker 3 (01:04:44):
Right.

Speaker 5 (01:04:45):
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.

Speaker 2 (01:05:08):
Awesome. All right, Well that's myop dot dev.

Speaker 1 (01:05:12):
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.

Speaker 4 (01:05:25):
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

(01:05:48):
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.

Speaker 3 (01:05:58):
You know different.

Speaker 4 (01:05:59):
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

(01:06:19):
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

(01:06:40):
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

(01:07:00):
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.

Speaker 2 (01:07:15):
You know.

Speaker 4 (01:07:15):
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.

Speaker 3 (01:07:33):
There's first of all, obviously a g grid if you're
looking for something really heavy duty.

Speaker 4 (01:07:39):
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.

Speaker 3 (01:07:47):
So there's also the ten stuck uh.

Speaker 4 (01:07:53):
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.

Speaker 3 (01:08:03):
Congratulations on the new job, Steve.

Speaker 4 (01:08:06):
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

(01:08:27):
I was recently diagnosed that I have a fear of
being trapped in a small room with Santa. You could
say I have claustrophobia.

Speaker 3 (01:08:37):
Good joke, wrong season.

Speaker 4 (01:08:39):
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.

Speaker 3 (01:08:56):
You know.

Speaker 4 (01:08:57):
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.

Speaker 3 (01:09:12):
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.

Speaker 4 (01:09:23):
I'll give that a rim shot.

Speaker 3 (01:09:24):
Ice.

Speaker 2 (01:09:25):
All right, Dan, what are your picks?

Speaker 3 (01:09:26):
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.

(01:09:48):
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.

(01:10:11):
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

(01:10:38):
I'll go by dates. One is Tropic Thunder. To remember
that one, the Ben Stiller movie with a whole cast
of actors.

Speaker 4 (01:10:46):
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.

Speaker 3 (01:10:57):
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.

Speaker 4 (01:11:13):
Yes, he's playing a black character.

Speaker 3 (01:11:15):
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

(01:11:37):
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

(01:12:00):
The Other Guys.

Speaker 4 (01:12:01):
The Other Guys?

Speaker 3 (01:12:02):
Now, I highly recommend you watching both these movies.

Speaker 4 (01:12:07):
I see it on TV and replace a lot.

Speaker 3 (01:12:09):
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

(01:12:33):
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.

Speaker 1 (01:12:50):
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,

(01:13:11):
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.

(01:13:31):
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.

Speaker 2 (01:13:37):
Somewhere just above one. Yeah, one point two.

Speaker 1 (01:13:43):
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

(01:14:05):
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.

Speaker 4 (01:14:21):
That's called the two do list. You should make an
app for that, right.

Speaker 2 (01:14:25):
Yeah.

Speaker 1 (01:14:25):
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.

Speaker 2 (01:14:39):
It's Pioneer Day.

Speaker 1 (01:14:40):
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

(01:15:00):
Place monument up there where he came into the valley and.

Speaker 2 (01:15:03):
A bunch of my ancestors did that. It's it's funny.

Speaker 1 (01:15:05):
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?

Speaker 5 (01:15:24):
Actually, didn't prepare for that, so I'm not sure.

Speaker 1 (01:15:28):
Just anything you're enjoying these days, books, movies.

Speaker 5 (01:15:33):
Hard to say, hard to say, I don't know. Didn't
prepare for that.

Speaker 2 (01:15:37):
All good, Yeah, no worries.

Speaker 4 (01:15:39):
We got plenty between the three of us.

Speaker 2 (01:15:41):
That's true for about two episodes. Maybe you can just
give us this. Then, what's the best part of living
in Thailand?

Speaker 5 (01:15:46):
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

(01:16:07):
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.

Speaker 2 (01:16:23):
Yeah.

Speaker 1 (01:16:24):
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.

Speaker 2 (01:16:33):
But is that even possible for someone in my situation.

Speaker 5 (01:16:35):
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.

Speaker 2 (01:16:54):
Yeah, very cool.

Speaker 3 (01:16:56):
So chat my.

Speaker 4 (01:16:57):
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

(01:17:19):
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.

Speaker 2 (01:17:25):
Cool, good deal, All right, Well let's go ahead and
wrap this up.

Speaker 1 (01:17:29):
I guess one other question is where are you on
the internet on social media and stuff?

Speaker 5 (01:17:33):
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.

Speaker 3 (01:17:50):
All right, cool.

Speaker 1 (01:17:51):
Well, let's wrap this up till next time, folks max
out adios.

Speaker 5 (01:17:54):
Thanks guys,

All Episodes

How to Use Web Components, Iframes, and Module Federation for Multi-Framework Apps - JSJ 689

Episode Transcript

Popular Podcasts

Dateline NBC

Stuff You Should Know

The Breakfast Club

.css-15opob5{left:0;position:absolute;top:0.8rem;} All Episodes

.css-14f5ked{margin:0;word-break:break-word;display:-webkit-box;-webkit-box-orient:vertical;box-orient:vertical;-webkit-line-clamp:2;overflow:hidden;}How to Use Web Components, Iframes, and Module Federation for Multi-Framework Apps - JSJ 689