Upgrading to Angular 17 with Jorge Cano
Translated transcription from Spanish of episode #13 of the Angularidades podcast
Listen to the entire conversation in Spanish with Jorge Cano on Spotify, YouTube, and other podcast platforms.
Alejandro: Jorge Cano, let me introduce you to those who have not yet tuned into your podcast and don’t know you. You’re from Buenos Aires, Argentina. You’re a software architect with a focus on JavaScript and web performance and a teacher of various courses related to these two areas. You’re also a speaker, and a writer of technical articles.
You’re one of the panelists on the excellent podcast Looks Good to Me — or LGTM — which airs every Tuesday, and where Andrés “El Pana” Villanueva, who was here a couple of episodes ago, is also a host.
Largely due to all this work you do with development communities, you hold two Google Developer Expert (GDE) recognitions from Google: one in Angular and the other in web technologies in general. Besides this, you’re recognized by Nx as an Nx Champion.
It’s phenomenal to be recording this episode together, and thank you for accepting the invitation and being here with me.
Jorge: Please, it’s my pleasure. I want to mention that ‘El Pana,’ as they call Andrés, is thanks to me… I was the first to call him that :) Yes, I’m the creator of his nickname. Even though in Venezuela ‘Pana’ is quite common, he used it so much here that we rebranded it.
Alejandro: I can’t believe you :) Well, there are so many things that I’ve learned from those first 5 minutes of each episode of LGTM... as I was telling you a few minutes ago, I can’t miss an episode. Amost every Tuesday I’m there tuning the podcast. If it’s not on Tuesday, then it’s at the beginning of Wednesday because I enjoy these laughs — literally more than couple of laughs — when I start listening to your podcast. It’s super refreshing.
Jorge: That’s great! Yes, that’s the idea of the podcast: a bit of current events paired with some experience and a few laughs.
Alejandro: The etymology of the title of this podcast, Angularidades, which launched its first episode a couple of weeks after LGTM came out, is quite simple. ‘Angularidades’ — in Spanish — comes from ‘Angular’ and ‘particularities.’ Where did the idea for the title of your podcast really come from? Because ‘looks good to me’…
Jorge: Uff, actually, we wanted the podcast’s title to reflect the idea we had in mind, because it might seem like one day we just said, "let’s record," and that’s it, but the reality is that we spent a month and a half, almost two, finalizing the idea. I discussed this project with Nico and ‘El Pana,’ and they liked it. This is how we started to shape the podcast to suit all three of us. Added to the fact that we’ve known each other for so many years — I don’t know if it’s noticeable in the episodes, but there’s such knowledge and trust that makes it easy — we started to play with title candidates from the technology and development theme, and we ended up with the famous ‘Look Good To Me,’ which used to be used a lot on GitHub.
It was terrible that the only thing people use to write was ‘Look Good To Me,’ when approving your PR, so this ended being a long-time meme. And from there, our podcast title came out.
Alejandro: Now, with this new project added to your weekly life, if you had to choose just one option between giving conferences, releasing podcast episodes, or writing technical articles, which would you choose if your time or circumstances changed?
Jorge: Let’s see… I could say it’s difficult, but honestly, it’s not. I'll go with conferences hundred percent. Before the pandemic, I used to doaround 10, 15 conferences a year and I wouldn’t exchange that for anything. The contact with other individuals who do the same, seeing your friends or meeting new people.
Listening to the live talks, being able to discuss with the other speakers and all that makes it 10,000 times better than everything else, although I like it all, right? If I have to choose one, I'll go with that.
Alejandro: Recently, in this decade of 2020s, which is the most memorable conference you’ve had to this date? We’ve only gone through almost three years, right? But do you have a favorite in mind?
Jorge Cano: In terms of quantity, when I participated in ngconf 2020, at the time of my talk there were about 15,000 people because it was an online event. Nevertheless, I must say that perhaps the one I liked the most in terms of my performance, which was, let’s say, good overall in the talk, for how people felt it despite being online and all that, was NG Honduras at the beginning of 2021. The talk title was ‘Nx para sobrevivientes’ — in English, ‘Nx for Survivors’— and it was like a mix between an 8-bit game and this survival kit things, mixing a bit of Nx into Angular and so on. This talk was translated into English live, and the person translating had quite a tough time, so if you watch it in English it’s quite funny.
Alejandro: What do you have in mind for the upcoming weeks or months? Something that’s getting you excited about preparing all the presentation and content?
Jorge: I’m kind of returning to YouTube. I mean, I never really left YouTube — there’s always a video or something on my channel. But recently I went to San Jose, to Google HQ and I recorded the answer to some questions I asked several GDEs.
I recently had a talk for a Google program aimed at startups — it was in English because it was for people from Jamaica and the United States — about how Google’s AI products can help you, even if you’re not a developer, to create language models, chatbots, and all that. What I’ve come up with — this is a complete spoiler — is to combine Mario Maker 2 with Google’s Maker Suite to create a concept for a talk. I’ll upload it to YouTube, showing how I create it, and then the talk will be ready for some DevFest or something similar.
And I’m also recording an Angular course from scratch for my YouTube channel, which, if all goes well, if everything goes according to plan — fingers crossed — will be released on November 6th.
Alejandro: November 6th is just in time for what’s coming next week :)
Jorge: Yes, November 6th is the same day Angular 17 will be out. The event is at 10:00 am Pacific Time, if I’m not mistaken. The course will be released, if all goes well — again, this could fail — at 11:00 am Pacific Time.
Alejandro: On what platform? YouTube? How many episodes will there be? Do you have a format planned for its trajectory?
Jorge: YouTube, yes, yes, yes, no other platforms. It’s a ‘basic’ course, and I say ‘basic’ with quotes because it covers some advanced topics. A bit of TypeScript, but really just a bit because the idea is to release a dedicated TypeScript course before the end of the year. It will also have the basics of Angular, such as what it’s this framework for, how to use it, what the CLI is, how it works, what alternatives there are. It will cover how to work with and without modules, what architectures there are, how to program in Angular, what are the good and bad cases, how to make a component, how to make a route, so, really from scratch.
If you know Angular, this course might be good for a refresher because we’re going to remove all the RxJS part that’s replaced by Signals. From RxJS itself we’re going to see very little because there’s already a very comprehensive five-video RxJS course from a year or two ago on the channel.
I really wanted to leverage some of the content that’s already been created and not to duplicate content. This course will be based on Angular 17, which comes with many changes, to be honest. These changes are public — I’m not revealing anything strange. Signals, the new testing features, and it will touch on a little bit of everything. It’s great if you’ve never done Angular, because it gives you all the updated basics.
Alejandro: With all the updates coming in this new version of the platform, you’re probably discovering during the course preparation a bunch of spectacular features from a different perspective. What motivates you the most to not only launch this learning course but to share your knowledge in the software development community?
Jorge: Look, the truth is… I’ve been developing for many years, right? And when I say many, I always say more than fifteen years. And there was something that used to happen before, which doesn’t happen so much now: here in Argentina, we say everyone looks after their own ‘ranchito’, you know? The ‘ranch’ is your parcel, your portion of the company, code, whatever. And before, people didn’t share their knowledge that much, or if you had to touch something that belonged to someone else, they would get angry, or they wouldn’t help you, or explain why they had done something in a certain way. That was very common. And when I got to know the GDGs, I discover that there were people who liked to share, who enjoyed doing these type of things.
I had already been teaching Web Development at the National Technological University here in Buenos Aires, and when I saw that there were people who liked to share their knowledge during the time I started to work with Angular, in version 0.9, where components didn’t even exist yet…
Alejandro: Do you literally started from Angular zero?
Jorge: AngularJS 0.9, yes, on a pretty complex project because it was a banking project and not only because of its complexity, but also, of course, we had to go through the bank’s security process, and for that, we had to review the code. At the time AngularJS was just like 1500 lines, just so you have an idea. So, we had to review everything, to check everything.
And I always remember one day we were very troubled with something that we didn’t understand why it wasn’t working and I sent an email directly to Miško Hevery, the creator, and got a response in three days. I found that incredible, so I started to share things about AngularJS.
Alejandro: Possibly, if you send an email today to Misko about Qwik, he or someone from his team might answer very promptly.
Jorge: Look, I’ve known Misko for many years. Yes, he’s a super, super, super nice guy, but of course, at that time when they released AngularJS, they were — I mean, AngularJS comes from a delay of a project for Google Drive — they were using a language that was "ugly" and Misko said: "give me three weeks" — it eventually took him four weeks — "and I’ll create a new framework for you to handle this." It’s a crazy story the internal story of AngularJS, and yes, it was in the middle of this situation when he answered my email.
This experience continued when I attended a GDG event where the discussion about AngularJS was quite basic. They presented it as if to say, ‘Here’s AngularJS for front-end web development.’ Afterwards, I approached the speakers and mentioned that I was deeply involved with this framework in my professional work. They were intrigued and extended an invitation for me to speak at the event.
During another talk, a moment stood out that encapsulated the beauty of sharing knowledge. A participant asked a technical question that the original speaker couldn’t answer because they hadn’t encountered that specific issue. I stepped in and provided the answer, and the relief and gratitude on the attendee’s face was palpable. It was an immensely satisfying moment, knowing I had made a difference to someone who was struggling with a freelancing project. This was when I realized how rewarding it could be to share my own experiences and expertise. This feeling of community and support is what drives me; I want to continue contributing and sharing with others in the field.
Alejandro: Exactly, you’re having an impact and this is not like a scientific experiment that takes months to find out if it worked well or not. We usually have an instant gratification, similar to what happens with programming applications.
Jorge: Today, you have many podcasts, lots of people streaming on Twitch or elsewhere, so there’s much more content available now. About 12 or 13 years ago, if it wasn’t in English, it was in Russian or Japanese or Chinese, and you’d struggle with Google Translate to understand the translation.
Alejandro: Exactly. By the time we release this episode, which we’re recording the day before the end of October, Angular 17 should be released as a stable version. If not, it is likely to be announced soon.
So by the time this episode is released, many Angular features are expected to transition out of the developer preview phase, and new features will be introduced. Which of these features do you consider to be the most transformative?
Jorge: I feel that since one or two versions ago, Angular began to… It’s said that it took a sharp turn, right? It changed direction a bit. I won’t say for better or worse, but you have to keep evolving. When they removed modules at first, I didn’t think it was a good idea, I am quite a fan of having everything very well organized. And for me, modules were a way to order things properly.
I must say that I focus a lot on performance issues because I work on a very large application, and a single line of code that’s not quite right can greatly affect performance. So for me, modules were never a problem, importing a module with performance in mind and everything because we had everything so structured that it wasn’t an issue for us, but later I realized that it was a good move when Signals first appeared. At first, I said "Why not?" I mean, why are we going to stop being Angular? And then I realized the impact on performance. I think Signals is going to make it easier for this upcoming version if they release it as a stable feature.
And moving to "zoneless," I mean, leaving Zone.js, is going to be interesting but very painful. As developers of large applications, we’re probably going to suffer during this migration, but I think it’s going to have a very positive impact. That is, the day we fully migrate to Signals, everything that should be in Signals will improve the performance of our apps incredibly.
Alejandro: Do you have any advice on where not to use Signals in an Angular application for those who might want to replace Subjects and all things related to asynchronous calls, events, and the like, aiming to convert everything into Signals?
Jorge: Well, let’s see, for me, there’s a simple rule: if it’s a component, you can use Signals. If it’s a service, you shouldn’t use Signals. I mean, all the HTTP calls should go through RxJS because you need RxJS-style reactivity for now. I say ‘for now’ because we don’t know what the future holds.
Angular has always had this love-hate relationship with RxJS. I tell you because it’s like there was too much RxJS, but at the same time, it was never complete, like, are we reactive through RxJS, or are we not reactive because we haven’t fully implemented it? I think Signals comes to cover a bit of everything the Angular core team didn’t want to do with RxJS, and I believe that in the future — this is something I’m saying… I don’t have any insider information or pretend to know something — but I think that in the future Angular might abandon RxJS for HTTP calls in favor of the Fetch API.
Alejandro: I have two questions based on that. The first, so I don’t forget it: When you mention only using Signals at the component level, not services, what about events initiated by users? Events like click, tap, and keyboard inputs.
Jorge: Those events are essentially a form of monkey patching. They are not reactive; they are just events. Signals and RxJS are reactive: they react to things that happen in the system. When we talk about using onkey* in a template, these are fundamentally just bindings, right? They use the API that Chrome or other browsers provide. So, in the end, that monkey patching, now if you tell me, ‘No, I’m actually binding the click of a button,’ the question is, why would you do that? Why would you create an RxJS from this type of event? Why would you load something into memory that you could do another way? Why complicate your code?
Alejandro: Exactly. It’s an unnecessary over-engineering.
Jorge: It’s like saying ‘I need to go two blocks away, okay, can you walk? Yes, but I’m going to take a helicopter instead.’ Well, you’re going to get there, but at what cost?
Alejandro: I asked you this because in the initial days of Angular 16, I saw one of the Signals anti-patterns transforming an event coming from the user input into a Signal. So, to handle all the data binding and have it listened to from this perspective, they computed based on a specific user input. This was suboptimal because it was too much for something that could be done directly.
Jorge: Look, simple code is good code. Are there times you need to introduce some complexity? Yes, I won’t deny it because sometimes the data doesn’t come the way you want, or the functionality doesn’t work as you would like, there are time constraints, and one ends up complicating simple things. But, except for very specific, very particular cases, those things you usually see on Twitter are the result of people making a joke, saying ‘look what you can do, yeah, with reactivity, you could put your entire application in one component too, in your app component, you could put your entire application and manage it with a shift, appearing and disappearing screens’ But that doesn’t mean it’s right. I guess they do it more as a joke than anything else, but we should try to avoid anti-patterns.
What I say is, to give you an idea, when you have a form within another form, you have to do a setTimeout() to execute something for the form to regenerate, right? I remember there was a talk that was given at Google I/O, specifically in the Angular web track, discussing about handling asynchronous events. They pointed out that when using setTimeout() required a manual trigger of Angular’s change detection because Zone.js might not detect changes that occur only at the form level as opposed to the individual input level. Consequently, you are required to initiate detectChanges() explicitly. I don’t want to delve too deep into technical details, but to put it inside the JavaScript callback stack, a form that has some data change and you have to call detectChanges(). You shouldn’t have to set setTimeout() at 0, but it ended up being a normal pattern in Angular because there’s no other way to do it, and Signals is going to change that, so that part is going to benefit all of us because those are milliseconds of computing, of performance. These are small numbers, but in large apps, they are very noticeable.
Sometimes, the anti-pattern seems to be a joke, but you end up using it because the framework or library isn’t prepared to support that. So it’s kind of funny, right? We say not to use anti-patterns because it’s wrong when they are too exaggerated, but there are things that were not possible. In fact, I was talking with Alex Rickabaugh, who is the leading promoter of Signals within the Angular team, the one who set up the structure and everything. I was telling him that this is very normal for me, and he laughed and said it’s not normal for everyone, but it annoys me, right? Because I have to set setTimeout() to 0 to execute the Zone change detection and execute a bunch of other things within Angular just to get my field updated.
Alejandro: Which other new features in version 17, from your point of view, could generate divided opinions or have a mixed reception in the community in the medium term?
Jorge: Brandon Roberts, one of the great contributors to Angular, and maintainer of NgRx, recently proposed this idea of being able to create components in a style similar to React… that thing of having a file that executes a function and rendering the template, etc.
It wouldn’t surprise me to see this approach becoming more accepted in the future. It’s unlikely to happen right away, and personally, I’m not keen on it. Some argue that Angular is losing its core identity — that with Signals or standalone components, we’re straying from what made Angular unique. But in my view, we’re simply evolving. Just last year, I was planning a course and found myself wondering why I should cover the same old topics, especially since I don’t use Modules anymore. That’s the main shift.
Angular has indeed been progressing incrementally — updating the router, revising modules, among other changes. Generally, we adapt. However, imagine working at a bank entity, stuck on Angular 12, and facing an upgrade process. You might as well take a vacation during the transition to avoid the headache. But why do people really complain? In my experience, with any change, you’ll always find someone unhappy and someone else who’s pleased. It’s just the way it is.
Alejandro: What do you think is the biggest challenge developers, not those still working with versions as old as Angular 12, but those migrating from version 15 or 16 to the new one, will face? What advice do you have for development teams considering updating their applications to get the most out of not only Signals but everything related to templates, deferred sessions, and new control structures?
Jorge: First, make a good plan. For me, the basic thing always to migrate well is not just to change the version. It’s not enough to just bump up the version number. Changing the version in NPM, installing it, fixing a few minor issues, and calling it done is insufficient. We’re talking about a comprehensive update of your codebase.
For instance, this year, I created an NPM script designed to analyze your code, regardless of whether you’re using Nx or the Angular CLI. It scans your project and libraries, identifies all the inputs, and advises which ones should be migrated to Signals because the old approach is becoming obsolete. The script will point out which components have inputs due for an update, and it will also flag all the components that depend on those you’re updating. It’s tools and steps like this that can make the migration process much more manageable.
Alejandro: Do you need to update it to be compatible with version 17?
Jorge: No, the tool is more like a folder scan. It goes through directories to find the components. To give you an idea, it specifically searches for TypeScript files. It identifies any inputs linked to event emitters — an output, actually. That’s the key. Once it finds them, it moves on to the templates.
It catalogs all the outputs, the event emitters, and then checks which templates utilize those outputs. It compiles this data into a comprehensive file, complete with proper indentation. It even formats it as markdown, so you can easily integrate it into your GitHub repository, in your project, or post it as an issue. You can list out the to-do directly. It’s quite detailed — it generates all the checks. I’ve put a lot of effort into this.
The first step is to identify the components that need migrating and those that depend on those being updated. With everything organized and ready, you can confidently begin your migration. So, the advice is to meticulously prepare for the migration, not just rush into it. Don’t just wake up on a Monday and decide to update everything on an impulse. If you simply run an update and start without preparation, you’ll encounter errors. We’ve been through this with Angular versions 4, 5, and 6. But the changes now are substantial, so preparation is crucial. In my current project, the script output is 1700 lines long; that’s 1700 updates we need to make across various components and their dependencies.
Alejandro: Identification is the first phase, so thank you very much for putting this script out there. I will test it on my own applications to see what it tells me. Because if we turn a blind eye and decide not to follow the trends that are being recommended, there will come a time in version 20 or 21 of Angular, that…
Jorge: Let’s see, how much will you suffer?
Alejandro: these versions are basically just around the corner. Angular is already a late teenager, so it begins to approach the age of maturity :) And if we don’t consider these iterative migration steps, we will face an enormous tech debt that will result in a painful process.
Jorge: The truth is, you don’t just focus on upgrading Angular from version 15 to 16 to 17. This is also about dealing with issues, incorporating new features, and fixing bugs. Upgrades are important, but they’re not the sole focus — the client or project manager wants to stay current but only up to a point. It boils down to the cost and benefit at the moment.
I recall when RxJS moved from version 4 to 5, it was a significant shift that led to deprecations. People were stuck with deprecated warnings for a year and a half because they hadn’t taken the time to update their code. The approach to updates really depends on the team’s size. If you’re part of a small team, you might integrate a new component every few tasks without much disruption.
For larger teams, meticulous planning and execution are non-negotiable. Without it, migrations become a nightmare, and eventually, you might find yourself unable to update at all because the deprecated code has been removed from the libraries. The strategy should be incremental updates. Taking a year to transition to Signals, for example, isn’t unreasonable, especially for complex applications.
For us, it will likely take about a year to migrate to Signals after reaching Angular version 17. We’ll probably complete it by version 18, and just as version 19 is rolling out, we’ll have fully integrated Signals. That’s the scale of planning we’re talking about.
Alejandro: This makes a lot of sense because of the amount of lines that need to be changed.
Jorge: Right, it’s a huge project, and in the end, there are not many developers assigned to it.
Alejandro: How do you approach all that technical debt accumulating over time? Especially when stakeholders and project managers need to hear from you a solid reason for allocating part of the team’s capacity towards tech debt. What’s your approach when you’re in this situation?
Jorge: Well, it depends a lot on the team and who your project manager is. In our case, I’ll speak about our particular situation: our project manager is also a developer, someone who knows how to develop software. When our workload is lighter, we take the opportunity to start implementing necessary changes. If we’re looking at 1,700 changes to be completed over 12 months, we break it down and set monthly targets. Some sprints are busier than others, and the time we expect to spend on tasks can vary significantly.
It’s essential to utilize any free time effectively. For instance, in our team, we’ve achieved comprehensive testing coverage for both unit and end-to-end tests by capitalizing on these quieter periods. Good management and a proactive team ethos are key — there isn’t a need for one leader to direct every task. Instead, team members can use their initiative: ‘I’ve got some spare time, I’ll tackle those pending tests.’ That’s how we’ve achieved solid testing coverage. We don’t strive for 100% because it’s not practical, but we’ve tested all components and integrated Storybook for each one.
There are times when one person can handle the existing workload, allowing others to focus on different tasks. I’ve personally spent a week on the Angular 15 to Angular 16 migration. I was prepared to switch gears if urgent issues arose, but proper planning and honesty about the project’s status are crucial.
Of course, if the project is in crisis or we’re swamped with tickets and struggling to reach deployment with everything tested, additional tasks like these take a backseat. So, it’s about how well-organized the project is overall. I’m on a project that’s been ongoing for 7–8 years, and it requires consistent and structured efforts to maintain and update it efficiently.
Alejandro: What you mention about the free time is essential because one is really building not only with the quality of the code from the team but also with that future self who is going to have to deal with a series of obstacles or problems because the code is not sufficiently tested or because you have to go through a massive migration that we have been postponing and procrastinating.
Jorge: Right. It’s like if I leave a to-do, there’s like an internal rule that a to-do is fixed the following week. But why? Because the project already has a maturity. It’s a simple process: you leave a to-do note along with a reminder, which is effortless to manage. Sometimes, a to-do arises because you’re awaiting input or action from someone else. When this happens, setting a reminder ensures it doesn’t get overlooked: ‘I’ve left this to-do at this particular line of code; now, what was required? Is it the right time to address it, or should I consult with the team on how to proceed?’ It’s about the sense of comradeship among team members, functioning as a cohesive unit rather than individuals just ticking off tasks and moving on.
But of course, as always, it depends a lot on the project, on who leads it, on how it is led, and how the entire team works.
Alejandro: Many code quality analysis tools like SonarQube, for example, will detect TODO comments as a code smell.
Jorge: Yes, it smells a bit, yes. In WebStorm, for instance, the ‘Problems’ tab flags all the to-dos and warnings. We have a rule, although there are one or two to-dos related to third-party dependencies that have lingered due to some unusual imports. These are workarounds we’ve had to accept to keep things functional.
Regarding these pending tasks, our stance is to wait for the next version release of the dependency. Upon its arrival, we check if the issue can be resolved. If it’s not fixable, the to-do remains as a reminder of something that works, albeit not in the ideal way we prefer. For now, those remain as the exceptions to our rule.
But let me emphasize, this is a project with seven years under its belt, one that has striven to follow best practices from the outset, with a keen focus on code quality right from the start. The quality of the final product is a reflection of the underlying ideas, its functionalities, and the manner of their implementation, all of which are encapsulated within the code. That’s the foundation we’ve built upon.
Alejandro: I have many questions to ask you in another episode about web performance, like how do you measure using web APIs, even beyond what Angular offers us, etcetera. But I would want to take advantage of the opportunity to ask you on this occasion since we have the new version almost ready to be released: as an Nx Champion, do you see any unique synergy between Nx and the new version of Angular?
Jorge: Yes.
Alejandro: How do these new features, like deferred blocks and the new control structures, integrate with the tools that Nx offers by default?
Jorge: In fact, we didn’t talk about templating, did we? I mean, I think I skipped it mentally because I don’t like the new syntax. I omitted it. My mind said: ‘I don’t want to talk about that’. Let’s see, the truth is that Nx was created and maintained by Victor Savkin, a former Angular, and the CEO of Nx is Jeff Cross, another ex-Angular. Victor created the Angular router after four failed attempts. He came in and, in two weeks, created the router that we know today. I mean, the basis of today’s router was created by Victor. I’m lucky to know them and to have spent a lot of time with them, and I remember when the new schematics were being made and the CLI was going to be updated in 2018–19 — it was a very strong update of the CLI — and Victor was already out of the team. I remember that he sat down with other team members and said, look, this is the new architecture of the CLI, right? And someone who was outside was explaining how to make the new CLI, and I think it was very much in line with how Nx was going to become to be able to have that conjunction they have today.
It’s fairly straightforward for Nx because, as an open-source project, it’s public in many aspects — except, of course, for its cloud services and other proprietary offerings that constitute its business model. They have an architecture that’s built around compilation, and they’re quick to adapt to any changes Angular introduces.
Having what’s colloquially known as the ‘red phone’ to the Angular team is a significant advantage. It seems that whenever there’s a need for consultation or discussion, Nx can reach out directly to Angular’s developers. My perception is that the Angular team still occasionally turns to Victor, the lead at Nx, for insights or brainstorming sessions when faced with challenges or when they’re ideating new features. This isn’t something I know for a fact; it’s more of an educated guess.
Regarding Nx’s response to Angular updates, they seem to have a well-oiled process in place. They typically release their version about a week after a new Angular version drops, which suggests they prepare in advance and spend that week rigorously testing before making their own release. Given that both Nx and Angular are open-source and maintain their repositories on GitHub, collaboration or alignment appears more seamless. After all, Nx is a business, and its operations revolve around these updates and integrations.
Alejandro: So the Nx roadmap is strongly influenced by any dynamic and tectonic changes in Angular.
Jorge: The Angular part, of course. Exactly. But well, if you read a little about Angular, you know what the new Builder is.
Alejandro: Yes, I’m aware of it, not at a deeply technical level, but enough to understand the changes.
Jorge: It’s about the whole set of tools. And with the release after Angular 17, we’re looking at esbuild and Vite integration. Nx is already using esbuild in other aspects. It’s becoming standard for us, so the transition is smooth. Plus, builds are going to get quicker, which is great news for those who’ve been enduring longer compile times.
Alejandro: I’m hoping that we continue to see the synergy between Angular’s core and Nx’s tooling, especially with NxCloud. The parallel processing and task distribution can yield some impressive results when used correctly.
Jorge: Exactly, and it’s worth noting that this synergy isn’t exclusive to Nx. All kinds of libraries and frameworks — backend, frontend, compilers — they all influence each other. Angular, for instance, adopted the concept of using signals from Solid because it was a good idea. It’s a natural and necessary evolution in front-end development. It’s not just Nx; it’s a widespread practice.
Alejandro: What improvements would you like to see in Nx? Not only to complement this new Angular 17 stuff but other things that you feel are still to be achieved on the platform.
Jorge: I like, the graph of Next I like a lot, yet I wish it could include performance metrics. What I mean is, I want to understand the ripple effect when we alter a component, a library, or an entire project. Our project’s large scale makes performance a daily focus area. Sometimes, a seemingly minor change deep in the codebase — a middle component — can tank performance. That’s why, if Nx could enhance their tooling to analyze performance impact, it would be phenomenal.
Performance isn’t just about fast cloud compilations, which we know Nx handles with ease; I’m interested in the broader implications on my application. A performance impact graph would be groundbreaking. It could be an eye-opener for many who aren’t deep into performance tuning or lack profiling expertise. Profiling isn’t common knowledge; only a handful of devs are proficient at it. Such a tool from Nx could democratize performance understanding. It could make a substantial difference, transforming how we approach development at a fundamental level.
Alejandro: We have most of the tools and APIs available, but integrating them into daily practice hasn’t quite caught on, even though they directly affect user experience. Consistently using these tools also impacts us as developers, especially from a maintenance standpoint. It’s essential that we embrace these practices if we want to improve.
Jorge: Personally, I believe that if you want, and this is personal advice that people can take it well or just think I’m crazy, but I say, if you want to be a better developer, architect, or whatever your position is, learning profiling is going to make a difference when it comes to looking for a job, when it comes to being able to develop something or when taking advantage, it’s going to improve your skills.
My introduction to profiling came from my Java background, where managing memory and understanding garbage collection are essential. At that time, web performance issues were often shrugged off as internet problems. However, with the evolution from simple web pages to complex applications, profiling has become increasingly significant.
The Google Chrome team, for instance, has made some remarkable advances in profiling tools. And you don’t need to master APIs right away, just start with the basics of profiling to identify where your application may be lagging, not only during load times but also in its ongoing operations.
Take the comparison between using ‘hidden’ attributes and ‘ngIf’. The former approach keeps elements in the DOM even when not visible, leading to unnecessary rendering, whereas *ngIf ensures that you only render what’s needed. Recognizing such distinctions is part of the insight gained through proficient profiling.
I’ve noticed errors in the console often stem from a common oversight: using CSS display hidden instead of *ngIf. When something is merely hidden, not removed, errors can pop up because the underlying data may not exist yet or is not meant to be displayed at all. It’s better to default to *ngIf which ensures that elements are only present when they should be. Start with that principle and then address other concerns as they arise.
Alejandro: And soon it won’t be *ngIf, but @if, in the end, I was convinced by the @ syntax, instead of using brackets or sticking with the current structural directives.
Jorge: Oh no, don’t tell me that, it hurts :) I remember how weird it felt when we moved to asterisks. But at the end of the day, let’s be honest, WebStorm, Visual Studio Code, and other code editors allow us to autocomplete this. I switched this year to NeoVim, and it has excellent Angular language support. It doesn’t matter what we use; sooner or later, we’re going to get used to the @if syntax, although it's going to be weird for the first few days.
Alejandro: And in the future, we’re going to have this code automatically written while passing to the code editors some diagrams to build the application :)
Jorge: Something like that, right?
Alejandro: Much more efficient and native code than how JavaScript is interpreted by browsers today.
Jorge: It could be. We’ll see. As long as we are the ones doing that and continue to make a living, I have no problem :)
Alejandro: Is there anything else we haven’t mentioned during the episode that you would like to comment on before concluding?
Jorge: I think we went a little through everything, except for these ugly templates that I still refuse to like. Still, you’ll see that, I don’t know, three days later I’ll like them, I mean, it’s always like that, right?
One sometimes refuses change just for the sake of refusing, without any sense. But they also have to keep this in mind for new templates, where we should consider approaching this new templating system. And well, hydration as well, right? We are close.
Alejandro: With everything that has to do with SSR to hydrate the application progressively and non-destructively.
Jorge: That’s right! It’s there. It’s coming, possibly in v19 or so…
Alejandro: Sure. Well, as you said yourself, we’ve talked about a lot of things. It has been quite rewarding to have been able to cover the things this new Angular version brings and also see how Nx adapts to it, like a two-way data binding between Nx and the actual Angular core :)
Jorge: Yes, there are always ongoing discussions to support each other, because, in the end, that’s what it’s about: Nx has grown a lot because of Angular, and Angular has grown a lot because of Nx, so I think it’s a form of two-way data binding, as you say.
Alejandro: This conversation will continue. Thank you again for being here, and see you on another episode.
Jorge: Well, thank you very much for inviting me, really, and next time we can talk about profiling, if you want.
Alejandro: ¡Definitivamente! Bueno, Jorge, chao.
Jorge: ¡Hasta luego!
Stay tuned and check out who is getting interviewed for future episode releases at https://twitter.com/angularidades or LinkedIn.
