Luis Atencio: 0:00

So, you know, there there's, uh, best practices that you can put around it as a team, but in terms of what the language offers. You know, the malleability and the versatility of an object in JavaScript is something that I hadn't seen in any other.

Fernando Doglio: 0:29

You're listening to episode number seven of 20 minute JavaScript this episode, as all other episodes is hosted by open replay, an open-source session replay tool for front end developers. If you're looking for a way to understand how your users interact with your application, you might want to check out OpenReplay, I'm Fernando Doglio, your host and metaprogramming fan boy for the next 20 or so minutes. And today's topic is going to be exactly that meta programming. And to talk about that, we brought Louis Atencio developer, and author of "The Joy of JavaScript" a book published by Manning that covers this and many, many other topics. So, Louis welcome. Thank you for being here and please introduce yourself.

Luis Atencio: 1:10

Sure. Uh, so I live in Florida and I work at a company called Citrix, uh, which is a company also in Silicon valley. Um, and mainly I'm responsible for the, um, so the customer facing the front end, uh, of the company, um, not, uh, just so much in its marketing, but more of like the, the consoles that power, the services that we, or the products that we sell. Right. So to allow the. The administrators to configure their, let's say their gateways or their, their, uh, serverless, uh, instances and things like that. You know, any of the products related to Citrix, which is around virtualization and that kind of thought that kind of stuff. Um, so I'm mainly responsible for sort of architecting and leading the efforts surrounding the, uh, the front end development of the company.

Fernando Doglio: 2:00

All right. Perfect. And you also wrote a book called"The Joy of JavaScript", which we'll now be discussing that. Yep. And out of our book, uh, I wanted to talk about metaprogramming with you because that's a topic that is very interesting, at least to me. Um, I think it's a very fun as well, but could be, can be really complicated. So can you please let's start with the basics. Can you please, uh, tell our audience what metaprogramming is?

Luis Atencio: 2:28

Yeah, absolutely. So, so the idea of metaprogramming is, uh, at very high level is basically code about code. Right. Um, the idea of manipulating the code itself or manipulating the structure of the running program using code, right. Hence the Meta because it's code about code, right? Um, that's what at a high level what it is and, uh, JavaScript, uh, opens a lot of doors for that. So a lot of. Um, programming languages that we've used, maybe, you know, for a, at least for me, I've used a little bit of Go Java C#, you know, they all have their models for things called reflection, which is a form of metaprogramming but in those languages, things tend to be a little bit more, uh, close to the sense that for you to be able to inspect the structure of an object, you really have to go your way up, you know, work your way around the language. Right. Use specific API. Some of those APIs might be built in, they might not be built in, they tend to be built in. Uh, but again, you have to kind of be very specific about it. In JavaScript we tend to do it on a day-to-day basis and we don't realize it. Right. Um, so sort of things like, you know, uh, the mutable operation on an object to say, delete, delete, this key right. You know, right then and there, and just modify the structure of an object. Now that's not a big deal. For JavaScript, because we don't tend to, uh, consider objects as being a, uh, a template of some class. Right? So typically you're not allowed to do that in, in classes that are, uh, in objects, sorry, and programming languages that are class-based because then you'd be effectively destroying the structure from which the object was derived. Right. If you go delete a property of an object, the object derived from some class, let's say, person, person has first name, last name, you delete first name, basically that object did not come from the class person anymore. Right. So it's, it's, um, you know, it's unheard of what would you do? Something like that right now in JavaScript, uh, things don't derive from a class. Right. In fact, it's a, uh, it's not really a class-based language, even though we, you know, we, uh, a lot of people think it is right. It's just basically all sugarcoating. Um, but you know, we, we think with that, we tend to think of objects as just being just collections of properties. Right. Those properties can be. Of different values, strings functions. It can be anything, but, you know, down to it and the very basic level, it's just basically a collection of properties. So that means that you can really do anything you want. You can do a introspection, which is basically you could say, uh, Object dot keys and enumerate the entire structure of the object, just like that. Right. Um, and, uh, you know, you can do reflective, reflective operations, which is you can actually manipulate the structure of the object. You can say this, I want to remove that key. I wanna repurpose that property to be a function I want to do, you know, why would you do that? That's another question, but you could do that, right. It gives you all that opportunity. So that's the main difference. That's why JavaScript is so different than the other ones is because, um, we tend to do these things on a day-to-day basis. We don't have to go around using very specific, specific APIs to do so. Um, it's just kind of part of the, uh, you know, the evolve and that.

