 And I am building a tool that finds dependencies name and put those dependencies name in a resource manifest. And what do I mean by this? So I have a static portfolio website, and I want this web app to load really, really fast. And fortunately, I came across this technology called HTTP to server push. And it loads website really, really quickly because it reduces the unnecessary round trips between server and browsers. So traditionally, it is up to a browser to discover dependencies. But it requires a lot of round trips because every dependencies has its own dependencies that has its own dependencies and that has its own dependencies. So it's just like, oh, results in a lot of round trips. But with HTTP to push, server push, server can reduce, we can eliminate all these round trips because server can discover dependencies its own. It has all the files locally, and it can check locally all those dependencies' names. So, but server doesn't know anything. So we as a developer have to tell server, hey, these are dependencies' file names. So before jumping in, I want to show you some examples of dependencies' names that we can add to a resource manifest. So this is index.html from my portfolio site. You see main.css and some image file. These are two dependencies to index.html. And this one is, let's say, three dependencies in a style.css. And these are like many dependencies, JavaScript, file dependencies on script.js. So these are dependencies' names that we can add to resource manifest. But now to benefit from fast web loading using HTTP push, we want to write resource manifest with these dependencies' names. So the problem is that these are very tedious process. Imagine I put 100 images files to my index.html. That means that I have to go back to manifest.js. I have to go back to manifest file and these are t-time image or brunch image. These are like 100 times. These are very tedious. And this is a space for improvement. We can automate this process. So the solution is that we can parse through these files and then find dependencies' names, automatically find dependencies' names. So the parsers I used are following. For HTML, I used HTML parsers too. For CSS, I used CSS tree. And for JavaScript, I used Acorn. You can find them on GitHub. And all these parsers share commonalities. They turn my source code into a tree. And then each node are the constructs in a source code. So let me give you an example in CSS. So body, background URL, and import URL, these are two constructs. And I can visit this URL by using this concept called visitor. What visitor does is that we describe which specific... So I can visit either of this by indicating which specific nodes I want to visit. So for instance, CSS. So CSS parser turned my source code into a tree. And then I can walk the tree and then visit a specific, let's say, import URL. I want the dependency name of font awesome, CSS. Then I can visit it by using if statement or node type is at rule and then node name is import. So it would retrieve the dependencies' name of import URL. So I did it for not only for my CSS file, but also my index HTML and JavaScript file as well. So I succeeded, I think, I hope. So take away is that HTML, so HTTP to push is really cool technology. And what's next is that I just finished my first part of retrieving all those dependencies' name. But then now what I need to do is generate, automatically generate resource manifest that includes all those dependencies' names so that we can enjoy the fast, you know, web loading with HTTP to server push. So thankfully, I have a friend, my friend generated, he built another component that automatically generate resource manifest by using my project. I call it Sherlock because it detects all the dependencies' name. So with Sherlock and his contribution, now we can optimize the unnecessary roundtrip automatically, which is really exciting. So if any developers are interested in exploring HTTP to push and, you know, faster web loading using this, then very exciting. And this is under a very meaningful free and open source project called Common Source. So Common Source is a next generation content development delivery network project that allows web loading much faster even in a very remote area without a big server center. So and then I find this very meaningful because I say it's a next generation because I, as a private individual, not as a big server center, can also contribute to faster web loading by hosting a mini server. So I think I kind of fall in love with it. I really enjoy it. And then so now I'm part of it. So I hope that you also find it interesting. And thank you for your attention. And thank you. Oh, oh, hello. Thank you for the discussion. So first is what happened when the dependency free as a loop in there? Sorry. How did you deal with second is how do you deal with that? Oh, oh, can I talk to you after the, after the meetup? Yeah. So, yeah. So, yeah, let me think about it and then get back to you. Okay. So thank you. Okay. No. So sorry. I might not be in tune. So when you say HTTP, are you talking about protocol too? Yes. But then it has this server push feature and then there's no like standardized, standardized way to do it. And then my friend came up with the format and I just, and I said, oh, that's really interesting. So let me help you out. So what servers are available out there that uses HTTP to as a protocol? Oh, can I get back to you later? Okay. Because I'm, so I'm with like six months baby quarter and then my friend been like helping me and then like, I'm very, very excited to be part of this project. So, but then I need to study a lot and this is a great question. I will look forward to learning more about it. Thank you.