 How many of you have heard the name Brahmos? Yeah, so it's a fastest supersonic missile built in collaboration with India and Russia. And I was looking at analogy of something fast for the name of my library. And one of my friend, Yuraz, came up with this since the name Brahmos. About me, I'm Sudhanshu. I work at Hacker Rank. I like talking about front end platform, architecture, tooling, patterns, and frameworks, and mostly about react. So let's get it started and let's launch our Brahmos missile. Okay, good. So just a small brief on what we will be talking about. So Brahmos, it's inspired by litastimal and hyper-estimal if you guys have heard about it. So the main idea about this library is to divide your application into static and dynamic parts and on updates, only compare the dynamic part. So I'm a React developer and I love React. React is great. That's because it provides a great declarative API. It has well proven patterns like JSX, contacts, hooks, and now the concurrent mode is coming up. It's a widely adopted library because it provides a great developer experience and that is because it has a great tooling ecosystem around it. But it has one key problem. There's something with slide, problem with the slide. Okay, so if you think about an application, it's a combination of nodes. It can be like a static node and dynamic node. So here, the green dot represent dynamic node. The blue dot represent static node. And whenever there is an update on any of the nodes, so here, let's say we are updating the last node and the state is coming from the top, React doesn't discriminate about static versus dynamic node. So instead, it tries to compare everything and then it finds what exactly changed. It finds what's the minimal update required for the actual DOM and then it applies those updates. So kind of React is a function of nodes and nodes here can be your component, your native element, and in a React term, it's basically a Fiverr node. So when I came across a talk by justin about justin about LiteracyML, he introduced a pattern where we don't have to care about the static nodes. Instead, if there is any update on the DOM, we just have to compare those dynamic parts and find what has changed and we will have associated actual DOM node to it and then we can update those DOM nodes. So LiteracyML basically is a function of dynamic node versus React, which was function of nodes. So this sounded like a great pattern. So that kept me thinking, how this, there is some problem with the figure, okay. So how this pattern can improve the overall performance. So I went to check the benchmark, check the performance benchmark between these two patterns. So there is a open source project where all the libraries have added the benchmark of itself and there I compared mostly on the pattern which I will be discussing today versus the virtual DOM. So we can clearly see that the pattern itself performs better than a V DOM. So LiteracyML, LiteracyML and HyperacyML all uses the pattern we'll be discussing versus the React view and React which uses virtual DOM. So this library usually renders like a thousand top rows, try to update it, replace it, remove it and then check the performance things. So not just the performance, even this pattern can be implemented in a lighter-wet library. So the whole startup metrics can also be smaller. So all of these three libraries are much, much smaller than the other virtual DOM counterparts. And even the memory allocation during the runtime is less on the pattern versus virtual DOM. So this gave me a good motivation to explore more on this pattern. And by the way, benchmarks are good but they're not like, they doesn't show the complete picture. So, and most of the time if you talk about performance, it's not the library which is slow, it's more of your application code which is slow. So the library providing a proper API through which you can write something, performance code is much better than the library which performs better internally but the API are not very well accepted. So, because React provide a great declarative API and now they are going toward this concurrent mode, so they are trying to focus toward making your whole application performance. So I thought like, can we implement the pattern, rendering pattern in React itself? So the first thing I thought was, can it be a improvement on React library? And suddenly it can't because React is tightly coupled with virtual DOM and the reason behind that is it has to support multiple platforms and you can write a different renders, renders for like native element for browser, for server side, for VRs. So React is never going to ditch virtual DOM, they might find a different way to figure out what is a static and what is dynamic notes on it but we don't will stay. The second thing I tried was to write React API wrapper above LitSTML, but the problem with that was LitSTML API and React API doesn't match properly, they have both a great API but the API of React is not directly mappable to LitSTML. So I was left with one thing of creating my own library and I saw that as a great opportunity to learn about the inner working of the library I use and the other JavaScript libraries for rendering your application. And also I thought like I'll have one library in my name which I can drag about, so why not? So let's not talk about how the whole bramosing work, before that let's see how React rendering work so you can compare it with, you can relate things that how bramos is trying to fix that. So in React you write something in JSX and you write a component in JSX. The JSX is transformed to create element syntax using React Babel preset. In the create element syntax the first argument is element type which will be string when for the native elements and will be component reference for the components followed by all the props you pass followed by all the children. And then create element syntax, create element function returns a data structure we call it as a VDOM and as you can see VDOM contents all the information about the nodes you are trying to render, the static part, the dynamic part and everything. And then later on it's converted to Fiber nodes and when there is update the whole previous VDOM structure is compared with the new VDOM let's say Fiber node are compared the whole Fiber nodes are compared. So here and then find like what is the actual difference and then apply those changes on the actual DOM. So in this example we are trying to update just the name from React to Delhi to Sudhanshu but it will try to compare the whole object. Now let's see how BrahMos tries to solve that particular thing. So you write in JSX the same way you write React. The main idea of BrahMos is to have the exact same React API. So developer coming from React will have a zero learning curve and also BrahMos can be built progressively. So some part can remain and BrahMos on some features that we can opt from the React tab. So you write your component in JSX then JSX is transformed to tag the template literals using bubble plugin BrahMos. In a tag template literal you have a tag function the literal part and the dynamic part which goes as expression. So tag functions are nothing but a normal function which receive a literal part as the first argument. You get an array of literal parts followed by all the expressions. And the tag function doesn't have to return a string. It can return anything. It can return object, array, Boolean or anything. So there is one key property of a tag function that for a given template the array of string or the reference of array of string would never change. No matter where you have used it, no matter where you have the places you have using that particular template. So in BrahMos we use the literal part to create template tag and because the reference of the string, array of string doesn't change we use that to cache the previously done work. So the next time you're trying to parse the same template it will just return from the cache. And then the template function returns the template instance which would never change and the dynamic values. So because the template is a static which never changes on the updates you only have to compare the dynamic parts. You don't have to compare the static part. So here we only have to compare the ID and name. So let's see more about the template instance how that is formed because the main things are happening there. So with a static part the BrahMos generate template tag, HTML template tag with a placeholder for dynamic attributes and the nodes. For attribute it creates a attribute called data BrahMos attribute and for node it creates a commit node. And for every instance of the template during the rendering it generates, it clones the DOM element from the template type and it remove all the placeholders and with those placeholders it creates the part information. Now the part information have everything about the node because this node we can directly append to the DOM. So for attribute it will have information about the node that attribute belongs to the index where that attribute lies and that helps on like a finding what is the correct order of attribute, how to handle proper overrides and all. And for the node part it will have the information about parent node, previous sibling and the next sibling. The dynamic value which I showed is directly associated with these dynamic parts. So that is one to one mapped and whenever those dynamic value is changed you exactly know it what DOM location you have to update something. So you can check more about that on the wrapper itself I've added a dog but let's talk about what's the current state of BrahMos. So it is ready for your site projects. You can start using it now and it supports all the major React API. All the major React APIs implemented, class component, functional component is there. All the life cycle methods are there. Context API is there. Hooks, all the hooks are there. The current version of suspense and lazy is there. And recently, a few days back we launched Create BrahMos app. So you can get started with your site projects. This is on alpha stage right now but you can give it a try. And the overall size of the BrahMos is 6.8 kb versus React plus React DOM which is around 43 kb. But there are a few more API has to be implemented. And a little bit of refactoring would be done. So I'm assuming like I'm trying to keep it around eight to nine kb overall size when everything is there. So right now we are exploring on the fiber architecture of the React. We're trying to implement the same thing in BrahMos to support a sync rendering. It yet has to support server-side hydrogen so it can boot up from the server-rendered page. Right now it does support create element syntax. So it by default support all the third-party component, React component but it doesn't get actual benefit out of it because everything is treated as a dynamic node there. So yeah, there are a few more work has to be done for a better third-party component. There are a lot of work ongoing for the optimization, performance optimization, and making BrahMos stable. I'll give you a quick demo of a classic 2-2-MAC built with BrahMos. So here you can add a 2-2 task, you can mark a task done, you can delete any of the task, you can filter between completed and non-completed task like that. And if you see the code, it exactly looks like React. Only the difference is instead of importing from React, you import from BrahMos, but the API all are same. You do change the state in the same way, you define the JSX in the same way. So there are a lot of things yet to be done and mostly around the development ecosystem around the BrahMos. And one good thing about BrahMos is because it has a same API as a React, it can be progressively developed. So we don't have to wait for BrahMos to be fully finished. We can start using it beforehand. For some part of like environment, you can use React and then in other environment, you can use BrahMos. But that would require a full support of React API. So there are a few things and I've already added those as a bit of issues. And it will also require environment-based Babel preset which can use React in some environment and BrahMos in other environment. Using BrahMos as alias for a React. So the third party component which are published pointing to React, those will start pointing to BrahMos. And then because I mentioned like though third party components are supported, it doesn't give you proper aesthetic and dynamic differentiation. And so we are thinking of to write a script which can transform those third party component to BrahMos, React component to BrahMos component, which will probably run up a post install, post npm install. And on the build side, right now, similar to React, everything is named spaced under BrahMos object. But there is no reason to do so. So we can probably make the BrahMos resecable and it will only import the things you need. Like if you don't need hook, it will not try to import those. On the tooling side, there are a lot of work has to done to support DevTool, the React DevTool. And on the testing side, though React testing library would work because there you just mount and try to check something. But the enzyme would not work. So we still have to write enzyme adapter. So there are a lot of work yet has to be done. And here I like to invite all of you folks to come here, join the BrahMos community or let's say BrahMos cult. And so how many of you are fan of sacred games? So join BrahMos and this is a good opportunity for you to learn the inner things of the library you use. Not just the React, also the different libraries as well. And we are also starting a meetup group, online meetup group where we'll be discussing about inner implementations of different libraries, which is the first meetup is happening on the 30th November. I'll keep it more updated on the Twitter, but yeah, that is there. So I've added the links of the BrahMos. So BrahMos is moved now to BrahMos organization. You can find everything, the BrahMos library, the Bible plugin, the to do MVC, and you can do NPM install G create BrahMos app and you can start using create BrahMos. So BrahMos, so that is also there. And the talk which inspired me to do this whole thing, lead HTML talk, I've added link for that as well. With that, I like to thank you folks. And if you have any doubt on the BrahMos, the talk or anything in JavaScript, just ask me, you can ask me on Twitter. So follow me on Twitter and get up. And yeah, I'll be around. So you can keep asking me things around it. Thank you.