Fernando Doglio: 5:44

Absolutely. I tend to think of JavaScript as a, as a very malleable language because it lets you do that natively. Like you say, um, uh, while others are very restrictive, as you well put it, but would you say that JavaScript is, I mean, in scale, in scale from one to 10, would you say it's closer to to a 10 or is it a 10? Is it the most malleable language you worked with?

Luis Atencio: 6:08

Uh, definitely the one I worked with. Yeah, for sure. Absolutely. So. Um, we haven't even talked about intercession, which is like the, the other form of metaprogramming, which is like, you put something in between the caller and an object, uh, something like a proxy. Right. Um, but yeah, absolutely. So when, you know, when we think about an object, it's just being a free form object structure or anything that you can think of without really a kind of template where you derive and say, new of this from that, right. Then there's just opens the doors to anything, right. The object that runtime can become something that is completely different in identity than the one that I created initially. Right. Um, so, so I mean, there are obviously rules as to like, uh, you know, you, you probably don't want to do all these things in code. You can abuse this to, you know, very detrimental. Because then the code becomes, becomes really hard to parse and understand what it's doing, especially if you're troubleshooting a bug in production or something like that. Right. Um, so, you know, there there's, uh, best practices that you can put around it as a team, but in terms of what the language offers, it's, you know, the malleability and the versatility of an object in JavaScript is something that I hadn't. In any other way language.

Fernando Doglio: 7:23

Yeah. Have you, uh, worked with Ruby at all?

Luis Atencio: 7:25

I have not done ruby no, I had done Python. Uh, I've done very little Ruby in terms of like maybe writing some chef cookbooks and things like that, but not really rails. or anything Yes.

Fernando Doglio: 7:36

I found Ruby to be very, very, uh, prone to metaprogramming as well. Very interesting as well. Okay. You talked about, you said proxies, is that reflect, um, can you elaborate a bit more on what they are because, uh, even though they're not specifically new to the language, uh, they're not old as well, and, and not a lot of people use them because they're not really that common. So what are these, uh, these tools that we have, uh in Javascript?,

Luis Atencio: 8:05

