 journey. So let's hear it from him. Hi everyone. Hi again. So, like, I know you guys are sleepy. It's been a long day, right? So, like, another, like, I know I don't need to introduce myself, like, because you guys were here in the morning and you don't remember it. So I'm Vivian Rastogi. I'm a senior application engineer at Flock and this presentation is going to be an experience talk as to why Flock chose you for a lot of apps that we built. So to explain the problem statement, I'll need to introduce Flock to you. Flock is a platform for communication between teams, within teams. So the aim that Flock has is to make communication between you and your team better. And so basically it's a productivity suite. It enables you to be more productive. For example, if you have, if you have a Jira integration, if someone created a Jira that has been assigned to you, then you don't need to go outside of Flock to mark the Jira as done or maybe change the state of that Jira. So that's what Flock is. It helps you be more productive without leaving, without making more, without more screens on your cognitive load. So the problem statement is that we have multiple applications that help you be more productive, right? So, and they were, because there are multiple, productivity is not a single application problem. It's a multiple application problem. You've got to do, you've got Jira, you've got GitLab, you've got GitHub and you've got Trello and so on, so many tools, right? So many tools that help you with productivity. So all of those tools, how do they interact with Flock? That is through app integrations. And because there are multiple app integrations, which means that there are multiple applications. And initially for these applications, there was no defined framework that we'd use. We basically go with any framework that you wanted. Like, Jira was working with me in Flock and he even used functional programming once for a project. And we also used vanilla JS. We also used React to solve this problem. And then we've also used View. So the choices of framework were all over the place. And they varied from backbone JS to, like, everything to vanilla JS. So, and these apps are supposed to be a part of Flock, okay? And even though they were being built and maintained separately, they, we did not, we had to make sure that it did not feel any different. The user did not find that the look and feel of this application is different. So that is why, like, we needed to make sure that the whole look and feel integrated into the whole Flock experience. So this is an example of a channel. And there's a to-do list with that channel. So this is a to-do app integration which enables you to assign any task that you create or to-do that you create to any channel member that you have. So a channel is nothing but a group, like, a group-like feature in which you can add multiple people and you can discuss any projects related stuff you have on. You could even, like, add files. You could even, like, share those files with each other. And so right now here we have the use case of a to-do app. And, like, you might not need JIRA for, like, maybe if it's a small project, if there are, like, three developers and you might not need, you might not even need JIRA because JIRA involves a lot of workflows and you would need to configure those onto JIRA, right? So instead, why don't you just use that to-do app directly? So that's how the to-do app gets things done, like, if you... So basically the to-do app solves this particular use case very easily without you having to switch context, okay? But the extra challenges that we faced were that with other frameworks like VanillaJS, BackboneJS, maintainability was becoming a problem. Like, a problem in the sense that we had new, like, whenever we have, suppose, let's say we have three applications and in a day we were to fix three bugs in each of those applications. So it required a lot of context switching at that point. I mean, first you have to think, okay, let's let me think this in terms of Backbone, then let me think in terms of VanillaJS, then let me think in terms of another framework. So that was becoming a problem for us and we decided that we want to, like, you know, standardize. So maintainability and extensibility was a problem. The fact that we had a small team at that time, we... And we were definitely growing at that point in time and we needed speed. And because of these, like, multiple different frameworks, we knew that the build process was actually very, like, different for all of them. So that is why, like, we tried out some existing frameworks at that point. Like I said, like, we would already use Backbone and Backbone has been around for a long time. Like, last I worked on Backbone was in 2015 and, like, before last year. And I, like, because I'd been working on, like, other frameworks for that long and I had to go back to the documentation a lot. Like, I had to read up on the documentation a lot. And, like, in my opinion, Backbone required more code. Like, if you wanted to add a plugin or a base code and then extend it, then fine. But Backbone definitely requires more code. And Backbone, the problem with Backbone was that it could easily lead to spaghetti code. Like, if your code wasn't organized properly, like properly, then you'd end up with a lot of spaghetti code. Then there was React. So we also tried out React and already worked on React a lot. I mean, I know it looks, looked easy at that point in time. Like, starting with React is always easy, but there are always a lot of gotchas when it comes to React. Like, you never know what, like, what kind of gotchas you might end up with depending on your use case. And, like, for example, let's take the example of a life cycle method. At that time we had the component life cycle method called component will mount. So, like, do you make an API call in called component in mount? Do you set state in component in, in mount or not? Or like, where do you do all of that stuff? Right. So that was a little bit unclear. And basically there was a learning curve involved with yeah. And, like, it did, like, even though the documentation was good, but a lot of free resources were not available at that point in time. Like, if I wanted to look up video tutorials, I might get the basic ones, but not, like, really good advanced ones. So I needed to spend a lot of time on the documentation. And for the same thing to be done as compared to view, I felt that it required a lot of more code. But React had community support and really good documentation. So that's my takeaway from React. And another, another issue I faced with React was that, like, you have this, this funda called component and pure component. And the life cycle method, the method called component update. So you get to decide what you want when you want to render. And to me, that was just an overnight overload. Like, why do I want to decide what needs to be rendered. So what we needed was at that point in time, a unified framework for new apps. Basically, if we're building new apps, we wanted that it should be in this particular framework and a framework that accommodates a growing team. When I say a growing team, I mean that like this framework should be such that you could learn it in very, like in the least possible time and it has less gotchas. So basically, you'd want to do more with less code. And we also wanted that it, it should have good community support. It should have good, a good number of stack overflow and GitHub issues, a good number of like a really good documentation as well. And a framework basically with growing support. And we also wanted support for like project generator generators, a CLI kind of a thing to bootstrap any kind of project. If I wanted service work to be included into my project, I shouldn't have to like hard code it into the whole thing. It should just be there out of the box. If I wanted state management, I would, I wouldn't have to like go and go read the documentation and then add it by a code. So similarly for ESLint and Babel integrations, I wanted to have like from the get go. So, so yeah, so all of these things could come in with us good CLI bootstrap project. And that was the requirement of offer free work from like that was a requirement from us to that free work. So that is when we tried out a Vue JS. There were just three of us and all of us. We tried out Vue JS, which was like, I know like you had been around for a long time, but it was the time when we was gaining really like a good community support. So, so as with all new things, there was some resistance to adoption and like trials as well. So there were some concerns like, was there enough community support? Were there enough people doing Vue? Were there enough questions on Stack Overflow that were like answered the right way? And what about the performance optimizations? Like would be, is it performance? Does it have a good bundle size? Does it have a lesser bundle size? And does it do DOM diffing? So and so on. But to like, again, Vue CLI 2, which was there at the time, it was a game changer for like for us. We realized its power and how it made starting up of new projects because we were building multiple apps. It was important that we build those apps like and we have a good configuration from the get go. So Vue CLI, we realized that it made bootstrapping and deploying a breeze. So some comparison that we made with like Vue and React, because those were the two finalists that we had. For example, if you wanted something reactive in Vue. So it was as simple as like assigning it inside an object in data and then doing a this dot change that values. So that is how you achieve the reactivity in Vue and you could see that on the UI directly. But with the React, you have to do something like this. So basically a lot of code was like being written to achieve the same thing. Similarly, like one thing that really blew my mind about Vue was the computed properties. And if you already, I'm sure most of you must have used it already and computed properties like it makes things so much easy. And what it does is it listens, it subscribes to the value of let's say like greeting and name. So it subscribes to the value of both these changes and if anything changes, the whole component will re-render. The component will re-render. And the same thing emulated with Vue, sorry with React. You need to basically create a helper method inside your render and then like do the same thing. So what we found was that like Vue really fit the bill for us. Like some features we loved about Vue were that it had inbuilt DOM performance optimizations like the VDOM. And also performance optimizations like we didn't have to worry about component or pure component. So I'm sure like you must have already heard that in the second talk, third talk here. And there were computed properties like which completely sold us. The reactivity syntax, it makes things so much easy. You get to do more with less code, you're more productive. And so these are the some of the apps that we built using Vue. And the video confidence app, the Google Calendar integration, read by is when you want to see who read your messages. Files app, search app, the polls app, mailing list and reminders. So in conclusion, Flock loves Vue. And we'd love to build more apps with Vue if there are any more apps for us. Any questions for me? So why didn't you choose something really crazy like Svelte or maybe... To be honest, in 2017... It was there but yeah. Since 2017 it's been Vue for apps for like... I mean people have come and go in Flock but like I've been there so... So yeah, Vue is all the way...