Astro, Analog, and Kendo UI in Angular with Dany Walls
Translated transcription from Spanish of episode #5 of the Angularidades podcast
Listen to the entire conversation in Spanish with Dany Walls on Spotify, Youtube, or other podcast platforms.
Alejandro: Hello, Dany, ¿how are you?
Dany: Hi Alejandro, how’s it going? Good.
Alejandro: Great to have you here!
Dany: Yes, perfect. We’ve wanted to talk for a while, and finally, we’re having it.
Alejandro: Let me introduce you first to those who don’t know you yet. You’re originally from the Dominican Republic, a front-end developer, GDE (Google Developer Expert), a distinction that Google offers to outstanding developers in specific technologies — in this case, Angular. You’re also a fantastic technical writer for Kendo UI on Angular and for Google Dev Library as well. Currently, you’re based in the beautiful city of Barcelona, where you work at the consultancy InnoIT. I guess that stands for Innovation IT, right?
Dany: Yes, that’s correct.
Alejandro: Dany, thanks for accepting the invitation to be here with me on this fifth episode of the podcast.
Dany: Thank you for the opportunity, really. When you mentioned the possibility of coming on here with other people — who I recommend everyone listen to because the content is very good — I said, ‘Me? Sure, we’ll make some time for that.’
Alejandro: Thanks, and I have some questions for you, not just about Angular but also about the new development framework Astro, which you’ve been writing about recently.
Dany: Yes, mostly talks about Astro, because honestly, when Astro came out, it was like a ‘wow’ for me, how it comes and solves many problems for us. So I said this needs to be shared; the community should find this tool to easily accomplish what we do daily. You see, sometimes we use the same tool for everything, and there are times when you should use the right tool for the job.
Alejandro: Exactly. We have a rather interesting wave of meta-frameworks, as well as static site generators with server-side rendering (pre-compiled on the server so that JavaScript does as little work as possible). The contributions that people like you are making to the community are quite valuable because it helps one process all that cognitive clutter due to the overwhelming amount of information.
Dany: Well, consider that I also don’t know many of these things in depth. Writing is also a way for me to process information because I have a low retention capacity. So I have to write it down for the future Dany to use it as a reference. And if it helps other people, then perfect.
Alejandro: Excellent, similar to the philosophy of open-source software, right? In the end, you’re sharing code without legal limitations so that others can also learn how you managed to develop that type of application, service, or software library. And you even allow it to evolve in directions that you didn’t originally anticipate when you put the code out there.
Dany: Yes. I’ll tell you a story later about when you do something for yourself, the impact it has, and how it benefits you and others in learning.
Alejandro: Sure, let’s not forget.
Dany: And you’ll like it. No, no, it’s on my to-do list.
Alejandro: Well, going back to the Astro framework, I’d say it’s one of the most recent stars in this sky of available technologies, which are already in the dozens, hundreds, and thousands, for building websites and web applications. Astro is a framework known for excelling in browser performance comparisons, thanks to the implementation of the Island Architecture pattern in software engineering. Like me, you were born on a Caribbean island, where the sea is the only border we have, unless one does data binding with other geographical locations using maritime or air transportation. :) Moving away from that kind of analogy, geopolitically and economically, it doesn’t make much sense to remain isolated nowadays. But in a web browser, it’s computationally evident that there’s a benefit to keeping a section of the web application frozen until the user intends to interact with it.
Dany: Exactly.
Alejandro: Please shed some light on how important the concept of ‘hydration’ is, which has been gaining a lot of traction for the past couple of years. How important is this concept in web interfaces, and how is it achieved in Angular, as well as how it’s done in Astro?
Dany: Look, really, as you say, the term hydration has been in my vocabulary for about two years. I wasn’t familiar with this concept before. I learned the term ‘hydration’ directly from Miško Hevery, the creator of Angular and recently Qwik, who last summer came to show us Qwik here in Barcelona. By the way, during the talk, he mentioned Astro, and that’s when I also wanted to learn about this new framework because it seemed like competition for Qwik, although not entirely. But what is hydration? When we have a server-side single-page application, the server sends you the fully built HTML document. Then, how does the browser know that there’s an event attached to a certain element? That process of restoring the application state is what they call attaching those events to all the elements we have in our application; it’s really the simplest way to explain what hydration is. The time it takes to recreate those nodes and, at the same time, add that event to them. When, for example, many of us use Angular Universal…
Alejandro: Which is now likely being fully replaced with Angular SSR in version 17.
Dany: …we currently have in developer preview a way to enable provideClientHydration which easily activates this client-side hydration non-destructively. The Angular team has been improving the old model used in Server-Side Rendering so that all DOM nodes, when processed on the client, don’t have to be reloaded again. Going back to Astro, I want to start by mentioning that there’s a difference between an SPA (Single Page Application) and an MPA (Multi-page Application). Astro manages each page or each section as a different page. That’s why it can go so fast because it doesn’t have to handle everything at once. Another thing I really like about Astro is that it’s content-focused; the framework is explicitly designed to create static pages, landing pages, or content-focused pages.
Alejandro: Which corresponds to the majority of pages we can find on the Internet. Most websites are not super-interactive applications. They are simple portals to display relevant information to the user and even to sell products or promotional space to get a return on investment.
Dany: Exactly. Many people might get confused and want to use Astro for building an e-commerce application, for example (to some extent it may be viable using microfrontends), but not for making a Facebook. No, Astro is not designed for that.
Alejandro: Or an augmented reality interface or a video game…
Dany: …or an accounting system that employs a grid with high levels of interaction. Astro isn’t made for that, but it is for other use cases. You can even mix technologies, like having one part in Angular, another in Svelte, and another in Vue. If I work for a company that already has a set of components made in React and I have to create a landing page, I can use Astro and reuse those components. One advantage of Astro is that you can reuse what you already have. I don’t know if that more or less answers a bit on the topic.
Alejandro: Exactly. In fact, let me take a sip of water to hydrate myself :)
Alejandro: By the way, Dany, the official Astro documentation mentions that it’s a UI-layer agnostic framework, supporting React, Preact, Vue, Lit, and Solid natively with Astro. But what about the intersecting opportunities of Astro with Angular?
Dany: That’s a very good question. I’ve promoted the answer quite a bit, because when people ask, ‘Where is Angular?’, as of today, unofficially, several people led by Brandon Roberts from NgRx are working on developing the meta-framework Analog, which allows you to use Angular within Astro. I have a demo, and there is also an example on the Analog website, where the details are provided.
Alejandro: There’s also an excellent article about the stack called SPARTAN, which covers the entire workflow using Angular, Astro, and a range of other technologies that allow you to tackle the development of these types of websites that are fundamentally static.
Dany: And to go a bit further at the level of Micro Frontend with Module Federation. Or even, without depending on it. For example, I recently did a workshop with a friend to mix Vue and React within Astro without having to implement a Micro Frontend, proxy, or bridge between those two frameworks.
This is the part where maybe tomorrow someone comes along and says, ‘Look, I have this set of Vue components already made with business logic, but we have these other pages already made in React and we want to combine everything.’ You could start working with Module Federation for the whole Micro Frontend topic, or use Astro as a container, which is what I’ve used it for most recently, as a container for my applications made in Vue or in Svelte.
Alejandro: What challenges have you encountered with Astro? For example, in these types of projects that you’ve been carrying out to test the technology, where does Astro become functional and where do you start to find limitations, obstacles?
Dany: There’s something they don’t solve. There was a part that was a bit difficult for me, as it changed the way of working a lot. And it was the part about sharing state. To share state in Astro between different technologies, between islands, they use something called Nano Restore, which is very good. They do have native support for components made with Svelte, Solid, React, or Vue, allowing them to communicate seamlessly. When I started, the Angular plugin wasn’t ready, and sharing the application state became very difficult.
Alejandro: And what about Analog? If you have people who are really strong in all this state management stuff…
Dany: Right, that’s when I started talking more with Brandon. Because I was wondering, when will Astro natively absorb it? And that’s when he told me, it’s not fully ready yet, but work is underway. So, officially, there is no support, but the package is already there. So, that left me like… I would have liked it if Astro had already internalized it as they have with Vue or other frameworks.
Alejandro: Exactly. In the coming months, we will see some very important developments with this topic of server-side rendering, with hydration, as everything continues to evolve.
Dany: Of course, now with the whole topic of Signals in Angular, Alfredo Perez wrote a very good article. I think that since Astro supports Solid and manages the whole reactivity topic built on Signals; when Angular gets Signals stable it will be easier. We’ll see what happens.
Alejandro: Well, I had mentioned earlier that you contribute to Google’s developer library and also maintain a blog on your personal site dannywalls.com.
Dany: Yes.
Alejandro: By the way, Walls comes from your last name.
Dany: It seems so :)
Alejandro: I really like your brand, and the way you’ve approached your personal branding. On dannywalls.com, you frequently publish relevant articles. It really takes a lot of commitment to maintain a specific frequency. I think you’ve managed it quite well, and the way you categorize content for Kendo, Angular, work-life balance, etc., you’ve structured the taxonomy quite well from an information architecture point of view. What I’d like to ask you about is that process. Could you describe the process you follow when writing a technical article on your blog, from topic selection to the final review?
Dany: I don’t think I can offer a specific technique for the process. Like I told you at the beginning of the conversation, I write — although people may think otherwise — mostly for myself about things that happen in my day-to-day life. Most of the time, believe it or not, I use paper and pencil to jot down the main ideas. For example, if we’re talking and you mention something about state management, that’s an interesting topic for me. If I think the topic could be useful for me in the future, or even if I may need to explain it to someone else, I’ll write an article about it. For instance, I wrote two articles in recent days. One was about when to use the ‘Record’ type in TypeScript, and the other was about Maps and Arrays. Why did they come about? Well, I had a scenario where I needed to create dynamic properties in an object, where both the keys and values had to be of a certain type, with certain restrictions. I needed all the keys to be derived from a list of bank accounts, for example. And of course, I had to find a way to do it strictly. I thought, ‘Wow, how do I do this?’ After reviewing some documentation, I discovered that this data type solved my problem. I had never used the ‘Record’ type in TypeScript before. So, I finished my task and drafted an article. This is something I recommend to everyone: write a draft with the idea, but don’t publish it the same day because it’s still too fresh in your mind. I always let it sit for a couple of days. Then, two days later, I review it and try to simulate what I wrote at that time. You also have to provide context for people. Otherwise, it’s not well-explained. Why? Because, as I said, I have a bad memory. In two days, I’ll probably not remember and may wonder, ‘Where did this property come from? Why was it like this?’ So, to summarize, my flow is: write a draft, let it sit for at least two days, more if possible, three days so you forget the context. Sometimes I share it with friends. I’m working on it… What do you understand from this? And then the person reviews it, gives feedback like, ‘This isn’t clear to me,’ and then I improve it.
Alejandro: Excellent advice. I love that you use tangible technologies like paper and pencil. This even helps you reason and understand elements you wouldn’t necessarily get by typing into a computer text processor.
Dany: It’s also because we often get stuck in the habit of coding. But when I write it down on paper, that’s when I realize, ah, OK, this part is missing. So, I can guide myself. One of the articles I wrote was about using the Tuple Map set. A coworker once said to me: “Hey, but you always used Array for everything.” I responded, no, man, but we need this to check for duplicates, for this other thing, and that’s it. But after this initial reaction, I immediately asked myself: Are there other collections in JavaScript to do this? How can it be done? The thing is, if you have a hammer, everything looks like a nail. But that’s not necessarily good. I remember getting up one morning and saying: “Look, I’m going to do it differently.” As you know, I’m a big NBA fan, and I approached each data type as if I were planning the players’ strategy. An array serves me for this, a tuple for something else. Why don’t I use a tuple here? I need to understand the reasons why and the advantages of using them. And that’s how the article came about, from day-to-day experiences. Almost 98% of what I’ve written about Angular is the result of what I’ve been experiencing at my job. Exactly like that.
Alejandro: I use sticky notes a lot, and several of my technical articles have come from them. When you have fragmented information, it’s easier to create an article to share with others by following the basic principle of ‘divide and conquer’ to break down the core ideas. Once I have everything divided into small notes, it’s simply a matter of organizing them, even organizing my thoughts to avoid starting to write and not even knowing how it will end. Having a clear purpose and different basic ideas separated in their specific notes helps to argue them later in the article. This is quite similar to what you’re saying about writing on paper some snippets that will serve as support later.
Dany: If you remember, I told you I was going to mention something at the beginning, now is the exact time.
Alejandro: Yes, please go on.
Dany: There’s an article I wrote about a challenge that recurs in almost every company. I imagine you’ve also encountered it when developing a dynamic form.
Alejandro: Is it about using JSON to pass the metadata of elements and then constructing the form from them with embedded views?
Dany: Exactly. I’ve had to do this for two companies. The second time, in January last year, I said, no, no, no, I can’t write this code again without at least a guide. So, I decided to write an article that I think has around 50,000 visits or something like that. In the article, I started with something very basic, about how to create a dynamic form to which you can add elements like a ‘select,’ ‘radio,’ and the corresponding validations. After I published it, someone commented: ‘Hey, in this code I’d like to propagate these changes to another internal form.’ And I said, okay. Shortly after, another person commented: ‘Hey, you’re using NgSwitch, why don’t we make it even more dynamic?’ And I refactored the content to allow the system to dynamically load components and trigger events at the specific moment. As people kept asking me questions…
Alejandro: That article turned into a literal RFC for you :)
Dany: Right now, I have two requests from readers; maybe I’ll work on it after I get back from vacation. The source code I have on GitHub already has about 24 stars from people who’ve told me it’s been really helpful because they needed to develop that same scenario. So, often, when you write something geared towards your own problem, you start hearing from other people who provide feedback, helping to improve the code, or just seeing things you didn’t initially see. For me, that project, that article has been one of the ones where I’ve learned the most, based on what other people ask for.
Alejandro: The next level should be writing articles right there on GitHub so that people can make pull requests and it gets edited in wiki mode.
Dany: Well, some pull requests with improvements have already been made to the project. That’s very important. When you write something, you don’t know how many people you can impact. I never thought that article would reach over 50,000 reads. I originally thought it would just be useful for me.
Alejandro: And mainly for people who are just starting with Angular, whether they are recent graduates or are approaching it from specializations in other JavaScript frameworks or from the back-end. I’d like to know, Dany, how do you ensure that the technical information you are putting out there is accessible for readers, regardless of their prior knowledge on the topic? I mean, a person might have no idea what a ‘reactive form’ is, or a ‘template-driven form’, or even what we’ve previously mentioned about data structure, what a ‘record’, a ‘tuple’, a ‘graph’, or a ‘tree’ is. How do you make the content in your articles accessible without making it too basic for those who are more advanced? How do you achieve that balance?
Dany: That’s something I’ve learned recently when I started writing for the people at Kendo. When I write an article, I have to find a way to make the content clear for people. If they are not familiar with the topic, I have to make references to the basics, meaning, I link to such an article, so go there and read that first before you come back here. That’s very, very important. Why? Because, for example, there could be someone who has never developed forms before. So, you have to guide them. Sometimes, I prefer to err on the side of making it simple. And then make it more complex, so to speak, like in the dynamic form article example. I first went over how to create a form by reading a JSON basically like an ngFor. Then I added a step 2. If you want to come here, perfect. If you want to stay at that part, because maybe there are people who don’t need to dynamically create a component. So, slowly tightening the screw.
Alejandro: Do it like ‘progressive enhancement,’ similar to the typical front-end technique from over a decade ago.
Dany: Exactly. I never go straight to the most optimal solution; instead, I show you the process. In my work philosophy, I write my code, it works, OK, then I refactor. I don’t refactor at the beginning, no. Because I leave it there, I have a commitment that I know worked. So if they tell me it needs to go into production right now, I can send it, and then I start refactoring from there. So, I write and try to guide the person without being too basic, but also without being too complex, because I don’t know who’s going to read me. And if it’s super simple for you, it’s not necessarily the same for me. Especially because there are days when your mind is blank, and you need things spoon-fed to you.
Alejandro: Exactly. And with so many components out there, since you mentioned Kendo UI, I have a question. What do you consider, from your perspective, to be the most significant advantages of this component library when combined with Angular? Instead of using Angular Material or Tailwind, why Kendo?
Dany: Currently, we have many options for frontend component libraries, such as Angular Material, which are open-source and work really well. However, when you’re running a business, especially with a large team, you have to make decisions about using an open-source library or a paid one. In my opinion, Angular Material solves many common problems, but paid libraries like Kendo offer additional advantages. Kendo, for example, offers more than 110 ready-to-use components and covers all aspects of accessibility. Most importantly, when you’re running a business, you can’t afford to wait a long time for technical support. You save all that time with Kendo. Kendo, for me, is a library that should be one of the right choices to adopt in companies. Regardless of whether you have your own library. In the company where I currently work, we use Kendo as a base, but maintain our own library.
Alejandro: So, you extend components from those that already exist in Kendo?
Dany: Exactly. Why do we do this? We have our own set of components, but developing something like a data table (grid) from scratch consumes a lot of time and resources.
Alejandro: I understand, the effort needed to create even components that seem simple, like a date picker, is significant. Users may think it’s easy because they use it daily, but the logic behind these components is complex. Therefore, it doesn’t make sense to reinvent the wheel.
Dany: Although in our company we have a team dedicated exclusively to developing a component library, it’s not efficient for us to create something like a data table (grid) with dynamic support for different types of data. I recently wrote an article on how to create inline editing in a table. You can specify that if the data is numeric, a numeric ‘input’ is shown for editing. If it’s a date, a calendar is displayed; and if it’s a ‘checkbox’, you can have it show ‘yes’ or ‘no’ instead of ‘true’ or ‘false’. Even though we could develop this logic internally, we prefer to use a framework that already offers these capabilities, like Kendo, which also provides good support. If more features are needed in the future, such as combining components, we know that Kendo can meet those needs. And that’s the good part about using Kendo.
Alejandro: In the medium term, to sum up, Dany, what do you think will continue to be the trend in adopting visual component libraries? What does the future look like for Kendo UI in application development? Let’s ground it specifically in Angular. This interaction between Kendo UI and Angular, what’s the future development like?
Dany: Well, the Kendo team, for example, supports Angular 16. They release a version every 3 months. They also offer support for older versions. In the real world, we know that not everyone is using the latest version of Angular, so having a library that continues to offer support for older versions builds trust. Additionally, the speed of development is increasingly crucial. It’s not practical to assign a team to develop, say, a PDF handling component that works in all browsers. Businesses can’t afford to wait for your team to take, for example, three sprints to develop a drag-and-drop with upload feature. No.
Alejandro: It ends up being much more expensive than hiring the services of a platform that offers those kinds of capabilities.
Dany: And if you need to customize components beyond what Kendo offers, you can do it. I recently wrote an article about using directives for API composition, so you can extend components. With the native support that Kendo provides for Angular, you can apply all your prior knowledge of Angular to fill any gap that Kendo doesn’t cover. We don’t expect Kendo to do everything, because if it did, then… where would we be?
Alejandro: What would you like to see in future versions of Kendo UI and Angular as a component developer?
Dany: What I’d really like to see in future versions of Kendo UI and Angular is better support for the composition API. Some components are still being developed to be compatible with this API. Since many of the Angular features I’m using are still in ‘Developer Preview’, I understand that Kendo might be working on this, although I don’t have concrete information about it. I’d also like Kendo to align more closely with reactive programming. For example, I think Angular 17 will come out of ‘Developer Preview’ and offer ‘Signals’ as a public feature. I’d love for Kendo to be prepared to support ‘Signals’. I believe ‘Signals’ will represent a significant direction in reactive programming and I’d like Kendo to adopt it.
Alejandro: So let’s hope that Signals appear as something fully stable in Angular 17 this November.
Dany: Yes, I have high hopes even though I can’t confirm anything. I’d like to see support for ‘Signals’ because I believe it would simplify life for developers, especially those new to Angular and RxJS. RxJS is a powerful but complex library, especially for those coming from other frameworks. The introduction of ‘Signals’ could make reactive programming more accessible. For those already familiar with RxJS, Angular has a new concept for combining ‘Signals’ with RxJS, called ‘RxJS Interop’. It would be exciting to see how these technologies can work together more efficiently.
Alejandro: You mentioned that you’re soon going on vacation. And when you step out of the day-to-day environment, that doesn’t necessarily mean you immediately unplug your brain and stop thinking about software problems. This can affect anyone, in any industry, in any kind of role. You’ve written articles on how to achieve a balance between the responsibilities inherent to software development, digital products, and those other ones around you, in the real world, let’s say, off the screens. Is there anything new you’ve learned in the last few weeks or months that you haven’t shared in your articles?
Dany: Well, what can I say? The reason I’ve written on the topic is mainly because sometimes we get too caught up in technology. One might wonder, where do I get the energy to write constantly? Sometimes, you have to take a break to recharge. We can’t let technology dominate our lives, so taking time for oneself is crucial. In this era, things move fast: close your eyes, and three new frameworks and a new Angular version have already come out. Despite this, something I learned years ago is the importance of learning at a moderate pace and not trying to grasp all the new technologies. For example, I haven’t learned GraphQL yet, even though it’s been in the market for quite a while. I don’t have the time to learn everything. Therefore, it’s vital to focus on what really matters in your daily work. In my case, I need to stay up-to-date with Kendo, testing, and Angular. That covers my job. Anything beyond that is extra. So, you need to have that balance. Even though technologies like Signals may be exciting, it’s important not to lose focus on what you really need for your job. Don’t immediately get carried away by the new thing is my main advice. A few months ago, I had to take a break from some of my activities in the software community because I had to prioritize my job and other aspects of my life. At the end of the day, we’re all human and need to know when to stop so as not to compromise quality on any of the fronts we’re active on. And I said, hey, I need to prioritize, because otherwise there might come a point where I’m not doing well in anything.
Alejandro: Exactly. I often recall the Eisenhower matrix for decision-making, which can be very useful in these cases. It helps categorize tasks into ‘urgent’, ‘important’, ‘not urgent’, and ‘not important’ so that we can focus on what’s truly important and urgent. It can be overwhelming to try to conquer everything and stay on top of the latest trends and technologies. At the end of the day, it’s about finding a balance that allows you to be effective in your work while also finding time for what you enjoy and what’s truly relevant for your personal and professional development. That’s the ultimate goal.
Dany: Someone told me many years ago, back in 2005, ‘If a technology is going to be truly relevant in the market, you’ll have enough time to learn it.’ For example, have you ever heard of Microsoft’s Silverlight?
Alejandro: And Adobe Flex as well. Flash was indeed something epic, very important for almost everyone who started with front-end 15, or 20 years ago.
Dany: Yes!
Alejandro: But yes, technologies come and go, and one shouldn’t worry too much about it.
Dany: Same with Svelte, which came out some time ago. You don’t need to rush to become an expert in it. I tried it because I was doing a Micro Frontend workshop and wanted to show something more than just React. React has been there, has stayed, and has given us time to learn it. So, if something is relevant enough to change the market, you’ll have enough time to learn it.
Alejandro: It takes a lot of community support, and you also have to understand that it’s not humanly possible to know everything. As part of a much larger mechanism, you need to learn how to delegate and trust the people on your immediate team who work with you. For example, as a UI developer, you rely not just on infrastructure but also that there is electric power. You can’t take care of those kinds of issues; that’s what the power companies are for, etc. So, basically, everything is a framework and cohesion between a series of structures. It’s good to know they exist, but you don’t have to specialize in everything. This allows you to be capable, as you were saying, to focus and enjoy the process of what you’re doing and learning day by day.
Dany: Yes, like the case with Qwik. When Miško showed it to me, I saw it and liked it, but I set it aside. Later, when I saw it was gaining traction, I dedicated time to it, but not to an extreme. I studied it enough to understand its changes. I haven’t needed to delve as deep as Leifer, for example, who is really into Qwik. He’s made direct pull requests to the code. I don’t have to go to that level. That’s what Leifer and others are for. For example, right now I make a living from Angular, great. And maybe I have to learn a bit of GraphQL for specific things at my company. So, I’ll read and inform myself. Plus, technologies are constantly changing. In the case of Angular, there are new updates all the time. You don’t need to be an expert in everything. You have to know how to balance.
Alejandro: By the way, Leifer gave a very good presentation at the Angular Community Meetup, mainly for people who are not familiar with Qwik’s meta-framework.
Dany: Yes, I know it was recent, in August. In Leifert’s case, he has fully immersed himself in this technology, but he hasn’t touched Astro. I have, because it solved specific problems for me. Everyone has their own circumstances and challenges. Choose your battles wisely. Comparing yourself to others is not useful; Alejandro knows 10 things, but you are Alejandro, with your own needs and problems. There’s no benefit in comparing yourself to others. That’s the advice I can offer.
Alejandro: Dany, before we wrap up the episode, is there anything else you feel hasn’t been mentioned during the conversation that you’d like to comment on?
Dany: No, mostly I’d like to invite people to subscribe here, to watch the other episodes. You have really good content, as does the Angular Meetup community. They should subscribe there as well, because Angular is really evolving, and for me, it’s getting better all the time. They should also take some time to rest every now and then like you’ll do and like I’ll do too; life isn’t just about code.
Alejandro: Exactly. Thank you so much for being here, sharing and contributing various ideas that have been collected in my mind. I will definitely review the transcript. What you have shared today has been very useful and interesting.
Dany: Well, I hope to return to Angularidades at another time, and that’s what we’re here for.
Alejandro: Gracias, Dany. ¡Hasta luego, chao!
Dany: ¡Chao, chao!
Check out who is getting interviewed for future episode releases at https://twitter.com/angularidades.