Yeah, absolutely. Yeah, like you said, so they're definitely not new. They've been around for awhile. They, uh, the, uh, API for proxies tends to be more of a, a framework, the framework development tool. Right. It's really, uh, and, and the reason for that is because you want to be dealing with some. Abstraction layer that, uh, that, uh, for your own applications, you probably don't want to deal with, uh, debugging or, um, you want to, you, you don't want to deal with the, the internals of that, right. That's why it tends to be seen a lot in library development, uh, framework development. And the reason for that is because basically you're moving part of the behavior of not that you're moving it away from the object, right. You're saying I'm going to do, I'm going to do an intercession, which is I'm going to insert a proxy in between you and an object and the real object. Right? So if you were to be reading that code yourself, your, you know, your first thought would be, was, you know, there's an issue with that object. Let me look at the object itself right now, in this case, there's something sitting in between that might not might or might not be obvious that it's there. And so, uh, that's why, you know, I also in the book I say, you know, it's, it's, you have to be, you, you have to use it with caution and the purpose needs to be one of these like last resort kind of thing like that, where the, the readability of the code is actually enhanced by using a proxy or the, uh, the approachability of the code is actually enhanced by using the proxy where these things are very useful are when you use the proxy as a tool for simplifying your code. And what I mean by that is let's say that you have cross-cutting dependencies, like a logging or monitoring or observability it, things like. Typically you don't want to, you know, insert, uh, let's say that you're measuring the performance of some object. You don't want to insert performance counters all over the place because then your code gets bloated right? Those types of cross-functional behavior. Uh, I put in logging also a lot in that are really, you know, move, uh, you know, cross cutting in the sense that they're not part of the business logic of the object itself, but there are things that we need to do as a pro as a programmer, or as you know, in the practice that we, you know, Um, those things are easily, uh, uh, shifted to some other place, right. That at runtime can be there or might not be there, right? Because it, proxy is an object that you can, uh, you can apply or you can also, you know, unapply it, right. You can take it away. And so it's sensible for things that, you know, things that have that nature, where you can say, well, in development, I want to do these things, but in production, I don't, they lend themselves very well to that, to that API as well. Take these cross function, cross functional behaviors like logging and things like that. Move them away from the object keep the object simple. And so that, that, because that's mostly the business logic is what you're mostly looking at when you're terms of readability. And when you're trying to find a problem, it's in the business logic it's not going to be in the call to logging or in the, you know, sending out, uh, data for some kind of monitoring tool, right. Leave that in a proxy, make it really obvious. And I would use all kinds of JavaScript, documentation, and code, right? To say, look, this, this, uh, API is being spied on and is being observed by this proxy, right. To make that really, really clear, you know, those are really good users of, of a proxy. Right.

Fernando Doglio: 11:22

That's fair. Yeah. But if you don't, if you're not careful, it's like magic essentially, because you just, add behavior that, you're not, documenting you're, not telling anyone and things happen around you when you want to do something else. So the example that you said that sending, uh, like tracking data or even logging information, you could configure an object to just log their, their API usage, essentially for every method that that gets called. You could just keep it, keep logging what gets called, what information and what kind of, um, whatever data you want. Without the developer using your object, even knowing about it.

Luis Atencio: 12:01

Correct correct. And so, you know, there's a lot of things that you can do in code to make it as explicit as possible. I just, I just mentioned, you know, you know, uh, go to town with all the commenting, like do inline comments as much as possible to indicate, Hey, this property is being observed. Um, and this is the proxy. Another, another practice that I've done in my own code is to, uh, uh, use, uh, like a dollar sign. Uh, so you can name the variables to indicate that that's a proxy object. So you can say a variable name to describe what the object is and then dollar sign, what the proxy name is. Right. And then I see this, if you looked at it like. Stack traces from like a language like Java, whenever an object is proxied by, let's say a mocking framework or something like that. They typically tend to do that dollar sign, you know, to show that this is the class name of this and the class name of the proxy. Right. And so I kinda took that pattern from, you know, way back when I was doing a lot of Java development. And so in my object to actually have the variable name, to describe the object dollar sign, and then the proxy name. That's being used and that's what I use in the code. So it makes it clear that, Hey, this is a property. This is an object that's being observed by some other entity. Like the object has its own behavior and that's all great. But if there is some kind of side effect that's happening, every time you call a method on it, right. It's just makes it clear.

Fernando Doglio: 13:21

That's an interesting pattern. Yeah. Okay. And outside of proxies and, and reflect, uh, let's, let's touch reflect before moving on. So because we've covered proxies, uh, where w what kind of use cases you have for reflect, or what will you use it?

Luis Atencio: 13:39

Yeah. So reflect API, uh, It goes along really well with a proxy because, um, so you have two ways of, uh, invoking, um, like I said, JavaScript, you can do it in so many ways, right? Um, you have a way of invoking a property dynamically on an object by using named properties. Right? So if I know the name of a property or the name of a method, I can just have the variable name, bracket, the name of the operation, and just invoke it. Reflect, gives you a more, much more cleaner API and safer API to do that. Right. So when you observe, when you intercess an object through a proxy, you receive the hook, uh, in other words, the API call or the method call, then if you want to further delegate that to the original function call, which is very typical, right? You come in, you, you do something with that, and then you eventually delegate back to the original object. Then you use a reflect API to do that. So the reflect API allows you to invoke. You know, like it's reflection, right? You you, you, you modify the, or you enumerate the structure of the object and you can modify it. Right. So the reflect API lets you call or set a property on that original object that you, that you're dealing with in this case, it's called a target object.

