 I am Ashreth. I work for OlaCabs as a tech lead in the consumer web division. Today I am going to speak about how we use OlaCabs, how we use UJS at OlaCabs. So before I begin my actual content of the talk, I want to set some context. So basically last year I gave a talk at JSFOO about how we built a PWA for OlaCabs. So during that talk I covered a lot of parameters on how we chose our framework, what were the benefits and what the journey was. So you can go and check that out on YouTube. So the reason I am mentioning this is because this talk is sort of a continuation on that. So I am going to highlight on the key aspect from the last talk. That was which framework did we choose and how did we choose it? So first we considered Angular 1 at that point. Angular 1 was a good framework but it had problems rendering large lists. It also had digest loop problem. But we had good in-house expertise in Angular. So that is why we had considered it first. But because of its problem, we thought we cannot go ahead with that. We will consider something else. So next choice was React. React was a very good framework with unidirectional data flow and also virtual DOM. So the render performance was also really good. But at the same time Angular 2 came out. So Angular 2 had incorporated unidirectional data flow but had retained two-way data binding. Or as you call it today as reactive programming within its component. So that was best of both worlds for us. So we built a POC for the OLA PWA using this. And we ran performance tests on it. So what we found is that it was a good framework but it was very heavy. It had around 30 kb of polyfill and 198 kb of Angular 2 code. That is library code. And our sample application that we had written it was around 50 kb. So this was a very large size considering that we wanted to deliver this application on a mobile platform. Of course by AOT and tree shaking, this size could be reduced. But still the abstractions in Angular 2 made the render performance difficult. So we were looking for something lighter. That is when we looked at Vue.js and Polymer. So between Vue.js and Polymer there was a very tight competition. They had very similar performance characteristics. It really boiled down to how we wrote code in this framework as opposed to the framework itself being a bottleneck. But we went ahead with Polymer. Another rationale behind this was that our historic traffic pattern. That is we didn't have to worry about old browsers. And also for OLA, the PWA was supposed to be an experimental, futuristic and an acquisition only channel. Because of which we didn't have to worry much about supporting old browsers. So with this we built a very good PWA and it was showcased in Google IO as well as last year JSPO. So let's pause this recap here and take a look at what happened after that. So OLA as a company found that web is a reliable platform. It has a very good performance and the time required to ship an application to production is significantly less as compared to Android or iOS platforms. So that is where the mandate for web generated. So what we wanted to do was replicate the capability and best practices that we found while doing the OLA PWA across all projects in the organization. So that is when we took a look at how our web stack was at OLA. There were the fragments, the whole frameworks were fragmented. So there were different teams using different frameworks. Even in a given team, there were multiple projects using different frameworks. So we felt that we need to have a common framework. So it was an effort to streamline and standardize the web development process across our consumer vertical, across our supply vertical and all other internal websites. We also wanted to use the same framework across our desktop and mobile and app web use. We wanted to give our developers a way where they can develop test and deploy applications at scale. So we didn't want the developers to go through choosing a framework cycle every time they develop the application. So with this in mind, we thought what can we do? Of course we can start writing our own framework or we can write some vanilla JavaScript and enhance on top of that. But all of this is like a large cost to the organization. So what we did is that we thought there are a lot of good frameworks out there. So why don't we leverage them and not reinvent the wheel, but we'll just tweak them to our needs. So one of the main thing that we learned is that web component is a very good architecture in terms of delivering web applications. Next came intercomponent communication. So with our web experience, we found that if we are doing something like unidirectional data flow, that is parent to child props and a child to parent events and use a store for business data, that is a very good scalable architecture. Next is data driven reactive coding within the component. So we didn't want to lose out on that. Also the mobile web performance should be out of the box. That is an individual developer should not be worrying about how to deliver a performance web application. Also we should be able to leverage the lazy register of a component that was present in polymer. So with this, the developer should be able to code and run. And but at the same time, he should make conscious decisions regarding to the page load performance. That is, he should not be sending down additional JavaScript, which is not necessary for the critical rendering path. So he has to choose how to load the files. So this is a choice that we will give to the developers. Next, we also had a buy-in from the design team. So we what we communicated to them was that we were going to have a central framework and we want to reuse libraries across the multiple projects. So we want your support so that the design that you give will be where so that we can leverage on previous projects. So other minor requirements where something like we wanted to leverage HTTP to so we had an infrastructure support for that. So also Ola is supporting local languages and we are also going international. So we wanted to have that support as well. And in case we wanted to make a PWA, the same tool should be able to support that as well. And we wanted to integrate it with our build infrastructure so that developer doesn't even have to worry about how to get it to staging, how to get it to production, how to debug, how to set up the logs, how to scale up and scale down the number of servers. All of these components were also part of this, but this doesn't pertain to view assets. These are general framework, which is framework agnostic. There was also one another requirement. Now that we were writing a unified framework. So this had to be compatible below Android 5 web views because our traffic pattern indicated that we had a significant amount of users coming in on web views below Android 5 as well. So now this was these were the requirements. So the key points that we were looking was that the framework should be of a small size. It should also have less abstractions and complexity. So obviously we had seen other frameworks and we were in we like the philosophies of view and polymer. And so this time we had to choose a view because of the browser support constraint. And this is how we are going forward in securing our web future. We will write our code in Vue.js and we'll develop it in a web component style. We are using Vue.js in a single file component style and that we will deliver applications like a traditional compiled JS. And once the browser support for all the web components come in, we will still be writing our code in the same way we do. And at that point of time we can reevaluate our position and see if there is view is also supporting web components build by the way. Is it view or polymer or any other web component library in the future. So this way I will ensure that my development pattern doesn't change by much. It's only a little bit of syntactic sugar that individual frameworks introduce. Other than that, my development style, my performance patterns, all of these remain same. So Vue, so to talk about Vue, Vue is a very good framework because it was inspired from angular react and polymer. So it took best of all the frameworks and gave a good default and gave a good default build system. So if you're interested in knowing more about how Vue compares against your choice of framework, you can go to Vue documentation and check out that section. So it is a very well documented section wherein you can read a lot about how it compares with your frameworks with other frameworks. So single file component is a development style wherein I can write the template and that is your HTML and your script and your style in a single file. So this sort of development has a lot of benefits. It's easy to use because everything you want is in a single file. You don't have to switch between tabs. You don't have to wait for a lot of compiled or like complex CSS to be rendered. Also polymer and Vue that is basically web components library suggests that separation of concerns need not necessarily mean separation of file types. You can pack all the CSS and JavaScript and templates in a single file and still have a separation of concern with respect to the business components. But you don't necessarily have to separate out file types into different silos but rather have a compact single functional unit which makes debugging easy. And the best part of it is you can pick and drop it into another project. Next, as I mentioned that our developers will have to make a conscious call about how to load the assets required for the performance for the page to perform. So first I will load Vue runtime. So Vue runtime is the one which does all the framework related tasks of Vue. Vue router is a client side loading a client side routing library and UX is a state management pattern. So once this is loaded, next I will load one web.js. So this is something with with Ola specific code and certain Ola specific modifications on one web, which is particular to us. Next I will load router store and app.js. And once app.js is downloaded, we will decide what are the components that will be loaded next. I usually load a Ajax library and then rest of the components that are required for the homepage to be functional. And then we lazy load the rest of the application code. So this way of loading ensures that in my critical path, I am making a conscious call and my page performance is guaranteed in a repetitive way out of the box. So every project that we do implements this another feature that we are using from view is the declare first load later, which is present in polymer as well. So let's I'll give you an I'll explain it with an example. So you will have your root base component. There will be a first parent top component, right? So in that you will declare some component like which is necessary, not necessary for the critical rendering path, but it still has to be in the parent component because for it's a reusable piece of code and child components send event to that and it will be utilized. So it may not be in the, for example, Ola notification web component, which is not used in the first critical rendering path nor in the first usage by the user, but it still has to be in the root component. Now what happens if I include it in my beginning only so it will it will hamper my critical rendering path so I can declare it in my main component and I will not download it in the initial part. But I will rather download it later and once I downloaded it later, it will the moment the download is complete, it will react it the component will get activated and start for performing its functions. So this is not going to cause any console errors. So in a typical day, we don't have any decisions to make when it comes to framework. So whenever we get a new project, we just clone our starter pack and we start writing our application logic and we don't even have to be worried about performance because performance patterns are the best patterns are baked into the framework. And we have a shared design language and component library across teams, which makes our development speed really fast up over a period of time. So initially we took some time building a critical mass that is we had to build a certain amount of library common buttons and various other components. But once that was done, now we are at a place where we are delivering applications at a very good turnaround time. Also, because now we have a unified framework across Ola, the engineering folks can move across teams and contribute in terms of crunch. So this framework initially was used by we made a POC of it and we tested out in production in one or two applications. And now it has been it is and it was well tested and then it had a worldwide adaptation. So everybody in customer and supply and even the internal teams web portals are on one web now. So there are around 20 plus projects which are running one web along with Vue.js. So let's take a look at some of the pages. So the first one is a single sign on website, which is powered using a web view of using one web. And the other the next screenshot is your track right screen. So when you book a cab, you will share your right details with your loved ones and there is a track right link over there. So that that link is powered using one web. So after this, we wanted to reduce the time taken for turnaround in Android and iOS applications. And we started to use web views instead of developing it natively for certain screens where which were not in the critical flow of the booking. So this view this view is for merchandising view wherein we show the features and facilities that are available in the that are available in the in the given city. So this is powered entirely using web views built using one web. So once we built this there was confident the organization got confidence on web platform and we started getting more and more web views to be implemented. So here you can see that donation and insurance web views which have API functionalities as well also implemented into using one web. Furthermore, we have launched new categories in both Android and iOS platforms by developing developing the flow booking flow on web first and then implementing it on native. We also got a permanent like place in Android and iOS apps for certain critical flows like GDPR GDPR is the regulation of data protection in Europe and UK. So here this particular flow is built using web views. Also the two factor authentication which is a critical component again is also being used via web views. And of all the integrations food panda integration was quite a large one with respect to scale. So as you can see along with the category you can see a food panda icon and also the food panda information bar. So when you click on that a full fledged food panda website is loaded in the web view and you are able to order inside Ola app. So this was a very big project wherein we built an entire website using one web. So now let's talk about how the performance works on what is the performance matrix of one web. So Google performance standard says that you can effort to send only around 130 to 150 kb of JavaScript on a median internet connection and at median internet medium median phone that is your slow 3g connection with 400 kbps speed and 400 RTT and a Motorola G4 phone. So our let's take a look at one web footprint. So the common library is around 33 kb some lazy loading and Ola specific library code is around 3 kb gzip. All the values are actually in gzip. So that is around 36 kb of library files. After that this leaves us a healthy 100 kb of application code that we can send during the critical rendering path. So this way we ensure that all the performance patterns are baked in. So now let's take a look at some numbers. So if I ran web page test on various websites. So the e-commerce website that is PWA which had some performance that was performed out of the box performance. No special efforts. It had a start render of 3.2 seconds because it was using app shell. It was interactive by 15 seconds and document complete that is HTML was parsed was completed by 40 seconds. And the page size that was sent down was around 1.2 MB. Next Ola website built in a non one web framework. It had a start render time of 12.9 seconds and it was interactive around 16 seconds. So next Ola PWA. So this is a website wherein we put a lot of effort in optimizing the performance and that had a start render of 2.4 seconds. And rest parameters are also very good. Our regular view PWA which was built. It didn't have any special performance tuning or tweaking built in. But even then it had a good start render of 6.4 seconds and interactive by 10.21 seconds. So on a one web website which has default performance patterns baked in but no additional performance tuning done by the individual developer. But what the framework gives me and what is if you just follow the standard pattern of development what we get is around 2.8 seconds of page of a start render time for with app shell. If you are not using the app shell then it is around 6.9 seconds. But the page is interactive by 7 seconds and document is complete by 7.2 seconds. And we are sending down only 125 kb of total page total page size. So in this way we can see that I am able to so this is a good number. It's a decent number and I have not put any individual developer is not going to put additional efforts on getting this number. He just has to clone the one web starter pack and start writing his application code. And we have seen that this number is consistent across all projects. So this is a graph from one of the applications. And you can see that most of the practical page views values are around 3.58 seconds. So page load is completed within 3.58 seconds for most of the folks. So there is a concept called mythical man month written by Frederick Brooks essay on software engineering. It says that in a given project by adding more people you are actually increasing the complexity of communication. And it also could potentially hinder the delivery time. So this concept it holds true for your traditional web app development method in monolithic environment. But with single file components or web component architecture development style we found that we could break this barrier by a great extent. So if I to give an example OLA PWA was built by three engineers for three months. So that was around nine months of effort. Whereas the foot panda integration website that we did it we took nine engineers and we completed that project in one month. So the same amount of effort was done by adding more engineers which means that the mythical man month philosophy doesn't hold good when it comes to single file components. It it's a it's a very different way of development with single file components. So with this we found that view is able to satisfy a lot of our requirements given that view is a framework. View is a frame is a progressive framework. So we use it in a single page category launch website as well as to a full-fledged single page application. So this is the team that developed one web. So the folks there are folks who are not in picture as well who have contributed to one web. So that's about it folks.