GitLab Pair Programming - Frontend, 25 Sep 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: FE Pairing - 20200925 - Optimizing Webpack Chunks

Description

In this video we discuss a lot about optimizing Webpack bundling chunks and observe that GraphQL is being loaded in every page specific chunk.

Here's the resulting MR:
https://gitlab.com/gitlab-org/gitlab/-/merge_requests/43421

A

Let me end: okay, hi everyone, um I'm just closing some windows and moving slack windows so that I don't expose like stuff that we don't want to have on the recording, like private messages and download folders um and uh nico asked asked me why the bundle size in one of his mr's in increased like dramatically and um and we're going to have a look, how you know how, if you get such a report, what what does ip actually do and what can you do to maybe have a first understanding of what actually happened.

A

So I'm just sharing my screen, and this is the merge request.

A

So you can see here here. We have a report, the bundle size here increased by 400 kilobytes and um on this page and uh we're basically just adding a few uh graphql things, um and it seems really weird that the size increased that much so, let's dive into it. So generally, if you have this bundle size report, there is the full report button which gives you a nice similar view to the markdown comment.

A

But what's really essential is that um here you have a list of all the chunks that are actually loaded on that page and if you are.

B

Are these sizes, the all the chunks, or is it just that single chunk.

A

So that's that's the thing.

A

So, basically, if you're going on the pages project, settings ci cd show, all of these chunks are loaded and the size to the right is everything except the main chunk, and this is historically um we when we started doing the bundle size review and maybe we should change it in the future, is because the main chunk is now really small back when we started the main chunk was like eight megabytes and it was really confusing um um if you had like a chunk that grew from eight megabytes to you know eight and a half megabytes and you're like.

A

Why is this you know or like the the entry point right uh terminology is hard. um It was a bit confusing, but now, given that the main chunk is smaller, we might be able um to edit. uh Maybe we should just change it so that if you have one entry point, everything is considered to the size of the entry point, because if you actually look at the size of the largest entry points, you have to add the the size of the main chunk in your mind right, so we're not loading 10 megabytes here.

A

We're loading 12 megabytes and then, on the other hand, we're also not loading 12 megabytes, but it's less because um this is the raw size and not the past size. um The path size would be very interesting, but it's very hard to get past size would be. How much characters is the abstract syntax tree right, and then we have the g sub size, which is like how much stuff goes down the pipeline.

A

So actually, what would be interesting is the past size, um but as these all kind of depend on each other, you know if we send four megabytes down the wire and it's eight megabytes past and uh the raw size is 10 megabytes. You know it's still like larger is larger. So right, like you, can you you know. This is obviously about 10 times as large as one.

B

That is three one observing, so you mentioned graphql we're saying we actually load graphql for every we don't load in the main bundle. We don't.

A

B

It's it's in all specific.

A

Page chunks, so yeah now now also some more things. What are these chunks right? um So the main chunk is the chunk, that's loaded on every page, and we have these other chunks, um so you can, for example, clc. This is basically the the chunk. That's loaded that loads the stuff. That's just on the page and I'm putting air quotes here um for reasons we get into in a second and you can see what what happens- um and these are basically the comments.

A

Ones are shared chunks, so you, for example, see hey the pages project licenses index and pages project settings. Ci cd apparently share some code and that shared code has been put here. So if you actually visit this page and then go to that other page, you know- and this whole chunk, let's say is 1.5 megabytes.

A

You don't don't need to download 1.5 megabytes again right, so this is basically like the thing of cash ability and where do stuff end up and this all these common chunks are basically chunks that are magically generated by webpack got it, but because we have a lot of entry points, it might be that these common strongs are sometimes small and it might- and this is what's happened here- it might uh lead a situation where certain things don't end up in common chunks that potentially could end up in common chunks and in this case graphql.

A

B

Yeah, so would it be wise for us to lean towards having really small entry points that import and like having lots of small modules, rather than having, like one large entry point like for this? The fact that we are kind of chunking things up like that?

B

Have we observed any kind of effect based on entry points that end up having lots of small modules versus and like okay, we just have one huge index.js file or something so.

A

A few things here, one of the problems is that um we recently changed it because before we just had like four or five common chunks, so um per page, and now we have a higher maximum because of http 2. We, you know it doesn't really matter, it's actually good. If we have a lot smaller chunks that get delivered over the pipeline, um because those chunks were those chunks can be delivered in parallel.

A

And you know, computers with more than one cpu can already start pausing the multiple files in parallel right, there's, obviously a downside with the magic here, and this is what we're going to see in a second um I I think it doesn't really matter. I mean in the end, if you deliver 1.7 megabytes of javascript on this page, either in one file or in 10 files on five files in the end, you're delivering 1.7 megabytes of javascript. The only thing that I'm concerned here with the graphql stuff is hey. We use graphql in more pages.

A

It would be smarter if we have one chunk where all the graphql stuff ends up, because if you navigate through gitlab a lot, you will actually be able to reuse that graphql chunk right.

B

Yeah, so let me ask one more question: are you are we planning on putting it in its own chunk or are we gonna put in the main chunk.