Fernando Doglio: 14:51

Okay. Interesting. All right. So, uh, outside of that, where does the "eval" function stand? Is that, uh, kind of old, old magic, old way of doing metaprogramming in Javascript?

Luis Atencio: 15:04

Yeah. Uh, eval I think it was incredibly popular in the, what is it? Maybe the two thousands or something like that? Um, I could be wrong with a year, but it's something that definitely for quite a long time, it's been, it's been considered a, uh, an anti-pattern or a bad practice. Uh, for many reasons, one of them being obviously security, right? The ability to invoke a string of code, right. Opens the door for a lot of, you know, uh, cross-site scripting, injection attacks, you know, anything you can think of. Um, in fact, a lot of linting tools already, and maybe even the transpilers. And I think even if you use IES modules that, um, in-district mode right. That they're not allowing any of these things to happen. To move the needle forward and eventually, you know, eventually go to its deprecation. Right. Um, but in, in that time, right. Uh, it wasn't modern love introspection. Right. So I actually, in the book compared, uh, that use of, of, or that type of API to something like a homo-iconic language like Lisp, where you could actually invoke the code within the code, right? This is kind of like that, right. You know, it opened the door for you to say, you know, I can take a function, object, change its representation into a string by using, let's say something like function dot prototype dot to string, take the string representation of a function and then just use it in an eval. I started calling that right. Uh, in other words, it, it allowed me to take the representation of the code as text. And then invoke it back as code, right. In that sense, homo-iconic. Right. And so, you know, uh, obviously it was a, it was one of the first encounters for a JavaScript programmer into this idea of like reflective programming, but it's something that we largely now, you know, there are no use cases for, right. There's absolutely no use for it before we used to do it a lot and framework development. Now we have better ways to get around all these problems.

Fernando Doglio: 16:53

It's crazy that it's still hasn't been deprecated, right?

Luis Atencio: 16:57

It hasn't been right. Yeah. I I'm imagining there's a lot of still leftover tools that people still use, uh, and packages that rely on, on eval. But I mean, mostly, um, nowadays a lot of websites, but they're, uh, you know, they're instructed by their security teams and companies to put their CSP policy, right. The CSP policies that says unsafe eval is you know, put that in there or, uh, or, sorry, you're not put in there. So you don't allow unsafe eval so of have blocked out of the browser though. Certainly we do it. So, you know, it's, it's already part of our mandatory security guidelines. Like we're not even allowed to use. Yeah.

Fernando Doglio: 17:36

Yeah. I remember the days where you would just get the input from the user and just throw into eval because you know, why not?

Luis Atencio: 17:44

Throw that into the database too?

Fernando Doglio: 17:48

We learned the lesson. All right. So you mentioned that a use case for my programming already. So let's move forward. Would you say that the program is for everyone? Uh, do you think there, and I think that I know what you're going to say about. Is there, too much, uh, or too far gone into metaprogramming where you say, well, this is just, you know, there's no way to, to get out of here. We just need to remove everything.

Luis Atencio: 18:15

