Lucas_Paganini:
Hey, welcome to Adventures in Angular, the podcast where we keep you updated on all things Angular related. This show is produced by two companies, Top End Devs and Envoid. Top End Devs is where we create top end devs to get top end pay and recognition while working on interesting problems and making meaningful community contributions. Envoid offers remote design and web development services with specialization in Angular for companies that truly care about quality. In today's episode, we'll talk about Angular signals Practice! Our guest, Eduardo Roth, wrote an article about his experience building an app with Angular Signals. We'll talk about his first thoughts, what he liked, what he didn't like, how easy it was to use Signals, and how to bridge Signals with RxJS. My name is Lucas Paganini, I'm the CEO of Unvoid and your host in the podcast. Joining me in today's episode is Charles Maxwood from Topendevs.
Charles Max_Wood:
Hey!
Lucas_Paganini:
and Eduardo Roth, our special guest for today.
Eduardo_Roth:
Hello, good morning and thanks for having me here. It's a pleasure for me.
Lucas_Paganini:
Thank you for taking the time. Eduardo, let's get started. So the premise of today's episode is that we won't talk too much about the theory and concepts of signals because everybody's talking about that, right? So we're gonna talk about how it is to actually use signals in practice. So how was the experience? I just wanted to kind of pick your... initial thoughts and then perhaps we can dive deeper from there.
Eduardo_Roth:
Okay, so for me, it was like... I've been working with RxJS for a long time and having to use the observables and the subscriptions, async pipe and everything just to have... Well, for example, if you get one observable and you want to have the values in your template, you will need to subscribe to it and then assign that to another variable or maybe use the async pipe in your application. But with signals, because it's synchronous, you only need to call... This is something that many people will say, that you are not supposed to call a function in your template, because you have to get the value of the signal you need to call it. For me, it's easier to implement or to work with because you are not handling asynchronous values, you are not handling subscriptions, you only need to have the signal, just call it to get the value of it. of it, sorry. From the developer experience perspective, I think it's a simpler approach to using values and implementing reactivity in your code. Because there's a lot of talk about signals replacing RxJS, but I don't think that it's a complete replacement, but something that should be used. alongside RxJS. So signals have these synchronous tasks and things that you can use with that. But RxJS still has a place in Angular, in your Angular applications.
Charles Max_Wood:
So I have two questions on this. One is we've been kind of looking at and reading a whole bunch of things about signals, like Lucas said. We actually did another podcast episode, and I think Armin went into some depth as far as what is being said about signals. But I don't think he had tried the reference implementation that they've kind of been putting into Angular, but haven't, I guess, fully released. And so I'm curious, does your experience with signals kind of line up with what people are talking about it being able to do? Or are people fundamentally misunderstanding what it does from what they're reading on the internet versus what Angular is actually implementing or implemented so far?
Eduardo_Roth:
I think that when people heard about Angular signals, their first thought was, this is going to replace RxJS. This is going to simplify the way that we implement reactivity in Angular, and we no longer have to worry about subscriptions, observables, and things like that. The real thing is that signals is going to help developers to... In the long term, it... it might replace or it might enable zone-less applications. But right now, for developers, it's going to make it easier to implement some reactivity in their code. You don't have to worry about observables. But for example, if you want to have a synchronous task or just an HTTP call, you will still rely with observables. I think that the first approach that people had was, this is going to change the way that Angular works, and it is going to change how we work with Angular, but not the way that people thought.
Charles Max_Wood:
OK, but they work more or less like if you go read the implementation in Solid.js or, you know, I think Preact built theirs in. It's going to work mostly the same as those, right?
Lucas_Paganini:
Yeah, I've been checking out some differences between the signals implementation in Angular versus the implementation in other frameworks. And it's mostly syntax changes. So there are implementations where you just do like signal.value and then you have this getter property, which... If you look at it, it seems like you're just accessing a regular property of an object, but internally it's actually a getter that is registering the dependency and automatically updating it when the things that it depends on changes. But on Angular, they decided to really use it as a function. So all signals are a function. So if you have a signal, you just call it like a regular function. And this is the way that you get the value. But other than that, other than synthetic changes, it's really the same concept. And that actually was a great question because in the AngularRFC, the request for comments that they opened for the community to give their inputs about Angular signals, there was a section about why not just use a library. that implements signals, why rewrite it? Why create an implementation just for Angular? And there are many reasons for that, but mostly is because they don't want to have something that is gonna be such a core thing from the framework, depend on an external implementation. So if they want to have full control over the implementation such that they can really integrate it with how they want it to work with the Angular internals. and Yeah, it's actually mostly that.
Charles Max_Wood:
Well, I can
Eduardo_Roth:
down.
Charles Max_Wood:
see also if the difference is mostly syntactic. I mean, I want it to be natural to me as an Angular developer to use it the same way I use everything else. And so it just gives them that level of control too, right? It looks like it belongs with everything else. It's not, oh, well, we went and grabbed this thing in, and it's slightly different.
Lucas_Paganini:
And that's... We can relate this to what Eduardo said, which is we've been taught as Angular developers to never call function inside a template. So that was actually a really interesting decision from the Angular team, like the fact that they chose to use a syntax which forces you to be calling a function in the template. Now, they could have just used the get accessor, like dot value. And it would actually fix another problem, which is type inference from TypeScript, because for example, if you have a, if you use TypeScript narrowing, so let's say that you have a signal which can either be a string or null, and then you say like, signal value equals, type of signal value equals equal string, then you know that it's a string, it's not null. And then you can use it in your, in all the child elements. knowing that it's going to be a string and it's not going to be null. So you can do like ngf and then you have it correctly type checked. But because it's a function, they are actually considering to add a custom type check to the TypeScript compiler checks in the template because it's a function, TypeScript doesn't understand that if you call it twice, it's going to return the same value. TypeScript thinks, oh, it's a function, it can return different things
Eduardo_Roth:
anything.
Lucas_Paganini:
all the time, it can return anything. So you can't do the isString check and just expect it to be a string internally, because if you call it again, TypeScript will just throw away the type narrowing check that you did. One way to maneuver that is to create a variable. So instead of just calling the function twice, you call it once and then you save it in a variable. So for example, const name is equal to, and then the name signal being called. And then you just do your isString in the name const that you just created, and then you just did your type check. But the problem is that in the template it's not so easy to create variables. So, yeah.
Eduardo_Roth:
Yeah, I've seen this approach of some developers that it reminds me the days of AngularJS because they create a constant or a variable in the component called VM, like view model. And they assign properties with the signals. So instead of... So you get the whole view model in your component, and you can use that in your template, and the values are... automatically updated in the component. So you call the signal function and you assign that to a property. So technically it works and you don't have to call the function in the template.
Lucas_Paganini:
Yep, by the way, what do you thought about that when you were building your application? Was it annoying that you didn't have this type narrowing working as easily as it could have been? Or do you think that it's okay the way that it is and the fact that it's a function being called and then you just lose the type narrowing, but what do you prefer?
Eduardo_Roth:
To be honest, I didn't mind not having the Type Narrowing in the template. As long as I have it in my component, I think that it's good enough. But I think that there's some effort to have this strict template checking or the Type Narrowing, like you mentioned. So it's going to improve the developer experience. So you know actually... exactly what variable and properties you have from your signals. But for now, it didn't bother me.
Charles Max_Wood:
Well, and I have to say that we've got some of these things where we're like, hey, maybe it could be a little more perfect. But
Eduardo_Roth:
Mm-hmm.
Charles Max_Wood:
I like that there's something out there that, hey, we can poke it. We can put it into our app. We can figure out what's going on. And then we can come back and tell the Angular team, hey, look, this would be really nice. So maybe, yeah, maybe we figure out, under these circumstances, the type checking would be really important. But under most other circumstances, pretty consistent and so, you know, it's not a big deal. But yeah, I mean, kudos to them for at least getting something that we can go look at and play with and see what it looks like. I'm kind of curious, did you feel like there were things that they could have done better or things that they should improve before they put it out? Is it ready for prime time or not?
Eduardo_Roth:
I think it was just in time for developers to try it. It was like they have enough functionality so we can test it. And we can give... Well, they released a developer preview in Angular 16 Next 0, or the first version of Angular 16.
Charles Max_Wood:
Mm-hmm.
Eduardo_Roth:
And then they gave us the RFC around one week or two weeks later. So I think that was a great approach. So we can test it. the current functionality, and then we can improve it with comments on the RFC. So I think it was good enough so we can test what they are trying to achieve and get enough... get enough information so we can comment more on the RFC and give more valuable comments there. So I think it was great.
Lucas_Paganini:
Yeah, I really like that. I've been saying that in the past episodes, but I really think that the Angular team isn't being appreciated enough by the commitment that they are having with the community to open up to them and accept suggestions. Because at the end of the day, let's think about it this way. Angular was created by Google. So actually, although it is open sourced, and we all benefit from it and I'm very thankful for it, it was actually made to be used by Google. Like the interests should be directed towards Google and they are opening up to everyone to give their inputs and their feedback and they don't really have any monetary gains from that at all. There's the community effect of... Hey, you see that we value your opinions, so everybody feels that they can actually trust the framework and they can adopt it, which makes the ecosystem bigger, which helps Google at the end of the day. But in a more short to medium term, there aren't really any other benefits that I can think of for them to do that. So it's really cool that they do it.
Eduardo_Roth:
Yeah, I think that, well, I guess that the bad perception of the Angular team was from the Ivy change, because it took like three years, if I recall correctly, it took around three years to get Ivy enabled and working for libraries and applications. And I remember that the Angular team at that time was like, oh, the next big thing is going to be Ivy, you keep an eye on that. And it was like... one year, two years, three years until we finally got Ivy, because it was on Angular, I think it was nine, but it was like partial support for Ivy Engine. But after Angular 11, it was like, okay, we are ready. This is production ready for applications, libraries. And then after that, it came like the Angular team was so into the community and getting the feedback. And okay, so we are going to try this. this stuff, or we want to hear from you what do you want. And for example, standalone components, it was like a huge thing in the Angular community. And it was brought by the team. Sorry. It was brought by the team, and they mentioned that, well, it It was like the main problem from Angular was the modules. And they, give me just
Charles Max_Wood:
Mm-hmm.
Eduardo_Roth:
one second, sorry.
Lucas_Paganini:
Ha ha ha ha
Charles Max_Wood:
No,
Lucas_Paganini:
ha
Eduardo_Roth:
It's
Charles Max_Wood:
it's
Eduardo_Roth:
my daughter.
Charles Max_Wood:
all good. I've been there.
Lucas_Paganini:
So cute
Eduardo_Roth:
Yeah, so I'm so sorry.
Lucas_Paganini:
Never own
Eduardo_Roth:
Working at home and having three daughters can
Charles Max_Wood:
Oh,
Eduardo_Roth:
be quite a mess.
Charles Max_Wood:
I totally understand, so, yeah.
Eduardo_Roth:
Yeah, so I was saying that Angular team has been so open to the community and they have been giving us some RFCs to main functionality or changes that they want. I think that they learned from their mistakes from AngularJS to Angular 2 or plain Angular migration or change. So right now, they try to keep... everything working and they try to streamline any big changes that they have. They are really open to hearing back from developers and community.
Charles Max_Wood:
Yeah, I agree. I kind of want to change gears a little bit just because I'm curious. So what do I have to do in order to give this a try? Let's say I want to go build an app and see how the signals are working and where I may or may not replace or make signals work with RXJS. Do I just go get the pre-release and then I'm good to go or are there other steps?
Eduardo_Roth:
Yeah, exactly. You only need to create an application using Angular 16. I think that the latest is Next 7. But you only need to call the Angular CLI with addNext, and that's it. You already have it enabled. No need to enable any flags or anything else.
Charles Max_Wood:
Oh, nice,
Eduardo_Roth:
As long as you are
Charles Max_Wood:
nice.
Eduardo_Roth:
using...
Charles Max_Wood:
So I guess the other question is, once I have it in, then, yeah, how do I start adding it into the app? So do I just
Eduardo_Roth:
Just
Charles Max_Wood:
declare
Eduardo_Roth:
out.
Charles Max_Wood:
a signal somewhere?
Eduardo_Roth:
Yeah, you only need to create a constant, like const something equals signal, and you add the initial value because every signal has to have... Well, I think that they added a null or no initial value signal with the latest changes in the Angular signals implementation, but you only need to call that const something equals signal, and that's it. You import the signal... a class from Angular Core. I think that's the package. But VSCode or WebStorm automatically do that. So you don't have to worry about importing. And that's it. You already have a signal working.
Lucas_Paganini:
Is there anything that doesn't currently work with signals? For example, do we have any issues regarding server-side rendering or any other parts of Angular that maybe aren't as smoothly integrated with signals yet?
Eduardo_Roth:
I don't think so. I don't use that much as SSR, or server-side render. But I think there are no current issues with signals, at least. I heard that there are some issues with the standalone components and PWAs and standalone components and server-side rendering. But as far as I know for signals, there are no issues that I'm aware of.
Lucas_Paganini:
Okay, and now I'm very curious to know, how do you actually do the bridge between signals and RxJS? Like we know that this is possible, but in practice, how is it?
Eduardo_Roth:
Well, on the first release of Angular 16, I don't remember when they implemented the fromObservable or fromSignal methods. I think it was around v16.next.tree. But with those functions, you can bridge between observables and signals because you can easily change an Observable to a Signal and a Signal to an Observable. And the way that this works is that it uses the destroyed ref, Lifecycle Hook, I think it's a class. But you can, well, internally, they use that to unsubscribe the Observable when you change that to a Signal. So the way that it works is that, for example, if you want to get... Well, right now it's not from Observable and from Signal. They changed that to Signal and to Observable. So, for example, if you want to change an Observable to a Signal, you use that function to Signal, and internally it subscribes to the Observable, and any time that the Observable emits, it sends a new value to the Signal. So you get that working from the Observable. And when the component, well, by using DestroyRef, the observable unsubscribes automatically, so you don't have to worry about that. And it's really good because you no longer have to worry about unsubscribing your observable. So, and for example, if you want to, if you have an HTTP call that it's unobservable, and you only need to do to call that and to signal, and you have it working in your component. No longer have to use the asyncPy for subscribing in your component, and then assigning the value to another variable.
Lucas_Paganini:
I really like the destroy ref. I know that it isn't exactly the subject here. I know that this is being used by the bridge between signals and observables. But I really think that this is so cool because a problem that I had with Angular, and this is actually the most popular article that I have on Medium, was because I created a library that allow developers to easily destroy unsubscribed observables when the component was destroyed. So he used some tricks with dependency injection. There's also a really good library from Netanel Bazal. I think it's, yes, Netanel Bazal, which is Nginit, if I recall correctly. which also does a really good job at providing a clean way to automatically unsubscribe from observables when the component is destroyed. But everything got so much easier when Angular exposed the inject function, because
Eduardo_Roth:
Mm-hmm.
Lucas_Paganini:
when we
Charles Max_Wood:
Yes.
Lucas_Paganini:
got that, we were able to just inject the view reference, and the view reference has a callback for when the view is destroyed, and then you can just turn that callback into unobservables, and then, boom, you can just call... like use until destroy, and then you have this observable that is going to emit when the component is destroyed, and then you can just use that along with the take until operator of RxJS to automatically unsubscribe your observables. And that solves a really big problem, which was splitting your code. So the place where you actually used the observables was isolated from the place where you... managed the subscription and unsubscribed from it. So you had your NG on destroy with a bunch of unsubscriptions,
Charles Max_Wood:
No.
Lucas_Paganini:
but the place where you're actually using those subscriptions was elsewhere. Then the code gets a little bit harder, not impossible
Charles Max_Wood:
No.
Lucas_Paganini:
of course, but a little bit harder to follow because things are separated. So now with Angular 16, they're exposing a new interface to listen to.
Charles Max_Wood:
Yes.
Lucas_Paganini:
the moment where the component is destroyed. And this injectable is
Charles Max_Wood:
internet.
Lucas_Paganini:
the destroy ref. So you no longer need to inject the view ref and then listen to on destroy. You only need to inject the destroy ref,
Charles Max_Wood:
Yes.
Lucas_Paganini:
which at the end of the day, it does the same thing, but it's a more,
Eduardo_Roth:
That's simpler.
Lucas_Paganini:
yeah, simpler. And the responsibility is more isolated like. If you just want to listen to onDestroy,
Charles Max_Wood:
Internet.
Lucas_Paganini:
you may wonder, why do I need to inject the ViewRef? What is the ViewRef? What does that mean? But now you don't have that problem because you want to know when it's about to get destroyed, you inject something called DestroyRef, you're like, oh, okay, that makes sense.
Eduardo_Roth:
Mm-hmm.
Lucas_Paganini:
So yeah, I think that's actually a really interesting thing. And even to developers that are not going to use
Charles Max_Wood:
No.
Lucas_Paganini:
signals as soon as it gets released for whatever reason, This is actually super useful to clean up your observable subscriptions You can fully
Charles Max_Wood:
No.
Lucas_Paganini:
get rid of ng-on-destroy in most components because most components in ng-on-destroy the only thing that they do honestly
Eduardo_Roth:
It's
Lucas_Paganini:
is just
Eduardo_Roth:
unsubscribe.
Lucas_Paganini:
unsubscribe. Yeah
Eduardo_Roth:
Yeah, you can create an operator function and then
Charles Max_Wood:
No!
Eduardo_Roth:
just add that to the pipe in your observables, and it will unsubscribe there. So it's going to simplify the way that. I think that what the Angular team is trying to do is simplify the way that we work with Angular, having to learn the fewer topics or things before we can start. having the mental models that we have to think about. I think that they want to have something that it's really easy for beginners to start working on, and it's going to simplify the way that expert developers code. I think that this is something great that they are doing.
Lucas_Paganini:
Me too, me too. And it's also good for the advanced use cases, right? Because signals make the application much more performant. Like the real problem that signals solve beyond the developer experience, which is a problem, not going to devalue that, but the other problem that it solves is that when you're in a really big application... Even if you're using on push change detection in all your components, you're still
Charles Max_Wood:
One.
Lucas_Paganini:
not getting all the performance that you
Charles Max_Wood:
Piece
Lucas_Paganini:
could
Charles Max_Wood:
of trash!
Lucas_Paganini:
get. Because if you're using on push, like you're already doing manual change detection, like you should get more benefits than the benefits that you do get with on push. Like for those of you that maybe aren't aware of, when you're using on push, a lot of developers think that if you're using on push, it only... detects changes to your current component. But that's actually not true. It still checks the parent components too. Like it's not going to check the child elements and child components from your own push component, but it's going to go upwards because it starts from the top until it gets to your component always. So yeah, you're still doing unnecessary checks at that point.
Eduardo_Roth:
Now with signals, we get this fine-grained reactivity, and any signal that triggers a change will just update exactly the part of the component. It no longer has to recreate or check any parent or child component. Also, we finally can get rid of Zone.js. This is something that the Angular team is also working on. I think that on the next release, I don't think it's going to be labeled Developer Preview yet, but they have these... On Bootstrap application, they are going to add a function to provide the zone.js function, so you can disable that and handle the change detection by yourself. This is not something that is going to be production-ready yet, and it's something that... we might not see even on Angular 17. But this is, I think that finally, we will be able to have full Soneless application, and we can remove the overhead of having some JS loading and monkey patching every single event in the browser. So this is also something big that will land on Angular, I expect, soon. Sooner than later.
Lucas_Paganini:
Actually, I've never seen anyone removing Zone.js from production currently, but I know that this has been a possibility for a while now because you can just inject Zone.noop.
Eduardo_Roth:
Mm-hmm.
Lucas_Paganini:
And then if you provide Zone.noop in your app module, then it's not going to use the actual implementation of Zone. It's just going to... It's just a mocked... that doesn't do anything. It just provides the interface that Angular expects for zone.js, but it doesn't actually do anything. But I wonder, like, this exists for a while. The zone.noop exists for a while. But if anyone uses that currently, how do they code an Angular application? Like, if you use on push change detection, then it works with zone.noop?
Eduardo_Roth:
No, you will need to add the check, well, mark for dirt and check changes. Or I don't remember the exact function names, but you will need to handle that by yourself. And you will need to add a lot of extra code that the Angular team is trying to reduce. So you can, well, I think that by the end, they are trying to get rid completely of some JS. But they are, because they know there are a lot of applications. that might rely on that or might not be updated really soon, they still keep that. So they are giving us the chance to still use ZoneJS or remove it completely. And they will make the transition
Charles Max_Wood:
I don't have wifi
Eduardo_Roth:
easier
Charles Max_Wood:
on that
Eduardo_Roth:
for
Charles Max_Wood:
rubber.
Eduardo_Roth:
us to just, let's say you provide, I'm not sure if it's going to be a no-op function, but you are going to be able to replace the ZoneJS implementation in your AMP. Angular applications, and that's it. And you are going to be able to have a full soundless application. I think that there are some libraries that actually use that kind of approach. For example, I remember Rx Angular, or that's something that works with RxJS, and I think that they have this soundless implementation, or they have this guide on how to implement Rx on Angular without sound. or disabling song jitters.
Lucas_Paganini:
Interesting. Okay. There is another entire topic that we haven't gotten into, but I'm really curious about, which is migrations. So
Charles Max_Wood:
Yes.
Lucas_Paganini:
first, do we have an easy path forward, maybe with tools that the Angular team is going to create, to facilitate a migration from... zone-based components to signal-based components, or will we have to do it all manually?
Eduardo_Roth:
That's something that some developers have asked me. I know there's
Charles Max_Wood:
No.
Eduardo_Roth:
an schematic for migrating NG modules application to a standalone. For this type of change
Charles Max_Wood:
My internet
Eduardo_Roth:
for zone
Charles Max_Wood:
connection keeps
Eduardo_Roth:
and
Charles Max_Wood:
dropping.
Eduardo_Roth:
at least for signals, I don't think that this is something that it's easy to create an schematic because the way that your application You might have some observables and you might have some variables.
Charles Max_Wood:
No!
Eduardo_Roth:
The way that we work right now with RxA.js and libraries, I don't think that it's going to be easy to create something that works for everybody.
Charles Max_Wood:
accessing
Eduardo_Roth:
I guess
Charles Max_Wood:
the
Eduardo_Roth:
that
Charles Max_Wood:
internet.
Eduardo_Roth:
it can give some recommendations or some ESLint rules with warnings or information notices, like, this is something that you can change, or you can replace this observable with a signal and to signal method. but I don't think it will be possible, or at least with my knowledge, I don't find it easy to create an schematic to automatically migrate this. It can
Charles Max_Wood:
No!
Eduardo_Roth:
be a combination of things, but at the end of the day, you will have to manually update a lot of code.
Charles Max_Wood:
Let me talk to somebody.
Eduardo_Roth:
I guess it can give you this recommendation. If it finds some observables, it can say, you can create a
Charles Max_Wood:
Let
Eduardo_Roth:
signal
Charles Max_Wood:
me talk to
Eduardo_Roth:
and
Charles Max_Wood:
an
Eduardo_Roth:
just
Charles Max_Wood:
agent.
Eduardo_Roth:
call
Charles Max_Wood:
Let me talk to
Eduardo_Roth:
toSignal
Charles Max_Wood:
an agent.
Eduardo_Roth:
method,
Charles Max_Wood:
Let
Eduardo_Roth:
and that's
Charles Max_Wood:
me
Eduardo_Roth:
it.
Charles Max_Wood:
talk to an agent.
Eduardo_Roth:
But to actually
Charles Max_Wood:
Let
Eduardo_Roth:
manually
Charles Max_Wood:
me talk to an agent.
Eduardo_Roth:
update your code, I find it difficult to do. So
Charles Max_Wood:
No!
Eduardo_Roth:
I think that this is a huge change
Charles Max_Wood:
No,
Eduardo_Roth:
that will...
Charles Max_Wood:
let me talk to an agent.
Eduardo_Roth:
Well, it depends on the size of your application, but I guess that you are going to add some effort to actually migrate or change to signals completely if you rely a lot on RxJS and observables.
Lucas_Paganini:
Gotcha, gotcha. Yeah, I imagine that that would be
Charles Max_Wood:
Charles Wood.
Lucas_Paganini:
the path forward because you're right, like this is too intrinsic to the way that you organize your code base for a tool to automatically
Charles Max_Wood:
I'm alright,
Lucas_Paganini:
migrate
Charles Max_Wood:
just
Lucas_Paganini:
it.
Charles Max_Wood:
frustrated
Lucas_Paganini:
I mean,
Charles Max_Wood:
with the internet connection.
Lucas_Paganini:
if a tool could do that, then I don't think it would be a regular schematics. They would have to use perhaps artificial intelligence to try to figure it out. But
Eduardo_Roth:
Yeah. Ha
Lucas_Paganini:
yeah. I don't see that
Eduardo_Roth:
ha.
Lucas_Paganini:
happening so soon, which is a shame, because it would be so cool if
Eduardo_Roth:
Yeah.
Lucas_Paganini:
new things were released, and then you just run a script, and boom, you're in the new version. That would be awesome. That's actually one of the things that we do a lot in Unvoided, my company, is we do a lot of Angular upgrades. The client comes
Charles Max_Wood:
Yep.
Lucas_Paganini:
in, and they're in an older version of Angular. and we help them migrate to the latest versions. This is kind of like an entry service. You know, it's like, you don't know me,
Charles Max_Wood:
So I got
Lucas_Paganini:
I don't
Charles Max_Wood:
a
Lucas_Paganini:
know
Charles Max_Wood:
new
Lucas_Paganini:
you,
Charles Max_Wood:
modem
Lucas_Paganini:
but I see that you have this need,
Charles Max_Wood:
and I put
Lucas_Paganini:
and this
Charles Max_Wood:
it
Lucas_Paganini:
is
Charles Max_Wood:
in,
Lucas_Paganini:
a service that we can
Charles Max_Wood:
I can't
Lucas_Paganini:
get
Charles Max_Wood:
remember
Lucas_Paganini:
started
Charles Max_Wood:
if it was
Lucas_Paganini:
working
Charles Max_Wood:
yesterday
Lucas_Paganini:
together,
Charles Max_Wood:
or
Lucas_Paganini:
and
Charles Max_Wood:
the
Lucas_Paganini:
then
Charles Max_Wood:
day before,
Lucas_Paganini:
the partnership
Charles Max_Wood:
but
Lucas_Paganini:
goes from there. But
Charles Max_Wood:
just periodically
Lucas_Paganini:
it's interesting
Charles Max_Wood:
the internet
Lucas_Paganini:
because
Charles Max_Wood:
just drops out.
Lucas_Paganini:
it gets,
Charles Max_Wood:
And then
Lucas_Paganini:
it's
Charles Max_Wood:
it'll
Lucas_Paganini:
getting
Charles Max_Wood:
come back
Lucas_Paganini:
easier
Charles Max_Wood:
after a couple minutes, but. So, I'm gonna
Lucas_Paganini:
to do
Charles Max_Wood:
go ahead
Lucas_Paganini:
upgrades.
Charles Max_Wood:
and turn
Lucas_Paganini:
Like,
Charles Max_Wood:
it
Lucas_Paganini:
even
Charles Max_Wood:
off.
Lucas_Paganini:
though we're talking about something so big as signals, everything else that existed before is still supported. So upgrading to Angular
Charles Max_Wood:
Yeah,
Lucas_Paganini:
16
Charles Max_Wood:
well it's
Lucas_Paganini:
doesn't
Charles Max_Wood:
intermittent outages
Lucas_Paganini:
break
Charles Max_Wood:
more than intermittent
Lucas_Paganini:
your zone-based
Charles Max_Wood:
connection.
Lucas_Paganini:
components,
Charles Max_Wood:
It's connected
Lucas_Paganini:
doesn't
Charles Max_Wood:
most
Lucas_Paganini:
break
Charles Max_Wood:
of the
Lucas_Paganini:
what
Charles Max_Wood:
time,
Lucas_Paganini:
you had
Charles Max_Wood:
but
Lucas_Paganini:
before.
Charles Max_Wood:
yeah,
Lucas_Paganini:
It's like
Charles Max_Wood:
it'll just drop
Lucas_Paganini:
you're still
Charles Max_Wood:
out.
Lucas_Paganini:
gonna get more benefits, you're still gonna get performance improvements, security improvements, developer experience improvements, but those new features, they are optional for your use. So if you don't want to use them, then... That's okay, well, at least for now. I imagine that eventually
Eduardo_Roth:
Thanks for watching. Bye.
Lucas_Paganini:
they're going to... They are really not mentioning that. If you look at the RFCs, they're being very clever with their words. But the thing is, eventually, I think that they're just gonna drop Zone.js. But this is probably gonna take a very long time because they do not, they definitely don't want to make the entire community angry by making this big change so soon.
Eduardo_Roth:
Yeah, I guess that they will mark those or zone applications or everything as deprecated, and they are going to leave like two or three major versions, and then they are going to be removed. So that gives enough time for the LTS, well, the latest Angular LTS version for companies to catch up. Here at HeroDev, we also work on Angular migrations. And one thing that you mentioned is that You can actually tell this is something that they work on because on the first versions of Angular, Angular 2, and then 4, 5, 6, and I think that up to 9, you have to do a lot of changes in your code, manual changes in the way that your application is built. But after that, if you jump from 9 to 10 or up to 16, it's just like...
Charles Max_Wood:
Um,
Eduardo_Roth:
It's really easy
Charles Max_Wood:
it was getting
Eduardo_Roth:
and
Charles Max_Wood:
errors
Eduardo_Roth:
everything
Charles Max_Wood:
periodically.
Eduardo_Roth:
works. Even if you
Charles Max_Wood:
It was,
Eduardo_Roth:
just
Charles Max_Wood:
it was,
Eduardo_Roth:
change the Angular version, everything
Charles Max_Wood:
it
Eduardo_Roth:
works
Charles Max_Wood:
was kind of doing the
Eduardo_Roth:
and
Charles Max_Wood:
same thing. It just wasn't
Eduardo_Roth:
you
Charles Max_Wood:
doing
Eduardo_Roth:
can have
Charles Max_Wood:
it
Eduardo_Roth:
your
Charles Max_Wood:
as often.
Eduardo_Roth:
Angular application on your latest version. And if you want to get the benefits of the latest changes or the latest updates, you have time to do that and you can plan an upgrade time or project so you can implement those features while still having your application working. in production. So I think that this is something that the Angular team has been doing really good, like don't break in anything. They learned their mistake from AngularJS to Angular.
Lucas_Paganini:
Yes,
Eduardo_Roth:
So.
Lucas_Paganini:
yeah, yeah. And actually, that's another good point. I know that this, what I'm going to say, may sound distant from the reality of most developers listening to the podcast. But I assure you, it's not so distant.
Charles Max_Wood:
I
Lucas_Paganini:
There
Charles Max_Wood:
haven't
Lucas_Paganini:
are a
Charles Max_Wood:
tried
Lucas_Paganini:
lot
Charles Max_Wood:
that,
Lucas_Paganini:
of developers
Charles Max_Wood:
but
Lucas_Paganini:
in this situation,
Charles Max_Wood:
it does
Lucas_Paganini:
which
Charles Max_Wood:
it
Lucas_Paganini:
is
Charles Max_Wood:
across the
Lucas_Paganini:
there
Charles Max_Wood:
entire
Lucas_Paganini:
are a lot
Charles Max_Wood:
network.
Lucas_Paganini:
of developers
Charles Max_Wood:
It's not the WiFi.
Lucas_Paganini:
working still on Angular version 1. There are still many applications written in AngularJS and they haven't been migrated to Angular version 2.4.5.6, whatever. They are still running AngularJS. So they're not, we're talking about like the benefits that we're gonna get with signals. Like there are people that haven't even gotten the benefits from like the Ivy compiler and typed forms. Like there's so many things that those... projects are not getting because they are still on AngularJS. And I remember that there was a time where the Angular docs, they had a clear migration path from AngularJS to the latest version of Angular. But it's been a while since I haven't read that or seen how this is looking like nowadays. But I do wonder, as we progress in terms of features, And again, I'm not complaining about that. Let's add as many useful features as we can. But the more we progress, I imagine that it might get harder for those that are still running AngularJS to migrate to the latest versions of Angular. Do you have any information about that? Like, have you recently done any work from migrating AngularJS to a latest version of Angular? How is that migration path?
Eduardo_Roth:
Well, actually at Herodev's too, we work on migrations from AngularJS to Angular. So right now I'm working on one and we are jumping from AngularJS latest version, which was 1.8. And we were working on migrating that to Angular 9 because that was the client application Angular version. But then they started working on updated that. And right now they are on Angular 13. Actually, the change from Angular 9 to Angular 13 was just so small. It didn't require that many changes. And this is something that... It's kind of like a complete rewrite. Well, if you were using AngularJS components, then it's kind of like similar. Not the same, but you get the live hooks, and you already got the onInit methods on destroy. So it's... It's kind of similar, but if you were on previous versions of AngularJS where everything was on the controller and that directive, it's going to be a huge change. And you will probably have to almost rewrite your whole application to support Angular. So that's a huge effort to take. And that's the main reason that many companies still use AngularJS. Actually, for example, Microsoft was... recently released the Teams application, the Teams version 2, or I'm not sure how they call that. And they released the current stack and the previous stack of technologies. Right now, they are using React, which is a shame because they should have gone with Angular. But the application that was running on production was AngularJS. So it was like, even in 2023, we still... use, major companies are still using AngularJS, which is good because the application or the framework still works, but bad because where are the security fixes and the performance and application improvements of latest frameworks and technologies. But to answer the question, it's a huge effort to switch from AngularJS to Angular. That's the reason that you can still find many applications and companies are still using AngularJS. But as time passes, it's going to be more complex and complicated. Right now, AngularJS is... I think that it stopped getting any security fixes for four years right now. As time passes, it's going to be more complicated and harder and riskier for companies to still use AngularJS.
Lucas_Paganini:
Yeah. So what you're saying is that in terms of migration, we're kind of at the path where we're kind of at the point where you don't really migrate, you just rewrite.
Eduardo_Roth:
If your AngularJS application was using components, then you can copy-paste and then just update a couple of things. But if it wasn't, you will need to rewrite your application. So it's not like just call
Charles Max_Wood:
Um
Eduardo_Roth:
the CLI migration script and you got the Angular
Charles Max_Wood:
I mean
Eduardo_Roth:
application
Charles Max_Wood:
during the day
Eduardo_Roth:
running.
Charles Max_Wood:
I'm the only
Eduardo_Roth:
No,
Charles Max_Wood:
one here so it's just
Eduardo_Roth:
sadly, it's not that easy.
Charles Max_Wood:
my
Eduardo_Roth:
So
Charles Max_Wood:
laptop
Eduardo_Roth:
you
Charles Max_Wood:
and
Eduardo_Roth:
have
Charles Max_Wood:
my phone
Eduardo_Roth:
to do a
Charles Max_Wood:
and
Eduardo_Roth:
lot
Charles Max_Wood:
maybe
Eduardo_Roth:
of
Charles Max_Wood:
a
Eduardo_Roth:
manual
Charles Max_Wood:
tablet.
Eduardo_Roth:
work.
Lucas_Paganini:
Gotcha, gotcha. Yeah, but that actually sounds like a fair point.
Charles Max_Wood:
But yeah,
Lucas_Paganini:
You can just
Charles Max_Wood:
and then
Lucas_Paganini:
upgrade
Charles Max_Wood:
I think
Lucas_Paganini:
to the
Charles Max_Wood:
we have
Lucas_Paganini:
latest
Charles Max_Wood:
like
Lucas_Paganini:
version
Charles Max_Wood:
thermostats
Lucas_Paganini:
of AngularJS.
Charles Max_Wood:
that connect and
Lucas_Paganini:
You try
Charles Max_Wood:
we
Lucas_Paganini:
to
Charles Max_Wood:
have a bunch
Lucas_Paganini:
migrate
Charles Max_Wood:
of Amazon Firesticks
Lucas_Paganini:
everything to
Charles Max_Wood:
and
Lucas_Paganini:
Angular
Charles Max_Wood:
Amazon
Lucas_Paganini:
components.
Charles Max_Wood:
Alexa's that
Lucas_Paganini:
And then after this
Charles Max_Wood:
all connect
Lucas_Paganini:
step
Charles Max_Wood:
as
Lucas_Paganini:
is
Charles Max_Wood:
well.
Lucas_Paganini:
done,
Charles Max_Wood:
But
Lucas_Paganini:
then you are
Charles Max_Wood:
like
Lucas_Paganini:
more
Charles Max_Wood:
I said, I'm
Lucas_Paganini:
prepared
Charles Max_Wood:
the only one here right
Lucas_Paganini:
for
Charles Max_Wood:
now.
Lucas_Paganini:
the
Charles Max_Wood:
I'm not using
Lucas_Paganini:
actual
Charles Max_Wood:
really
Lucas_Paganini:
migration
Charles Max_Wood:
any of those. So.
Lucas_Paganini:
to the latest version of Angular.
Eduardo_Roth:
Yeah, exactly.
Lucas_Paganini:
But... Now we're actually getting to a pivotal moment on that because even the lifecycle methods are changing with, like
Charles Max_Wood:
Yeah,
Lucas_Paganini:
signal-based
Eduardo_Roth:
Yeah.
Charles Max_Wood:
I do have an internet
Lucas_Paganini:
components,
Charles Max_Wood:
connection right
Lucas_Paganini:
they
Charles Max_Wood:
now.
Lucas_Paganini:
have different lifecycle
Charles Max_Wood:
Like
Lucas_Paganini:
hooks.
Charles Max_Wood:
it goes down for
Lucas_Paganini:
So
Charles Max_Wood:
like five
Lucas_Paganini:
even
Charles Max_Wood:
minutes
Lucas_Paganini:
that
Charles Max_Wood:
and then it
Lucas_Paganini:
is
Charles Max_Wood:
comes
Lucas_Paganini:
like,
Charles Max_Wood:
back up. The problem
Lucas_Paganini:
it's kind of
Charles Max_Wood:
is,
Lucas_Paganini:
like
Charles Max_Wood:
is
Lucas_Paganini:
a
Charles Max_Wood:
that
Lucas_Paganini:
window
Charles Max_Wood:
I run a podcast network
Lucas_Paganini:
that
Charles Max_Wood:
and I'm
Lucas_Paganini:
is
Charles Max_Wood:
recording a podcast over
Lucas_Paganini:
rapidly
Charles Max_Wood:
the network, I can't
Lucas_Paganini:
closing.
Charles Max_Wood:
have it go down while I'm recording. So,
Lucas_Paganini:
Or,
Charles Max_Wood:
I'm recording
Lucas_Paganini:
well,
Charles Max_Wood:
a podcast
Lucas_Paganini:
they
Charles Max_Wood:
over
Lucas_Paganini:
could
Charles Max_Wood:
the
Lucas_Paganini:
just
Charles Max_Wood:
network. I'm recording
Lucas_Paganini:
still migrate
Charles Max_Wood:
a podcast over
Lucas_Paganini:
to zone-based
Charles Max_Wood:
the network.
Lucas_Paganini:
components, which would still be better than AngularJS.
Eduardo_Roth:
dan kami yang jual aja ya
Lucas_Paganini:
Yeah, yeah. Interesting.
Eduardo_Roth:
Yeah, and that's a great thing because even though that we are getting new lifecycle hooks and that signals is going to change the way that we code Angular applications, the previous way of coding still works. It's not going anywhere soon. So if you are, for example, a company that is currently
Charles Max_Wood:
I
Eduardo_Roth:
moving
Charles Max_Wood:
mean, I don't
Eduardo_Roth:
from
Charles Max_Wood:
see what
Eduardo_Roth:
AngularJS
Charles Max_Wood:
difference it makes
Eduardo_Roth:
to
Charles Max_Wood:
how
Eduardo_Roth:
Angular,
Charles Max_Wood:
many devices
Eduardo_Roth:
they don't have
Charles Max_Wood:
I
Eduardo_Roth:
to
Charles Max_Wood:
have
Eduardo_Roth:
worry
Charles Max_Wood:
connected
Eduardo_Roth:
that,
Charles Max_Wood:
to the
Eduardo_Roth:
hey,
Charles Max_Wood:
Wi-Fi.
Eduardo_Roth:
I'm getting
Charles Max_Wood:
Because
Eduardo_Roth:
behind
Charles Max_Wood:
that,
Eduardo_Roth:
and this is
Charles Max_Wood:
it
Eduardo_Roth:
going
Charles Max_Wood:
really
Eduardo_Roth:
to...
Charles Max_Wood:
wasn't a problem
Eduardo_Roth:
to be
Charles Max_Wood:
until I
Eduardo_Roth:
deprecated
Charles Max_Wood:
replaced this one.
Eduardo_Roth:
too, and then I have to worry about migrating to signals, and then I will have to create to do another migration project. So it's safe to say that if you migrate right now, it's still going to work. Your application is not going to be like... It's still going to be good enough to go.
Lucas_Paganini:
Nice. One big problem that we haven't touched about in terms of migration are
Charles Max_Wood:
No,
Lucas_Paganini:
the other
Charles Max_Wood:
I didn't.
Lucas_Paganini:
libraries,
Charles Max_Wood:
How do I
Lucas_Paganini:
right?
Charles Max_Wood:
check that?
Lucas_Paganini:
And I'm not even talking about the problem of migrating from AngularJS to Angular. I mean, if you upgrade from Angular 8 to Angular 9, it can... Everything that is Angular-related and that you wrote is going to keep working, because that was when they introduced the... IV compiler, but if the libraries that you depend on still don't have support for that, then you might have a problem.
Eduardo_Roth:
Yeah.
Lucas_Paganini:
So, yeah.
Eduardo_Roth:
Yeah, if you go... Well, I think it was on version 11 or 12. I don't remember the exact version, but they removed the Vue engine completely. So if your library doesn't support
Charles Max_Wood:
Okay,
Eduardo_Roth:
Ivy,
Charles Max_Wood:
here's the
Eduardo_Roth:
then
Charles Max_Wood:
deal.
Eduardo_Roth:
you are
Charles Max_Wood:
I
Eduardo_Roth:
left in
Charles Max_Wood:
mean,
Eduardo_Roth:
the... Well, you won't be able
Charles Max_Wood:
I
Eduardo_Roth:
to
Charles Max_Wood:
went,
Eduardo_Roth:
use that,
Charles Max_Wood:
I looked
Eduardo_Roth:
or
Charles Max_Wood:
at
Eduardo_Roth:
you
Charles Max_Wood:
your
Eduardo_Roth:
won't
Charles Max_Wood:
list
Eduardo_Roth:
be able
Charles Max_Wood:
of compatible
Eduardo_Roth:
to update
Charles Max_Wood:
modems. That's
Eduardo_Roth:
to
Charles Max_Wood:
why I bought
Eduardo_Roth:
Angular
Charles Max_Wood:
this
Eduardo_Roth:
12.
Charles Max_Wood:
one.
Eduardo_Roth:
And that's something that Chow Tran shared on Twitter. He is the developer behind Angular 3. He mentioned or he posted a poll that if a library right now in Angular 16 uses
Charles Max_Wood:
I mean, I
Eduardo_Roth:
signals,
Charles Max_Wood:
guess I could put the old modem back,
Eduardo_Roth:
were
Charles Max_Wood:
but...
Eduardo_Roth:
you
Charles Max_Wood:
Yeah, it would, it would like
Eduardo_Roth:
expecting
Charles Max_Wood:
slow down this
Eduardo_Roth:
to
Charles Max_Wood:
stuff
Eduardo_Roth:
have
Charles Max_Wood:
on the other
Eduardo_Roth:
support
Charles Max_Wood:
modem. I figured
Eduardo_Roth:
to
Charles Max_Wood:
it was
Eduardo_Roth:
previous
Charles Max_Wood:
just because it
Eduardo_Roth:
version
Charles Max_Wood:
was old.
Eduardo_Roth:
of Angular which doesn't have signals? In my case, I think, well, I voted to not have support for previous versions. But. I know that many companies don't have the developer force to keep on latest versions. And also, if your company policy is to be one behind, then it might create some problems or troubles because you are going to have the latest version of the library that only supports signals, but I don't support signals yet.
Charles Max_Wood:
Okay.
Eduardo_Roth:
And the previous version is not getting any support. And if I have It's not going to get a bug fix, so it might create some problems with third-party libraries. But as long as Angular is related, they are trying to keep everything simple, don't break anything approach. But as you mentioned, third-party libraries are a different word. It's going to be a thing in its own.
Lucas_Paganini:
Yeah, that was a great point. Like Angular can do as much as they can help a lot with keeping old versions still being supported and doing patch releases. But if the third party library that you depend on doesn't do that, then you're just left hanging, right? So, that's it for this video. I hope you enjoyed it. If you did, please like, share, and subscribe. And if you haven't already,
Eduardo_Roth:
Yeah, but I think that in the end, this is something good because it kind of forces developers, third-party, well, company developers, third-party libraries developers, and the same Angular framework developers to be up to date.
Charles Max_Wood:
Okay.
Eduardo_Roth:
For example, I remember that it was until Angular 11, I think, that Internet Explorer was fully removed.
Charles Max_Wood:
Alright, so
Eduardo_Roth:
And if you think that up to that point,
Charles Max_Wood:
what
Eduardo_Roth:
it was
Charles Max_Wood:
modem
Eduardo_Roth:
like
Charles Max_Wood:
do
Eduardo_Roth:
five
Charles Max_Wood:
I need for
Eduardo_Roth:
years
Charles Max_Wood:
the speed
Eduardo_Roth:
with
Charles Max_Wood:
that I have?
Eduardo_Roth:
no support for Internet
Charles Max_Wood:
Or
Eduardo_Roth:
Explorer until
Charles Max_Wood:
can
Eduardo_Roth:
we
Charles Max_Wood:
I,
Eduardo_Roth:
could remove that from Angular.
Charles Max_Wood:
what's the difference
Eduardo_Roth:
So
Charles Max_Wood:
in the plan
Eduardo_Roth:
by having
Charles Max_Wood:
that this
Eduardo_Roth:
these
Charles Max_Wood:
modem will
Eduardo_Roth:
quick
Charles Max_Wood:
work with?
Eduardo_Roth:
or faster deprecation paths, I think it's something good and we don't have to worry about having these old legacy systems still working.
Lucas_Paganini:
Definitely. Well, Eduardo, I know that we've completely diverged from the initial subject. That's the thing about this podcast, we're always diverging. But I think that was really, really great. I think we should start wrapping up because otherwise it's just gonna get like a super long episode. But if... If I may, I'd like to close with one last question to try to help the developers that find themselves in that situation of... It's not that they can't do the update, but they have to convince the management side that it is worth doing this update. And it's a really difficult situation to be in because I can understand both parties. I can understand how management doesn't want the risk and quite frankly, the money investment of migrating their systems. But I also think that's a
Charles Max_Wood:
Okay,
Lucas_Paganini:
bad decision
Charles Max_Wood:
but you're not
Lucas_Paganini:
because
Charles Max_Wood:
telling me
Lucas_Paganini:
it's
Charles Max_Wood:
anything.
Lucas_Paganini:
a ticking
Charles Max_Wood:
Like
Lucas_Paganini:
bomb.
Charles Max_Wood:
what what
Lucas_Paganini:
The longer
Charles Max_Wood:
what's the
Lucas_Paganini:
time
Charles Max_Wood:
difference?
Lucas_Paganini:
passes,
Charles Max_Wood:
Is this one just not fast
Lucas_Paganini:
the harder
Charles Max_Wood:
enough?
Lucas_Paganini:
it gets for you
Charles Max_Wood:
Is
Lucas_Paganini:
to
Charles Max_Wood:
it
Lucas_Paganini:
recruit
Charles Max_Wood:
too fast?
Lucas_Paganini:
developers
Charles Max_Wood:
Is it?
Lucas_Paganini:
because nobody wants to work on old technologies. And the ones that do accept that... they understand that they are losing their career progression a bit because after you stay, like you join a company that is working on legacy technologies, when you leave this company like two, three, four years afterwards, then during this period, you're not going to have a resume that other companies are going to be interested in because they are probably not using those legacy technologies. So this is... bad for management because it gets harder for them to attract and retain talent. And it's also bad for talent because they need to work on something that it isn't that beautiful shiny thing that you are excited to work on. And they hear about the updates and they're like, oh man, I still haven't gotten the updates from like Angular 2. They're talking about Angular 16. That's
Eduardo_Roth:
Hehehe
Lucas_Paganini:
so sad. But I wonder what could be an advice for those developers, those tech leaders to bring that conversation to management. And yeah, like how would you go about this if you were in the developer situation? And also do you think that the individual developer should be the one that brings that to management or maybe the tech leader or the CTO itself?
Eduardo_Roth:
I think that this is something that any developer in the team can raise their hand. This is something that this is inevitable. So sooner or later, you will have to do that migration or just deprecate your whole application. But the thing is that I think that the first thing that you can approach management or just the stake for the application is that the security risk of having... That's one major issue that if you are still an AngularJS, for the company, this is a security issue or concern. Even it can be a huge problem because you are no longer getting... There are some end-of-life support services, XLTS, which is a side company of HeroDev's, provides that. And they currently... release updates or security patches. But if you don't have that, and you still rely on latest AngularJS version, you're a target for any security breach from anybody. So that's one main point to bring to the table. Also, the other thing is that as more time passes and as more developers shift to latest technologies, Angular, React, Vue, Solid, even Quik, you won't have enough people that, for one, know how to work with AngularJS, and two, that they want to still work with AngularJS. Because right now, the people that we still work with AngularJS are people that were there when AngularJS was released. But for any developer that maybe from three years past, they are no longer using AngularJS in anything. They are using Angular React. So it's going to be harder to find new people that might support your applications in the long term. Also, as you mentioned, this is not something... If you have two open positions, and one is for Angular, and the other is for AngularJS, the developer is going to jump to the Angular one. So that's something that is to think about. Also, as I mentioned, this is inevitable. sooner or later, you will need to migrate. You can have the AngularJS application running forever. This is something that you will have to do. And the more time it passes, the more complicated and harder it's going to be for you as a company. You will require more people or the effort is going to be bigger. Well, if you do it sooner, it's going to be... Even though it's going to be a huge effort, it's going to be better to do it before it's too late.
Lucas_Paganini:
I like that. Just one expansion, because you touched on a really nice point, which was security. I think that it's kind of hard for developers to bring this topic of security because there is a real misconception that the big security risks are in the backend, not in the frontend. And I don't disagree. I... I think this is true, like if you have a security vulnerability in the back end, that is generally much more, a much bigger problem than front end security issues, but still this is a problem. So do you have specific examples that maybe the developers listening to this can bring to management in terms of like, these are the security risks that... you are accepting to have because you are still on AngularJS.
Eduardo_Roth:
I don't have any example or a specific example right now, but for AngularJS or actually any frontend framework that you are using, this is the face to the users or to your clients. So you might have like a thousand clients, 10,000 clients, 100,000 clients that use your application. So if they target your frontend application and they inject some code, they can... The reach is for all these people. Imagine that someone injects, breaks your AngularJS applications, injects some component or HTML and JavaScript there. So all these 10 or 100,000 soft users that you have will have that security breach. And it's using their browser. And now you have the web containers. And then you can spin up anything from the browser. That's something that is. StackBlitz uses so they can have Node.js running on the browser. So if you think about it, if you have a security breach or a security issue on your backend targets you and all the information that you have, but it's at the end of the day, it's your company that it's the target. But for front-end applications, the security breach, the target is the users. So it impacts if you have a lot of users. it's going to impact them. And nobody wants to be a user of a company that has been targeted by hackers. So I think that's it's not a specific example that you might have preferred. But I think that if you realize that all your users are target by the security breach, then you realize that it's a huge problem company-wise.
Lucas_Paganini:
Yeah, no, I love that analogy is security vulnerabilities to the backend affect your system, security vulnerabilities in the front end affect your users. And at the end of the day, they need to trust that your system is secure. So I like that.
Eduardo_Roth:
Yeah.
Lucas_Paganini:
Nice.
Eduardo_Roth:
Thanks.
Lucas_Paganini:
Okay, awesome. Eduardo, that was a great conversation. I really like how in-depth we were able to go into a lot of... things that are related to the new versions of Angular, not just signals, we were talking about migrations. And I think that was a really useful subject to bring to the audience. And yeah, let's go to picks and promotions. So starting with promotions, is there anything that you were working on or that you did, a product that you have, anything that you want to promote? Like this is the moment where you can... Literally use this space as if you were a sponsor and just say whatever you are promoting
Eduardo_Roth:
Well, right now, in my personal case, there's nothing. I've been trying to build a couple of side projects. You know, as developers, we tend to have side, well, extra domains for side projects that we imagine or that we are working on. Right now, I don't have any. But for HeroDev, the company that I work on, there's open spots for Angular developers. So if you want, you go to herodevs.com and you can go to the job board. and apply there, it's a great place to work. Not only for the projects that we work on, but the people that it's there, it's an awesome place to work. So that was my moment. Thanks,
Lucas_Paganini:
Awesome.
Eduardo_Roth:
I appreciate that, Lucas.
Lucas_Paganini:
No problem. And we're gonna put the link to it in the show notes. So if you want to check out the open rows that they have on Hero Dabs, then you can just go to the show notes and see about that. On my
Eduardo_Roth:
Oh,
Lucas_Paganini:
side, oh, sorry, go ahead.
Eduardo_Roth:
sorry, I forgot. I'm also the co-organizer of the Angular community meetup on, well, en español, in Spanish. So we have this meetup each second Tuesday of every month. So I will also share the link to you. So the next one is May 9. So if you want to join, it's completely in Spanish. And what we are trying to do is to get more people or get more content in the Spanish for developers that prefer this content in their mother language and not exactly in English. And this is the official or the ng-conf sponsor meetup. So that's also a huge plus. And also there's... I am also an Ionic developer expert, and we are going to have on October... Right now, I don't have the exact dates. I think it's 17th, but I will share that with you. So there's going to be the Ionic Conf for this year. It's going to be live. And I forgot the name. Well, it's going to be a physical event. So it's going to be on Dallas, Texas. So it's going to be huge, too. Sorry
Lucas_Paganini:
Okay.
Eduardo_Roth:
if that was like a lot of mix up information, but I remember all of that right now.
Lucas_Paganini:
No problem, no problem. That was funny. He's like, oh, I don't have much. Well, actually I have a lot, but that's
Eduardo_Roth:
Yeah.
Lucas_Paganini:
great. And it's really nice to know all those other things that you're involved in. And that tells me how much more knowledge we can get from you. So I would be honored if you want to come back whenever. I'm sure that there's a lot to talk about in the Ionic side of things. I'm sure that there are a lot of new things to... to talk about too. So yeah,
Eduardo_Roth:
I
Lucas_Paganini:
man.
Eduardo_Roth:
saw that you have as guest Simon Grimm. He's
Lucas_Paganini:
Yes.
Eduardo_Roth:
a huge developer in the Ionic community. So I don't think that I can match that, but I can do my best. So we can... I happily join another day and have a topic of Ionic if you want.
Lucas_Paganini:
Awesome, okay. On my side of things, I'm only gonna promote my company. So, Envoy, we do design and development remotely, and we specialize in Angular development. So, if your company needs help with anything, or you want to help with migration, you're on AngularJS and you want to migrate, or you're on a legacy version of Angular and you want to upgrade, or you just want to develop a system from scratch, like... All of those things, it's well under our domain. So these are all things that we do. If you're interested in that, you can check out unvoid.com for companies that want to completely outsource their project. We do that. We have plans that are fully managed. So we can do everything for your project from design, project management, development, all of that. But if you... want to have like more control and you want to be part of the process and just manage the individuals yourself that's also super okay. We also do staff augmentation so if you're interested in any of that and you need help with your project then be sure to check out unvoid.com. Oh also if you don't have this need but you know somebody that does you can refer a client and earn up to ten which to me, which I'm in Brazil, that's a shit ton of money. So
Eduardo_Roth:
I'm going to go ahead and close the video.
Lucas_Paganini:
if you find yourself in that situation and you have somebody to recommend, then I'm going to put the link in the show notes. You can go to unvoid.com slash refer clients. There's a hyphen. So refer hyphen clients. And then you can just submit the form
Eduardo_Roth:
Yeah.
Lucas_Paganini:
and we'll talk to you. and put you in our referral program. So this way you can earn up to 10,000 US dollars. Jesus, that's so much money. Well, yeah, these are my promotions. And in terms of picks, interesting things that maybe are not related to Angular or technology at all that I want to bring, I'm just going to bring the Apple TV series about WeWork. It's called We Crashed. It tells the story about how we work started out and they grew as a company up until the point where everything went to shit so I'm really Enjoying enjoying the storytelling it's like it's captivating. You can't stop watching and I've I Haven't like finished the entire mini series just because like I only watch when I'm at lunch, otherwise I'm just going to waste an entire day and not have anything to watch afterwards. But it's really good. So it's called We Crashed. It's available on Apple TV. So if you're into that, highly recommend. How about you, Eduardo? Do you have any particular picks?
Eduardo_Roth:
No, well, I've been watching this show with my wife. I don't really remember the name in English. It's kind of like this, mom, why are we follow or something like that is on Netflix. And this is the tale of a mother and her daughter. And they are like kind of escaping. But there's something odd with the mom. So if I tell... anything more, it's going to spoil the show for everybody. But it's a good show. It's kind of weird at the start and you start to wonder what's happening and why. But as you follow the episodes, it's like getting more, you're getting more context of what is happening. So it's really, well, I find it good enough to watch.
Lucas_Paganini:
Awesome. Okay. I like that. Thank you, Eduardo. Thank you for your time. Like honestly, this was such a valuable episode and
Eduardo_Roth:
Thanks, Rukia.
Lucas_Paganini:
I hope it was valuable for everyone else that was listening to this. And yeah, I'll see you all in the next episode. Thank you.
Eduardo_Roth:
Thanks Lucas for having me.