 My name is Jacob Schatz. This is the front end functional group update. So at the front end, we have a couple of big goals. One is to ship awesome features and the other is to make GitLab faster. So in the vein of making GitLab faster, we have what's called the big front end plan. And step one of the big front end plan is complete. So that was webpack is in. And everything that we put in obviously has to solve a problem. So we can't just throw things in without solving a problem. So we have full ES6 support, which means that we can write in the new JavaScript. We're going to put yarn in, which is going to solve the NPN bugs that we've been having, which locks the dependencies, which is similar to what Rails does. And we're going to have karma test coverage reports. We also removed turbo links. Turbo links was causing a lot of front end bugs, and now it won't. So that also is a thing there. I can't totally see. I'll look at the chat afterwards, because I can't totally control it at the same time. So right now, unofficially, once we put webpack in and remove turbo links, things did get faster. There's going to be situations where it is slower, but that's the future is to make that faster. So steps two is to make it lab even more fast. So with these things in place, we can now do things like code splitting, so making sure that the JavaScript pages only have the JavaScript that they need instead of all the JavaScript from everything, which is the way it was before. So smaller file size per page, less JavaScript. And we're going to make certain pages, single page applications with View, which is going to be a better UI experience, which means we're going to write less code with View. We're going to compile less JavaScript, follow smaller file size, faster code, et cetera. So this will make GitLab a lot faster. So the result will be less code, faster GitLab, better UX. So our first spa stance for single page application is the merge request widget, which is something that Fatih is currently working on. So right now, the way the merge request widget works is you click merge, and it refreshes the page. It's not very reactive, and it's kind of slow and chunky. So instead, it's going to be one thing where you click merge, and it merges right there. And then eventually, when we make it real time, we'll be able to make it real time, and it will show that it's merged for somebody else who is looking at it unmerged, that sort of thing. So this is our first single page application that's currently in the works with the whole Webpack Remove Turbulence View situation. So we also have a bunch of other features that we're putting in this release, which is the deploy boards. We're tokenizing the filter search. We're fixing up Drop Lab, and there's a whole lot of other features which product has already talked about, so I don't need to keep repeating those things. Some of the concerns are that there isn't enough back end bandwidth at the moment, so we are going to help out where we can else present the solutions after this. Webpack isn't perfect, obviously. We'll need the Webpack people to improve themselves over time, which they will. The question is, will it get fast enough for us? Will it be a low enough RAM situation? And will real time happen? Because a lot of the stuff that we're doing right now is preparing for real time, and we really want that to happen. One of the other things is we haven't always had an architectural step, and we really need to have that. And please don't delete my repos again. That's just a completely separate thing. So some of the solutions to these concerns is we put in something called API Labs, and we have other solutions that are similar to this. So not everybody has to use API Labs, which is the bottom line, as it's helped us finish front end work without waiting for the back end. So for the first time, we finished several issues with a mock back end in place that the front end was able to give to the back end. And then the back end can use that JSON that everybody agreed on, and they can make that. So I'm actually reviewing code where the back end isn't done yet, but I can run the code as if the back end were there. So this saves us a ton of time. We're starting to look at the performance labeled issues and debugging SQL queries to help out the back end devs, which thankfully, there's a lot of awesome performance tools in there, and we've done a couple of demos on how to do that. So that's going to be in the works. We have a front end performance monitoring system similar to what the back end has. That will report to Prometheus. That will also tell us more front end specific things that are slow. We've added an architectural step so that every front end thing has to be architected properly so that when it comes to the time that it's done, we all agree that that was the best way to do it. And we're learning Rails and Go. Currently, I think we have two front enders learning Go and five front enders learning Rails at the moment they're taking some courses. So we have some really big UI changes for 9.0. Obviously, you have the side nav that has been moved to a dropdown, which is a big UI change, and it's happening. We have a bunch of other UI changes where we're moving a bunch of different navigation elements around, and so that's also happening. And I'm going to open it up to any questions. And let me just look at the chat here. I can figure this out. I'm gonna stop sharing the way I can control this better. Can you still turn the nav? No, you can't pin the nav bar because the nav bar will be gone. Yeah, but you can open the nav bar any time you want. Right, so if anybody has any questions, let me know. Jacob, these are awesome changes and it's great. I'm very excited about the future of front end. API labs and drop labs was new for me. How do our contributors that might want to use the same things find out about these things? Yeah, so drop lab is just a dropdown library that we use to replace our other dropdown that's trying to provide one dropdown solution. So that is an open source library that we're currently trying to properly document and put in there because we have a lot of dropdown problems and we're trying to make sure that we don't have dropdown problems anymore. API labs is something that's experimental and that is currently also open too, I believe. So Eric is the one who put together API labs. I just Googled them, I understand what they are. They're awesome, I like it. But how do people find out about them? Would it be an idea to have in our handbook have a front end page under engineering and then link from contributing to that to say, hey, here's certain things that the front end team uses because right now it's hard to, if a new person onwards, how do they find out if a contributor adds something that there's no venue to find out about these things? Absolutely, we'll add that in, that's a great point. And regarding the hiring stuff that was mentioned, we currently have stopped hiring for the front end to kind of, we have enough resources on the front end at the moment. I'm sure that will change. So right now the front end engineer position is closed and then we're also hiring a front end lead to join me and help me out. So that's the situation with that, right? And when do we expect the constant UI changes to stop? It's often hard for some customer and prospective customers to deal with that. We've definitely heard that before. So what we're trying to do is we're trying to make sure that any of the big breaking changes, because like this sidebar thing is huge and it's breaking and it's different. So that's why we're trying to do it in 9.0 because 9.0 is the breaking changes time, not just for the API, but also for the UI and the UX. Right, so that's why we're trying, yeah, that's why we're trying to do it all for 9.0. We're trying to like make all the stuff happen there. The reason for removing the sidebar, I don't know if Allison is on here. She could probably explain that more. But I would defer to her for that, but the reason is that it just makes things easier. We had a lot of, we got a lot of feedback from a lot of users and tried to figure out the best way to use that space and right, it's, yeah, it's been in the works for months, but there was a lot of research that went into that and there's obviously issues and discussions on that as well. It wasn't like we woke up and we're like, okay, let's remove the sidebar and see what happens. Cool, I don't see any other questions. Yeah, we could write a blog post on Drop Lab and we definitely have a couple of blog posts in the works and really cool ideas. The front end talking to the API instead of Rails controller. So that's, the backend has provided this really, so with view, obviously view is going to be talking to JSON instead of downloading HTML and JavaScript that gets loaded into the page because view consumes, or it doesn't have to consume anything, but in our case, view consumes JSON. So we've worked with the backend and the backend put together this really great serializer so that it's really easy for them to make JSON responses to our code. So we're not consuming the API, but we are consuming JSON that is now has a standard way of being done. Regarding the color differences in the background for the sidebar, I will defer to Allison for that. Right, so one of the things that's talked about is like, is there gonna be a difference between EE and CE? One thing that we do have is we have a Fabe icon that is different depending on whether you're local or how you're running GitLab, but similar to what GitHub has is the black header. There's a discussion as to whether we would do that. That's something that's still in discussion. Cool, and Drop Lab will eventually be published to NPM. Cool. Well, thank you very much. I appreciate taking the time to listen to me and everybody have a great rest of your day. See you in the team call.