Yeah, yeah, no, I, I think that just like with everything right now, There's definitely overdoing it, um, meta programming is something like I said, you have to have a very specific purpose and where, where you could actually say that consistency becomes really important. If you do it, if you do logging any certain way of objects and you use Mehta programming with a proxy, then do it everywhere. Right. You know, keep that consistent so that your, you know, your team, the developers that you're working with, who are the ones reading your code, those are the ones that suffer from this. But if you're consistent about it and you make a team position, then it's clear that it doesn't cause harm that actually. Removing all that duplicated code allows you to have better code coverage. When you do have your unit tests and allows you to have automatic code injection in the sense that you proxies taking over a lot of the responsibilities that you would have otherwise had to hard-code yourself. So it becomes a, it becomes a benefit rather than a harm, but if you're just going crazy with, uh, proxying and everything, you know, you're proxying all your objects, or you're trying to get really fancy. And let's say, mutating, your objects at runtime. And you're overdoing it. That's, you know, for example us, we, we don't have a delete statement anywhere. Right. If I see at the least statement and a pull request, I'm like, do you actually need to delete that key? Right. Is there any good, valid reason why that key can't be there because you can always have additional data in your JSON or your object payload that doesn't hurt anybody. Right. Is there any good reason why you want to do that? Because if I ever, or anybody else ever needs to access that key, assuming that they look at the optic structure and say, oh, that property is part of that object. Why is it not available? What is it, why is it undefined somewhere else? Right. That has to be a really good reason for doing that. And like I said, you know, you really have to have a valid purpose for it. I think something that's going to change this game when it comes into JavaScript or decorators, decorators, or something that, that they are eventually going to land in the language TypeScript uses it all over the place. Uh, Java programming uses it all over the place. There are a way of a way of doing this as well. You know, decorators are kind of like meta programming in the sense that you can, uh, write, uh, decorator handles and, you know, modify the behavior of your code depending on what those decorators do. But again, they're explicit, right? You see the decorated label, you see that there's something is there that there's, you know, there's some kind of side effect happening somewhere else. Um, and they're explicit. So that, that might change the game. I know, like if you do angular development, you've kind of are using that three or four or five, seven decorators on a single class. So there's a lot of, there's a lot of magic happening there. Right. But again, if it's, if it's properly abstracted and very made really clear that it doesn't do any harm right. To me, my concern is. Developers changing the structure of the object and rewriting keys to mean something else. And abusing that that's, that's where it gets. That's where it gets problematic,

Fernando Doglio: 21:08

Right, adding extra functionality or simplifying it a for others. That will be, yeah. Okay. All right. Perfect. Thank you. All right. So tell us a little bit about your book, "The Joy of JavaScript". Uh it's uh, it's definitely an interesting title to say the least. I love JavaScript I'm with you. Uh, but I know a lot of people hate it. So, um, is, is the book for them? Is that meant for them?

Luis Atencio: 21:37

