 Good morning. It's 11 o'clock in Eastern State of Time, so it's time to start the functional group update for the front-end team. My name is Jacob Schatz and I will be representing the AC and the DC team, so Tim as well as myself. So I'm going to share this. Can you guys give a thumbs up if you can see this full screen? Great. See if I can. There we go. Okay. So some accomplishments, some things we've achieved. And I will show screenshots of these after the slide. The issue discussions was completely rewritten in VUJS, so the issue discussions is all the comments on an individual issue page and it was completely rewritten and it's already in and you probably didn't even know that we rewrote it. It has made the issue discussion pages very, very fast. So now when you go to an issue discussion page, it loads the page and then it loads the discussions asynchronously after the page is loaded and that has made the issue page faster initially but it's just the beginning of performance improvements that we will be making to that page. The group level issue boards went in and we fixed the merge request, widget compatibility with external services and integrations like Team City and Jenkins. The move issue button has moved to the sidebar and we now have really great consistent drop downs everywhere. Also we gave the service desk a new UI. So when you first go to the issue page, you'll see now this loading spinner which is going to change into what we call a skeleton loader and a skeleton loader you've probably seen on other sites which is where it looks like if it's an individual comment, it looks like the comment but there's these bars and it looks like it's like faded typing or something like that. So that's called a skeleton loader. We're going to be putting those in shortly and once it loads, it loads the rest of the comments and this is all done in VUJS and it has made it much, much faster already. Here's a picture of the consistent drop downs. You can see that also they got a slightly new look. They look really nice and the move button is now in the sidebar so this is on an individual issue page. You can see that nice move drop down and the group level issue boards is just really fantastic and here's the service desk UI. We gave prominence to this user interface. We have some concerns. There's still a lot of regressions on the front end but the number is going down a lot. We've done some research into regressions and how they happen and how they're created and if some are preventable and this is yielded tons of information which we will share soon. While working on deliverables is still an unsolved problem. It's a time management thing because there's still regressions to and there's still deliverables to deliver. Right now the only solution is to do less deliverables so it's something that we're currently trying to solve and then the other question is can we fix all the performance issues while still shipping new features? This is also another time management thing that it's something that we've been working on. So hiring. We are hiring two front end developers, one for Tim's team and one for my team, one for the AC team and one for the DC team. We're looking for mid to senior developers hopefully on the higher end of mid. So if you know anybody then tell them to apply and then you can put them down as a reference. Some cool stuff that we are working on on the side. The repo editor is happening. It will be going in. There's a link to a list of bugs. You should have a PDF of this presentation in the event. The CI CD jobs page proof of concept which is something that's really cool that Philippe is working on. So you now have these tabs on the jobs page that allows you to see multiple things and switch between them. We're going to be putting together a Selenium viewer. So this is something that where Selenium allows you to test on multiple browsers. And so from a front end perspective, it's really important to test things on different browsers, test things on Firefox on Chrome and especially IE, which if you aren't aware has the most problems classically. So it's going to be really fantastic in the future when people are saying I want to test this not just on, you know, I don't want to just test this test going through the command line. I want this to also run specifically on Firefox and take screenshots and show me the screenshots and let's see what it actually looks like because some tests are purely visual. And we're currently testing with Selenium. There's a proof of concept that Bryce has created where we're running all of, all of GitLab and we're just taking screenshots and just taking a look at them. And then we're running a diff, a visual diff, to see what's changed since the last version. And then we can alert people when something's changed. And then we'll see if it was an intended UI change so that we don't have as many regressions in our user interface. We're creating sheets for SVGs. So classically what happens is an SVG is loaded individually on the page. Now, all the SVGs are on one SVG. And we can just move to a specific area of that spreadsheet. And then we can just pull in that sprite and then improves performance a lot. And that turns into a huge optimization. And also what that does is that we created a separate repo for the user, for the UX people. They can upload their SVGs to that repository. And then it's going to get automatically compiled and included in GitLab. So then the work of the SVG creation and all that can go happen in a different repository. So it's a really cool idea that Tim put together. We're working very hard on performance. This is just a highlight of some of the things. We've done tons of stuff, but this is just a highlight of some of the cool stuff that we've done. Like I said, the issue discussion refactor, you can see that graph down there, that stand head included in his talk, was 2600 milliseconds went down to 1.9 and just the beginning, this from purely refactoring it in Vue.js. So the stuff we can do from now on is going to be huge. And lazy loading the images made a huge improvement because it means the images don't have to be on the page in the first place. They only get loaded afterwards. Some stuff that we're working on right now. There's a huge meta issue to check out the front end performance with network stuff. So we make tons of requests to the network. And can we make that faster? I'll have a screenshot to show you what some of the performance problems are there. When we load the issue page, there shouldn't be that much of a difference between 20 and 100 issues. But what about 1000 issues? We can't really support that very well right now. So we're talking about loading the issue page in chunks. And it actually works really well. And the chunks can be any size. That means that you load all the all the issues, but maybe 50 at a time, 100 at a time, 200 at a time, three at a time, it doesn't matter. The point is to not load all of them at once. And they're not going to get to the bottom that quickly. And if we improve the performance of loading the discussions, then we can improve the performance of loading them in chunks. So the thing is, why shouldn't we be able to load tons and tons of issues? Our competition currently has issues that have, you know, 500 comments in them. And what they do to solve that is they just cut out the middle comments. And it looks like a little page tear, and then you can load the middle comments. So there's different ways to handle this in the UX. And we're going to try and experiment with all of those. Eventually, we are also going to do the same thing we did with the issue discussion. We're going to rewrite that merge request discussion in view as well. And that will make a huge, huge improvement on the diffs. And on just the discussions on merge request, because the merge requests are classically slower than the issue discussions, but they're also harder to rewrite. They're more complex. So that's going to be something. Now this graph is crazy looking. But it also highlights something really important, which is just that you can see the yellow on the left hand side is all of the JavaScript libraries. They're all combined. You can see one called common. You can see one called main. And those are already combined. And we're still loading a lot of them. And you can see all the way on the right hand side, that gray bar that says discussions.json. So by the time we finish loading the JavaScript to when we actually load the comments, there's that big gap in the middle. And you can see on the bottom, all that is just evaluating tons of JavaScript. And so this is where we're at right now. And what we want to do is basically remove all that stuff in the middle. Because if we can remove all that stuff in the middle, then we can load the comments faster. So in one hand, this graph is really confusing. On the other hand, it's like, look at that big white space in the middle, we want to lessen the white space. And that's going to be that's going to improve the performance a tremendous amount. And I annotated what all the different things that are happening here. So this I'm going to take a look at the questions. Let me see if I can see my mouse. And if anybody has any questions, feel free to shout them out. Right, the, the, exactly an example of a skeleton loader is like what Slack does, or if you've looked at Quora, I think that's how you pronounce it, Quora does that too. Yes, comments. I meant comments. Thank you, Victor. Does anybody have any questions at all? I'll wait like another 10 seconds. What am I most excited about? Thanks, Job. I'm really excited about. So as an example, when I wrote the new repo editor that we're going to put in the merger quest for that repo editor is like almost unopenable at this point. It's something that we can't even like barely open because there's just so many, there's like 800 comments in it. And I'm sure that other organizations have the same exact situation. So I'm really excited to make these things just load really, really fast. I'm really excited about improving the performance of these things. And I'm also really excited about getting the repo editor in when it's ready. Because we really shouldn't have any issues or merger quests that are just unopenable. That's silly. Yes, the repo editor will be lit. I knew what that meant. Okay, thank you so much, everyone. Does anybody else have any questions? I heard somebody make a peep. Okay. All right, have a great rest of your day. Bye.