Video details

Challenges in Building Micro Front Ends| Vishal Kumar | Reliable Web Summit 2021

Microfrontends
05.02.2022
English

Micro Front Ends come with complex architecture and many hurdles to implement. In this talk, I share my learnings and architecture patterns I developed in building micro front ends at different organizations. When to use micro front end patterns and what level of isolation to implement. How to share js and css payloads elegantly and allow for interaction between such isolated components. I will also delve into practical considerations for keeping the complex application performant and solve issues around compilation and build pipelines.
ng-conf is a three-day Angular conference focused on delivering the highest quality training in the Angular JavaScript framework. 1500+ developers from across the globe converge on Salt Lake City, UT every year to attend talks and workshops by the Angular team and community experts.
Join the Angular Community: http://www.ng-conf.org/ Get your ng-conf tickets: https://ti.to/ng-conf Follow Us: https://twitter.com/ngconf Learn More: https://ng-conf-school.teachable
Read More: https://medium.com/ngconf
Hear More: http://theangularshow.com
Follow us on twitter https://twitter.com/ngconf Official Website: https://www.ng-conf.org/

Transcript

Hi, everyone. My name is Alvaro. I'm a senior software engineer at Southwest, part of Cisco. And today, basically, we're going to talk about the future of JavaScript. First things first. Thank you so much for choosing my talk. And we have a lot of content to cover in just 50 minutes. So we're going to go straight to it. Okay. Basically, what we are going to do today is that we will go together through some of the proposals that will be part of the next ECMAScript release that is scheduled for July. That is Ecmasc 13th. And then we will spend around half an hour going through some of the most interesting proposals that are out there, basically the ones that the community has been requesting the most and what problems they solve and basically how JavaScript will look like in the upcoming years. First things first. Why should you care about the future? Right. And why don't we focus on the present? Well, for a couple of reasons. The first one is that this might be one of the key factors which you see between, for example, adding a new dependency to your project, like a new library, or going with something that will be supported natively by JavaScript in the near future. Right. And the other reason why you might be interested is because some of the proposals that we're going to see here today are already available. I mean, they are not supported by the browsers yet, but as long as there is a bubble plugging or a polyfill or a transposer that you can at least start paying with them. Okay, cool. So if we want to talk about the future of JavaScript, then basically we need to rewind a little bit before so we can understand where we are right now. So let's rewind back to 95. This man here, his name is Brendan Ike. He's the one who created JavaScript when he was working on Netscape. Basically, someone came to him and we need to create a new standard of web development and programming language. And then he said, okay, give me ten days. And then in ten days he came with last script. He wanted to call it Mocha at first, but the problem is that it was trademarked. So then internally they called it Lastscript. But then when it was released with Netscape Navigator 2.0, that is basically a browser that Netscape had back in the years, then they decided to call it Boom JavaScript. And the idea for this was basically that Java was trendy. And then it was like, okay, the marketing team came and said, hey, if we call it JavaScript, there is a lot of Java developers out there. So if we call it Java, it's like it's going to attract some people. Java script, lightweight Java, boom. We are going to nail it. Right? And so they decided to go with it. And they were super proud of what they did. So they decided to level it up. So they decided to create a standard out of it. No. So Netscape, what they did is that they went to ECMA. That is an organization that takes care of creating standards. And then they say, hey, we want JavaScript to grow organically. We want to have a big community, we want to expand, to have more features, to have the syntax. So we need a standard out of this. Can you help us? And through JavaScript. And then created a committee, a group of people called the TC 39. And they were the ones in charge of creating a standard out of JavaScript. And then they started working on it. And in 1997, in June, they came up with the ECMA 262. That is basically one of the many standards that ECMA has that contains the definition of ECMAScript. And what is ECMAScript is nothing else. That the document that I mentioned before that covers basically the syntax, the API, the spectators of the language. And then in June 1997, they created Eggmascript. And then this was a big moment for JavaScript, because at this point, before, what we had is that ECMAScript was created based on JavaScript by the TC 39. But from now on, JavaScript is no longer its own programming language, is now an implementation of ECMAScript. What does this mean? That if Eggman script changes, if you change what is in this document, then JavaScript needs to support it. Okay, so basically, you might be wondering, Alvaro, why are you telling me this after four minutes of the talk? Well, because when we talk about the future of JavaScript, what we are talking about is about the future of ECMAScript and the different proposals out there planning to change what is in this document. Okay. Then the question that might come up is, okay, average, how do we change ECMAScript? Like who can change ECMAScript? How does this work? Well, there is basically a process composed by five different stages that they go from zero to four because we're engineers. So this is how it works. And then the way it works is that, let's say you have an idea, you want to change something, then you need to find someone in TC 39 that is willing to introduce your idea to the committee. Right? They have a meeting every two months. And then basically, this is where they introduce new proposals, et cetera. And then once that person in the TC 39 introduces the idea to the committee, two things can happen. It could either be rejected, it's not worth spending time on this. This is not a problem. And then it would go to withdrawn. Or the other thing that could happen is that TC 39 agrees that this is worth spending some time on it. So let's start working on it. Stage one. That is when we start thinking of the solution for the problem. Right? You have a problem. And now we need to find the right solution for the problem in the sense of like we can extend a class, we can change the class, we can change prototype, we can introduce a new operator. There are so many things that you can do. So this is about finding the right one. And once everyone is on the same page and we know what we want to work on, then we go to stage, we go to stage two. And in stage two what we do is getting our hands dirty. And this is when now we start designing the solution. This is where we talk about the syntax, the API, the methods, what the solution will contain and nothing else. Right? So once everything is written down and everyone agrees on that this is what it will be included in ECMAScript, then we are ready for stage three. Stage three is like, okay, there's nothing else to write. Everything is already done. Now what we're waiting for is for developers to implement what we have written down here and they will come up with feedback, right? They come back and say like hey, for example someone in people from Mozilla, people from Google, they will try to implement these changes in V eight, Spider monkey's, right. And then this cannot be done at first because the way we implement private properties, blah, right. And then they will iterate over this. And as soon as all the developers give some of the developers give the green light the thumbs up, then boom, we are in stage four. And stage four. What it means is that Congrats, the proposal will be part of the next Ecmasc version that is released every year in July. Right. So for example now we're in May. So there's one that's going to come in just a couple of months. And what we are going to do now so that you can get used to a little bit with how the proposals look like is that we are going to dive into some proposals. Okay. So let's take a quick look. So first things first, for anyone who is interested, the TC 39 has a repo in GitHub that is the proposals repo. And this repo, basically what it does is that it shows the stage of each one of the proposals there and their ongoing development. So you can see how we have them here in stage three. But for now we are going to focus on some of the ones that will be part of the next Egg Masculine 13. Basically these are the ones in finished proposals. Let's take a look at some of them. So you can see you might be familiar with some of these ones. We have been using them for a long time now. Includes object values, object entries. These are already like the basics of JavaScript, right. These are not new anymore. So if we scroll down then you will see how everything that has the column, the last column is 2022. Then this means that it will be part of the Eggmaster team. So because we only have 15 minutes, of course we can't go through all of them. And there is more interesting stuff that we need to talk about. But let's take a look at this as some of the most curious ones, the ones that are not that easy to understand. And then if you have any questions about any others, please let me know and then we can talk about them at the end of the session. Then let's start, for example, with something that has been introduced in JavaScript. And these are private properties for people who develop with Java, this might be like super basic, but for us, we didn't have JavaScript, we didn't have private property supported by classes. Right. What a shame. As of today, I'm showing you here right now, like the workaround that our JavaScript developers have to deal with, that is basically the creation. What you do is that and just to confirm, can you see properly the screen? All good. Okay. Awesome. What we have here right now, it's a map. Okay. It's a weak map that basically is like a map. But the keys are objects and the values will be removed by the garbage collector if the reference to the object disappears. For example, what did you say? Let's say that I have this person. Right. And then one of the keys of this map is this person. If I remove this key, if I remove this person in runtime, then the garbage collector will say, hey, because there is no longer a reference to this object, I'm going to remove the key and the value. I no longer need them. Right. So now that we have this map, then when constructing the class person that has a name and ID, and we want it to be private, then rather than define a property that you would do like normally or any other languages, then what you do is that you set this, you hide this private property in the map and then you can always get basically what you're saying is like, okay, this instance of person will have this ID. And then you can always get the ID by ID map. But get this right. Similar to how a map works. Well, just so you know, what I'm going to do is that I have here running an extension, it's called Waka. That basically whenever you see these comments followed by the question Mark, what you see on the right side is basically the result of that line of code. Okay. So for example, here you can see how in fact, we are not exposing the ID, we are not exposing the name. And when getting the ID, we get the spected ID. That is 27. But yeah, this is a workaround. This is a shame for us. We shouldn't do this. So let's take a look at how we can change that now with the additions of private properties. It's as easy as boom. Congrats, you have your first private property in JavaScript. Basically everything that all the private properties are defined with the hash at the beginning. And then by doing this you can assist it as doing the Hashid, you can just access to the property. Notice how you no longer need any weird weak maps? And then there are a few caveats that we are going to cover. But for now, if I save and I refresh, you can see how the gate ID is still working, right? For example, you can define private getters. You can do something like this would be the private getter of ID. And as I said, there are a few caveats of this implementation as of today. And that is that for example, right now we have the class person. Right? Let's say that you want to create a class that extensive person like you're in a DevOps. We're in DevOps or developers. Right. As you can see here, I'm trying to access to this private property in a class that extends person. The problem when I save is that you will see how the private field cannot be accessed from classes that extend it cannot be accessed from other classes. That is not the class that defines the property. Right. Basically what this means is that this unfortunately is not valid. You will have to have some sort of get there. But what you can do is that you can access to private properties of the same instance of the same class. Right. When running methods inside the class. Now let me explain what I mean by this. So for example, let's say that we have equals and basically we have a person. We want to check if it's equals to another person. Then first things first, this will be this has ID and this person that is an instance of the class person. Then you can access to the private property of that instance even when it's received as a parameter. You can always access to the Hashid. Right. And the reason why you can do this is because you are inside the class person. The method is running inside the context of the class person. And this is pretty much how it works. I can do a quick example here. If I do another speaker and then we'll call him Cesar or why not? And then let's keep the ID the same. Then if I do another speaker equals the speaker, then if I'm not lying a lot. Yeah, this is true because they are the same ID. If not, this is false because they are not the same ID. Okay, cool. In addition, another thing that they have added is static properties like you can now define static type, for example. Right. Which is something that we also didn't have before. So something to keep in mind. And yeah, this is coming to Ecmasc. I think it's already supported by pretty much all the browsers out there. But it won't be part of the standard until July. This is one of the things that has been introduced. The other thing might be a little bit more controversial to say in a way. Basically, I'm pretty sure you're familiar if you have Word with JavaScript, there is this keyword that is called wait. This is a keyword that you use when you're running inside as in function like get developers know. And if this is for example an API call to an API, right? You can always do constraints equals a wait and then you do a fetch and then return results. What this means is that the JavaScript will stop here until the promise is fulfilled before continue running the code. It will wait. Otherwise, if you don't have this, then what it will do is that results will be the promise of that request. Right? So this is something that as of today you can only do in nothing functions, but that's no longer the case. You can also do it, for example in the top level module. Top level module. Let's see an example. I think maybe to understand what's going on here. So for example, let me show you a quick project that what it is is nothing else. Then it's an app that basically shows high DevOps or Ola DevOps in the language that is configured in the Navigator. Let me actually quickly run it and then I can show you how this works. If I do NPM run, this is nothing else at a big project and if I do pound you can say Hi DevOps. Okay. And this is because I have the programming language, I actually have the language in English. Then what we are doing basically is that we are importing all the labels and then we are in real time checking which labels of we want. So for example, let's take a look at one of them. So you know how it looks. It's basically key hello and then the value is the name, the label translated. Let's go back, where am I? Here we are. And then what I'm doing is I'm importing all of them and then I'm deciding which one runtime by using Windows Navigate language and then based on that I choose one and then I use access to the hello key pretty straightforward. There is a problem with this one right now. The cool thing about this project is that we're only supporting two languages, right? Each one has only one key value. So it's quite light in terms of what we are doing here at the end of the day is that if you see it like we are Loading in memory all of them and then we access to the one we want. But let's say that rather than two, then we have like 20 or 30 languages and then each phone has like 2000 keys with 2000 values, right? Then it starts getting a little bit like in terms of memory like maybe this is not what you want to do. Right. Because at the end of the day you're using one. Right. So maybe not the right option. So now you can use a weight. The keyword that I mentioned before to cover this case and the way it works is that as I said before, it was only available in a sync method. But now you can do something like, okay, I want the labels basically to be the result of this import and this is going to be the Windows Navigator language. Gs. No, it's the convention. So you can see it better. Right now it will wait until, until the import promise is fulfilled before continue writing the code. But now I can get rid of this and then I can just do labels default and hello, right. And then what will happen here is that before I was Loading to a memory, I was Loading the Spanish one and the English one. Now based on the runtime value of Window Navigator language, I only import one of them. And just for the sake of like is this really working? Are you just like lying to us? If I go to languages and then I change the language and then I go to Spanish, that is my original language, then I refresh all of the books. Right. As I said in Runtime. Cool. Let me move it back to English and then this is something that has been there's a lot of discussion going on. In fact it's quite interesting when I was working on Detector because there's a lot of drama in a lot of these repos in the sense of like is this the right? Because this can create bad patterns in the sense of like you need to wait until all the promises have been fulfilled before you actually render the website. Right. So this can create really slow performance. So it's something that has some use cases, like the one I show you or for example when trying to fetch from different CDNS, no one of them fails and you try for another one, then it has different use cases. Right. But it's definitely something that you might not want to abuse off. Right, okay, cool. These are some of the proposals. There are more out there for ECMAScript 13. But let's do something. Let's set this aside. And what we're going to do now is that as I promised, we're going to spend around 30 minutes looking at some of the most interesting proposals. Basically these are the ones that we are going to cover, are some of the ones that has been requested the most by the community and will solve some of the pain points that we have right now as a community when working with JavaScript. So there's this website for anyone that is interested. It's called Proposals. I think that I'm not sure if maybe you can see it better this way. That basically is UI friendly way of seeing the state of all the proposals is not updated, but close enough. So let's go for example to some of the ones in stage three that are basically the ones that will come sooner rather than later. So the first one we're going to focus is temporal. Right. And this one comes here to solve a problem that I'm pretty sure like a lot of people who work with JavaScript had already. And that is working with this class that no one likes called date. If you ever had to work with date, then that might be a little bit like problematic. Right. Because it has a lot of problems. It's mutable, it doesn't support time zones. It only supports UTC and the time zone where you are running the code, right? Yeah. The parcel is not reliable. Or you can even set the month and then you set the same month again, it will give you a different month. It's crazy, right. So we don't do date right here. So then that's why libraries like moment looks on. Came trying to help a little bit with this problem. And now the committee decided that maybe it's time to have a solution that is supported natively in JavaScript. And this is where temporal comes to help. So I'm going to show you really quick like how temporal looks like. So for that I'm going to go, I have another project here that is here we go. And this is what I said before that basically we have polyfills that can help us like basically start playing with proposals. This is right now not supported by any of the browsers. And the main reason is just that it's broad right now that everything is ready in terms of the proposal itself, it's ready to move to stage four. But they are working right now. An external organization is working on standardizing the time zones themselves. Right. So that's why it's blocked right now. But as soon as that's addressed, then we will be ready to start using it. How does it look like? So let me show you for example the different types that employer will provide you. So these are some of them. We can group them in three groups. The first one let me run Quoka really quick so you can see at least how it looks like there are three different groups. So we have instant that basically is an instant in time in UTC. Right. We have a plane followed by plane date, time, plane date, time. Basically the idea with them is when you're not worried about the time zone or when you're only worried about date or only the time, then these are the classes to use. And then you have sun date time that this one is the most complete one. And it has everything, it has the calendar, it has a time zone, it has a date, it has a time, it has everything. Right. And in fact, if I do, for example, current date here you will see how it's pretty straightforward basically to go to any of the other objects supported by temporal, provided by temporal. Sorry. Because it basically contains all the information. Right. And you might be wondering, okay Alvaro, let's see this in action. This sounds cool but can you at least show me how this would work in a practical example? So let's do that. Let's say that for example we are going to calculate, let's say that we take a flight now from here, from DevOps, we have the plane outside. Right. And then we take it and then we fly to Tokyo. Right. The idea here now is basically to get at what time we would arrive in Tokyo if we do that, right. Spoiler with that. You cannot do that because we don't support time zones. So there's no way we do it with doing it with just like JavaScript native. There's not like an easy solution. Right. So let's do it with importance. So first we need a departure. We said that this is going to be just now. So we can just do departure this. No. And then the other thing that we need to understand what time we would get there is the duration. Please someone correct me if I'm wrong but I think that to access to get to talking might take like 13 hours or something like that. And if not, feel free to correct me. Now is your moment and then 30 hours, 30 minutes, so we can play with more depth. Okay, cool. Now that we have the departure and now that we have the duration, I think we have all the data that's everything that we need. Then the arrival time will be the departure and then we have the duration and then the time zone will be well, Asia Tokyo, that is where we are traveling to. This is more than enough. Now you can see how if we see the values, if we leave right now at 525 on the May, then we would arrive there on the 12 may pretty much at three, right. With the Asia Tokyo. And as you can see already, it's super straightforward to work with things like adding time or subtracting time. Right. Things that with data are not quite straightforward. But here is super intensive. For example, creating new instances like let's say you want to create a plane date, you can always do from. And it's as easy as like, okay, day and then day is going to be the 29th of the month, seven. And by the way, compared with date, in day, the month they go from zero to eleven. No, we don't do that in temporal. In temporal they go from one to twelve because it's like what we are used to write in real life. So this is the way, right. Then this is how you create for example, as you can see it's quite readable, it's quite easy to understand. There is no magic behind it and then boom, you have your plane date already available to start playing with it. It has a really good documentation, it has a really good cookbook. It's super interesting. The documentation is super straightforward and really easy to read in case anyone is interested. Like at the end of the session you will have a QR code with all the resources that I will be mentioning along the talk. But at least you know that temporal is coming as soon as that's addressed and then we can start playing with it. Okay, cool. This is one of the proposals that are quite interesting. The other one that I wanted to mention is stage three. If we go back while there are some of them like Shadow Realm regarding this is basically running JavaScript code in an isolated environment so that you don't affect the global window or the global disk. So it's quite interesting. For example for iframes but we're not going to cover that one because it's quite complex to cover. I would need like 20 minutes for that one. So let's focus for example in import assertions. That is quite interesting. So as you might know now, browsers support native modules native JavaScript modules before one of the main reasons why bundlers are here on the webpage is with the idea of basically taking all the different imports and then bundle all of them in a JavaScript object on a JavaScript module. And then this is what is later sent to the browser. But you don't need to bundle them anymore in most of the modern browsers. So that's what for example some bundlers like Beat are using to speed up basically the process when compiling. But there's a problem with that and I'm going to show you and some of you might be able to help me debugging a problem that I currently have. And that is let's say I have a project that is basically an index HTML with a module JavaScript module main and then main. This is the only thing that is doing is importing a print high and I'm just calling it and this print high is nothing else than a function console log highdevox. Then if I run this let me check if I go to the terminal and then we don't need this one anymore. Now we are working with this one. I'm going to run MPX server that is basically to serve static files. In this case what it's doing is serving the index log HTML. If I go here now and then you will see how the console log is not being displayed. So at this point are there any guesses of why this could be happening? And I can show you all the codes for whoever is interested. If no one, I can. This is the code. This is pretty much the code. Any guesses of why the console log is not getting rendered? That means that if you cannot catch it, that means probably that you use bundlers as we all do. And if we go to the network tab then you will see how if I refresh the page, you will see how main GS is being loaded. And this is the date that this is the right model. Right. But printhigh is returning actually a 301. Right. When we use bundlers the bundlers, the good thing that they have is that they have access to the file system. Right. So if you write something like if you have something in your code like import print high from print high, then basically the bandit web pack will do. Okay, is there any task file pinhys? Yes. Okay. Is there any JSX? No. Js. Okay. Found it. Okay. Then this means that this is Pinghai JS. Right. So now if I rerun the code again, you will see how in fact now the console log works as expected. But this is something that you might when you are used to work with bandage. This is something that you don't know that is happening in the browser. But there's a problem with this. Notice how when I didn't have the extension, what it's trying to retrieve and I'm not sure if you can see it, what is trying to load you can do it is a script. Right. Even when the extension is not there. Let's make things worse. If I do this, printhigh CSS and I refresh the page, it's trying to load a script. It's not style. Right. And the reason why this is happening is because by default the browser assumes that you're trying to load and script and it doesn't rely on the extension of the file to assume the type of content. Right. The type of the model that you're retrieving. And this is a problem because for example let's say that you are actually importing a CSS and then you have this is style, import style from blah. Right. And then at some point this is something that you don't own and then whoever owns it decides to hey, this no longer will be an effect. For example, if I change this print height to CSS, you will see how it's loaded. Now as a script, it is what it is and it has been loaded as a script. Yeah. Someone could potentially change the extension of one of the change the value of the CSS file and then inject JavaScript in your code. And we don't want to do that. Right. So this is a step in that, right. So import assertions, that is the proposal that I wanted to talk about basically comes here to solve that problem where you assert before importing you assert the type of the model that you are retrieving. Right. So for example, if you have full JSON, then you have said that the type is JSON before you even start Loading it. Right. And then by adding that line of code, I said what you're doing is that the browser will check that in fact it's adjacent. Right. This avoids this kind of surprises of like injecting JavaScript. And basically the good thing about it is that this is a step in the direction of getting rid of bundlers because if we can import models natively and we can import them in a safe way, then a we are at least one step closer to get rid of what there are so many steps that we have so many things we have to do first. But one step in that direction, which is always helpful at least for the developer experience. Okay. This is the other one that I wanted to cover in stage three. We will talk about one of the other ones that have made it to stage three later. That is decorators that for you who work with Java, for example, or similar to it, we will talk about it in a second. But for now, because this happened like two weeks or three weeks ago when you got moved from stage three, we are going to focus in the most liked proposal by the community as of today, that is the pipeline operator. And the pipeline operator comes here to solve a problem. Right now this is the operator itself. It comes here to solve a problem where basically let me show you the problem that it fixed here, for example. So we have this beautiful code. Your code is really bad. Okay, I agree. But basically what we have is a number five and then we are adding eight. Adding eight. This is not really readable right. It's quite easy to get lost. So a good way of for example showing this of calling this in a clean way would be like following functional programming, like super clean when you have an array and then you do a map and then you filter and then you reduce it and then you return this. This is super easy to follow. Right. But this is something unfortunately you can't do if we have a Const number five. No, you can do something like number five at five. No, this will blow up. Okay. There should be a JavaScript error here. This wouldn't work. In fact if I do Coca right, it will break. So the pipe operator comes here basically because on one hand we have nesting function calls and then the other one we have like chaining like for example functional programming. The pipe operator comes here basically to be an intermediate step for these types that don't support functional programming or not primitive types, for example numbers. So the way it works is that you can use the pipe operator and let me write it really quick so you can see how it looks like. What we are doing here is that after the previous step of pipe operator, that is basically the result of this is just the value five, the number five. Then we are calling the method the function at five and then the token these hash represents the value contains the value of the previous step of the pipe operation. Right. So right now if I show you the result of this basically is five plus five is doing thing. And then the good thing about it is that now it's quite clean not to see what's going on is compared with the other one with the one above. No, I mean, I know it's not the same. Exactly the same. But you can see how this is at least more straightforward than the option above. Right. And you might be wondering if this is you, that you are using the two methods and you're just basically trying to confuse us. Not really. If we go for example, let me show you an example of code extracted from React. This is from the React library. Currently when running just it has like this code here and then I wish I'm not sure you but at least for me, it's not as straightforward as I would like to to understand what's going on here right now. Right. But let's see how it looks. At least with the pipe operator. If I Scroll a little bit down, at least compared with the previous option, you can see how. Okay, now I pretty much get what's going on. We have some variables. We are getting the keys, we are mapping them this way, and then we are creating a string with all the envelope and then we add the door sign at the beginning. We do some chocolate thing. We don't need to understand what this is. And then we do a console law. Right. If you compare this with this, I guess that there is an obvious winner, at least in this example. And like this, if you go to the proposal, there are so many that are like real. This is like go that you can go to GitHub right now to some of your favorite repos and you will see unreadable code that with type operators. Potentially it will get better. By the way, you might be wondering wait a second. But here is a hash and here is a percentage of what's going on. And the main reason is that the token right now is not well defined 100%. In fact, when I did the talk like three weeks ago or four weeks ago, it was a percent and now they changed recently to the hash. Right. So right now it's work in progress. In fact, if you go to the plugin, it actually allows you to change it because they are still trying to agree on which one should be the way to move forward. Okay, cool. Pipe operator covered. Then let's go to the next one. As I said at the end of the session, if you have any questions, then feel free to come and then we can talk about them. Decorators will talk about it in a little bit. But first we are going to focus on records and Tuples for this one, I think the best thing that we can do. Well, first, let me tell you what the problem is. I don't know how many of you have worked. For example, with let me see, with Immutable, there's a library called Immutable. That basically because JavaScript doesn't support natively immutable objects or immutable leads lists. Sorry, we do the object trees, but it doesn't work with nested objects inside. We do deep freeze. Right. But it's a workaround. Okay, cool. Then Records and Tapas basically come here to equivalents to basically immutable objects and immutable arrays. Let's see it in the playground, because I think this will be the easiest way to see what's going on and the syntax. So as of today, if you have a person and then name Alvaro and then A and B, let's not focus too much on. Right? And then if I freeze this object and then I cannot reassign the value of hobbies, but I can edit the reference to this list. Well, I can edit the array here, this array I can push, for example, and that will work ten out of ten, even when I'm doing object freeze. So this is where Records and Tapas come here. So basically record is nothing else than an object. It has the same syntax but with the hash at the beginning. And then what this means is that this is now immutable. I can do something like record probe equals seven, because this will blow up. Right. This will return an error. And then the same applies to Tuples. That is basically same as an array. Where do you go same, right. And then it has its own types, records and taples. And some of the good things that it has, for example, is that they have the same methods as the original one. So an object, you can do object entriesofrecord and then let me log it. And then this is like basically everything supported by objects will be supported by records. And all the methods available for an object are available for records too. And the same applies to Tuples, except for the ones that are basically mutating the value. In that case, of course, they are not available. And the good thing is that it's not only immutability. In fact, for example, you can create immutables. Let's say that you have any mutable object, not like this. You can create an instance of that mutable object by just using the speed operator. And this works perfect. Then it comes with some other benefits. So, for example, in terms of equality, as of today, in JavaScript, equality of arrays and equality of objects are based on the reference. So if you do something like this, this will return false, right, because it's basically not the same instance of the object with immutability. With Records and taples, it will be different. It's different now. And finally, they are based on the content itself. So, for example, you can see here how I have defined two different records but with the same properties and the same values. And then you can see how this equality simple here. Just in case you cannot see it, it returns true and the same applies to topples a tables with just one element one is equal to a table with one element one, even when it's not the same instance, which is something that you don't have to do deep equals anymore. For example when checking the quality of objects and then this also and this is quite interesting. This is also supported for nested quality. If you have an object inside a record, it will be the same as another record with the same record inside, even when they are not the same instance and it's dependent of the order. And then it also comes with some other benefits. Like for example not a number that in JavaScript as of today, not a number is not equal to not a number that is something that whatever. Right? If you have not the numbers inside tuples they are considered equal. Right. So you can see here how we have a tuple with this one element one, not a number and another one. They are not the same instance but they are true because they both contain another numbers. Okay, so yeah, really useful. Fortunately this is still in stage two. So work in progress. They are discussing still the syntax, API and everything, but at least we are one step closer too. And something that I forgot to mention before. But all these proposals, because they are all in GitHub, you can always follow the issues, you can always follow them the discussions and you can even participate. I mean you cannot join the meetings, but you can always participate in all the threads that they have in GitHub in case you want to give your opinion. That is always valuable. Right? Okay, so let's go back to the light. We have seen some proposals. Now I'm going to show you is a survey. So this is coming from something called the state of GS. The state of GS is basically a survey that is done every year where between 25,000 or 30,000 developers they submit like anyone can submit their responses. But basically this is asking for feedback. Which technologies do you use? But it's super interesting. It has a lot of really cool data. What we are going to focus today is one of the questions that they ask is what do you think is missing in JavaScript? And I'm not sure if you might be able to see it. So I will read it for you. But basically the top one is static typing similar to TypeScript. Then we have a standard library that's utilities like loads for example. Right. Then we have better date management, Immutable data structures, observables that is push based data source. Basically. I don't know, whenever you click this push an event. Right. So it's basically modeling these push based data sources. And then we have pattern matching, pipe operator and decorators. Right. We have covered some of them today, like better date management with temporal immutable data structures with records and topples and pipe operator with the pipe operator that we just a minute ago. But I didn't want to miss the chance to at least give you a high level a brief overview of where the others are at right now. Then in terms of static typing, at the beginning of the year, I think it was around February, Microsoft came up with a proposal for TC 39 where basically they want to introduce types in JavaScript natively support. And it's interesting because as of today I know what we do is that we compile test to JavaScript and then this JavaScript is what is processed by the browser ranging. Right. What we want to do is that now JavaScript and types with just the types. You can send it to the browser and the browser will be able to parse it and execute it. Right. Which is like in terms of developer experience is an improvement because we no longer have to save wait, refresh. Nice. We can skip one step. And I will briefly mention that if you want some JavaScript drama and the types were supposed to come to ECMAScript, in fact there is a proposal that is ECMAScript Four. So right now we're in 13. Okay. This Eggmanscrypt Four was supposed to have types and in fact it's super interesting. If you go to the proposal you will see how this was not part of the talk. But because we have three minutes, I can show you really quick the real story behind ECMAScript Four. And don't forget we are in 13 right now, the missing version. And then here you can see how classes were reintroduced, but they were introduced later with ECMAScript Five. But then you can see here how strict typing was already available. And for those of you who don't know we're talking about but this was already a proposal. Right. There is a lot of drama of why this didn't happen. At the end of the day there were two branches of ECMAScript like Eggman Script 3.1, ECMAScript Four. A lot a conflict of interest. But if you are more interested about it, then in the QR code at the end you will have the whole story with the drama of what happened and then moving to the next one. I'm sorry, static typing. Right now it's in stage one because it was just recently introduced. Right. For pattern matching. Unfortunately, I don't think you will be able to read this, but it's similar to other programming languages where basically it's like switch encase, but now it's match. When match is an object, you receive an object and when it fits the structure of that object, then you apply the function, you run the code inside that when statement and there is more information on the QR code and then decorators it was a big one but basically the curators basically are functions that what they do is that they will extend any elements that you have in your class and this means fields, this means getters setters the class itself, right pretty much anything you can the methods, anything that you have, you can extend it and change the behavior. For example, here what we are doing is that we are logging whenever you call a method, we are just logging it and displaying it in the console. This made it to stage three recently. As of today, as you can see, some of the ones that I mentioned static typing, the utility libraries, observable, that is the pushbased data sources, pattern matching are right now in stage one so there's a lot of ongoing right now they are trying to get the right solution right. So work in progress. In stage two, we have pipeline operator and records and topples so we can expect that they will take a little bit but temporal and decorators are in stage three so hopefully we'll be able to see them really soon in 14 or 15. Hopefully this is the QR code. No worries. Like the QR code is also here but I leave it here for you in case it's bigger. But this is basically the end of the session. Unfortunately, we don't have any time for questions but if anyone has any, please feel free to come to me and I'll be glad to answer any. Thank you so much for your attention and enjoy the box.