 So, let's start with our talk today, this is more about what are the various challenges that we have to face as a developer when we move from one framework to another, specifically Angular in this case. A quick show of hands, how many of you were working on Angular before? So I can say how many? Oh, it is absolutely well known. So, React did come into a space where there was a lot of class going into Angular and we were a lot of business decision makers and they were thinking about whether to go with Angular or React and we were pushed from being an Angular developer into React and things suddenly changed for us, right? And there were a lot of challenges faced by us and how did we move into it? So, hopefully this talk will help a lot of people who are jumping framework going further. So, this is actually one good thing that I always refer to and this is for relevant to our situation. This is why Agile's Money Guru is another strong developer. He says, first do it, then do it right and then do it better. Why is it relevant to us? The thing is, when I was an Angular developer, my manager asked me, can you put in React? And I was like, okay, my code is working so fine with Angular, I know Angular so well. Why do you want me to come into React now? I love to learn a whole new stuff again. And this all in that change is very strange. Again, bring up a new book and start reading of the whole thing. It's lovely to YouTube and start watching Angular people videos. It's a big pain actually. So, but then we as knowledge workers, this is kind of our knowledge and this is what we use in our work and like, you know, upgrading our knowledge on a concrete basis is a part of the process. So, why I've got to suggest, if you can see the good thing, when you say first do it, this is how it was before, plain JavaScript was even just get it done. Like, you know, if it was going to validate for password, this is the way to do it. Then Angular came the day saying that, you know, you do it right. Like, you know, we'll give you data binding and a lot of frameworks around your development. You do it the right way. And then React came and said that, you know, you can do it in an even better way than how traditional frameworks are working. So, a quick look into how my life has been pre-2012. So, I've been associated with the product and development for quite a long time, but in 2010 there was not much of a change, right? Like, if you see here, till 2010, we were actually recording more things, again, JavaScript. Generally, actually, each product is quite a lot, right? Like, plain JavaScript, it was more about if I enter a password, it will check for whether I have entered the letters and numbers, whether I have capital and small letters or not. There was not much of a business logic on the front-end side. But then, with jQuery, things became much more easier, because now we could query our DOM elements so much more easier. Earlier, it was document.getElementById and, like, we proposed a statement. Even with jQuery, we had Ajax coming in, which was actually a lot of ease for us to make query for API servers. Then, while we were still on jQuery, there was a lot of development on the user side. The user wanted more from the content side. Like, they wanted animation, they wanted gradients, they wanted a lot of fluid UI. This is where HTML was kind of lagging in, because HTML5 was still not there. And companies like Microsoft and Adobe, they came up with Silverlight and Flash, and they came up with the concepts of animation, gradients, and they came up with patterns like MVDM. And that was also when we had data binding introduced by Knockout, and that one actually came up with a big bit, talking, like, trying to modernize our UI code into model re-controller, which was now available mostly on the backend side. And then, around this 10,000-year-old time frame, Angular 1.x came up with a big bit. I said that, okay, whatever pattern you are using, we will actually provide you an entire framework to create complex UI applications. And that actually worked for a long time. And what really proved me to Angular 1.x at that time? Oh, I think the blue text is not really visible, right? Yeah. Okay, I'll just read it out. Anyway, it's too much to read. So the main thing is the magic of two-way data binding, right? When I say magic, it really was magic, because we didn't know what really was happening underneath. Like, we would just use the scope variable, and we'd say the scope for dot greetings equal to heliport, and it will magically show on my UI. Nobody really cared about looking at how the things were working. And this was really a big one for us, because now we could concentrate just on the business logic, and my UI would keep upgrading itself. And this actually laid the foundation for building a complex UI application, because imagine doing all these things with plain JavaScript. It's not that impossible, because it was not really a maintainable code, but now we are getting into a more structured UI programming. Similarly, it was using HTML templates that we were already used to. And applications like this became quite possible. This is a simple page application, wherein earlier you used to have a web page with all the links. So if you're going to go to a new URL, your entire page is replaced. But now, instead of having websites, we started having web applications. And this is one example here, which is more like a spreadsheet style kind of an application. I can just move my mouse around and do things on the page, and it just auto-updates without refreshing the entire page. And this was a big boost in user experience. There's a lot of things, and they actually created an ecosystem. It was more as a framework rather than a library. So we got support for router, internationalization, accessibility, and then there were a lot of material design concepts and a lot of code libraries supporting that. There was animation, and there was a bootstrap, gave us a responsiveness, and IroHandling was there, lately loading, there are a lot of browser tools which were available to debug our application. Because now our application was getting complex, more complicated in nature. So we wanted better tools to debug it. And then Angular was actually created by the testing team in Google. And that's why testing was kind of a foundation in the framework. And they came up with really a set of good test runners and libraries for Karma and Protractor, which allowed us to test our applications so well. And then there were other things like generators and then the whole new concept of mean stack-in, varying now to the stack-in thinking, how about JavaScript all throughout, how about JavaScript on the database, how about JavaScript on the node side, and even on the UI side. And even hybrid applications became a possibility. And then it was all maintained by Google. We were, you know, quite safeguarded around that and there was a good traffic community. But then suddenly this happened, right? So like Angular undertakes this, and now they have to switch on to 2.0 which is common in the name Angular, but there was nothing really common between them. And then they said, you know what, even there is not going to be any migration part. And this kind of was a big jitter to a lot of business because they said, what are the investments that we have done today? And more so, like all the new positions inter-thinking, like, you know, what do we do to the new projects? Like, do we still continue with Angular or shall we leave for option? So, and also, like when Angular 2.0 came, it was actually in a new language called TypeScript from the Microsoft base, which was a superset of ES6 like JavaScript, but it was not really, like there was a little bit of learning to get the concepts right. And the good thing about Angular 2.0 it's almost series the CLLA, that actually kind of at least eased out the way a little bit, because now you could develop applications really fast with the help of the CLLA. And while this change was happening, React starting was actually very nice, like it actually came in the time when it was really needed. And it made us rethink best practices, like till now, we were naturally thinking of UI side as really complicated applications, and I know you have to, you have to think really about the performance side. We were only thinking about how to get the job done, but React came up with a very concept. The first thing that came up first, it was the myth of separation of concerns of HTML and CSS. Like till now we were always thinking that, okay, you know about presentation, JS is my behavior and CSS is my styling. There are kind of three different concerns for my UI application and they should always be kind of separated. And that is how we were going to handle activation complexity, that was the notion. But then React side, you know what, if you are using Angular and other template frameworks, then you're always inserting JavaScript inside your HTML. So that separation of concerns, then it is gone. And if you are always trying to think of missing tools, why not have HTML inside JavaScript, rather than the other way, because JavaScript is a much more powerful language and much more expressive. And this is again, DOM render performance took a center stage. Like till day, we had never even thought about, you know how much time it takes to render a DOM. Because it was never really a concern. Like even if a page renders in 10 seconds, it was okay for us. Because we were only thinking of getting the work done. But now that this foundation was laid down to create complex UI applications, now we have started filling these field points of what is I have a lot of components on my pages. I have a lot of pages to show. I have a lot more complicated page structure. In that case you have to handle a lot more models on your own business project on the UI side. Is it possible with the existing framework? We were actually seeing a lot of delays. For example, AngularJS 1.x could not handle more than 2,000 models. And we were actually hitting 2,000 in a lot of real world applications. So react was based on the concept of virtual DOM where in the time concept was to make sure that we take care of the performance of DOM rendering well. Like instead of trying to render DOM in any kind of new detail we kind of handle it first on the JavaScript side and render only what is required. And this was actually a big crowd pooler. And then the concept of components. So not that concept of components was introduced by React. It was already introduced by Elbert before and even Angular. But then React actually came up as more as a UI library and they say that you know what the first thing about your UI page is to create components. And then after they say that you don't even think about it as a page, you think of it as a screen in front of you and how do you divide that into components. And then JS says give you the kind of an abstraction saying that you know what instead of taking off your UI in developing using HTML think of it as an abstraction which is similar to HTML but there is an abstraction so that it can create application now not just for web but also for VR and other platforms. So these were actually the things that actually drove me also to jump into the React side of it. Like the virtual DOM the performance of the hitting algorithm. The concept of emotability that came with React that was really nice. Like it was really something we were doing for the first time and that really handled performance of the application really well. Then there was server side rendering which was supported in React and again this was this is something that posted the search engine optimization very well because in most of the single page applications we were facing the problem and initially the HTML test was coming and data was coming later and my search engine was not really able to pick up the data when it was rendering for the first time. So Angular kind of picked up but this was there in React from video and then the concept of a one way data flow this was also kind of very new and quite exciting for me also to jump into. Let's go to jump into what were really the pay points that we had. So the challenges that we faced so all the good things about React that we shared good things today they were actually challenges for us that we really started because they were all very new for us to get into. For example, React being all opinionated is actually a good thing that you can use your own components to build up your framework but then when you are new to the system you really don't want to invent that much of time into that. So that is one of the challenges then the other one is understanding of JSX because JSX is a little different from HTML or JavaScript. So you have to get a little bit of content and it did really have the concept of HTML template that we are so much used to till now. And then how do I mobilize my complex applications because till now I was really used to have important with Angular modules how do I break out my code in React this was again a concept that we have and then we have also kind of supporting the idea of having CSS in JS which was not really there before so these are the kind of things that actually were a little difficult to pick up what about state management using stored which was never even heard of before and especially the one way direction of your state application state. So these are the concept which are a little difficult to pick up and earlier not many UI libraries were there so and again how do I handle response units in my application these are little bit and heated which are blockers even currently the React React apps here like doesn't really have support for SSR and they have written for it like because they don't want to keep it opinionated for SSR but there's a lot of people who want to have SSR support they don't face problems and they have feedback out of this here or use some and then they want to have SSR components these kind of ads keeps adding into my overall payload so basically if I make a thing between how Angular and React they match one to one like React doesn't really propagate so much about type safety but then the IPvg what you have then Angular always goes there on type then again you have RxJS versus Promise on the React site then these two CLI compare pretty well and although we say it's library but I think now with the advent of the new CLI it is not really a case anymore like React has kind of bits of the entire framework for it so what we are saying the case is React native because earlier React was saying you learn once and write anywhere that is how the concept of React was but React native came up with the concept of write once and deploy anywhere this was possible because of another library called React native where have you ever used it you know this okay so that's a wonderful idea to definitely type around React native that will allow you to deploy your application on Android IOS that in any case by React native but even on web and naik on other bigger disk space with the web thing so that's it in my case yeah and auto-upgrade was possible now for React native so a lot of good things coming up here that's the end my talk saying that you know these kind of changes still keep happening there will be something something else which will be much more exciting as other than we grow in the UI area there will be a lot of more demand for our application so keep embracing changes and look out for more things