Speaker 1: Hey everybody, and welcome to another episode of Adventures in Angular.
This week on our panel we have Brooks Foresight. Hey everyone,
Eddie Hinkle, what's going on? Chris Ford and Lou and
Charles Maxwood from devchat dot tv. We have a special
guest this week and that is Niel.
Speaker 2: Hi everyone, if.
Speaker 1: You want to just introduce yourself real quick, let us
know who you are while you're famous.
Speaker 3: Sure, so yeah again, Hi everyone, I am My name
is Nishigil and I work as a software developer at IBM.
I am recently being recognized as a Google Google developer
expert in Angular and with technologies. I love writing blog
posts around the concepts of Angular, and I also paid
code labs, which you can refer to if you're stuck
anywhere with any any code activities.
Speaker 2: So yeah, thank you for having me.
Speaker 1: Faz, Yeah, no problem. We got you on to talk
about your article that was written oh last year. I
was like, oh, this is real recent and it is
kind of but the number of last year you wrote
an article creating framework agnostic web components with Angular. Do
you do you want to just kind of give us
the ten thousand foot view on this that the general
outline of what we're talking about here, and then we
can have a conversation about what it means.
Speaker 2: Sure.
Speaker 3: So first of all, the idea behind this, why I
chose to write about it was the setting that I
work in at IBM. At my workplace is more like
a garage concept. Now, what it really means is that
we don't really work on a long term project which
has one you know, tech stack involved. It's more like
different clients coming in different text tech stack involved. So
that's that's when you know the need of web components
really jumps in. We have Angular for two months, let's say,
but then React for another five months, and that's when
creating one component and then you know maybe having the
need to create it again with any other technology or
any other framework is not really a smart thing to do, right,
So what I really do at my workplace is building
a component, exporting it as a web element, be it
with with any framework or without any framework, pushing it
to the Internet repository, and then using it in any
other framework based project that we are working with. So
I think that's the main reason why I chose to
write behind write about web components, and then Angular is
my forte So with Angular elements is the go to
about this.
Speaker 1: Block post right and web components. My understanding talking to
people is that they pretty much run everywhere. There are
different specifications, but it's it's pretty direct. So how does
Angular elements actually tie into this because it seems like
that's also supposed to run everywhere. But I've not gotten
like the clear rundown as to what the difference is.
Speaker 3: So if you look at it, the way we do
property binding, event binding and Angular is almost similar to
how web components work. There also, we do property binding
just using a property and you know, passing it any
value that we want to. For example, we have built
a web component or a custom element using polymer, and
that's when you know, we want all the properties to
be coming in from some other component as an encapsulated
value or any any dorm node as such. That's when
we just simply, you know, we pass in the template
I mean or the property and the event. This is
exactly what we do in Angler with the custom selector
that we use. So I think Angler was built with
respect to, you know, thinking that we can use it
use a component as a custom element. So it pretty
much aligns with how web components work and the specifications.
If you look at those, they're also very similar customer
elements being the linchpinnefit because that's what the main role
of web components are is. And just like we use
view encapsulation using shadow dom in there to encapsulate the CSS,
the styling, and the dom nodes from the rest of
our consuming application, that's exactly what we do in Angular again,
so yeah, pretty much. Am I able to make it
clear to you how Angular elements aligned with web components
in general?
Speaker 4: Yeah?
Speaker 1: I think so. I am curious then, does Angular elements
actually compile down to web components in some way or
is it it's kind of a light weight Angular that
you tree shake everything out and throws. I don't know.
Speaker 2: Yeah, so pretty much. Not not really.
Speaker 3: So it's like a lot of Angular code is still
involved in the bundle that we create. Obviously, officially it's
not yet supported to you know, export that bundle use
it in any other framework.
Speaker 2: So in Angular we can use.
Speaker 3: It as a web component, but outside in any other
framework it's still not officially supported. But then we have
other community projects that are helping us with that.
Speaker 2: So for example, NGX.
Speaker 3: Built plus if you've heard of that, that allows us
to create a single bundle of the code of the
component that we have created as a web component, and
then we can use the web component in a React
framework project maybe or any Vanilla Javisk project as well.
Speaker 5: So there's there's a community project that lets us do that.
I guess it's it's not out of the box yet, but.
Speaker 3: Right, okay, it's called dx built plus. It's it's not
just for that purpose, but many other purposes as well.
I mean, if you want to compile down to a
very small bundle, not just for Angular elements, but for
you know, other purposes as well when it comes to
dependency injection or other things.
Speaker 4: Sounds cool. Should take a look at it.
Speaker 6: Now, do you guys tend to just build straight web
components and then use them in your Angular projects or
in your React products or do you actually build it
using Angular elements and then use build plus to export.
Speaker 1: I guess where do you start, right?
Speaker 6: Is it the web component level or do you actually
start in a framework and export it.
Speaker 3: So the basic idea is to create a lot of
components so that you know, we align with the reuse
it ability at our workplace, and a lot of components
are available for other employees as well, so that you know,
they can just come in use a component, not really
referring to outside components which are externally available. So that's
the basic purpose, which means that we don't really start
at a framework level level. We would just prefer to,
you know, create a component and export it as a
web component. If it's an Angular then rate, If not,
then outside maybe you know, using stensive, jas Polymer or
any other framework or technology to build a web component.
Speaker 2: That's the main.
Speaker 4: Idea, gotcha.
Speaker 6: So regardless of where you start, you're able to still
you know, if it's Angular, use ng export plus if
it's you know, a different framework, you do do it.
However they support Yeah, but they just collect it all
into like a library of web components that you guys
can So we call.
Speaker 3: It the internal NBM repository and push it all there
and then use it for our internal purposes.
Speaker 6: Awesome, very cool.
Speaker 2: Yeah. Has anyone has created a web component before?
Speaker 6: Yeah, nope, I don't think so.
Speaker 4: I've only done it on a sort of a tutorial level.
It's it's something that I'm I am interested in that
I want to dig into when when I can find
time in my life to dig into stuff I've I've
mentioned before on the podcast I've Got the Manning did
a book published a book, Web Components and Action. I
have that book of work through some of the examples.
It's something that I I think it is very cool.
I think it's going to be possibly part of the
part of the future of front and development. But yeah,
I haven't done. I haven't dug into it as much
as I would like to.
Speaker 2: Right.
Speaker 3: The very interesting thing that you mentioned here was the
book Web Components in Action. I was reading it sometime
back and it really mentions a very good concept there,
which is framework fortigue. So how many of you agree
with that framework fatigue? Do you suffer from framework for tigue?
Speaker 6: Yeah, I think that's definitely a thing. I mean, depending
on the work context environment. So I think like in
the front end world we run into that a lot.
I think like in my job, I'm able to kind
of be insulated from that because we can just focus
on one and forget that anything else exists. But yeah,
in the day to day job of you know, a
front end developer, it's definitely tough to keep up with
all the different frameworks and what works here and what doesn't.
Speaker 5: I just used the best framework out there and Angular,
so you know, no fatigue for me.
Speaker 4: I mean, I think the main thing I see with
or feel in terms of framework fatigue is just when
it's more of the conversations between people who who are
just obsessed with their framework or library of choice being
the only good one. I like to maybe I'm very enlightened,
but I always like to go into those arguments by
just saying, look, all of these major frameworks, they all
address the same issue, and all have their own ways
of handling it, and they've all got pros and cons,
And I get frustrated when you get someone going yeah,
but also you'll use an angler and that sucks, you know,
something like that. So that's where I feel fatigue.
Speaker 3: Right. Another interesting thing with web components I just remember
is is that you know, you don't really carry the
framework functionality into the customer element that you will. So
somebody who's using the custom element that you have built
doesn't need to be an Angular expert, doesn't need to.
Speaker 2: Be a React person.
Speaker 3: It's just that he has to use it as another
development or another button element because it's it's just an
HTML element right that it compiles to so my Angular component,
let's let's call it a spider chart, but spider chat selector.
It's going to compile down to a lot of divs
in there. So it's very easy for the user consumer
to you know, understand it and doesn't really need to
be a framework or a technology expert.
Speaker 4: Yeah, and that's exactly what you need. Because just just
to tell a little story, I had a colleague about
six months to a year ago who built a help
a tool basically for the project that we were working on,
which was an Angular project. Now, he built this help
a tool in view because it was because he just
saw it as a little side project. He was doing
it to help himself. But then of course the stakeholders
for the project come along and say, ah, we like
this help a tool, can we please integrate into the application.
He had to rewrite the entire thing in Angular. Now
if he if actually we've been able to do that
just as web components, then presumably he could have built
that once and we could have inserted it into any
application he wanted.
Speaker 1: Right, So my question is is you know, we've talked
about the portability, but besides portability or their other advantages,
I'm thinking performance or things like that.
Speaker 3: Yeah, so imagine using a dynamic component in Angular. So
there's a lot of code that you write to create
a dynamic component right now, Instead of creating a dynamic
component within Angular, why not just use you know, a
component that's that's already built with some other lighter functionality,
use it as a selector in your HTML application and
it works. But performance definitely is an issue when you
know you are creating a big bundle for a small
functionality which might not really be required. For example, you know,
if I'm if I'm wanting to build a let's say,
what do we call it. Let's take some other example,
not a spider chart.
Speaker 2: So let's say.
Speaker 3: I'm creating a slider and that's what I'm creating my
component for. But now that it's such a small functionality,
I don't want to create a big bundle for that
with all the Angular functionality or any other functionality per se.
And that's when you know, we really might have to
reconsider that. Should we create it as a web component
or it's good enough, you know, as a native component
it self. So yeah, that's where performance comes into a picture.
But web components are really helpful with micro front ends,
and people are really you know, choosing to go with
web components when dealing with micro funds, and you know,
having a full application parallel to let's say one Angler
application and then using a separate application to use the
React functionality, but then just use a web component in place.
Speaker 5: What's what's preventing you from doing an application just in
web components, like just building it all web components. I
assume there's some functionality missing from there, right, like.
Speaker 2: Routing or in case of Angular, you.
Speaker 4: Mean Angular or in general.
Speaker 3: So if you look at the Ironic website, it's all
built on built on I mean stensil Jas components, so
you can actually that it's very performant. But yeah, with
Angular sense it's not officially supported yet and there's a
lot of Angular code that comes in. We don't really
you know, you know, you're not really looking forward to
building the full application with Angular components, which means web
components here. But yeah, I think we people are using
a lot of sensil zas components, polymer components I mean
lit element now and building applications just on the basis
of those.
Speaker 5: Yeah, I've been using Ionic four and five, so I'm
familiar with Stencil, I was just just Stencil compile. Is
there a difference between Besides, I know the syntax is
difference is different, right, you're with Stencils more React based
kind of and you know Angular Elements obviously isn't. But
is there a difference in what comes out at the
other end through the compiler? Is stencil just a web
component and Angular elements you still need this other library
to get it to work in other frameworks.
Speaker 3: So there's a lot of dependency on zone JS as
of now. But then again with a lot of refactoring,
and then you know, when it comes on officially then
we are not really going to acquire all that. But yeah,
obviously with sensils and Polymer, we don't really need those,
which is why they you know, people are using those
lighter components a lot into their applications.
Speaker 2: But at the end of the day, it's just.
Speaker 3: An HTML element which your browser should understand and it's
all a lot of develments. So yeah, that's that's what
it is at the end of the day. Also, so
let's say you have created one component. Now the browser
is definitely not going to through an error for that.
It's just going to consider it as an HTML unknown
element and ignore that if it doesn't understand it.
Speaker 2: Do you understand what I mean?
Speaker 5: Yeah, if it doesn't recognize that all.
Speaker 3: Yeah, So it's not gonna say I don't understand what
spider chart, let's say spider chart selector is. It's just
going to ignore that because it will consider it as
an HTML unknown element.
Speaker 4: Okay, so that makes sense. I'm curious what is the
what is the advantage of using Angular elements over just
a Vanilla Web components. I mean, in my head, it
would be that I and again from from sort of
my my small amount of dabbling, you you've got to
not exactly a new syntax to build a Vanilla Web component,
but you've got to kind of learn how to do
a new thing, whereas presumably building an Angler Elements component,
I can just go ahead and use Angular in the
same way that I'm used to doing it. Is that
the main advantage or are there other advantages to doing that?
Speaker 6: So?
Speaker 3: Yeah, I think of it as as somebody who's developing
an Angular application for like four to five months, because
you're you're into a full time project maybe at your workplace,
and a lot of your colleagues have to use the
same thing over and over again, and you definitely don't
want them to write the code for it because maybe
they might be working in a React application. But it's
the same functionality, so it's just a little extra work
you have to export it as a web component, but
then you know it's really adding value to the efficiency
of the work that you're doing. So if I am,
you know, developing five components because I'm working in an
Angular project, I might consider building them as web components,
and you know, it really soothes and smooths the process
for all the other my colleagues or maybe anybody there
who's who's who might be interested to use it. So
I think that's that's how I consider it to be
of great use.
Speaker 4: Do you have do you have a preference? Would you
go Vanilla web components or would you go Angular elements?
Speaker 2: No preferences?
Speaker 4: Excellent.
Speaker 1: I'm kind of curious how do you test them? Like,
if you pull a web component in, how do you
go about testing it to make sure it does what
it's supposed to do.
Speaker 3: I have not really been I'm not into testing as such,
so no idea on that.
Speaker 4: I think you can't you just use uh, you know,
your your normal front end unit testing library choice or
do you mean like to end testing or do you
mean like unit tests? Because I mean I meant like
unit tests. I would imagine you could just use you know,
just or trans Yeah, yeah, just tell it because it's
it's just it's just JavaScript. At the end of the day,
right click it.
Speaker 1: Did it trigger the theme?
Speaker 4: Yeah? Yeah, fair enough, I should have a looker. I'll
have a look at the at the manning. But because
I'm sure it's got chapter on testing, I'll come back
to you with a hot update.
Speaker 5: Let's say if I have just a regular, you know,
dumb Angular component, how much work is involved into turning
that into an Angular Element component?
Speaker 2: Right?
Speaker 3: So, first of all, that okay, earlier, I mean before
Angular AID, you had to consider creating it as an
entry component and declare it in the entry component's ERIC.
But now that IVY has come in, you don't really
need to declare one component as an entering component. It
would be considered an entering component already. That's one thing
which we used to do before Angular AID. Another thing,
you need to woodstrap your module, whichever module has that
component in it. Let's say, if you don't want Angular
application to bootstrap the module that you're looking for, you
can you avoid bootstrapping it and then manually, you know,
use the ng to woodstrap method. That's where you write
the code for creating the custom element. Now that's when
the role of web component come in. You install it,
install the package web Components, and then use the custom
Elements API. Then there's this defined method in that which
you used to define the selector of the component that
you're using. So let's say you want to build a
slider component, you would define it there using the Customer
Elements API, and then because you need to register it
with your browser, that's when you'll register it with the
I mean the selector whichever you want to give. Let's
say you want to call it slider hyphen. Also, there's
a convention with the naming that you give to your
customer element. You can't just you know, call it a
spider with a with camel case or anything. It needs
to have a hyphen within the name of the component.
An interesting story when I was preparing for my talk
at Engenda recently, and that was about web components. So
I was naming my component Hello because I was, you know,
doing it very quickly, and I just wanted to keep
it hello and just try it, and it didn't work
at all, and I was like, why the hell is
not it's not working because I tried it too many
times before and I was using it already, but I
didn't really focus on the convention bit. Then I thought,
let me, let me try calling it hello there, and
I didn't check the convention even then, and it worked.
So that's when I understood, Okay, it's the convention, so
it needs to we need to keep it, keep a
hyphen in the name there. So yeah, I was talking
about registering it with the browser, so you register it now.
The main bit comes in anybody any less polyphylls. Polyphylls
are a pain when you're dealing with their components because
you need to add a lot of polyphylls and you
need to be very particular about those. So if you're
using Angular elements package, right there is a polyphyll which
is a very light in size, you can use that,
but then it's not really supporting all the different browsers.
So that's when we choose to use the web Componence
polyphyl We import that separately and use it inside our
polyphils file. That's when it would support all the different
rousers and what else do you need to do. You
have created the web component, I mean customer element.
Speaker 2: You have registered it with the browser.
Speaker 3: You would declare it as an entering component if it's
before Angular.
Speaker 2: Aid and yes, I think that's pretty much it. You
can use it then, Recall I didn't think, yeah, that's
pretty much it.
Speaker 6: We kind of touched on performance a little bit earlier,
but I don't think in this context, like when you're
an Angular angler is having to communicate with the web
component with change detection and things like that, is there
a performance that like do you notice that the web
component doesn't work as smoothly or easily as the native
Angular component or have you not noticed anything like that?
Speaker 3: So I particularly didn't notice anything of that sort, because
we usually create very small components as web components, right
because otherwise, if it's a huge component, you would not
consider exporting it as a web component. But yeah, it
works very smoothly with chain detection. You just need to
set injector service there and the dependency injection is taken
care of. So when you are declaring your remember I
was talking about custom elements dot define method that's where
you can use the injector service as well, and dependency
addction is then take taken care of.
Speaker 4: Gosh.
Speaker 3: Now, okay, yeah, if you're using this custom element that
you created using Angular Elements inside an Angular application, there's
just one thing that you need to do. So let's
say you have another Angular application which wants to use
a customer element which you built in this other Angle application.
So the consuming one needs to have this schema's air
in your engine module, which which would have custom elements schema.
Speaker 2: You just need to define that for just to tell
Angular that.
Speaker 3: Okay, you might expect, you know, a component which is
not a native Angular component, but it might come in
as a web component custom element, and that's all about
consuming it. So there's no no much of a hassle,
you know, when you're dealing with web components. So yeah,
nobody can you know, should say that, Okay, it's a
lot of hassle and I don't really want to create
it as a web component because it's really smoothing the
task that you're doing and not much of the work
to do there.
Speaker 4: Oh cool, that's awesome.
Speaker 1: Yeah, So one thing that I'm wondering is like what
prompted this article in Angular in depth. I mean, was
this something you did at work and then you reached
out to them and said, hey, can I write an article?
Or yeah, how did this come about?
Speaker 3: So I actually write a blog post around Angler concepts,
and before this as well, I was publishing articles with them.
Speaker 2: The first time was yeah, when I approached them that
I would like to publish it with Angler in debt.
Speaker 3: But for this one, I mean after that first article,
then I simply started submitting it to the publication and
they would accept it, correct things if need be, and yeah,
accept the article into the publication.
Speaker 1: That makes sense.
Speaker 3: This one is just submitting it to the publication and
setting it right.
Speaker 1: I guess what I'm asking because that was part of
what I wanted to know. But the other part of
what I wanted to know was is this something you've
done at work or done on a personal project?
Speaker 3: Right, I've done it at work, So, as I told
you before, the setting in which I work, it's where
you know, we use a lot of frameworks here. So
if I'm working on one framework, I would create and
there's an interesting component, let's say, I would just create it,
push it to the repository, and anybody can use it
in their projects. So let's say one other person is
working for another client with another framework, they can use
it to in their application. So that's what you made
me actually write about it. That's when I started exploring
a lot about their components and wrote about it.
Speaker 1: What kinds of components then are in this shared library?
Like what kinds of things are you finding you want
to put into this kind of a setup.
Speaker 3: For example, a bar chart component is the most widely
used here that we yeah, in many applications. Also that
gets used a lot for maybe an education based portal that.
Speaker 2: We are building.
Speaker 3: If it's a e commerce portal, then you know, maybe
a source bar which we don't want to use from
any other library.
Speaker 2: A search bar would be another one.
Speaker 4: Yeah, that makes sense.
Speaker 3: Yes, has anybody used ndxbill plus before for any other purposes?
Speaker 2: Not, if not web components.
Speaker 4: I've never heard of it.
Speaker 3: Okay, you must try it out for different purposes. It
really brings down the bunch sizes to very small. And yeah,
it's widely used for angular elements as well.
Speaker 1: Yeah, we should see if we can get men on
the show talk about.
Speaker 6: Yeah, yeah, I've heard of it. One of the guys
on my team was reading about it because we were
trying to figure out if we wanted to, like, we
have different sections of our rather large application, and so
we're trying to figure out do we want to single
large you know module where everything is one application, or
do you want it like a couple of smaller Angler
applications kind of micro front ends type approach, And so
he was looking at using JX built Plus to be
able to make that be possible. But yeah, it gains
complicated that we're like, ah, let's just keep it simple
for now, but keep a single Angular application. But yeah,
NGX build Plus seemed pretty cool for that, but I
had no idea it was also working with Angular elements
until today, so that's awesome.
Speaker 3: Yeah, And I'm just curious to know if anybody uses
the HTM and I mean the Web Component specifications for
any other purposes other than you know, creating Angular I
mean web components, just like in gender you know, HTMIL
templates or you know, encapsulating your code from the rest
of your consuming application. If not web components, just just normally.
Speaker 4: I think I guess that the advantage we have in
using a framework such as Angler and is that it
does such a fabulous job of scaffolding all of what
you've just mentioned there for us, doesn't it inside of
the inside of the framework. But the thing that the
thing that drew me to web components in the first place,
where when I first picked up that book, is from
from looking through the you know, the first few chapters
of the book, it was it made it very clear that, yeah,
this is this has given me the option to do
effectively what I do when I'm building angular components, just
without necessarily being tied to Angler. And I think that's
I think that's very powerful, and I believe fairly strongly
that that's that's probably the direction that front end development
is is going to head towards. I think, yeah, I
think you still need you still need your framework. And
this kind of leads back to I think Brooks question
maybe you know, fifteen twenty minutes ago, but I because
I and correct me if I'm wrong, But I feel
like building your your web components is still it's like
building your angular components, right, but you still there's more
two angular than just the components, because you actually it
gives you a really nice wrapper for making agax requests.
It gives you your routing, you get things like your
form validation and things like that. So it's still useful
to use a framework to help you with all of
that stuff. But I guess the point of web components
is that, yeah you can. You can if you want
to build a graph as you say, oh, you know,
a bacher or some amazing sire you know, sign up
for or a button that you might want to use
across multiple applications, across different libraries and frameworks, and yeah,
you do it a web component and then important into
your applications.
Speaker 3: Right And also in the first place, we always say,
right that Angular framework is to build enterprise level applications,
big applications, large applications. So if we take that into consideration,
these are two different different things, right.
Speaker 4: Yeah, absolutely nothing to stop you from using Angular for
you know, nice little hobby apps and things, I guess.
But I guess at the same time, it's it's quite
heavy weight.
Speaker 1: Well there.
Speaker 4: I mean they improve on that every with every version,
don't they. I mean, Angler is a lot lighter when
you ship it now than it was when it was Angular.
Speaker 3: Two, right, and with ivy coming in, we expect a
lot more degrees in the size of you know, the
web component that we'll be building. Also in in the
talk at Engine, yeah, Rob Rob Warmer came in and
he explained that, you know, with IVY, with Angular ten,
maybe there will be a lot of work on Angular
elements and it might be officially, you know, allowed to
export it as a web component to be used in
other frameworks as well.
Speaker 1: Yeah, that.
Speaker 2: Work on Angular elements in Angular ten.
Speaker 4: Yeah, that would be cool because I'm so having Alexis
the docs on the Angular docks site about about Angular elements,
and it does it does sound like at the moment
you you ship a lot of Angular like with your component,
which is gonna just going to give you a bit
bloated component. But yeah, it'd be nice to see something
maybe in a CLI or something that will just compile
it all the way out to just just straight up
web component. That would be nice because then you know,
you get the advantage that I can write it in
Angular because that's a it's a framework and a syntax
I'm comfortable and happy using, right, So it means that
I could I could start pumping out elements for other
people to use, regardless of their framework. But I can
sit at home or at work using the framework and
the syntax that I'm comfortable with, So that'd be very.
Speaker 2: Cool, exactly.
Speaker 3: And also, you know, your favorite functionality is in any
framework that you work a lot in would be you
would be able to carry those to any other framework
that you might have to work with in any other project. Right, So,
for example, validation and Angular forms is so advanced, so good,
we can use it very you know, for good purposes,
great purposes. So I think carrying that is a functionality
to maybe any other framework or a bune in a
project that that is something you know, with pumpan can
really help us with.
Speaker 4: Yeah. Absolutely. Actually, having recently built some some custom form
validation in Vanilla JavaScript, I can attest to the fact
that if I could have built a form in Angular
and just exported it as a web component that I
could have used, that would have been very nice because Angler, Yeah,
you're absolutely right, Angler, form validation is great. You just
drop a few things in and it works beautifully, whereas
trying to build it yourself does turned into a hot mess.
It was very unpleasant, Right.
Speaker 2: I'm the scurious.
Speaker 3: Did you write a customary validator in Vanilla JavaScript?
Speaker 4: Yeah, I don't. I can't. I don't know how good
it is, but it kind of did the job. But
it wasn't I want to say it wasn't fun. It
kind of was because I was hacking around with something,
you know, and I had a problem to solve. But
it was also I was sitting there, you know, just Oh,
I wish I was doing this in Angular because I could.
I could literally just go validator's not required done. It's like,
instead of just messing around with lines, reams and reams
of code and HTML and all sorts of stuff.
Speaker 2: Are using a component build Angular.
Speaker 4: Should have done that, should have done it in Angular
Angler elements absolutely well. Next time I will, assuming that
they make it so I can fully export it. Right,
But yeah, that's the future, and that that's the future.
That would be good.
Speaker 1: Yeah, anything else we want to pounce on here before
we go to picks.
Speaker 4: I can give you an update on the testing. Let's
do the book. I have no idea. I mean, it
might be that the book is opinionated, right, but the
guy who's writing it, whose name I don't have easy
access to, excellent. He says that there is a He
recommends using something called web Component Tester, which is a
tool created by the Polymer team, and once you're using
the web Component tester, you can just write everything in
your favorite front unit testing library. It looks like he
describes using Maca and we use it with China Think
and then also Calmer, but all using the Web Component
Testing tool. So yes, sounds like you maybe have to
add a little bit of extra stuff in there, but
I guess you could still just unit test the way
you're used to.
Speaker 3: Nice, okay, And about the web component specifications, I think
I can mention more so if you all know. I mean,
we have htmlmplate to template to you know, use templates
just like the version of it we have in Angular right,
just like we use Angie template or you can call
it the success or maybe not really an alternative to that.
But we don't really have HTML imports now because due
to you know, many different like different bundles, multiple imports,
we could not really many browsers didn't support HTML imports.
So that's that's cut off as a web component specification now.
And we have HTML template custom elements. Custom element is
the main bit because you what really wanted the end
of the day is a custom element of your web
component and then shadowed on which is for encapsulating your
styles and downloads from the rest of your component. So yeah,
that's about the Web component specifications.
Speaker 4: Yeah, that's interesting. Actually, in the in the early version
of the Web Components and Action Book, because you know,
Manning do this thing where you can just you can
buy the book as soon as they've got a couple
of chapters written and they update it as as it's written.
In the In the early versions, the author was talking
about HTML imports as being part of the spec, and
then another version comes out and the text has changed
to I'm not so sure this is going to be available,
but but we'll still talk about it, and then yeah,
that's that's pretty much out of the spec now. So
it's interesting. I mean, it's it's it's an evolving spec,
you know, it's kind of just the Web Component's spec
itself is just like evolving before my eyes, just with
literally every every version of this of this book that
I got hold of. So, yes, it is bleeding edge stuff,
isn't it.
Speaker 3: Yeah, But it's also great to be, you know, a
part of the process as it's building and becoming more
progressive and interesting to build with.
Speaker 4: M Yeah, absolutely, I'm going to have to move it
up my to do list. I feel like I say
this every week. Actually, somebody tells me about something that's
some might to do list, I say, move it up
my to do list. I'm just gonna end up with
another to do list, probably with everything I've moved up.
But yeah, I'm going to have to get into this
because I've been fascinated for a long time and this
is going to give me a kick out the backside
that I need.
Speaker 1: I see everybody else grinning when you say I've got
to move it up my to do list. That's me.
Like every week do an episode of any any of
the shows, and it's like, oh, well, I got to
figure this one out now and help.
Speaker 3: Remember we were talking about adding polyphills manually, so with
njxbil plus, we don't really need to add polyphils manually.
And there is this command where you can generate those
polyfhills using the library and it would add all the
polyfills for you, so that again, you know, the library
would help you with And obviously it happens a lot
of times that. I mean I was doing the live
then when I was giving this talk, and I forgot
to add polyphils can you imagine? So that's where the
library would really come to be of help.
Speaker 6: Speaking of polyfills, that is mostly just needed for like
wide browser support, Like if you have a modern browser,
does it require any polyfills or where is that?
Speaker 2: Yes? If you want to support the older browsers as.
Speaker 4: Well, gotcha?
Speaker 6: Okay, so if you like use Google Chrome that is
like the current version of Google Chrome, like that'll just
support any web components mostly yes, Okay, how.
Speaker 4: Can we find that? Is that on? Can I use
or is there a different thing for web components?
Speaker 3: No, no, you can use. Can I use a website
for that? And it would help you with all the browsers?
That would be someppointing.
Speaker 4: Can you just do it for web Well, I'm bound
to find out web components.
Speaker 3: Yes, there's another very interesting website. Let me just share
the link to that customer.
Speaker 4: Yeah, it's not supported in ie.
Speaker 2: Yeah you can imagine.
Speaker 4: Yeah, okay, so well yeah, custom elements are supported an
edge Fire for well everywhere except Internet Explorer. Safari is
needs a bit of work. iOS Safari needs a bit
of work, no surprise.
Speaker 1: Is it?
Speaker 4: Opera Mini completely not supported, But luckily I don't think
anyone uses that QQ browser. I don't even know what
that is. So yeah, customer elements are there in Evergreen browsers.
Speaker 3: Yeah, there's another link to this website that I have shared,
which is called custom elements Everywhere. Now, this website talks
about the compatibility of a framework to be building a
web component. So if you scrawl through it, you would
see that, you know, Polymer is a hundred person compatible
to building web components. It also shows Angular to be
perfectly compatible. Hunded person compatible. No, it's definitely not in
terms of bill size and performance and other things, but
in terms of you know, how you do property binding,
how you you export, I mean emit an event when
you have to deal with any click, let's say in
your web component.
Speaker 2: So again, in terms of that, it's hunded person performant.
Speaker 3: It would tell you for different frameworks which all you
know you can use to build your web component. It
also mentions about DIO. I don't know what that is,
DIO library, Angular JS, hyper HTML late Element. Again, that's
that's hunded person. Yeah, this is interesting as well. Yeah,
that's super helpful.
Speaker 1: Looks like d IO is DART. I might be wrong
just putting it out there.
Speaker 4: I might be wrong, but it's still a thing.
Speaker 1: You just offended a whole bunch of people.
Speaker 4: Where's the flutter show?
Speaker 1: Don't tell me? All right, I have enough going on
right now.
Speaker 4: Sorry, sorry, I'll be quiet.
Speaker 1: No, it's true though. I've had a few people asking
about that.
Speaker 4: Wow, it's interesting. Had angular dart for a while?
Speaker 1: Yes?
Speaker 2: What pas?
Speaker 1: What was that?
Speaker 3: Surplus? I've not heard of this library? This is right
above swell if you see on the website soplus. I
don't know which library that is.
Speaker 1: I'm not sure where is it? Oh surplus?
Speaker 4: Is it surplus js high performance JSX web views? You
lost me at JSX unfortunately. Yeah, let's have that fight,
would be fighting words d I.
Speaker 1: Oh No, that's got to be something else that is
not the dark library.
Speaker 4: Yeah.
Speaker 1: I wish they had a link out.
Speaker 2: Like, yeah, do open the document the official.
Speaker 1: Yeah, this is d I O right.
Speaker 4: Yeah, yeah, that would be helpful.
Speaker 5: Wow, there's there's a lot more libraries doing this than
I thought there was.
Speaker 2: Yeah, me through me through as well. Yeah.
Speaker 3: React React seems to be the lowest in terms of
score this school.
Speaker 6: Oh, here we go. If you click on the real issues,
it will take you to get hub, which I believe
that takes you to the official project gethub.
Speaker 1: Oh they changed is d yo yo of course, now
I want it to be today.
Speaker 7: Oh yeah dds yeah, so yeah, this other one should
just be updated all right, and now my autocorrect is
correcting dodo to dip.
Speaker 1: Well, let's go ahead and do some pics, Eddie. Do
you want to start us off with picks? Sure?
Speaker 6: So I have two picks today. One is sunlight and
warm weather because this warm weather this weekend I've loved it.
And in more practical is next JS. I am kind
of revisiting my personal website and currently it was just
kind of a whole bunch of JavaScript phone together in
just express no JS and so ne sgs. I've been
reading about and kind of starting to experiment with for
being kind of the framework for my website, which I
think will be much nicer because I don't have to
kind of worry about a bunch of architectural things. I
can just write the little bits. It kind of feels
like Anguillar for the back end, which is nice.
Speaker 1: So yeah, I keep hearing that I think we need
to bring somebody out to talk about it. Chris, what
are your picks?
Speaker 4: I'm going to have one pick this week. Last night,
my wife and I went to see our favorite stand
up comedian live who's doing a UK tour. It's like
the first time he's been out in about six or
seven years. It was really funny. He really enjoyed it.
His name is Rod Gilbert, which is our Hod because
he's Welsh. He's just this sort of really abrasive Welsh
funny man who manages to spend a couple of hours
talking about the incredibly mundane things in life that annoy him.
And it is just side splatantly funny. I did a
bit of a search because I appreciate that large proportion
of our listener base and probably in the US, I
did a search to see if you could get his
DVDs and things on Amazon dot Com, and you kind
of can't. It looks like you can get his live
shows on Amazon Music, so if you have Amazon Music,
might be worth listening to, or if you can find
any of his stuff on YouTube. I have no idea
how well the Welsh humor will translate outside of the UK,
but I thoroughly recommend it. He's hilarious. That's Rod Gilbert.
Speaker 1: Awesome Brooks what are your picks.
Speaker 5: I'll pick Capacitor, which is kind of the replacement or
Ionyx version of Cordova. I've been developing some Capacitor plug
ins and so far it hasn't been Capacitor holding me back,
that's for sure. But yeah, it's been good so far.
I've gotten a couple of working, so yeah, that's my pick.
Speaker 1: Awesome. I also was doing a little bit of work
and found that Niche I had written a book, and
so I'll put a link to that in the show
notes as well. It's about angular routing. We'll probably just
how you come back and tell us what we're doing
wrong there, because I know I'm not getting it right,
but anyway, so I'm going to shout out about that.
And then my wife and I have been watching a
show called The Masks Singer and it's it's kind of fun.
Of course, I want to go and like google all
the people and see if I can figure out who
these folks are, and my wife insists that's cheating, so
we'll see. We went back and started watching season two
because I didn't watch it and I don't know who
all these people are under the masks and I can't
google them. Right, because I feel like if I go
look them up, oh this might be so, and so
it'll actually tell me that it is. And yeah, I
want to be some you know, I want to pull
the mask off and then be like, see I was right.
So anyway, so that's been fun. So I'm gonna shout
out about that as well. The masks Singer. I guess
I have one more pick that I'll throw out there,
and it's called Expert Secrets. It's a book by Russell Brunson.
It's awesome. So there you go, Nichs. You what are
your picks?
Speaker 3: I think web I've been exploring web assembly quite a lot.
I'm really curious to, you know, know, how it takes
over the world of front and which is by JavaScript
and is it is it really a competitor? I mean,
is it gonna run in parallel to the JavaScript way
of building or is it going to take over that?
So that's that's pretty interesting. Also, also the terms that
it uses, you know, like a virtual container for for
the building of front and also one place for you know,
the UI, the back end and all that. So yeah,
that's pretty interesting. I've been exploring that quite a lot. Also,
there's a game built all based on web smile vasm.
Speaker 2: That game, it's also is very interesting.
Speaker 3: I don't have the link to that right now, but yeah,
you you should check that game out. That's that's interesting.
That's one of my picks. The other pick, I mean,
which which should be a more of casual thing, as
I pick up from the picks that you've been sharing.
So I think playing with rabbits is quite an interesting
thing that I've been doing lately. My Twitter handle is
the name is after my rabbit, a bet rabbit that
I had, So yeah, that's it.
Speaker 1: Yeah, I guess I should ask that if people want
to connect with you online, where are you?
Speaker 3: Yeah, I'll share diet here in the chat. It's called
Thecosta Wilson on Twitter. I know that that's a stupid name,
but yeah, that's how I used to call my rabbit.
Speaker 1: So oh, I think we've all had dumb handles at
one point or another, or things that were at least
embarrassed about that. Yeah, other people are going to look
at it and go, oh, well that's kind of fun.
Speaker 6: That's what internet handles are good for.
Speaker 1: That's right. Yeah, all right, Well thanks for coming and
talking to us, Niche thank.
Speaker 3: You so much for having me. This is really interesting
to talk to all of you.
Speaker 1: Yeah. Absolutely well, we'll have another one next week. Max
out everybody,