Wrapping Up Code Splitting

[00:00:00]
>> Sean Larkin: That would be essentially the entirety of I would say I've exhausted code splitting [LAUGH] to the maximum level. If you're creating something like a component library,
>> Sean Larkin: I think the only other thing that I would encourage you to consider is that if you are, think about how View makes code-splitting first class, right?

[00:00:28]
So this can be adapted to any other library code that you want, right? If you, a great example is Excalibur, right? So I'm sure that there are a lot pieces as a part of Engine that might not get used right away, right? So or that only happened lazily.

[00:00:47]
So the analogy could be while Engine, instead of shipping something under the hood automatically when an event happens. Maybe take and allow a user to use a dynamic import to load a piece that's required. And then, as a part of instantiating Engine, you pass that piece in as a dynamic import.

[00:01:10]
So that way, when that event occurs, you just made first class code-splitting for your library and make the pieces really modular. So if somebody wants to focus on performance in your library, having the ability to pass in in your API surface a function that returns a dynamic import is really powerful.

[00:01:30]
But that's really the last I can, if you have more questions about that or wanna see examples, I'm happy to show you sometime. But I think we've exhausted code-splitting, right? Does anybody have any final questions about it? The reason why I emphasize it so much is because literally code-splitting exists to solve performance, and to solve the number one problem of performance, which is the amount of JavaScript you ship on your initial experience, right?

[00:02:01]
So if there aren't any questions, I'm just gonna go ahead and, I mean, if there are just shoot them at me, and I will go ahead and check this branch.