A

So I wouldn't want to put it in the main chunk. Actually my goal would be in the future or the general goal is. The main chunk should be as tiny as possible, because, um yes, if ninety percent of the pages are loading graphql, uh if of you or whatever right, it's it's cool if it's in the main chunk, but still sometimes you have pages you go to like, let's say let's say, for example, I don't know if it's the reality, I'm just making up an example.

A

Yeah if you are on the login page and the login page is just a normal form without any javascript. Imagine it were like that. I don't know if it is or a 404 page. Why would you need to load if you on the 404 page load the main chunk, because the main chunk is loaded on every page? Why would you uh want to load graphql on a 404 page or the sign-in page?

A

If you don't need it there right, um so that makes sense and it sounds like the cost is pretty low to put it in its own chunk. Yes, exactly exactly so. What have I done? I have uh opened the compile production assets, one or maybe even easier is you can go to the bundle, size review job and we should link it at some point.

A

But the bundle size review actually has like the the markdown get that gets put in and the html page that we're already uh looking at here right. The comparison one and you can see, there's a bundle report one and we should just add a link, because the bundle report is the one and I'm increasing my font size, because people were complaining about it before and I'm just going to open the bundle report in a new tab.

A

So um the thing that I then oh my business, so you can see in total all of our javascript assets across gitlab are currently in 93 megabytes. Why is.

B

Monaco so big.

A

C

So this is, for example,.

A

This is before gt yeah. This is before jesus jesus is. Jesus is like 11.6 megabytes across all of the javascript right, um but even past you can see that monaco is quite big and so, for example, the problem that we had here have here with graphql is the problem that we had before, but for monaco and e charts and that's the reason why we put in monaco and e charts into a bundle, um because it's like hey, even if one is used in snippets and the other in, uh is used in uh the web ide.

A

It probably makes sense if there's just like one bundle. um So the thing that I usually usually do here is I deselect everything I select the main one and we can save us some time. I basically just copy the file names here, search for it and enable it, and you can see that some of the common chunks are actually quite small right um and, let's, let's save us, you know adding 10 of these, because if we add the last one, we actually see.

A

Aha apollo cache, apollo client viewer apollo, and, if I'm looking here, okay 73 98 56, it seems pretty reasonable that this is the 400 kilobytes that we're seeing, because we need to look at the the the raw, the the the stat size, the unpassed size right and here's apollo util. So we can see that all in a po- or it seems like I mean actually all of the new modules here, more or less right or most of them not modulus here is like hey and okay.

A

This is pretty interesting and if we turn on all chunks again, we just for we can just search for view apollo and before we would find it in main.js, but main js is really tiny now, so you can see. ah Okay, apparently like there are a bunch of uh chunks that you know rem. Have you apollo and you know uh like static site, editor cicd show sas configuration whatever and obviously it's not bad.

A

The only thing because it will just work and you will download the javascript and so on. The thing is bad is like hey. If I go to the uh milestone, show page and then I go to whatever other page like size, configuration or the idcd shows includes also the graphql package.

B

And just anything anything we might be using in the future, for it, there is an opportunity, for here is a box that really like should just live on its own because, and that makes- and the good thing is, if you have.

A

That box by the way is like because we recently changed how webpack compiles assets before webpack. These hashes were unique for each compile, so there isn't long-term caching, but if we actually end up putting viewer apollo, graphql and the related stuff into one bundle and assume we don't update it for three months or something um you know, there's even the the added benefit that this thing might be catched for um for three months right, while if it ends up in the project, setting cicd show bundle uh chunk, I'm always saying bundle, but I mean chunk.

A

um If I change one line in our code right, you would need to download the whole graphql stuff again as well right.

C

So just ap does this uh brings any consideration when we update one of those thing that these are in these common boxes. um So if do we need to do a special procedure for it to be sure, no.

A

No, no, no, this will. This will just happen automatically. um So, for example, like um I don't know how often we update each other, I assume it's not that often so just for fun we could go back, and this is actually something that you know long term. Cash ability is not a big concern of gitlab um because I don't know even which kind of cash headers we serve, so it could even be that our cash headers say 10 minutes anyway, I don't know we even include like the checksum.

B

Is in the url like right.

A

Yes, yeah. We include the checksums in the url, but also I think there are etag headers. How are they called? So? Let's have a look, for example, application main jazz right, so cache control max h. Oh, this is a really long max age, so it is definitely beneficial to have long term caching, but I mean it's fine right because as soon as you update view apollo, um the next deployment on gitlab.com will have a new hash in the file name.

A

um It will also have a new etag, because etags are based on the contents of the file and uh it will just work and people get the updated bundle. We had a problem in the past like three four years ago um that you know. Basically, this didn't happen so that the browsers you know were getting an old main.js or you had cached an old main.js and nobody told the browsers, hey, uh you need a new main.js and then the people ran into errors, because the other code changed right. That's enough!

A

Yeah! um I mean one more question: yeah sure! That's what we're here for yeah.

B