Yeah. So, um, so the, the title has multiple purposes. Um, I, uh, uh, a good colleague of mine, uh, uh, refers to, to your point, refers to JavaScript the Frankenstein language. Right. Um, and, uh, you know, sadly, you know, they're kind of, right, right. Um, you know, it's, if we look at the origins, you know, that there are some drawbacks of having a language that was done in, in 10 days, right. In the sense that, you know, not all things were maybe, uh, properly, um, you know, uh, studied or maybe had enough time to, to sort of sink in right in 10 days, certainly enough. And then, you know, how much review process can you have in 10 days? You know? And, and so, uh, it was, uh, it was good about right in the sense that, uh, we did get a lot of really cool things from just being a uh, a language that was inspired, uh, from things like Self and the prototype model and Scheme in the first, in the higher order functions. But then we all, we had all these, uh, uh, others behavior that should have been sort of more restricted or limited. And they weren't. Right. Uh, we had some keywords like, uh, with things like that, that died, you know, with time, but caused a lot of problems along the way. And, uh, the, you know, the fact that we didn't have a really good package manager model from the beginning, from the browser. That was an issue. Um, uh, I did like the departure from not having to use classes. Right. Even though it was made to be a marketing, a marketing term based on the popular popularity of Java at the time. Right. We didn't get classes from being, and that was really good. And yeah. Even introducing them later on, it was a mistake, but yeah. Um, I think we've learned the lesson from that and, and, uh, um, uh, and now, you know, things like react, it's all functions and hooks everywhere. Right. It's not classes anymore. And so we're, we're, you know, we're slowly phasing that out, I think. Um, but, um, so one of the purposes was to say, you know what, now it's different. Forget about your days of, um, your jQuery development and things like that. It's completely has changed the game. And now you're sort of, uh, your, your tool set has to be very sophisticated as well. The, what the tool set for JavaScript is very sophisticated. I can't remember the day where I wrote a JavaScript blind without going through a transplant. Right. It's just like so far. Um, and if you have proper linters and transpilers on the way ready, JavaScript is not what it was before. Right now, we have sort of the sophistication of almost having a compiler help us out. And if you use sort of the modern JavaScript, idioms and things like that, Then the days of that Frankenstein language or, you know, out the window. Right. Uh, so the first purpose is to say, look, this is a different language now, right? It actually is a joy to, to code with. Um, your setup is basically you say, you know, we're went out to the, uh, to the very, just, you know, say NPM install and you have a project ready to go, right. If you have the proper packages. So even getting up and started with it as quick now. And so, uh, so now it's a joy, you know, revisit it, it's worth it. And by the way, here are the amazing paradigms that you can come to life when you use it. And that's what the book is about. That's why I've touched on functional programming class or, you know, Object Oriented Programming. Why not to use classes and just focus on the, sort of the, the, the strong suit of the language, which is your higher order functions and your closure. And that's what if you just focus on that? And I, in fact, I think I'm remembering a talk with, um, Douglas Crockford that says, you know, he, he loves sort of, you, you stick to the minimal, the minimal artifacts that JavaScript gives you. It's a really nice and clean language. In fact, his, uh, his latest book, I believe it's called the, how JavaScript works or something like. If you look at all the code that he, that he writes, he basically uses the one, two or three features of JavaScript language. And that's it. Yeah. He doesn't use all the 30 other keywords that the language has.. Right. Uh, he's a very minimalist, you know, very minimal kernel of language kind of guy, you know, and that's what the book is about. If you look, you have all these API that you can use, and here's why you use them, that you stick to the strong suit of language, which is functions closures, then that's, you know, that's where you would start to have fun with it. Right. And then the other title is a play on a, um, I guess you can say it is a marketing thing, is it play on the, the publisher? Uh, so the publisher, which in this case is Manning, they have a book series called Joy Kotlin and things like that, where it tends to be a focus on the functional programming aspects of the language. And so I definitely wanted to bring that part of the title into JavaScript as well, because you can absolutely do functional programming with JavaScript. And when you do, again, focusing on functions, and closures, right. And away from classes. And this, then that's when you start to have fun with the language. So it's kind of like a two-part title.

Fernando Doglio: 26:31

Interesting. Interesting. All right. Cool. Uh, thank you. We're going to also have, um, a discount code for our listeners, uh, on the show notes for your book. So check it out. Uh, and all right, so we're, we're done with the metaprogramming questions. Uh, I just have three more questions that we ask all guests. Um, so tell me, um, what is the best advice that you ever had? Luis Atencio: In Yeah, ideally. Luis Atencio: This field. Yup. Uh, one, um, when I was starting my career, um, I was fortunate enough to have one is really good managers and another one, a really good mentor. And one of the things he told me that I've applied throughout my entire career. Uh, so I've been already programming for over 15 years. Um, one thing that he told me in this is just starting off. He says, find what you like. And then pursue that. And when you're there open your elbows out and make your own space for it. Okay. I'm here open your elbows out, you know, own it. Right. Um, and you know that that's just in wherever I, I speak to somebody, I always tell them the exact same thing. That's the best advice I can give them. Uh, my friends, my family. Anybody. I always told them the same, find something you like when you're there, open your elbows out and say, I'm here, I'm going to own this. I'm going to take advantage of it and try to be the best you can be. Right. Uh, this applies to things like if you see a good opportunity of a project coming down the road at the company you work for, you know, get ahead of it, right. Start to engage your manager and say, look, that's I see myself as a really good candidate for that project. I think I can. All these X, Y, and Z benefits to the company that way. And again, get in there, open your elbows out and make sure you're included in there as much as possible. You know, there, there would be many, uh, opportunities where it doesn't happen, where you try to open your elbows, but you're, you know, you, you can't because there's a lot of, you know, the other business pressures or maybe there are other candidates consider it, or whatever the case may be, or maybe it's something that. Not the right time. Right. But whenever you can just pursue it, you know, it's something that you like pursue it, get in there and own it. Like. Nice. Get a advice. If you can. Can you share with us, what's the most exciting project you've worked on?

