Web development courses and tutoring with Leifer Mendez
Translated transcription from Spanish of episode #8 of the Angularidades podcast
Listen to the entire conversation in Spanish with Leifer Mendez on Spotify, Youtube, or other podcast platforms.
Alejandro: Hello Leifer, how are you?
Leifer: Hello, how are you, Alejandro? I’m good, and you?
Alejandro: All good. Thank you for being here and accepting my invitation.
Leifer: Thank you for inviting me, it’s always a pleasure.
Alejandro: Let me introduce you to those who don’t know you yet. You’re from Madrid, Spain, a software engineer, a web development course instructor on Udemy. You also have a very popular YouTube channel with over 300 videos published, with tens of thousands of people following your content, not just there but also on other social platforms. And you have the online Bootcamp platform with programming courses in Angular, JavaScript, Node.js, MongoDB, and most recently, the meta-framework of Qwik. It’s a pleasure to have you here.
Leifer: Thank you once again, Alejandro. There are interesting points that need to be clarified. The audience always tends to get confused because I live in Madrid, but I’m not from Madrid. I’m from Venezuela, from San Cristóbal, in the State of Táchira. It’s a border city, just an hour and a half from Colombia. Someone from there might notice the accent, but I’ve found that in other places, the accent confuses me with Mexicans or even here in Spain with Canary Islanders because I’ve lived in Mexico and here in Madrid. So words from one culture or another get mixed in, and in the end, I have quite a strange mix. But I’m originally from the State of Táchira, which is not Caracas; the accent is much more similar to Colombia.
Alejandro: So you’ve accumulated more dialects than programming languages throughout your life :)
Leifer: Yes, yes, I think so. Exactly.
Alejandro: One of the things that people listening to this podcast might suspect is that this is the second time we’ve greeted each other. About 5 or 6 minutes ago, we started this conversation to break the ice, to catch up since the last time we saw each other at the Angular Community Meetup. This episode is just a conversation that requires little post-production work, except for the transcript to English to broaden the content to audiences who may not necessarily know the Spanish language. But there are more difficult formats, like the YouTube shorts we initially discussed, and other new things that may be emerging on TikTok or platforms that don’t yet exist. Leifer, how do you deal with the production and post-production of the videos you publish on YouTube, Udemy, and the other platforms where you have a presence?
Leifer: That’s a good question. I think it’s the first time I’ve been asked that way in an interview. Each social media platform has its own market and audience. It’s no secret that, for example, TikTok requires very fast-paced content. You have, at most, two seconds to engage the audience. In this case, the content is vertical, which is new for me. I’m not inexperienced in creating vertical content; I just analyze and get inspired. Sometimes, I literally copy because, these days, inventing something is difficult. There’s already a lot out there. I think what you have to do is get inspired and modify it for your objective, as it won’t always be 100% replicable in these kinds of strategies.
In the case of TikTok, being educational content, one could say it’s not the most ideal platform for this type of content. People are looking for more entertainment and something that can be consumed quickly. You can’t teach JavaScript stuff in 30 seconds beyond a very short and small concept. Regarding the vertical format, basically, what I do is that I’m not alone in that part. People help me cut, edit, add effects, and create the ‘call to action’. If you want more, you can watch the content on YouTube or follow it in the next ‘reel’. It’s not that you can’t do it alone, but you’ll get tired very quickly. The point on social media is that you have to be very consistent. I think before speed, you have to be very consistent, and for that, you either have to have a team or be very organized and disciplined. That’s hard for me, so other people are helping me in that part.
Regarding Udemy, we’re talking about an entirely different area. Many people perhaps don’t know how much time, on average, it can take me to create a course on Udemy. I see it this way: there are hundreds or even thousands of courses on Angular. What I’ve observed from the students I have on Udemy is that they’re not so much looking for the content as they are for the instructor with whom they feel a ‘connection’ and can better understand their explanation. The content is freely available; you’ll find it if you research. What people really pay for is the way you’re going to explain it to them. Some say I explain too quickly, while others appreciate the speed because I get to the point.
In my case, the courses I offer usually last 8, 10, or 12 hours. On average, it takes me two months to create a 10-hour course. These are two months in which I plan what application I will develop, as my courses on Udemy focus on creating an application from scratch to deployment. If you look for my Angular or Node courses, which are languages for building applications, you’ll see how an application is developed from start to finish. Before recording the course, I build the application once or twice to know how to connect the elements, whether to explain modules here or routes there. The structure of the course depends on the application I’m going to develop. Each instructor has their own way of explaining.
But from my point of view, as I work through the application, I need to build it to decide what’s better to explain at each moment. After it’s recorded, the editing work comes in. Normally, I only record two or three videos a day, because otherwise you get tired. I don’t want to transmit a tired video. I prefer to wait until the next day to record two or three more videos, and so on. Typically, by the time I start editing and am finishing up the course, there are usually more than 38 videos, each ranging from 8 to 20 minutes. Editing is not a fast process; it involves going back and watching all those hours of content and making cuts. It’s a process that takes two months, or even longer. I repeat, some people say they can create a course in a week. Sure, they can, but what I do is my style. I like to build an application. What you’re buying when you buy my course — and this happens often — is the code because you want the application. People sometimes skip around because they need to learn from a specific video to figure out how to modify something. I need to provide the application because if I just explain concepts, I get bored, personally. I need to be doing. So, I teach the way I would like to be taught. Some people like it, some don’t, and that’s the beauty of this market.
Alejandro: Exactly. And what you mention, the human component is extremely relevant. As I said earlier, it’s one of the fundamental reasons why many people who are starting out or who want to delve deeper into the more sophisticated parts of the framework or any programming language decide, instead of opting for official documentation, to go with what a human is saying in these courses that can be offline or may have some dynamic interaction components with the teacher. What’s the most recommended, most comforting thing to see in a person you’ve trained as a web application developer? After the course is over, when that person comes to you and gives you specific feedback.
Leifer: Yes, well that’s the point. The dopamine point is there when someone suddenly shares what happens to me. I won’t say every day but maybe once or twice a month, someone takes the trouble to go to LinkedIn, posts the mention, puts up the certificate, and some have said, “I got my first job,” others that “I managed to create X feature at the company.”
So that point is comforting because it’s the fact that you’re contributing knowledge for the journey. I’m one of those people who, well, there’s a saying that goes, ‘I don’t like being given, but being put where you can get.’ Like, some people say ‘I don’t like being given money, but put me where there’s money.’ Well, in this case, it could be applied to the knowledge part.
And that’s very good because if you learn how to do it, you’re going to be able to replicate it, and as you’re replicating that path, you’re gaining more experience. Personally, about four years ago, I mentored two people, without having planned any mentoring plan really, but they were people who in one way or another we got to through Facebook or through Twitter or through any network and they would tell me, “Well, I’m from X country and the truth is I’d like to know if you have a project in which to participate simply because I want experience and the like.” At that time, I don’t remember what I was working on, but I remember that I said, “Look, I’m working at X company, and I have the opportunity to basically create any feature I want here.”
I basically have an open field to do whatever I want. I started to delegate small tasks, very simple functions — a form here that validates input, email, numbers with patterns, or something like that. They began to work on that feature. As they were developing that feature, I would share resources with them. OK, look, you can check out the Angular course if you want to learn about this part of the module, which is what we need, and then you can integrate it with your projects. Similarly, with Next.js and Nx -around eight people were in that mentoring program.
Today, I can say that 90% of these people have their jobs, and I even still work with two of them. It’s not 100% free anymore; there’s a remuneration now because they’ve obviously gained experience. I’ve also reached the point with many of them where I’ve told them, “Look, you’ve reached a point where I feel you have the knowledge and skills to earn better pay. You can’t be a free collaborator forever.” Everything is fine, but you have your aspirations, right? If you have free time, you’re welcome here. I still work with one of them in this mode today. And yes, two work remotely from Colombia, and another works for another country. I’m not sure which, but it’s a remote position.
Alejandro: And this is one of the things that makes you a good mentor, going beyond just the programming language and the content you’re teaching to focus on other components that help people advance professionally in their careers.
Leifer: Absolutely! Look, most of my years of experience have been what’s known today as freelance work. At the time, I didn’t know what to call it. I was basically someone doing hourly jobs. And that experience helped me not just get stuck in opening Visual Studio Code, closing it, and saying goodbye. Instead, it’s like, how can I optimize processes in a given company to reduce costs? Any person starting now who says, “Hey, I can’t find a job. It’s difficult for me,” they should consider this.
It’s not just about having the knowledge. You can’t have it all. Nobody has all the knowledge. The only secret here is that if you come up with a proposal that convinces the company, or better yet if you have a sort of a demo on how to reduce their costs, you’ll be the best option. It doesn’t matter if you lack experience. It doesn’t matter if someone next to you has many years of experience.
Companies are interested in saving money. And if you propose an idea, that’s it. There’s nothing that can compete against that. And that’s what I’ve been doing in a way: figuring out how to automate and also how to produce for myself. These days, I’m at a stage where I’ve done this for many companies, and now I’m looking at how I can work to obtain that benefit for myself. That’s the hardest part because it’s one thing when you know there’s a company that pays you directly.
But another thing is, how do I make that leap? How do I attract clients and convert them? That’s a process that, as developers, maybe we work on a product, you work at a startup, and you have a form that connects with PayPal and Stripe, but you don’t care if this button is small or large; you don’t know why that button is there. I mean, there’s a button, it works, and that’s it. But when you’re on the other side, and you’re saying, ‘How do I make this person buy? I know they want to buy because they’ve gotten to this point. But what happens?’ That’s where you think, ‘Ah, maybe it’s better with an arrow, maybe it’s better to remove one click, maybe this needs to be larger.’ Those are things that one may not understand. When you say they’ve told me to change the button 14 times, it’s for a reason. Yes, maybe usually for very poor decisions, but it’s for a reason.
Alejandro: And that’s one of the skills that, as software engineers, sets us apart when going a bit beyond with solutions. That’s why it’s so valuable that you don’t necessarily have to know about control structures, variables, or even more advanced programming language elements. It’s about how you can use that knowledge to translate it into requirements, into the actual needs of the entity that’s essentially paying for it or is non-profit or whatever the objective of that institution is.
Leifer: Exactly.
Alejandro: Speaking of complex elements in programming languages, what’s the difficult part of Angular that you enjoy teaching the most to people who are delving into the more advanced functionalities of this framework?
Leifer: Hmm, that’s a good question because before version 16, it was modules. Honestly, I love the part about modules. I know I struggled at the time of learning about these modules. Moreover, it was totally different when I switched from AngularJS to the current Angular. And this thing about modules was, like, they added more complicated stuff. The thing is, it was a very good option at the time for having everything very separate. I mean, it was not designed to be a typical landing page. No, if you’re going to do a landing page with three routes, forget it; don’t use Angular. Use the dozens of other better options for that. But when you’re already working on a platform that, in my case, was very tourism-oriented, it had user panels, admin panels, filters, and a thousand things, hotels, flights, and all that. When you have that way of having a path already made so that you don’t have to, let’s say, invent things along the way, Angular has something called modules, and that’s basically what you need.
It’s like having a section of your whole application within this scope. This is the flights module, this is the hotels module, this is the self-guided module. So, on a business and development level, it serves as a pillar. If we need to do something in the flights module, it’s here. Let’s not touch anything else because that’s fine. You know, everything you need is right here, and you can also launch it with its routes, with its faces, assign their roles to them.
That part about modules was super complex for me, up to the point where I changed my perspective. Because I, before, when you don’t have a path, when you come from, I don’t know, in my case, I came from Laravel and then went to React. I made some weird jumps. When you come from that to something as structured as Angular, it was very, very confusing. I obviously did some super horrible things. I remember the first applications. There was only one module with everything imported there, everything. And that took, I don’t know, it was like 18 megabytes to download the first application. But well, I learned, and here we go.
Alejandro: And this is something you enjoy nowadays, teaching people how to structure or architect their applications more modularly.
Leifer: Yes, what I enjoy is more the act of how to think about it. You have to think about it these days. Today, I’ve seen that the current frameworks are lowering the learning curve, and I understand the authors. Their idea is to remove everything confusing and leave it a bit more open for the developer to do what they do best.
The point is, when you don’t have a path, you end up putting in things that you don’t know if they’re entirely valid, like me putting everything in a component because I didn’t know what modules are for or putting everything in one module. Well, people will do the same, right? They’ll put classes, functions, HTML in some, and CSS in others, and it will work at the beginning. It’s going to be like that until you change their perspective. It’s better to call them ‘modules’, call them ‘responsibilities’, call them whatever you want, but give it some order, like this is for users, this is for products, these are for orders. I still call it ‘module’ because I think it’s a very good name. It’s a module of the application as such, and I think this concept can be transferred between frameworks.
Alejandro: And let’s say you’re in those two months preparing a course. If suddenly -in a moment that must have possibly happened to you- you’re structuring the entire narrative from point A to the deployment part of the application, and you did it all based on modules, and then Angular 14 came along with standalone components, the hype, the trendy thing, this new thing that everyone wants to learn, what do you do at that point? For example, if a month and a half in, you realize that there’s something new like Signals or the new control structures or deferred loading, which in a certain way is not mutually exclusive with the content you were giving, but there are things you need to change, what’s your approach in this case? Do you incorporate the new knowledge as a bonus chapter? How do you do it?
Leifer: Yes, I will finish what I’ve planned to complete because, at least in my experience, a new version comes out, and it’s not going to be applied in a company right away. For example, in a bank, they will go through three or four versions before updating. And most startups also won’t switch to the new version the next day. That usually happens in personal projects. And well, let’s say you can do it, it’s your project.
So, at this point, I finish what I have planned to do and then as a bonus, I add what’s new, like I did in my Udemy course. It has Section 16, but I didn’t remove the rest because even today, I still believe that 80% of the applications you come across, if they are on Angular 13 and working fine, they’re not going to remove modules overnight. So, you are very likely to join a job that has an application with modules. So, here’s how modules work. And I show you, look, how we’re also doing modules. Let’s convert this module basically into a component. I show that and build upon it, teaching there. Look, this is how you update, this is how you migrate. You can remove this, remove that. See how it becomes emptier? And I apply that same knowledge to the same application.
And today, the course on Udemy starts from Angular 12 or 13, explaining everything about modules, but in the end, you even see the point of experience, how to migrate, how some packages break, what to do. OK, let’s look for the version, let’s install, let’s withdraw, let’s change this for that. I explain how a specific subscription used to work, and then we switch it to a Signal. And I think that’s better because, again, it’s real. I mean, you’re not going to get to a job and see, ‘Oh, we’re on Angular 17.’ No, at least not today, not while we’re recording this. It’s rarely going to happen.
Alejandro: Exactly, it would be like a futuristic course about things that are still in developer preview and not stable enough for instructors to undergo a whole didactic process related to those new elements. Leifer, as an instructor, as a teacher, how challenging is it, especially with back-end or full-stack developers who haven’t yet had the chance to specialize, to pay attention to the proper use of HTML, to teach them to structure Angular templates that are both lightweight and semantic as well as accessible?
Leifer: In Angular, although it may seem contradictory or make a lot of sense, back-end developers adapt very well. When it’s Angular, they bring that strong concept, like from Java or another language I can’t remember. But they adapt very quickly. Angular is their best way to do front-end because it’s strongly typed, it’s rigid. They think, “Ah, OK, this is how it’s done here. It’s the same as I do in the back-end, where I have my separation of responsibilities, my typings, my dependency injection.” So, that part is quite easy. For HTML, well, back-end people at least know what HTML is. When they see how Angular creates the view, the template, etc., they quickly get it. They even like that part where it’s separate from the CSS and from the functional part of the component. Things start to get a little more complicated when they want to take it to other frameworks like Vue or React, where everything is very open. They get lost there. They wonder, “Can I do everything in one file?” Yes, you can, but you can also do it separately. So they get a bit lost there. But I think with Angular, they adapt really fast.
Alejandro: When it comes to guiding them to have that line of thought on how to create HTML that validates correctly, the resulting HTML is processed not only by a person who is going to see the rendered content visually on a website — it doesn’t matter if you do it with tables or divs, simplifying it, right? But that HTML content can also be read by search engines or by readers that make that site accessible to people who are not going to consume the information visually but audibly or haptically through other means of consumption. Is there any element where, as an instructor, you make the whole process of structuring and marking up in HTML easier for people who are not necessarily familiar with the language?
Leifer: Sure, that’s a good question. Look, personally, I haven’t been working on a project that involves accessibility to a great extent, so I don’t have that experience to say, ‘Hey, we need to pay much more attention to this.’ But I try to go with the basics, right? If this is a link, let’s treat it as a link; if it’s a button, let’s treat it as a button, because visually they can look the same.
Some people might say they don’t like the link because it has an underline or something, but it has a semantic meaning. Also, regarding SEO, tags play a significant role; not everything has to be a ‘div.’ Some things maybe should be an ‘h1’ if the content is prepared for that. In the case of a dashboard, it makes little sense to use ‘h1’ or ‘h2.’ Since I don’t have experience with accessibility, I try to stick to the basics.
Essentially, we start with the fundamentals, and then if we need to go beyond that, we already have a foundation. Let’s make clickable things clickable, draggable things draggable. If this button is not accessible, in addition to making it disabled, put a ‘not allowed’ icon on it. I think that’s more logical. Think from the user’s perspective. If this doesn’t work but the button looks like it should, it will confuse the user. So just add an error there. That’s what I usually do. And if not, investigate, as everything is on the internet these days.
Alejandro: And what about teaching the HTML semantics? The meaning of each element and why to use it — for instance, why to use a ‘p’ tag instead of a ‘div’ tag — is the gateway to having an application that is resilient when processed by machines that analyze the content in a non-visual way. This is foundational; it’s literally the entrance to everything related to making the content accessible for other humans who may not perceive the content in the same way, as well as for machines to interpret the language we convey through Angular templates.
Now, I want to shift to CSS, a question I wanted to ask you. Style sheets have tended to evolve over the years through cumulative levels until level 3. Level 3 began to decouple the initial monolithic approach of features toward independent modules that continue to level up separately. For example, selectors level 4, media queries, box model level 4, all of that. There really won’t be a CSS4 based on what is stipulated by the W3C, the World Wide Web Consortium. Each of these modules will grow independently. How much of the new properties, styles, and selectors that appear as style sheets evolve do you decide to adopt in your courses when indirectly teaching CSS to your students?
Leifer: Another very good question. I don’t consider myself an expert in CSS. I’m very much in favor of using native features. If it can be done natively and time permits, let’s go native. However, in some cases, I try to keep up. How to put it — there are many new features that are not applied, at least in CSS, in the places where I’ve worked. They still use very basic things from the beginning. And today, those applications are still fully functional. When something new is applied, what I’ve noticed in people’s behavior is a sense of contrast. Like, ‘I went to my job and suggested we use this new feature, and they said no because it’s too new or the team doesn’t know it.’ So, then you’d have to train the team, and there’s no time for that now. We need to create products and so on. So, I try to apply what the market is showing. For instance, when Flexbox and Grid came along.
OK, yes, I noticed that pretty much everyone started using these for moving little boxes and tables up and down. That was something I adopted and continue to use today. However, newer selectors related to nesting, I haven’t used those up to this point. I haven’t found a situation where I’d say, “I have a need here that I can’t fulfill in any other way.” Will there be cases? I imagine so, that’s why these features were developed. But at this point, in what I’ve been working on, I haven’t reached that limitation where I’d say, “You have to learn this because it’s new and you can’t do the same thing without it.” I haven’t reached that point. I go more with what the market is saying, listening to the students a bit. I’ve seen that this is now being used. Can you produce some content on this? Sure, we can make a video, a blog, those kinds of things.
Alejandro: It’s interesting that you mention CSS Flexbox and CSS Grids, which came along almost at the same time as browser developers agreed on Evergreen Browsers that update dynamically in the background to offer users the ability to process the latest technology without breaking web pages, as used to happen with earlier versions of Internet Explorer. Now, as you’re saying, the limitation is self-imposed when deciding whether or not to adopt new features. You don’t necessarily have to go with the ‘fear of missing out’ or FOMO, trying to incorporate every new thing that appears. Whether you’re doing some sort of proof of concept, if there are projects, but CSS is already quite stable, it works. If you want to go a little further to maybe simplify what would have taken you 72 characters down to 30 with a new selector or something, it’s basically fluid how you can adopt those specific levels.
Alejandro: Jumping quickly into history. First, 1989, with the early versions of HTTP and HTML. Then, thanks to developers of more powerful web browsers, the capability to add separate visual features with CSS. I don’t know if you remember Mosaic, Netscape, and the first versions of Internet Explorer. I’ve only seen that through screenshots, as I wasn’t a user of those browsers. What I do remember is that almost simultaneously, in the mid or late 90s, came JavaScript, VBScript, and other languages processed by these early web browsers. Thanks to the work of several entities like ECMA with ECMAScript, Mozilla, Microsoft, Google, Apple, Opera, and many others, we now have a very solid ecosystem of Core Web Technologies. But that doesn’t mean we’re at a static point where nothing else evolves or changes. What path do you think, Leifer, these foundational web technologies will continue, considering we also have a whole ecosystem of native apps and other different platforms? Where do you see web development heading in the coming months or years?
Leifer: I think the focus will shift more towards performance. What’s available covers the needs of 99% of applications. If you have a very specific need, it’s probably because you should move towards something more native, like an actual application or executable. What’s designed for the web so far, I believe you can do everything and more. There must be browser API features we haven’t touched because we don’t have that particular use case. What I have seen is that most development communities, like Astro, Qwik, and even React, are aiming for performance. If browsers offer you the ability to run code in the background through web workers and service workers, it’s a new feature that ultimately translates to performance. It’s the same code you could execute in a runtime environment, but now we can divide it into different threads. The main focus is speed, and I think everything will point towards that. Unless all of a sudden, everything is augmented reality, and we have more input methods. For instance, glasses that can connect for a visual display. In that case, other functions would come into play for connectivity, but what we have now is more than enough. The focus will be on performance, accessibility, and maybe being very specific when developing views for certain devices. With the Internet of Things, smaller screens and devices have less processing power but more capabilities. The focus may be on those types of applications, but the functions are already there. It’s about how we’ll optimize them for these screens, these devices, and this browser header. I would bet on performance.
Alejandro: Why focus on performance specifically? How would you explain to someone who might not understand why Google puts so much emphasis on the DevTools tabs? Why focus on performance, auditing specifically, and how each specific JavaScript thread is monitored? And why not just browsers, but also the people creating code are so focused on optimizing resources to reduce the number of critical elements and minimize the critical rendering path? What’s the inherent reason for so much emphasis on performance?
Leifer: I think it’s the evolution of users. Ten years ago, maybe, one could easily wait 10 seconds or more for an application to load; it was what it was. But not today. Now it’s in seconds. It’s an instant. The same happens with social media, where you need to engage that person in the first second. All of that is moving to the web. You need to be 100 milliseconds faster than your competitor because that can make the difference between making a sale or not. It’s that simple. If your page is faster, it will appear first. If your page loads faster, there’s a higher likelihood the person won’t leave. If your page loads more quickly, you’ll sell more, especially when it’s a digital product.
Of course, there will be internal panels or products where the normal user doesn’t come into play, and what’s needed is stability and robustness. There, the focus would be more on security, stricter typing, and the framework being used. But commercially speaking, at the level where unicorns are created and people enter development, it’s about products that reach the end customer. And there, what’s prioritized is retention, which in turn translates to speed.
Alejandro: Very valid answer. I loved how you synthesized all of that. And Leifer, you’re one of the few people probably out there today who has not only used Quick for creating side projects or deploying it in production, but you’re also creating documentation and teaching people how to use this meta-framework. How do you see Angular in a couple of versions, let’s say, Angular 18 or 19, because 17 is just around the corner in less than a month, concerning the universe of frameworks and meta-frameworks coexisting today?
Leifer: Well, frameworks are like tools that serve the purpose they’re designed for. Imagine a supercar that can go very fast, but maybe it can’t go off-road. And maybe an off-road vehicle can’t go as fast, but it can go off-road. It’s basically the same analogy: if you want a very fast application, there are frameworks that are more designed for that. And if you want something robust, if you want something that can withstand, if you want something that is well-validated, there are other frameworks like Angular. For example, Angular on this side in Europe is being used a lot in corporate applications. We’re talking about insurance, banking, and companies that have been around for 20, 30, or more years. They won’t switch to another framework just because a new one appeared. They won’t do it. First, because that would imply a change in all their staff, and that’s very costly. Companies don’t like to spend money.
And on the other hand, they have such a broad ecosystem. For example, I worked in a bank where the typical NPM doesn’t work. You install your packages with NPM, but it’s not connecting to the NPM that everyone knows, but an internal NPM where there are internal packages developed by other hundreds of teams throughout the infrastructure or thousands of people who have created specific components for Angular in their version X for a project, which is a component shared among 200 applications. That’s not going to change overnight. They won’t do it, not even if Quick comes along, and it’s faster because they are tools that the end user doesn’t see, but that produce and involve a lot of money. So they are different things. I think that Angular is the king in that sector. There’s no one else competing with it, nor are the others looking to compete in that area.
In our case, we’re going to compete in the end-product area, for the customer, for fast loading, for loading on mobile phones that are on 2G and 3G, not in this section. This section is about robustness, dashboards, very robust applications that connect with hundreds of microservices. And there, typing, structure, and team knowledge that you can move, I think this is key, moving this team to that other one without having to go through another stage of training, of teaching. That’s a huge savings for companies.
Alejandro: So the learning curve remains minimal. Even when transitioning between Angular versions, we’re not in a dead ecosystem without evolution. Some elements from other meta-frameworks or specific things associated with hydration are being incorporated into new versions of Angular with new technical implementations of server-side rendering.
Leifer: Well, I have my opinions. I think Angular shouldn’t be positioned in some areas like SSR. There are other tools for SSR because you have to over-engineer in Angular to implement that functionality, which perhaps isn’t as utilized or appreciated. It’s a personal point of view. If someone tells me they want to make a blog, I’d say don’t do it in Angular. Angular wasn’t designed for making blogs. There are dozens of other frameworks that maybe started with the idea of making super-fast blogs.
I understand they have to innovate. You have to say, “we’re doing things.” But it’s also not like this is the highlight, the most outstanding feature of Angular that it does SSR. I’ve done SSR in Angular with Angular Universal at the time, and honestly, it’s crazy.
Alejandro: Now it’s much easier. In fact, my impression is that by just importing a library, the whole hydration process becomes a bit more transparent. My impression, Leifer, is that the Angular team, clearly identifying that Angular was mostly used for moderately complex applications, has wanted to encompass the rest of the applications that are extremely complex as well as very simple applications like a landing page or a blog.
For example, there are new tools like Analog, which Dany Walls and others have recently started to document in their technical articles and videos. This now allows Angular to be used for other use cases that are a bit more static by leveraging progressive hydration through the new SSR approach. The framework authors are learning how the market is moving and trying to make it so that companies don’t have to go and hire other types of resources or try to reduce the learning curve of their own team so that Angular continues to be used for other specific elements.
Leifer: Absolutely. Yes, it’s about listening to the market and adapting.
Alejandro: Do you have anything in mind to structure or launch by the end of the year regarding courses or documentation?
Leifer: I have a couple of things, but at least one in particular that I’m doing as a side project, more than a side project, a personal project with the aim to commercialize, learn marketing, all those kinds of things. It’s a SaaS that I’m doing with Qwik, and there are obviously many limitations in the sense that there are things that maybe I did in a minute before, but well, I’m working on it. It’s going well and that’s what I hope to finish this year.
Alejandro: I’ll be looking forward to the launch of the upcoming content to see how it goes and learn a bit more about them. And Leifer, before concluding the episode, is there anything we haven’t mentioned during the conversation that you’d like to comment on?
Leifer: Well, we covered a lot of topics. Nothing comes to mind right now. What I can say is that there are surely people who listened and will say “I was thinking about learning web programming, but after all I heard about the W3C and 1990s…” I think we’re in the best moment. This is the moment. There’s knowledge everywhere: you open your phone, and there’s knowledge, you open the browser, there’s knowledge. This is by far the most connected time in the world history. Now, everything is hyper-connected. You can get jobs anywhere in the world. This is the best time to start doing anything digital. Obviously, it’s not going to be quick, it’s not going to be easy, but this is the best time.
Alejandro: Indeed, it is challenging not because of lack of content but for one’s ability to filter what’s out there and try to find the optimal path for professional advancement. Well, Leifer, having you on this episode has been a pleasure. Hopefully, this will be the first of several conversations in the future, and good luck with all the projects you mentioned before the end of the year and early next year.
Leifer: Likewise. Thank you very much.
Alejandro: Hasta luego. ¡Cuídate mucho!
Leifer: ¡Hasta luego, chao!
Check out who is getting interviewed for future episode releases at https://twitter.com/angularidades.