So I have to admit that this is like the first time, I'm looking at the bundle, analysis, stuff, yeah and it's really cool um but I'd be curious to know what do we do for axios, because that seems to have a similar use usage of it's. It's something. That's spread across our application, that's used everywhere um and it makes sense kind of being its own chunk. But so exos actually ends up in the main chunk, and this is.

A

This is probably really so main chunk is a bit stupid. Sure.

B

And it just sounds like it sounds like the general comments like just contains yeah, and that.

A

B

I was just curious, though,.

A

So, let's, let's have a look at the main chunk, because the main chunk is really it's. The thing that's stupid about the main chunk is that it's loaded on every page. It contains our general bootstrapping on every page, so we generally try to remove as much as possible from the main chunk right and we are even some things and the reason I think the reason why we had a graphql in the main chunk before is, I think, the obviously there's not one here like.

A

I think these pop overs are using graphql, I'm not a hundred percent sure, but something something something uses graphql, that's potentially on every page. um We just made it so that it's loaded asynchronously um only. I think, if, if like one of these elements exists- and this is the reason why it isn't in the main bundle pair default anymore- um and it could potentially happen to axios as well. If we don't do a single axios call anymore right or it could actually happen to jquery.

A

If we remove from main.js remove jquery initialization, you know suddenly jquery might pop up at all the pages that are using jquery right and some newer routes that completely don't use jquery might not have jquery anymore. um I guess so.

B

A

I open the console.

B

And I can do dollar and I'm like okay, there you go.

A

B

Is this is a big problem still, and this is.

A

What we're slowly trying to get rid of same with bootstrap same with. uh We want to have view in a smaller bundle right, um and I mean it's looking like views a little bigger than jquery. Yes,.

B

Then we should be trying to get rid of you.

A

And jakeberry yeah, no, um the the reason why vue is relatively large years at the moment we still add a version of view that also has a live template compilation.

A

Because we sometimes create templates in hamel, which we shouldn't do security and.

D

A

Yes still, I just deleted a few today um and- and you know the problem, this is also one of those unfortunate problems where it's like hey. We cannot switch to this smaller view thing until the last one is actually removed right, yeah um similar, like font, awesome like we cannot get rid of the font, awesome font unless we have removed every single icon right. um So all of these efforts of removing font awesome at the moment don't yield any performance benefits until we have removed the last one same with bootstrap right.

A

We cannot get rid of bootstrap until we have removed the very last tooltip.

B

And they're all contributing to the potential performance benefit exactly hey natalia view. Three uh is: is there a bundle size change just for fun.

A

I think it's smaller right. It's smaller and more performant yeah.

D

It's smaller and it's more performant, and if we will be able to switch the composition api, at least partly it will be even smaller because it grows. When you have this syntactic sugar, we call an option options, api, which we use right now over the composition api. But this is just a dream: we will never switch the composition. Api completely still bundle size is smaller.

B

Maybe we don't say never that's how I.

D

I know that some of our experts are strongly against composition,.

B

D

Yes, wow, I even know names they're on my blacklist sounds.

B

Like we have a good reason to because then we could do your blacklist sounds like we have a good reason to, because it's a smaller bundle size so.

C

Let me see if we remove you from the main bundle, which page is just a position if you have a benefited and which not not correct, we.

B

A

Every page right like no, that's not that's.

B

A

True, we have pages that aren't just static and we theoretically still load view.

D

Like some wikis wikis are not had view outside of one model, but.

B

Like even but even if we did the like, even if I was running it locally, like the performance bar, is in every page and that's a view app like I. I.

A

Think it doesn't that's that's the reason why we now load the performance by asynchronously. So if we would have view in a separate bundle, it would actually. Oh you want to load the performance bar okay. Let me grab view for you and the performance barcode and bring it together. Okay- and you know often, this is like an overhead, especially if then view is cached uh um is an overhead of 10 milliseconds right and also one thing is the more stuff there is in the main bundle.

A

Again we change one line of uh we change one line of the main bundle. We get a new main chunk, while, if the view which we maybe update every two or three months or whatever you know, could be a long term, but certainly.

B

You can't just like chunk everything right like that's like, so so what I mean. Let's, let's look into the conflict. Okay,.

A

B

Yeah, go ahead. Keep going! I'm sorry! I appreciate the discussion. I'm sorry! No.

A

It's it's it's fine. I mean I kind of agree with you. The thing is we really trust um so the thing is we really trust webpack to do its thing in a smart way, um but the crazy thing is: we have 328 entry points and there is bound to be. Then we have stupid things that skew our views of entry points.

A

So, for example, if I'm here seeing a lot of similar sizes and if I see like the names of those bundles, I assume that this actually could just be one entry point right, um but the way how our entry points are structured, there's no deduplication similar, for example, with all the pipelines views right so like we have one entry point for each of the pipelines, views and uh so webpack.

A

