Eduardo Roth is a Hero Software Engineer and Ionic Developer Expert. He joins the show to talk about  Angular Signals in Practice. He talks about his experience in building an app with Angular Signals and the challenges he encountered. He also talks about bridging Signals with RxJS.  

 

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.

 

Hey!

 

and Eduardo Roth, our special guest for today.

 

Hello, good morning and thanks for having me here. It's a pleasure for me.

 

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.

 

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.

 

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?

 

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.

 

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?

 

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.

 

Well, I can

 

down.

 

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.

 

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

 

anything.

 

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.

 

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.

 

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?

 

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.

 

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

 

Mm-hmm.

 

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?

 

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.

 

Mm-hmm.

 

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.

 

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.

 

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

 

Mm-hmm.

 

one second, sorry.

 

Ha ha ha ha

 

No,

 

ha

 

It's

 

it's

 

my daughter.

 

all good. I've been there.

 

So cute

 

Yeah, so I'm so sorry.

 

Never own

 

Working at home and having three daughters can

 

Oh,

 

be quite a mess.

 

I totally understand, so, yeah.

 

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.

 

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?

 

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.

 

Oh, nice,

 

As long as you are

 

nice.

 

using...

 

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

 

Just

 

declare

 

out.

 

a signal somewhere?

 

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.

 

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?

 

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.

 

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?

 

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.

 

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

 

Mm-hmm.

 

when we

 

Yes.

 

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,

 

No.

 

but the place where you're actually using those subscriptions was elsewhere. Then the code gets a little bit harder, not impossible

 

No.

 

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.

 

Yes.

 

the moment where the component is destroyed. And this injectable is

 

internet.

 

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,

 

Yes.

 

which at the end of the day, it does the same thing, but it's a more,

 

That's simpler.

 

yeah, simpler. And the responsibility is more isolated like. If you just want to listen to onDestroy,

 

Internet.

 

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.

 

Mm-hmm.

 

So yeah, I think that's actually a really interesting thing. And even to developers that are not going to use

 

No.

 

signals as soon as it gets released for whatever reason, This is actually super useful to clean up your observable subscriptions You can fully

 

No.

 

get rid of ng-on-destroy in most components because most components in ng-on-destroy the only thing that they do honestly

 

It's

 

is just

 

unsubscribe.

 

unsubscribe. Yeah

 

Yeah, you can create an operator function and then

 

No!

 

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.

 

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

 

One.

 

not getting all the performance that you

 

Piece

 

could

 

of trash!

 

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.

 

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.

 

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.

 

Mm-hmm.

 

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?

 

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

 

I don't have wifi

 

easier

 

on that

 

for

 

rubber.

 

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.

 

Interesting. Okay. There is another entire topic that we haven't gotten into, but I'm really curious about, which is migrations. So

 

Yes.

 

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?

 

That's something that some developers have asked me. I know there's

 

No.

 

an schematic for migrating NG modules application to a standalone. For this type of change

 

My internet

 

for zone

 

connection keeps

 

and

 

dropping.

 

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.

 

No!

 

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.

 

accessing

 

I guess

 

the

 

that

 

internet.

 

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

 

No!

 

be a combination of things, but at the end of the day, you will have to manually update a lot of code.

 

Let me talk to somebody.

 

I guess it can give you this recommendation. If it finds some observables, it can say, you can create a

 

Let

 

signal

 

me talk to

 

and

 

an

 

just

 

agent.

 

call

 

Let me talk to

 

toSignal

 

an agent.

 

method,

 

Let

 

and that's

 

me

 

it.

 

talk to an agent.

 

But to actually

 

Let

 

manually

 

me talk to an agent.

 

update your code, I find it difficult to do. So

 

No!

 

I think that this is a huge change

 

No,

 

that will...

 

let me talk to an agent.

 

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.

 

Gotcha, gotcha. Yeah, I imagine that that would be

 

Charles Wood.

 

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

 

I'm alright,

 

migrate

 

just

 

it.

 

frustrated

 