Luis Atencio: 28:59

Yeah, absolutely. So you actually come in at a really good time. So. So what what's happening nowadays is, or I've seen it as well. And, uh, with big companies is that the, uh, the front end development is becoming harder and harder. Right? So in the initial days of like the web one, which, you know, you have a server-side page, a HTML, very, very light interactions, right. Mostly server driven, right. We will be coming to the web web two, and we say, you know, now we need a lot of interaction. And by the way, round trips to the server are slow. So we, uh, you know, we create single page apps, right? These single page apps now are growing to the, you know, millions and millions of lines of code. And now we're reevaluating that. And so for a few years has been the trend to now do the. The micro apps. Right? So the micro front end. So it was just say we want a single page app, but we don't want it to be so difficult. Right. Can we, you know, have all the, can we have the entire application live in the browser? Just not be a single code base that just gets unmaintainable and unwieldy, you know, with years. Right. And so lately I've been, uh, working with micro-frontends and, uh, also sort of leading the team and the product that I'm part of to use micro front end type architectures for, to simplify the admin consoles and the dashboards and the visualization diagrams that our customers deal with. And it's been really exciting because, uh, we're in the second phase of, so we've implemented a micro end architecture that was all based on what they call the, the light DOM which is like the, all the components are in the same HTML DOM, right. Or HTML page coexisting. What you want is in the spirit of the microservices is to have your micro front ends be isolated, right. And something like, let's say a CSS class from one micro front end not conflict or change or alter the behavior of another micro front end and so I'm exploring right now. A lot of the shadow DOM APIs, and then, you know, sort of these things that are more on the cutting edge and there's some limitations still faced with that. And I'm trying to be around all these things, but it's been super exciting. And so, uh, we're getting to the point where all of the micro front ends that are stitched to the page are their own completely isolated shadow Dom components. Right. Um, and just having that laid out and working it's, you know, gives you a sense of satisfaction because there's a lot of little loop holes that, that we still need to jump through. Uh, specifically how you inject the CSS inside that let's say that you have global CSS and the entire company uses well, how do you inject that and make it part of each little micro component? Right? Uh, so it's been really, it's really fun. Uh, I encourage anybody that is doing, uh, you know, that, that are thinking about this problem where, Hey, we have a gigantic monolithic UI start to see if you can componentize and start splitting it into. More manageable components and then just draw a boundary around them. Right. So that, you know, that it changed to one will not alter or change for another one right now it gives you that sense, that peace of mind also. And so what we also did was make sure all these micro front ends were their own repo with their own CI/CD pipeline. Right? So effectively now we had a single page app that was, you know, I'm going to just simplify it and say 800 lines of code right now. It's eight micro apps that micro front ends over 100 lines of code. And so if I released the micro fronted, a, the blast radius of the change is only one eighth of the app. So it gives us a lot of confidence to release, to say, I know I'm not going to be altering anything else inadvertently, because I don't even have access to it. Right. Even if I want it to, I can't access it. So we're trying to get into the mentality. Where can we release more often? Because we have much smaller projects now to release that. They're not talking to each other. Um, you know, only, maybe through a loosely coupled events or something like that. But other than that, they're not talking directly to each other. So it's been exciting.

Fernando Doglio: 32:54

No, it definitely sounds very, very interesting. I played around with the, uh, shadow Dom, uh, for an article I wrote recently. Uh, and it's definitely, definitely interesting, uh, and fun to play with, so I get what you mean.

Luis Atencio: 33:08

That could be a good topic of a future or "20 Min JS".

Fernando Doglio: 33:11

Yeah. All right. Last question. Um, what is one thing that you wish you knew before you get started? You got started coding.