Also, basically, things like this code is: if there's one line, that's shared just between those seven files, right, webpack, think: oh, this file is really important because it's you know queried seven times, even though in reality we actually just have it once um that's interesting. These are a few of the downsides with the webpack, smartness and um webpack. You know just looks at the current snapshot of dependencies in code that you have webpack doesn't know hey. It would be smart to bundle view in a different bundle, because you folks update vue just every three years.

A

um Let me just put it in a different chunk for you, and this is what we basically need to define ourselves.

B

I think it'd be a lot of fun to you know dive into some of the uh heuristics. That webpack is using to figure out how to slice things and maybe contribute upstream for more variables. We can give it to yeah, I'm just you sure you want to get into that pool. It'll be fun. I don't know.

B

I think you'll talk.

A

But, and the good thing is, though, the config is rather simple yeah, so it's like okay, maybe maybe we can be smart ourselves and don't need the machines to be smart and define a few things and that's a good point right all right. So where do we have it it's somewhere here here we have it so here you can see. We have these cache groups, so there's the split chunks plugin. This is the thing that splits, the chunks and there we have a definition of monaco e charts security reports, vendors comments.

A

These are all the chunks. You know that are ending up in all of the things um comments, comment and comments. Now, I'm a bit confused myself.

A

Okay- uh and this is like the stuff that ends up in you know it must I make this- is the main chunk? Yes common. So this is a bit confusing comments. Are the different ones that are split between the pages and the common chunks or comment between everything is the chunk. There is the main chunk um and you can see we basically have a really smart heuristic is like hey everything. That's on ninety percent of the pages is going to end up on the main track, oh cool.

A

So if we were using graphql on ninety percent of our entry points, it would be in the main trunk or we loaded.

B

And maintained right, it is in the main chunk right. It's not in me.

A

Oh okay, I thought you said something about it being in there. It wasn't the main trunk until earlier, so the thing is- and it's really good- that we have natalia on the call. What we would probably do here is like I would just you know, create a new chunk. That's called graphql.

A

um I would give it a priority of 16, because I think it's more important than monaco a priority basically just says which rule is going to be taken. So if, in the future we use graphql 90 of the page on 91 of the pages, it would end up in the main chunk again. Otherwise you know um right now. Yeah I mean we could probably make it higher priority to force it. But let's just you know, try this.

A

For now we can iterate on it and let mike review the merge request, because I talk all day and he actually has better understanding so name and should be pretty clear right. This is just how it's going to be named um this chunks. All basically just does, um because there are async chunks. If you have the dynamic import and there are static, chunks and chunks.

A

All just says: hey doesn't matter if, like something async uses the graphql stuff or something sync uses the graphql stuff give them both the same chunk um test is just going to be the thing that um test is just going to be the thing that you know where we're going to cry, because we have to write a regex, um and I think we can just copy the test from here and now I would need all the package names and my idea would be that these are view apollo.

B

Can we just say anything that includes apollo yeah? I think.

D

Anything that includes apollo or anything, it includes apollo anything that includes graphql, because we also have graphql and graph kill tag.

B

Yeah, that sounds great okay,.

D

We also have immer, which is not a polyneither graph, yeah.

A

Okay emo, then we have dot uh okay. This is going to be a bit tricky, um so we're going to have like uh something that is not a slash, a backslash or slash, and there we can have multiple ones right. Then we have apollo. Then we going to have this thing.

B

Anything, that's not a slash, so you want to do the the carrot thing at the front of your character. Selector thing.

A

Yep you're right, so any characters apollo. Just out of spite I'm going to create a package that has apollo in its name and it's just a list of greek deities and no just kidding.

B

um Apollo, what was the other stuff um right and it's the same thing, and I would even you know what would that not yeah yeah? I would, I would say you could put those things on the outside um and what we could even do to be kind of crazy is put. um If we really want emmer.

B

We don't want to do anything out like we don't want to do the wild card for emmer. We can end emmer in a slash and begin it with a slash so that.

A

Do you know what I'm saying? Yes, yes, I know what you're saying so you basically yeah. I mean to be honest, like I'm a bit confused that we even have the backslash slash any more here, because um the thing is that.

B

I know is this just any character? That's not that.

A

Yes, I know, but the thing is that we have the backslash for windows support but, to be honest, like half of the other parts of this file, you know don't even use it, so you can also rather.

B

Than doing the anything, it's not a slash, we can also just say anything, that's a word or dash, and that might be a little bit more readable anyway.

A

um Let's just go for consistency here, uh graphql you're, saying right: it's beautiful okay, so I think that's it. To be honest, um the only question now would be like uh production. Now, let's find no. This is a rake assets.

A

B

Oh, you see, are we able to run the same? Are we gonna be able to like run the same job.

A

Yes, cool, uh I uh I think it's even yarn run. Let's see how it's named, I think it's even called webpack product yeah and uh we won't get the nice bundle size analysis, but we will get. uh We can just look which files are going to be generated and then we can never check that those files are uh what we expect them to be right.

B

Cool, well, that's awesome, so the the catalyst for us making this change was. We saw that bundle, size, increased and yeah, because graphql was being included. Yes, we realized. All of these entry points are including graphql. We should put this in its own chunk, and so, if we see bundle size increase and it's not because of a new library or something like that, but it's because okay, here's just a common thing, that's kind of huge.