I mean,

 

with the internet connection.

 

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

 

Yeah. Ha

 

yeah. I don't see that

 

ha.

 

happening so soon, which is a shame, because it would be so cool if

 

Yeah.

 

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

 

Yep.

 

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,

 

So I got

 

I don't

 

a

 

know

 

new

 

you,

 

modem

 

but I see that you have this need,

 

and I put

 

and this

 

it

 

is

 

in,

 

a service that we can

 

I can't

 

get

 

remember

 

started

 

if it was

 

working

 

yesterday

 

together,

 

or

 

and

 

the

 

then

 

day before,

 

the partnership

 

but

 

goes from there. But

 

just periodically

 

it's interesting

 

the internet

 

because

 

just drops out.

 

it gets,

 

And then

 

it's

 

it'll

 

getting

 

come back

 

easier

 

after a couple minutes, but. So, I'm gonna

 

to do

 

go ahead

 

upgrades.

 

and turn

 

Like,

 

it

 

even

 

off.

 

though we're talking about something so big as signals, everything else that existed before is still supported. So upgrading to Angular

 

Yeah,

 

16

 

well it's

 

doesn't

 

intermittent outages

 

break

 

more than intermittent

 

your zone-based

 

connection.

 

components,

 

It's connected

 

doesn't

 

most

 

break

 

of the

 

what

 

time,

 

you had

 

but

 

before.

 

yeah,

 

It's like

 

it'll just drop

 

you're still

 

out.

 

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

 

Thanks for watching. Bye.

 

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.

 

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...

 

Um,

 

It's really easy

 

it was getting

 

and

 

errors

 

everything

 

periodically.

 

works. Even if you

 

It was,

 

just

 

it was,

 

change the Angular version, everything

 

it

 

works

 

was kind of doing the

 

and

 

same thing. It just wasn't

 

you

 

doing

 

can have

 

it

 

your

 

as often.

 

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.

 

Yes,

 

So.

 

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.

 

I

 

There

 

haven't

 

are a

 

tried

 

lot

 

that,

 

of developers

 

but

 

in this situation,

 

it does

 

which

 

it

 

is

 

across the

 

there

 

entire

 

are a lot

 

network.

 

of developers

 

It's not the WiFi.

 

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?

 

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.

 

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.

 

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

 

Um

 

the CLI migration script and you got the Angular

 

I mean

 

application

 

during the day

 

running.

 

I'm the only

 

No,

 

one here so it's just

 

sadly, it's not that easy.

 

my

 

So

 

laptop

 

you

 

and

 

have

 

my phone

 

to do a

 

and

 

lot

 

maybe

 

of

 

a

 

manual

 

tablet.

 

work.

 

Gotcha, gotcha. Yeah, but that actually sounds like a fair point.

 

But yeah,

 

You can just

 

and then

 

upgrade

 

I think

 

to the

 

we have

 

latest

 

like

 

version

 

thermostats

 

of AngularJS.

 

that connect and

 

You try

 

we

 

to

 

have a bunch

 

migrate

 

of Amazon Firesticks

 

everything to

 

and

 

Angular

 

Amazon

 

components.

 

Alexa's that

 

And then after this

 

all connect

 

step

 

as

 

is

 

well.

 

done,

 

But

 

then you are

 

like

 

more

 

I said, I'm

 

prepared

 

the only one here right

 

for

 

now.

 

the

 

I'm not using

 

actual

 

really

 

migration

 

any of those. So.

 

to the latest version of Angular.

 

Yeah, exactly.

 

But... Now we're actually getting to a pivotal moment on that because even the lifecycle methods are changing with, like

 

Yeah,

 

signal-based

 

Yeah.

 

I do have an internet

 

components,

 

connection right

 

they

 

now.

 

have different lifecycle

 

Like

 

hooks.

 

it goes down for

 

So

 

like five

 

even

 

minutes

 

that

 

and then it

 

is

 

comes

 

like,

 

back up. The problem

 

it's kind of

 

is,

 

like

 