Luis Atencio: 33:21

Man, that's a really good one. Uh, one thing I wish I knew. Yeah, absolutely. So, um, uh, I got into design patterns late after a lot of years of coding and possibly even making a ton of mistakes and confusing the heck out of my teammates. I then learned that they hey, there is there's these blueprints like that can make what I, what I'm doing. If I'm traversing through a tree or something like that. There's a, actually a good way of doing that. That makes it really clear for everybody else because the design pattern is basically a communication mechanism between your teams. Um, I wish I had, you know, once I learned, once I learned a little bit of coding, I wish I had got into hey industry, by the way, there are these design patterns and this is what you should be following. Um, had I done that from the beginning? I think I would have made for much cleaner, much better. You know, what much more professional. Uh, code. So that's one thing that I, I, I wish I, I wish definitely I had, uh, some, even some indication as to when, when, you know, when I started these things existed, but you know, these are not things you're going to school, and these are not things that you tend to be part of, any core curriculum for anything, the things you stumble upon right down the road. And, uh, for me, you know, I wish I'd, I wish I would've had, I would've stumbled upon that, you know, a little bit earlier. Right. It would've made things easier. That's the one thing I can think of right now. Huh?

Fernando Doglio: 34:45

Absolutely. Yeah. It's a great also thing to, to, to recommend to new developers, to look into. I, I went through the same thing that you, I did a lot of code without thinking about patterns at the beginning. And then when, you know what they started clicking on me and, you know, I started reading about them uh, I, you know, kind of looked back at the code. I had written and he was like, yeah, I don't, I don't want to do that anymore.

Luis Atencio: 35:12

You know, I just remembered another one. Fernando has, since now that you've been functional programming is another one that I, that I learned much later, even on design patterns. And when I learned about that, and I think it's maybe, you know, when I did a functional programming book back in 2016, uh, some years before that, when I, when I saw that, it just kind of like, my mind just went completely. It was completely blown so much. So I thought. Man. I think this for JavaScript is the way of doing Javascript. That's why I had decided to write that first book back in 2016, the functional programming book had. I learned that I think from way the beginning, I think also, you know, I think the code that I've written, you know, that I wrote the application that I've done, that they probably could have been done much simpler, much, uh, less bug prone and error prone and things like that. How did I learn about that? And sort of used the techniques and the principles behind that paradigm. Early on in my career. So that's actually a, I feel I regret not, you know, because I, I think I remember hearing the terms, it's just, you know, you're, you're so caught up in things like, you know, you're learning so many things because you're starting your new job, that, and then, you know, most companies are still around the Object Oriented Patterns, and then you'll be all down that road. You never looked at. And I regret that. Right. I wish I had known better and I wish that I had, uh, stuck to that, you know, you know, like what, what is that thing about? Maybe that could be something that I can use. Um, we should have known about that sooner.

Fernando Doglio: 36:45

Yeah, I agree. All right. That's all the time we have. Thank you again. Uh, Luis for joining,. Uh, can you please repeat where people can find you and then if you had any, anything else other than the book to plug, this is your time.

Luis Atencio: 36:59

Absolutely. Thanks. Thanks, Fernando. And thanks for the, uh, for the invitation. I'm really, really grateful for it. Um, yeah. So for, um, technical questions and things like that, uh, readers, right. You know, uh, readers, uh, use Twitter a lot. They get me through a food Twitter, and I'd love to answer any questions, any doubts about the book, any, or just any JavaScript questions or programming questions in general. So you can reach me in Twitter. Uh, my, my hashtag is @luijar. And just like that. Uh, if you have any questions, let me know about the book about anything in programming and I'll be happy to, uh, you know, have a friendly discussion about it, for sure.

Fernando Doglio: 37:37

Awesome. Alright. That's it. Thank you again so much for coming in and educating us about metaprogramming.

Luis Atencio: 37:46

Appreciate it. Thank you Fernando.

Fernando Doglio: 37:48

All right. That's it. See you on the next one.