B

Maybe we should put that in its own chunk.

A

So the thing is- and this is where the bundle size analysis is actually still right- even with that change, we're going to have a new chunk, that's about about 400 kilobytes, and that new chunk will still increase the bundle size of that page. But this is.

C

Just the reality, it's going to be cached right now,.

A

It's going to be cached, it's not yeah! Unless you always just visit the ci cd settings that you're changing uh and it's the only task you do with gitlab. uh um You will have the benefit that the graph.

B

How would I see that, um while we're waiting for a webpack to run? How would I see that where? Because there is just that one number that says this is the sum of all the chunks? How would I see? Okay, it wasn't actually the entry point chunk. We actually added a chunk or something like that.

A

That's a really really good good call out the problem is we have so many files and it's really hard to distinguish and we could potentially we could. What would be really interesting- and I know I don't know if it could be done- it probably could be done, is if we really compare and say hey, these are the new files in your diff right.

A

So you this this, the 400 kilobytes are coming from graphql right, yeah, um yeah, the only way how you could have done it is essentially opening at the moment the bundle report for the mr and the bundle report for master and compare what is the difference between you know these chunks, which is sometimes tricky because the chunks might change because of the webpage automatics right.

B

A

Yeah, so um it's it's just a bit a little bit of experience and and looking into it, and you know, I think the first thing to um just look at these chunks and, uh for example, oh now. This obviously doesn't do anything uh like looking at this chunk and be like hey it's it's a bit weird like because I expect this chunk to be rather tiny and just contain the page specific code. Why does all this stuff end up here right.

B

uh Oh there's there's one apollo cache and memory. Oh, but that's an apollo thing we're catching up. Yes, apollo.

A

Apollo apollo, oh man, we're about to catch all of it. I don't know what zen observable is. I assume that is some polyfill, so this might even make sense to look into. Why is this polyfill added this.

D

Is not a polyfill. This is an implementation on which apollo cache in memory works. It appears should be a pure dependency of apollo caching memory. If it's not a pure dependency, we should edit as well because they have their own implementation of observables. It's not a risk. She has observables, it's unobservable, yeah, sorry for some reason. For some reason, I thought it should be included into apollo cache in memory, but it isn't. Okay,.

B

But but shouldn't this already so wait when I say: hey we're gonna cache these things, wouldn't it also cache their dependencies nope. Oh.

A

This is, for example, like with the echos one, with the e-charts you're, like hey, e-charts and z-render right, that render is e-charts, svg, rendering library um yeah or, for example, if monaco would have external dependencies, you would do the same thing. Yeah.

B

So that seems like something webpack. Maybe we're not communicating to it the way we should like, because that seems like something they should be able to do, and I don't want to necessarily couple myself to packages that are outside of my package.json, like you know what I mean.

A

Yes, apollo, I'm just looking for ts invariant, but.

B

You kind of mentioned, like webpack, knows like hey. This line of code is only used here like I feel like it could be. I'm I I'm a bit unsure about the observer, but it could be that we can try it with that, we're already trying without it and then, let's see, okay. That sounds like a good idea. I need. I need to step away for one minute I'll, be right back thanks. That's good!.

A

Because webpack still compiles for more than one minute um yeah, that's the that's! The only downside of testing this webpack stuff locally is like it takes so much time faster than a pipeline.

C

Yeah you're right.

A

It's like also the screen share has not happened. I'm just going to stop my screen share for a second until um until this thing is compiled, um just experience also stop my.

C

Decay should we have a procedure where, um when we see that that during maintainer or reviews- and we see a big increase, we should, I don't know open an issue for you to look at or just being.

A

I mean I'm going to be on parental leave soon, so pinging pinging mic is also helpful and I mean sometimes sometimes it also. The problem is that until I think an issue would make sense right, especially if we want to iterate and uh iterate and develop a feature. I think the only thing where you need to be like stop, I'm not going to merge this, mr, is if you have a really sudden increase on main js, for example right.

A

If you had a 400 kilobyte on main.js, I would say: hey: let's try to figure out what happened here, because this is a blocker because it loads on every page.

A

I mean you're you're currently in this, mr changing a route that I don't know, probably someone visits once a year yeah, so 400, kilobytes, more or less, probably not a big problem, but um it actually is as right now and every time I see a big bundle, size increase it's because of something different right, um yeah, because sometimes dependencies are pulling in other stuff. That's larger than expected.

A

um We had that recently with jsyarmel, because js yama uh ships a complete, javascript parser, for whatever reason um the reason is actually stupid, uh not stupid, but, like you can serialize javascript objects into yaml, which you should not do, and what safe load and safe dump doesn't do right, there's load and dump and safe load which doesn't do the javascripty stuff, but yeah, because um that package is not tree shakeable.

A

You end up with a whole copy of an ast, parser yeah, and I mean that's that's to be honest, like the many benefits graphql has, and I don't. I never participate in discussion, and I don't want to step on any toes. But luckily all our toes are short. Graphql is amazing.