is

 

a

 

that

 

window

 

I run a podcast network

 

that

 

and I'm

 

is

 

recording a podcast over

 

rapidly

 

the network, I can't

 

closing.

 

have it go down while I'm recording. So,

 

Or,

 

I'm recording

 

well,

 

a podcast

 

they

 

over

 

could

 

the

 

just

 

network. I'm recording

 

still migrate

 

a podcast over

 

to zone-based

 

the network.

 

components, which would still be better than AngularJS.

 

dan kami yang jual aja ya

 

Yeah, yeah. Interesting.

 

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

 

I

 

moving

 

mean, I don't

 

from

 

see what

 

AngularJS

 

difference it makes

 

to

 

how

 

Angular,

 

many devices

 

they don't have

 

I

 

to

 

have

 

worry

 

connected

 

that,

 

to the

 

hey,

 

Wi-Fi.

 

I'm getting

 

Because

 

behind

 

that,

 

and this is

 

it

 

going

 

really

 

to...

 

wasn't a problem

 

to be

 

until I

 

deprecated

 

replaced this one.

 

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.

 

Nice. One big problem that we haven't touched about in terms of migration are

 

No,

 

the other

 

I didn't.

 

libraries,

 

How do I

 

right?

 

check that?

 

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.

 

Yeah.

 

So, yeah.

 

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

 

Okay,

 

Ivy,

 

here's the

 

then

 

deal.

 

you are

 

I

 

left in

 

mean,

 

the... Well, you won't be able

 

I

 

to

 

went,

 

use that,

 

I looked

 

or

 

at

 

you

 

your

 

won't

 

list

 

be able

 

of compatible

 

to update

 

modems. That's

 

to

 

why I bought

 

Angular

 

this

 

12.

 

one.

 

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

 

I mean, I

 

signals,

 

guess I could put the old modem back,

 

were

 

but...

 

you

 

Yeah, it would, it would like

 

expecting

 

slow down this

 

to

 

stuff

 

have

 

on the other

 

support

 

modem. I figured

 

to

 

it was

 

previous

 

just because it

 

version

 

was old.

 

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.

 

Okay.

 

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.

 

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,

 

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.

 

Okay.

 

For example, I remember that it was until Angular 11, I think, that Internet Explorer was fully removed.

 

Alright, so

 

And if you think that up to that point,

 

what

 

it was

 

modem

 

like

 

do

 

five

 

I need for

 

years

 

the speed

 

with

 

that I have?

 

no support for Internet

 

Or

 

Explorer until

 

can

 

we

 

I,

 

could remove that from Angular.

 

what's the difference

 

So

 

in the plan

 

by having

 

that this

 

these

 

modem will

 

quick

 

work with?

 

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.

 

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

 

Okay,

 

bad decision

 

but you're not

 

because

 

telling me

 

it's

 

anything.

 

a ticking

 

Like

 

bomb.

 

what what

 

The longer

 

what's the

 

time

 

difference?

 

passes,

 

Is this one just not fast

 

the harder

 

enough?

 

it gets for you

 

Is

 

to

 

it

 

recruit

 

too fast?

 

developers

 

Is it?

 

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

 

Hehehe

 

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?

 

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.

 

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.

 

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.

 

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.

 

Yeah.

 

Nice.

 

Thanks.

 

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

 

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,

 

Awesome.

 

I appreciate that, Lucas.

 

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

 

Oh,

 

side, oh, sorry, go ahead.

 

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

 

Okay.

 

if that was like a lot of mix up information, but I remember all of that right now.

 

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

 

Yeah.

 

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,

 

I

 

man.

 

saw that you have as guest Simon Grimm. He's

 

Yes.

 

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.

 

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

 

I'm going to go ahead and close the video.

 

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

 

Yeah.

 

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?

 

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.

 

Awesome. Okay. I like that. Thank you, Eduardo. Thank you for your time. Like honestly, this was such a valuable episode and

 

Thanks, Rukia.

 

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.

 

Thanks Lucas for having me.