Hello, everyone. How was the day? Yeah. Okay, some of us are happy at least. So I'm going to talk about future of view, but before I start with that, I want to address two things. It took a lot of convincing and almost an year to get Vue Day this degree to make this thing happen. And I want to thank Janab, Hasgeek and all the team who has made this thing possible. Round of applause for them. And also for all the speakers who were there late last night to preparing their slide and making all the preparation for the event today. Again, round of applause for the speakers. Yeah, events are made by people, but they need money and our Platinum sponsor, Anata has helped us to basically be here and all the facilities and everything. Thanks to all the sponsors. Let's do a quick recap of the day. We got to know like it's easy to learn Vue. You got to know you can build components and building component libraries is hard. We got to know we can build our blogs with Vue. Scale is also a people problem. Team can be a large scale application. Plugins can cure all kind of developer pain. We looked under the hood and find out how the activity works. And we heard the React developer show his love for Vue. And most important lesson of the day, accessibility is business. So let's start from where it ended in the morning. Vue 3.0 is coming. Yes, it's coming. A bit about me. I'm Rahul Kadyan. You can find me on Twitter with this weird handle. I call it junk zero, but yeah, whatever you want. I'm a core team member and I run a meetup in Bangalore or blr.vue.community. That's the website. And part time I'm building a conference in design. So look for that. Let's get back to the future. Yes, 3.0 is coming. So why now? Like 2.0 was released almost three years ago. And it has been almost good for us. Like there are no problems which cannot be done with 2.0. Why now? Why 3.0 is coming? So the main reason behind this thing is this particular chart. It was red three years ago. Now it's green. So it's kind of a go. You can use proxies and improve 2.3.0. So we kind of give us a just like how objects are defined. Reactivity works. You define a getter. There you just track all the dependencies. When something is accessed, you define a set of you where you can notify all the dependence like something a change updated. But there's an inherent problem with this thing. So all the caveats and the complexity like it has linear complexity. If you have 10 properties, we have to iterate across to all those 10 properties and make them reactive. So it incurs an upfront runtime cost. Then removal of properties and additional properties is not possible because all that wiring is done upfront when your component is initiated. Also array index and length assignments are not possible because there are no traps that which can actually intercept those goals. And proxy does all. So proxy is kind of an interceptor which sits between your object and the accessor. So whenever let's say you want to access a key on object, it will ask the proxy object. Give me the key, then the proxy will go and actually find the key and return it. So proxy can intercept all the calls like assignment on index, adding new properties, removing new or removing properties. Even your custom classes, objects, any kind of object you can think can be handled this thing. Okay. So no more caveats. And I absolutely love proxies. So, uh, as Praveen told us today, like dollar set is kind of a workaround, which object or define the activity cannot work with. So all those things are assignment are gone now with the proxy base, the activity implementation. And it works with maps at week, map, week set or any of the class you want. This small change had made you a lot faster, much, much faster than the object or define properties. And I have some numbers for you. So, uh, this is not a real world application. It is like 3000 stateful components with lots of properties on it. And we are voting the same application with a 2.6 visit the current stable build and 3.0 prototype. So if you see something, uh, the time spent in JavaScript is almost half. So we are getting double the speed of initialization of a new component. And you see on memory, it's almost half the memory. So we are creating, we are using less memory to double the speed half the memory 3.0 is coming. So, uh, plus there are a lot of more, uh, low level stuff is coming in view 3.0, which are going to increase even much farther.  If you already know this, okay. So it's a small crash course, how virtual DOM in view works. So we write a component, something like this, we write templates, uh, in a steamer like language. And this template is past converted and run time is represented as an object. So that object is representational like what is the tag, what are the attributes, what are the child elements, it's a representation, it's kind of blueprint of your component of your tree, what is actually being rendered in browser. So this thing we call a virtual node. And how we get there is view compiler compiles that HTML into a function, which uses like create element or the function to create those objects.  And this particular element create element takes three arguments are tag attribute and a list of children and basically returns out an object out of it. So this particular object is called virtual DOM node or also called V node. And we get this thing out of the template. So template convert to a render function, a render function returns a virtual DOM and virtual DOM node and all the virtual DOM node combined to create a virtual DOM tree. So that's all. Let's get what, how are we using all these things in 3.0. So we're trying to build a smarter compiler that understands your code and tries to generate a more optimized or better code. Let's see this example. It's a simple template. It has two elements. One is component, other is normal div. So what compiler knows is like all HTML tags are lower case single word and single word. And all components start with a capital letter. So compiler can use those information. So instead of using a generic create element, it can find like create a virtual element or create a virtual node for component. And this small change actually helps. If we were doing this, create element something looks like this. If it's a component, run this component, create component V node. If it's an element, run create element V node. So we are moving this condition from run time to compile time. So every create element is slightly faster and those slight improvements add up across your application to make your application a little bit faster. We call this thing element type detection. And we detect from the understanding like capital tags starting with capital letter is a component and a single word lower case tags are elements and cross only generate create node elements for that. Another small improvement, but more effective. It comes from a concept in the script called monomorphic calls. So what is monomorphic call? If you see this function call, it is taking four arguments versus tag. So it's taking four arguments. But same thing can be done if it was taking the first argument, the span element, the tag, because there are no attribute, there are no children, but still we are calling it four arguments. So what happens with monomorphic calls is like if your function is getting same kind of and same number of arguments again and again, JavaScript virtual machine optimize this function and reuse it. So monomorphic functions are a little bit faster because JavaScript runtime won't have to work on optimizing again and again. So that small improvement will affect every call. Like create element is being called for every item, every tag you write in your projects. So that small improvement will add up and will appear in the performance but mostly get in 3.0. So all remain same, whether you get arguments or not. So this is monomorphic call. You can search about it. It's a very interesting topic you can use in any of your applications. Another thing I'm talking about like component fast path. What it is, like at compile time we detect what kind of component you are writing. So if this element has zero items, zero children, then we know like you don't have to run the logic to different your children and all we can skip all this part. So we sort of have some flags. These flags are kind of tell the flags, detect some information about your template at compile time and tell runtime that you can skip on these things. You don't have to perform this. So all unnecessary work and rendering component can be skipped over resulting into a little faster, a little bit faster component runtime. Another thing is optimized slot generation. So if you are seeing how a compiler compiles a slot element is something like this. It creates an object and basically creates an array of all the elements in that slot. The problem with this thing is all the dependency collection and everything happens where it's rendered. That is the parent component. But parent component doesn't need to depend on those things. There is unnecessary render of parent component, a small improvement like converting this object to a function. So starting from 3.0, every slot is compiled to a function and this small improvement helps better track the dependency. Like now dependencies would be like inside the child and if something changed in slot, parent won't re-render. Only child would re-render. Another improvement comes from understanding your code. Like if you see this component, there is some reactive part. And corresponding to that we are generating some nodes. But there is other part which is static. It's never changing. So if your dynamic property changing, your static part is re-rendered, which is not required. So what we can do is we can extract that V node and store it as a static variable and use it every time. Now, when the Diffing algorithm would work on this component, it will see a reference to same object again and again. And it won't have to perform any kind of difference for that static part. So all the static chunks from your template are a little bit faster. So we applied same thing on props. If you see you have some attributes. So those attributes are static. There is no reactivity involving them. So we can do same thing. We can extract them out to a static object. And Diffing algorithm will be improved with this. Another thing we see is like we use lots of inline handlers. Something like this, an event you are increasing a variable or incrementing a variable. So this thing is converted to an inline function. So how Zaskit works is like every time you put an inline function, it's a new instance of function. So Vue has to unbind the already existing event handler and bind a new one, every render. However, we know that this is not what we want here. We want one event handler that stays across the lifecycle of the component. So what we are doing, we are extracting that handler into us out of the scope and using same instance again and again. So all the binding and binding of event is not required. So these are the improvements we are doing on compiler side. Now all those improvements in compiler side are complementing the runtime. We are getting a faster virtual DOM. And we have a new diffing algorithm that utilizes all the information we have collected at the compile time. Let's see this example.  Or let's diff the div, diff the attributes on div. Now go to child, find first child, diff it again, again. So you will go to every element, every prop one by one and diff everything. So you will find the differences. And if it doesn't match the previous DOM, you will re-render it. However, if you see this algorithm, most of the part is not changing. The part which is changing is this particular part where we are using some reactive state. So in 3.0 what we are trying to do is detect the part which are using reactivity or using some programming capabilities and extract them out and only work on them. So how we are doing this thing is we are dividing a component into blocks. So say a component, let's say it's a root block and every reactive content can be a block. And now collecting all the blocks inside a component and now diffing algorithm would only look at the blocks. So let's say you have an if state container component and now we'll divide blocks like this. You have a root block, you have a conditional block and a reactive block. All you need to diff in this particular case is those three blocks. If there is no change in those three blocks, rest of the content is already static. So you don't have to diff that. Same applies for four loops. So in this case, you have a for loop which will return multiple nodes. So every node out of that for loop is a dependency now and we'll basically divide this into a root block, multiple iterative blocks and a reactive block and diff only those part where something can change. Like a good way to see this thing is something I like this diagram. So every box is an element which is using some reactivity and every circle is a static element. So if you want to diff this three, in conventional way how 2.x is doing right now, you have to diff 23 nodes. All those items you have to diff. But if you get rid of static items and just collect the blocks, you get down from 23 to 7 nodes. And this is like a huge improvement on the diffing algorithm. The core of the introduction is diffing algorithms which would make you significantly faster. Another thing coming up is smaller bundle size. So right now what we have on prototype, the view 3.0 is 10 kilobytes GZIP and you can make it even smaller. So currently how we do all the things like we have some global APIs, view.next decode, view.use. So in bundle, in ESM build, we are removing all those surface APIs from there and making them as named exports. So you can import the parts what you need. And not just for those global APIs, we are making all the features like transitions, transition group B, so all those functionality that come out of the works view pre-secable. So everything you are using will be in your project and something you are not using. Let's say you are not using transitions in your application. They would be stripped out of the view build and you will get a smaller size, less than 10 kilobytes. So that's there. Next few improvements we are doing are on DX side. So a new API is being added. We call it render causation. Your component re-renders, but you don't know why does this component re-render. A new hook is coming called render triggered. So this would be fired whenever a change, a change is detected and re-render has been triggered. So you can put a debugger there and look at what is the property that triggered this particular change and debug your component with more information. Additionally, we are improving warning crisis. Right now you get some warning, but you don't know where this warning is coming from. So we would create a trace on a component tree like how this warning is being propagated and how it's presented to you. So you can debug, you can go to that particular component and debug how this warning was created or which component emitted that warning. One more improvement on template side is you would be providing template source maps. So you can now put breakpoints at your template strings as well. Let's say you have a VE in your template and you want to pause at that VE. You can put a breakpoint there and look like check what is happening there. Another huge improvement is coming from native. We are making it easier to target for multiple platforms. You would come with an API to create your own renders. So let's say you want to target native IOS or Android. Let's say you want to target a PDF. You want to generate a PDF using Vue.js. So you can create your own render. API is pretty simple. You call create render and you provide some method to insert an element, remove an element, create new elements and query selector and you get a render out of it and basically you can render it to any target. Next is we are making it simpler to contribute. So a lot of people are asking me how they can contribute and it was always difficult for me to tell how they can contribute because Vue is a monolith. You have to basically spend a lot of time to understand all the concern going in there. Going forward, we are adopting few things. We are dividing our project into smaller independent chunks. So let's say Praveen wants to contribute to reactivity. He can go to that model and contribute to that part. Somebody wants to contribute to compiler. They can go to compiler and contribute to that part. So all the concerns are limited to the scope of the package and it's easier to understand the small chunk and you can understand the whole chunk to understand it completely. So it would be a great opportunity for all those people who are waiting to contribute to Vue.js whenever it is open source, go ahead and start contributing. Another big thing would be like new three-pointer source code is written in TypeScript and you don't have to look through all the packages to understand. You can just look at the type inferences, all the APIs and just work in particular functions. But Vue is written in TypeScript. You don't have to use TypeScript. Currently Vue is written in Flow and you don't have to use Flow in your application. You can use JavaScript or TypeScript or anything you want. Similarly with 3.0, we are writing in TypeScript because it makes the job of maintaining the framework easy but you don't have to use TypeScript if you don't want to. Another way to contribute today is you can be part of RFCs. RFCs are kind of making all the decisions what goes into Vue and what doesn't. So if you have some concern, go voice your concern on this repository. If something is breaking your application, a new feature that might break your application, voice your concern like this doesn't work for me or if a lot of people have similar kind of concern, you will rethink and redesign the APIs. Okay. Finally, let's go to something which broke the Internet recently, a composition API. And yes, so why we are introducing a new API? Mainly if you have been using Mixins. The problem with Mixins is, let's say you are using two Mixins in one component and you got some issue. You look at like this state is coming from somewhere, which Mixins you don't know. You have to jump to the source code of both the Mixins to find out which Mixins is actually exporting that property. Another thing is let's say both the Mixins are exporting a prop or a state variable with same name. It's both a counter. And now you are using both the Mixins. You cannot use both the Mixins because both are depending on same variable. And they might change that variable differently that could break the behavior of Mixins in one component. So there are a couple of downsides to Mixins. Though Mixins help a lot in some mission areas, but eventually you can get to a rabbit hole where you don't know where changes are coming from. To mitigate all the issue, we came with a composition API and community React hooks have been working really well for React people. So we are trying to create a similar functional API which you can compose and reason about where state is coming from. Let's take an example. This is how a component would look like. A new method is added there. Set a method. It can set up initial state for your component. And here we'll go all the components in API-related stuff. A new API is exported reactive. This is same as what we have right now on API called observable. So you can define some reactive state. And in that state, you can use computed properties as well. So here we are using a computed property, a function that returns double of the count variable. We can define some functions in line here. And finally we can export whatever the state we have created here. This, the object return here is available on the disk scope of the template. So what we can do, we can do state.count, state.double. We can access that increment method with return. Pretty much how we all already do with data and computed properties and methods. Consumption wise, nothing is changing. Does this set up method is something new? And what we can do with, like, this method gives you flexibility. Let's say this component is growing in size. You want to reduce the size of this component. You can extract the function out of it. Like, let's say use counter. And all the logic from the set up method is now in this function. And we are simply calling this function in our set up method and returning the state. Nothing needs to be changed in the template. The template remains the same. What you can do additionally is let's move this counter method to a separate file. Now this use counter is in a counter.js file. And in our component, we are importing it using it same way. This allows us to refactor a code into smaller chunks and reuse it as well. There is no concern about, like, there's no information about component in this particular use counter function. It is creating some state and returning some API to access that state. So that's there. Low here. Okay, so nothing need to change. And let's go to the case, like, we're using two mixing and both have same properties. Same thing can happen here. But JavaScript comes to the rescue. When you are destructing the object, you can rename it to something else. Let's say you rename state to counter. And now you can return counter increment. And you will use it accordingly in your template. The state becomes counter.counter.counter. So all those namespace callings and things are going away. If you are interested to know more about it, go to this URL. Maybe click a photograph of this. You can see it. And we have created an extensive documentation on what is coming to the complex and API and what you can do. There are plenty of examples there. And there is a plugin that works for view 2.x. So you can try it. We are on questions, but I guess I came with my own questions. Let's go with them first. So 3.0 is coming in TypeScript. Do we need to learn TypeScript now? No. If you are using View 3.0, you don't need to learn TypeScript. If you want to contribute to TypeScript, you have to learn TypeScript. And it's a good skill to learn. Does 3.0 break my applications? 3.0 is not duplicating or dropping anything. All the public API in 2.x and 3.0 is almost the same. All the API is coming. That's the composition API that adds up on the existing APIs. You don't have to worry about anything breaking. Let's say you don't use composition API, your component works as it is. Why it's 3.0 is because we are dropping defined property syntax and using proxies. So that breaks something. Internet Explorer does not have support for proxies. And Internet Explorer is obviously dead now. So it won't ever get support for proxies. So if you want to support Internet Explorer, you have to use a build that would have all the consents, all the caveats of 2.x. But you can use 3.0. You can create two builds with viewcli modern mode. For modern browser, it will use all the latest proxies thing. For older browsers, it will use different implementation of the activity system using object defined properties. But you will be restricted to all the caveats we have in 2.x if you want to support Internet Explorer. And we will provide ample warnings. Let's say if you are using if you are building your component with modern mode and you are using array index assignment. So we will provide warning for that. This kind of syntax won't be this kind of feature won't work in Internet Explorer build to use an alternate way or remove the of supporting Internet Explorer and feeding Microsoft. Another concern I have now we have two ways of writing component. So we always had two ways of writing components. You can use template or render function. But I haven't seen any person who is writing all render functions for all templates. Most of the work can be done by template. 99% of my components are template with templates. In a while I will learn into some situations where I want to do something and those kind of things are not possible in template. Template is a restrictive language. So you have to jump into render function and create your component. You can analogous to this, you can have we have object-based API where we use data and computed method to basically build our components. That works really well. Once in a while you want to build a feature and you want to share that feature across multiple components. There we can jump and use composition API. We have two ways of writing components but we have to choose on a case basis if it makes sense to use templates, we will use templates. If it makes sense to use object-based API, we will use that. If it makes sense to use render function, we will use render function and same with composition API. That's all from me today. I'm Rahul. You can find your Twitter by this. I want to introduce Ustub. He is also a core team member and he is involved in community a lot. So, who do you... Does it work? It should. I originally wasn't meant to give a talk today but we still have a few minutes so let me share what I didn't prepare for today. Can we have a browser? Because I would like to show you a few of my favorite websites which may have or may not be created with UJS. Just a browser because I will be switching from one to one. My real name is Dariusz Weandruchowski but it's quite difficult to pronounce so my friends call me Gusto and I consider all of you my friends already so I would be happy if you call me this way. I came here to India. I also started having big problems with learning and remembering all the Indian names because we are so different from what I knew from Europe but what is not different is the passion that people here have for the technology and also for UJS. That's what I will be talking today. And I came a few days ago to Delhi and it was the cheapest way to come to India and I'm a cheapskate. I try to go to as many local meetups as many conferences as I can just to meet view developers to ask what to struggle with so I can pass people like Rahul who are better with coding than me. And in Delhi, my friend actually he doesn't use UJS he uses React but he was sick and that's also your friend and he took me to a sick temple and we attended community dinner together and what I noticed there were people sitting down and getting helped with food and service by other people who were voluntarily helping them and the quality of developers doesn't really work differently it works pretty much the same way some of us like library authors like event organizers like workshop creators authors of tutorials authors of courses or people who just ask questions of Stack Overflow or chats or forums provide help for others and later when they need to require help from other developers those that previously were helped by them were got help from them and now they are knowledgeable enough because they received this help before so now they can either they can push this help further to new generations of developers and in the developers what new generations practically year after year because we get new people interested in development very fast so what I when I was coming to India what I started becoming interested interested in was the place of India on the map of ViewJS World so let's start with the first website which is called ViewPeople ViewPeople.org Hi Niko, Niko is the author of the website it may be a little slow on this wifi so let's make it bigger can we make India a little bit okay we're doing nice let's see where we have some developers I see some in Bangalore some in maybe it's Mumbai, maybe it's Pune I don't think I see anything in Delhi that's Delhi I was in Delhi and I didn't recognize it on the map it's my fault I thought it's slightly more to the self okay so let me ask how many of you are represented here great, what about the rest and if you see map of the whole world in India there are so many people and there are so many developers so why on the map there are not as many ViewJS developers and that's nobody's fault but it's we as community that currently uses ViewJS or is just learning ViewJS it's we who can change it because together we can make the community bigger and better not only in India but also around all the world how I like to say it View United we stand let's go to the next website okay before there are multiple ways in which we can help each other and one of those ways is the way of Rahul I call it this way my friend Amandip Desik from Delhi helped me realize that on my trip around India I'm actually following the path of Rahul because I ended up on the exact seat in Amandip's car on which Rahul on previous conference was sitting before me so let's try to follow the path of Rahul and I will ask you about libraries how do you think how many ViewJS libraries were created by Indian developers and we're not talking about libraries of Rahul which were a few I didn't know even one before today now I know because I heard about it here on the corridor so let's open ViewExpersist is the author here with us yeah can I why we are opening it is because I want it to be inspiration for you that even if the community in ViewJS isn't what I would call the mainstream of the biggest libraries and biggest communities around the world libraries like Naxt or beautify or Element UI each of us can still add a small piece of it each of us can still create that will be used by other people we can see 700 stars that's a lot of people that found this project interesting a lot of them use it in their projects we can see that they are open opening issues and that's the easiest way to okay but other than other than right in the library you don't have to just create a new library if you don't have an idea you feel that you won't be able to focus on it too much what you can do instead you can join an existing team luckily during the last year a lot changed in the community previously libraries were mainly created by one person maybe two two people collaborated with each other now those teams grow good examples are Naxt team which currently has seven people I think beautify team which is growing very nicely Quasar framework also has a big team right now and also in Vue.js core team we now get specialized teams for example the team working on documentation there are a few people and recently created a new team that will be developing new versions of ViewPress and providing support for it so this is another way how you can join the ranks of contributors to Vue.js ecosystem the next website can I ask events or okay find meetups okay and India we have Bangalore we have Hyderabad we have Pune how many of you are from Pune I'm not okay from Hyberabad I wonder what about other towns like Delhi, like Mumbai there are so many times that are very big and there are so many developers of course there are other developer meetups like JS lovers which are popular but we all can take inspiration from the organizers and from speakers who share their knowledge on those existing meetups India is such a big country that there is always space for additional stages on which we can allow some of us to grow as promising speakers who next year maybe stand with us on this stage or on other stages around the world like on View Toronto View London, View Amsterdam next website let's go to View Vixen this is a website that is very important for me because I notice among you there are a lot of guys but there are also women and next year when I hopefully come here for the next edition of View Day because I hope it will be a thing let's cross fingers for that there will be more women among us and that on this stage sharing their knowledge with us there will be also more of them so View Vixen is an organization that organizes free workshops around the world for women developers providing a safe environment for them in which they can learn View JS at their own pace and where they prefer and why I'm showing this is because so far there were no workshops like that in India my friend here from Bangalore was invited at least my friend here from India there's a possibility that she will help with organizing such workshops around India so let's cross fingers for her too and finally the last website I told you that this talk was not prepared before I learned that I will be talking an hour ago or so so this is just one last topic I was supposed to talk to you two more two more projects I'm showing and we end okay, join can I look online to my website to my account to the web client to the web client I just put my password so next way you can collaborate with view developers from around the world is our official VJS chat where I'm administrator and you can also meet Rahul there and what's good about the chat we have over 60,000 users there a lot of core team members over 50 library authors from around the world authors of tutorials event organizers where we all share our experience exchange knowledge help each other to either create new applications with you or organize something for the community if that's here, okay yeah, that was the secret one so you can see we have some rooms for event organizers for library maintenance and a lot of rooms on which we exchange knowledge most of it is in English but very low at the list we also have Hindi channel which is also in English so I would be very happy if you join our ranks and we have a very fancy logo which you don't see here but I have a lot of stickers left so if you want I will give them to you later and what do we want to see because it's not my account other than official chat of Vue.js there are also servers on discord for many more supported libraries for separate server for next for Vuepress for Vue.tify, Vue.material Quasar framework all kinds of other libraries together it's a can we open Vue.family Vue.family channel yeah at the very top yeah here's a list of all okay so Vue.front Vue.storefront, Saber which is also get interaction in Vue.community BootstraVue all kinds of other chats related to Vue.js where you can discuss with authors of the libraries in the more okay we'll finish so let's go to our last project can we open Vue.community Vue.community.org this is the last project which got published finally just a few days ago it was started a year ago and practically okay it was we started working on it a year ago but you can see that when you work on something together it's going much faster when we try to work on it just as one person or two people it's not going as good so Vue.community.guide is additional documentation that is meant to provide information written by the community and specifically for the community and about the community and the ecosystem so all kinds of information and questions that you wouldn't find in official documentation you will hopefully be able to find here for example how to tell my boss that I don't really like React and I would like to work with Vue.js these kinds of questions official documentation won't help you with but we on official Vue.js chat heard such questions all the time so we're trying to prepare a resource the strongest point of view is still a stop so we need to make it longer we're trying to provide all answers to such questions that are most commonly asked by the community and why I'm showing you this it's because if you want to take your first step into contributing to Vue.js community this is the easiest way because creating a PR and adding something from your knowledge and we have so many and experienced developers here who have different points of view on how to create applications what libraries to use how to best write a particular feature you can share this knowledge on this guide which is meant to be managed maintained by the community and by community I mean us here and you on the stage that's all from me I'm thank you for listening to me give me back