A

What really would be amazing if browsers, should graphql support by themselves so that you don't you know, need to include like uh looking at it right now that you don't need to include the whole parser and stuff uh um yourself right similar to I mean the one big benefit of jason. Is that you know every browser just supports it by default, and you don't need to care about. uh You know getting your own parser in and so on and so on. So that's kind of.

B

This that's kind of related to the original dream of like having your third party things coming from a cdn uh like when jquery was around. It was like. Oh, you know, all of your clients that are using jquery. They can load on this page and it's the same jquery. That's on this page and it's like because it's all cached from this centralized cdn.

B

But what probably doesn't work there is that it's not a browser, it's standard and so everyone's still doing their own stuff. I kind of it would be. It would be neat if there is a way for me to cache.

B

I would love to catch something by like a checksum and a name across the whole, not by url but like graphql with this sum we can load it everywhere like that, would be really sweet.

A

I mean the first thing when that fell apart is like hey, here's a different version and then, if every web page you know, one is like loading view: 2 6, 0, the other 2 6 11, the other 2 6 12, and this is where it already falls apart and then, suddenly you know, network speeds are also now different. uh Oh yeah, it built the thing. uh Network speeds are now different and faster and yeah. Maybe we shouldn't be writing so much javascript.

A

Yes, no. I just created a much request that deletes 1 300 lines and I'm so happy about it. Oh wow of javascript, um mostly javascript, but also unused hammer views um speaking.

D

About different versions of view, potentially there will be a situation where we'll have two versions of you included, and will it be possible to have two different views around with like aliases, because I don't believe we can migrate at once.

A

I I think this is perfectly the way I would probably do it, and I don't know how view three works at the moment, but the way how I would probably do it is, I would just create a second package that is basically just a proxy for view right. So something like. uh Oh no, I think view three already uses ad view right, so it's different a different name space than the normal view right.

D

Yes, it uses, but it it was like this before and then. Unfortunately, the name of the package is still view without.

B

This view, with the with the version bomb.

D

Yeah, just a few.

B

You could we, you could do one, we could introduce it under our own package name, but then reference it by url, not by version or something. So we could just aliase it kind of like that.

D

B

View three have like a compatibility mode.

D

It will in december, probably I hope so in compatibility mode. I mean this is for internet explorer, because if compatibility build is for ie 11, but there will be also in between migration, build which will be 2.7, and we will probably upgrade to this one, because it's backwards compatible, but also has deprecation warnings.

B

Do we know? Oh sorry, cannot? Okay, okay,.

D

A

So I I think I think the biggest the biggest we could do it. We would just need a good migration path uh to actually migrate. Most of our view code over right, and I think the biggest problem will stem from things like uh with u3. There are still single fire components or we would likely still be using them for some use cases right.

D

Nothing changed in this.

A

Okay, exactly so, this would actually be a problem in our case, because if you now have a bunch of view files, how would webpack, for example, know hey? This is a view tooth file, and this is a view three file right and stuff like that. um So we might need to end up with single file, components that are named w3 or something- um and you know we might the hardest thing for us will be gosh. We need to maintain two versions of gitlab ui and yeah.

D

I already voiced this gitlab ui and tests on my documentary bloggers, yeah.

B

Maybe we need to start migrating away from gitlab ui, I'm sorry, I'm stepping north.

D

Okay, create components just over bootstrap, not bootstrap view, because right.

B

Now it's actually right. That's actually a really good idea. um Yeah.

D

C

Was a lot of guy on twitter saying that he should roll out our old ui library.

D

But I mean this idea about wrapping. Just bootstrap, not boost review is from one of our maintainers.

A

Yeah, um to be perfectly blunt, the idea and why I pushed back then pushed for git lab ui.

A

uh In a separate repository and wrapping bootstrap view was like hey: if we don't change the api of gitlab ui, actually, whether you wrap bootstrap view or wrap, something else doesn't really matter. So obviously we could just start working and completely remove bootstrap view from gitlab ui and just have. I.

D

Would be happy.

B

Because that's a good call- um and I think it is really nice that we've already we have all these adapters and that that that's already in place is really nice. But what's a little scary is we haven't been explicit with the adapters and so there's a lot of implicit behavior of bootstrap view that we depend on so our api.

B

We haven't necessarily totally defined it. It is still coming from bootstrap view, but we can, I think, probably the first migration step. If we were seriously considering. This would be stop implying the api from bootstrap view. We need to do explicitly passing props through whatever, so we harden our api.

A

And, to be honest, like we haven't been good ourselves when it comes to stable apis right like if I just like, like new button.

A

Yes, first new button is a whole story and I mean it's fine because iteration, but also you know every time I look at the version number of gitlab behind it's like oh yeah, now we're at 72 interesting.

A

Which is which is fine, but you know also maintaining a ui library is something completely different right and I don't envy the bootstrap view guys at the moment as well, because it's like shoot bootstrap five coming out u3 coming out ah right. It's like oh.

D

Yeah, the actually the author was was kind of surprising because there was an issue asking do you plan a migration to view three and they're like yeah? We are working at this and yesterday they fired like we started working on migrating. The library and the code of bootstrap view is like completely view free and friendly.

A

D

A

Yes, um I mean, to be honest, like I know, a company that has quite some money in the bank and uses bootstrap view and has like 60 front-end engineers. um What was their name? What was their name anyway? Yeah you know it's like you.

D

Know this company.

A

Also uses view.

D

And like never sponsored you in any way to.

A

Be honest to be honest like given the state that view is in, I would rather have us, invest in the ecosystem, like um we've run into the limits of the test utils before.

D

Right by view test details and let's maintain it ourselves.

B

I'm so stoked that you're saying this natalia. uh This is my idea and natalia was like no there's a community. There.

D

I told you I regret this.

B

Okay, so people.

A

B

um This this finished and so you're walking through the the.

A

Stuff right now, so I don't have the the nice bundle size, analysis here, locally and stuff, so I'm just you know, I just opened the js map for it like the the how's. It called the map file and I just searched in it for apollo and uh seems reasonable enough to me. Can you do.

B

A search for the observable stuff like was it was it called, um but did you re-run after you added the query.

C

A

Yeah, maybe not uh I don't know it's it's hard to guess. I would say: let's just push it and be a bit more explicit about the zen observable and have it in there. No, but it was.

B

A

D

B

You saw it then so just.

D

B

When I'm looking at this map- and I see an import that doesn't necessarily mean that zen is in here- it just means it's still referencing them right. So I need to start saying like it defines zen. Let's.

A

Let's do it differently. Let's look at the uh project settings ci cd show thing pages, save.

C

A

Is there yes see if there's anything here or how large that file is because projects.

C

Oh well project already it's five already. Hollywood.

A

Projects settings uh ci cd, show.

A

Okay, things here uh copy relative path.

A

How large is this by now 70 kilobytes seems a lot more reasonable than well 500 or 238 or whatever, how.

B

Big is that how big is this that index.js block that's over there in the purple screen on the right of your screen, this one, the concat? Just if you go to the right, if you get outside of node modules, how big is that little block the the not the far right? The this one.

A

Yeah, what is this by the way.

C

One kilobyte yeah.

A

B

A

It took everything out right: yes, it took almost everything out could be that still some good lab ui is in there or something but yeah. There is view x, probably in there, but um it's difficult, I think view x is probably if we actually look here view x is ah by the way we're really smart that we're looking at this bundle, because uh it makes no sense, because I didn't branch off your branch, so we will never find graphql in here.

C

But look at design management, for example, that don't.

D

Look at design methods.

A

So you can see if the id has graphql pages ide. Okay. So let's look at pages ide ide pages! Oh I I don't alphabet very well, sometimes pages.

A

Oh yeah pages, ide uh apollo, I mean no import words had as imports. Yeah imports is fine, I mean. Maybe I should look at the size of it and just you know, copy relative path. I think the easiest actually will be, and I'm now angry at myself that I just didn't push. While we did the thing 470 kilobytes uh pages ide. Where do we have pages dot?

A

There yeah see what's small right.

A

Yeah I mean here: let's just do it, let's just push it and see what happens, and then I will assign to one two. No three maintainers.

B

Usually you'll get the bystander effect. Then.

D

To maintain this and one graphql expert.

A

Yes, exactly um I mean this had nothing to do with graphql by the way right. It's just.

D

But anyways just in case.

B

Yeah, so um um this was super educational. um um This is a really interesting way of you know. I don't. I don't think about this problem a lot. So I appreciate you bringing up this issue.

A

Yeah, let's all thank uh nico for yeah.

C

But I mean the bundle analysis tool that gave me a stroke: human, significant growth 25. I added three utilities like 300 lines, a mark like what did I do now.

B

um We're not just you know, brushing past that uh that was that was good. Reading the error messages.

A

um When we reduced our main js bundle size, it seems like graphql and.

A

A

Oh no graphql and related dependencies get included multiple times uh into different chunks.

B

Yeah, you have a small typo on into.

A

Latino no, this is um this is a new into where you can directly define urls and uh the dependencies.

A

I see uh into different trends by manually defining a graphql chunk. We can increase cash ability.

B

So let me ask you: is that the word yeah you can throw illite and anything.

A

Yeah, for example, ip build ip ability right like okay, the.

B

Ability to be an ip, um so let me ask you another another question of just while we're talking about this problem. um Let's say someone sees that. Oh, I increase the bundle size. I can improve things by adding a chunk and they're just kind of doing this on their own. They create some are that chunks decides to chunk things based on a certain test and it hits a container's desk that doesn't actually know you know like. I don't really have a whole lot of expertise here.

D

B

That that we should like say please look for a domain expert review on just make sure we're chunking these things correctly, or does that I think I I.

A

Think you know, if you don't know about the stuff as a maintainer. That's completely fine, because you don't know everything so yes, asking for an expert would be good. It would also be good maybe to raise awareness uh of this session or what we've done here in the maintainer call, so that people learn about it and then you know, I think I think we need to educate folks- and I don't know this is a problem that I had in previous companies and so on.

A

It's like this, this understanding of how our assets are delivered right, not everybody needs a hundred percent of under understanding of that, but um yeah and you know cash ability and stuff this.

A

These are all things and there are like multiple considerations here like um because, if it's like a whole, basically all this apollo stuff in graphql always comes together in one chunk right, while in other cases it might not have made sense, for example with gitlab ui, we don't want to deliver one big gitlab ui chunk all the time, because some of the gitlab ui components like charts are rather large and we'd.

A

Rather have you know the total of gitlab ui is rather large, but the individual stuff, that's loaded on the on on pages, is rather tiny right. But here the downside is really like. Oh gosh in, like I don't know how many these are, but we basically loaded it like 20 times right in an ideal world, and that would be amazing, but I don't know how much processing power and understanding it takes.

A

We would have each dependency exactly once somehow in this view, um but yeah I don't know how to achieve it and because, on the other side like I, you know, you don't want to create like send down 500 javascript files.

B

Right plus, if you, if you're paying- and I don't know if how accurate this is but like that does mean that your point, you now have one point of failure and the chances that it's going to fail. If I hit it, 20 times is less than the chances it's going to fail. If I hit 500 times um so, I do think that there is a motivation for not chunking all the things, but these this kind of iterative approach of like here's, an opportunity, let's take it. That makes a lot of sense.

B

I think one thing that would be really helpful is improving the visibility of the diffs here. If I knew if I had, if I had like a even if I don't know, if we could do this but create a yeah, see you later nico. I know I know we're at times.

B

So if you gotta hop off yeah, but if we could create I'd like to see like for every chunk, what was the size difference like any time we do an mr every chunk, here's the new chunks that were added and like here's, the size, differences and if that could be in a chart that would be beautiful.

B

But even if it's just diffing two files that would be kind of helpful as a as a reviewer just to have awareness of what.

A

Yeah definitely- and it's uh it's just something that we need to um that. We need to improve upon and, to be honest, I think for maintainers. You also need to think about what is changing right. um Then it's highlighted um so now we can uh say the most important things at the end, just between the two of us.

A

No, um so, for example, one example that I want to give is like- and this is what I mentioned earlier right, even if that page grew by 400 kilobyte, and it's because you know I don't know someone added a new dependency that you know contains the color blue 500 times. It's not that bad, because it's a root projects settings the icd show you visit that route five times a year.

A

Balsamic viewer is gargantuan. Pdf viewers are gargantuan, but it's not a use case that someone is like hey. I review thousands of pdf files all day with gitlab right, but if suddenly the issues list page and the merge request page increased by a hundred megabytes, you know it's, that's like uh really bad, and it's also, you know- and this is actually you know, merge request- show- is 7.31 megabytes, but.

B

If that can like right but- and that can easily happen, though the more we we and we should be doing this, like the more we start sharing code and like just consolidating our experience like yes, you know hey and we're even talking from ide like okay, can we do like an editing experience in the merge requests using monaco like and.

A

Then you should, then you should load monaco and keep the size small. Then you should load monaco when the user requests it right. For example, we actually have some code in there for resolving merge conflicts and I think the code for resolving merge conflicts is loaded every time you don't need to resolve much conflicts every time in the ui in right or like these e chart stuff, like we have these nice little charts in nursery quest right that you know and each other's ridiculously large.

A

It's like look right now, I'm not seeing one single charge a chart. Why did I load e charts? There's not not like one little chart on this page here right, um yeah, some of those.

B

Can be solved by doing like async imports? Yes right, yeah! That's! um No! That's a that's a good point! That's interesting! Yeah.

A

And I mean this is this is like everything you should. We should try to make stuff async and defer it every time a user doesn't need it when they directly land on that page right. So, for example, if you think about it, theoretically, gitlab flavored markdown, um you know just needs to be loaded.

A

You know once a user actually focuses this thing or we can maybe defer the loading a little bit, um because you don't you know, you're not like bam and immediately can enter something right, yeah and then only that only takes effect when you're previewing, something too right. Yes, yeah, I bet no gitlab. Flavored markdown is also the autocompletion and stuff. Oh right.

B

Right, no, that's that's a good point! Well, hey, there's! So much so much praise for setting these watcher things up because yeah this is so off my radar of thinking of like maintainability and sharing code. That's a good thing! Balancing with this is a huge deal, and so this is awesome that we we have the bells going off when when things do happen, that's.

A

The cool thing is, and actually I thought about it- we actually record the bundle size on master um and I wanted to build a pipeline that runs once a week that just you know, um does a comparison to the previous result from the previous week and then we could just be like hey, oh look what happened last week and you know because then it's okay, if you missed something or we can create issues for it right, um yeah.

B

Okay, that's a good idea. I love these ip dashboards.

B

But I'm probably gonna try to motivate you to write it in dino, um anyways, hey I'll catch you later ip. This is a lot of fun thanks for hopping on.

A

No worries have a good one, bye.