 Hello everyone. The topic for my talk is a web pack plus view loader recipe for SuperchargeView. And let's start with the most cliched start. That's with a quote. But I do feel this quote encapsulates the essence of what we are going to target in this talk. And we'll see how the tools that we have been using for our development workflows have actually improved the way we think about development specifically when it comes to view development, because we'll be focusing on view. So my name is Hemant Rai. I come from Bangalore's not so cool cousin city of Pune. And I've been working with Vue from around 2015. We have been using Vue in production. And over the years, we have seen different dev workflows that cater to view development, starting from web pack 2, if I'm not wrong, and then 3, and then currently web pack 4. So it does require a recap given the long history that we have had of our different workflows. It does help us if we can go through a small recap of things, specifically to understand why we should use web pack. So there have been some generic ways of consuming content in browsers, specifically JS content. The first and foremost was using script tags. So you just have a bunch of script tags for each dependency that you would need in your project. But it came with its own issues, stuff like if anyone remembers the jQuery development ecosystem when you include a script had a major repercussion on whether those scripts are going to work and work in the way you expected them to or not. Similarly, the second option that evolved from that script tag implementation was to concat everything in a single JS file and use that, because having multiple script tags also adds its own network penalties and lots of script calls will keep your DOM blog for a longer time. Then you would want it to. So the second option was you just concat everything in a single JS file. But then that led to another problem, problems like scoping and maintaining the entire code base in a single file, which was always a hassle. So over that period, Node.js came into being. And with Node.js, a new problem came into picture. That was how do you consume JavaScript scripts within your Node.js applications? Because there is no HTML. There is no script tag over there. So Common.js introduced us to the concept of, I'm sorry. Common.js was the time when Require was introduced. And Require actually brought us to the modular front of JavaScript. But before that, there was something called IIFEs, which is immediately invocable function expressions. What they did was that they encapsulated everything, encapsulated different strings and stitched them together while taking care of stuff like scoping. And this is actually where we saw the advent of different task runners, stuff like Gulp and Grunt and Make, where we could then use IIFEs to better bundle our code bases into a single bundle. But then that had different problems, particularly when it came to performance. Stuff like tree shaking was something that developers had to do on their own. Making any change to any part of the code base meant a bigger change in the whole process had to be repeated all over again. So even though we were getting there, we were not actually there there with the advent of task runners. And that brought us to modules, the way we were just talking about when Node.js was introduced. Modules were evolved to work with Node.js. And the concept of modules was actually used further in bundling scripts that would later on be consumed by the browser itself. So modules is where things started getting interesting. And lastly, we can talk about ESM, although the support is not 100%. But we can very well see that this is the future, this is where we are heading. And to be honest, I feel stuff like Webpack is actually a stop-dap solution because ESM is not where we want it to be. So even though ESM is there, it doesn't actually replace bundlers like Webpack and everything that they do. So we'll just try to take a look into why Webpack, in particular. So many of you might remember many of these different things that we have been using over the years as part of our dev workflows, in particular. And the slide looks cluttered because this time was cluttered. The managing all of this was cluttered. Developers had to do a lot of heavy lifting. When we were using task runners, then in that case, we had to maintain our script files. We had to envision what we wanted to achieve in the best possible way. And it took several iterations to actually nail down our workflow, which would actually work for you. And we'll provide everything that you need to satisfy your development requirements. And that is why we come to Webpack loaders and plugins. So we'll just try to do a brief intro because we'll be reusing these words over and over again. So it's better to set a simple definition of what we are trying to save. And we are saying, particularly, loaders and plugins. Most of you might know is a JavaScript bundler. The main functionality of Webpack is to create bundles out of the scripts that it sees. And we'll look into how it does that in the slides later on. But we'll talk about loaders and plugins before we begin. Loaders allow Webpack to modularize files other than JavaScript. So Webpack, by default, deals only with JavaScript. But we consume a lot of other file types. We different sort of templating engines, flavors, all sorts of things. We want to do different preprocessing, post-processing. And all of this is mainly supported by the use of loaders. So loaders actually tell Webpack how to modularize something other than JavaScript and then to make it part of its own dependency graph, which we'll look into a little bit later. But basically, loaders are how we are able to use, say, SAS instead of CSS for our styling or TypeScript instead of JavaScript, or even later versions of ES standards while supporting all the legacy browsers and everything. So most of this thing is provided to us by loaders. Anything other than JavaScript that Webpack is handling comes to us through loaders. And last but not least, plugins. So loaders are kind of dumb in a way that they only tell Webpack how to handle that particular file type. Whereas plugins actually allow us to tap into the actual Webpack configurations and do stuff like optimizations and various other build optimizations, asset management, all the other things that Webpack allows us to handle most. We will do most of that using different plugins. So Webpack, loader, and plugins. Together, they form most of the current Dev workflow that we follow, particularly by developing view applications. And just a spoiler, but as the topic suggested, recipe for supercharged view. We are most of us are already using that supercharged view. It's not something that we need to supercharge. At least right now, it comes supercharged out of the box with Webpack 4, UCLI 3. So we'll try to mainly see what that supercharges. So before we do that, it would be better for us to just understand what is the normal state of view when using view library. So view can just be included as a script. View is a standalone library, which provides you with many APIs and features that you can use, but that's it. Browser understands only HTML, JavaScript, and CSS. So you could continue using view as the same way we used to use jQuery at one point of time. And that is the normal state of how we would go about using ViewJS or building ViewJS applications, whereas once we get into stuff, once we get into Webpack loaders, specifically ViewLoader, because that caters to the development requirements of ViewJS in particular, as well as certain plugins which help us do different things that previously developers had to do on their own. So moving on, we'll first take a look at Webpack. I'm sure most of you must already be aware, but just to sum it up, Webpack is a module, is a bundler for JavaScript applications. But how does Webpack work? What actually happens is that Webpack creates internal dependency graph depending upon the entry point of your application. So once you, so this Jeff comes from Webpack's website, and this pretty much sums up what Webpack does. So each and every different sort of asset that you might need to build your application goes through Webpack, gets bundled into static assets that you can just refer into an HTML, and it works simply. So instead of having to manage this clutter, we just have to configure our Webpack to give us the static assets that we can directly consume in our applications. And how Webpack does that is pretty straightforward. So if you look at the before part, how things traditionally used to work is that you have your index.html, and then you have different script tags where you are loading different scripts. And then the order in which you load these script tags actually defined the way your global scope was created, and then you can then use that going further. But this part is completely manual. You have to figure out what goes where and how you're supposed to do what. Whereas what Webpack does is that it takes this same file. It looks at the first entry point. In this case, let's say we have our app.js, which is where we include all the resources that our application would be needing consuming. So Webpack starts at our entry point, and you can have multiple entry points. For example, if you have, instead of having a single page application, if you have a multi-page application, you might require multiple entry points, and Webpack will support that and create dependency graph for each of those entry points. So Webpack starts at the entry point, which in our case is app.js. It finds each require or import statement that it does in app.js, and it then starts to create a dependency graph. And it starts to think or it starts to refer to each of these, your view.js, your view router, your utils.js as moves modules, which are part of that dependency graph, which is then later used to create bundle.js. Bundle.js can be a single bundle. It can be splitted into much smaller bundles. All of that will depend upon the way we configure Webpack in our case. So this pretty much is the, this gives you a brief overview of what Webpack does under the hood to create the dependency graph that is always talked about. So that was a basic introduction to what Webpack does for us. Now, the thing is in today's time, as view developers, we don't need to work with Webpack at all. I mean, because of view CLI, there is an abstraction that is provided to us on top of Webpack, which means that we don't need to worry about what Webpack.config actually looks like. And in the older versions of Webpack, particularly Webpack 2 and Webpack 3, for that matter of fact, Webpack configurations used to be a beast in its own right and would have required a talk just to explain what that particular config does and how you could go about editing that. But Webpack 4 works with zero configurations out of the box. It does make certain assumptions about your entry point and your output directories, as well as a few more things. But essentially most of us can continue using Webpack 4 out of the box without having to worry about whatever configurations are needed. But this is true for default use cases. This is true where we don't need to do anything that the default configuration doesn't support. There will be times, especially in larger applications, where we will need to introduce newer assets. We would want to use programming language or something that is not currently supported by Webpack by default. And in that case, we will need to modify the configurations. So, but instead of doing that directly to Webpack, we will look at how we will do that using ViewCLI. And what ViewCLI does is that it provides us with two APIs. One is Configure Webpack and another is Chain Webpack. So we can make these changes directly in ViewConfig file instead of going to, and referring to the Webpack config file. In fact, that is the recommended way of doing it because there are certain configs that are used in several places by Webpack. And if you have scaffolded the project using ViewCLI, not making those changes in ViewConfig would actually mean that you might not be aware of those changes and it might not be able to uniformly apply them across your application. So it's even suggested to make changes using your ViewConfig files rather than directly tapping into Webpack config, at least if you have used ViewCLI 3 with Webpack 4 to configure your application. So as we talked about two functions, the first one that is available to us is Configure Webpack. Now Configure Webpack, as the name suggests, will be used to configure Webpack. So there are two ways of using Configure Webpack. First of all is the most straightforward way where we just return an object with whatever configuration settings we need to be applied to our Webpack configuration. And in fact, as you can see the example shows this is the perfect place for us to declare any new plugin that we would want Webpack to use. So as in this example, we can have our own custom plugin or we can use one of the, like in this example, we are configuring StyleLint plugin to be, to work with our application along with whatever configurations are needed for that. So this traditionally would be done in Webpack config but we can very well do that using Configure Webpack to the view config file itself. Another way of configuring Webpack is, so the previous example that we saw was pretty straightforward. You just return an object, you just make changes and it would be applied. What if you want to make, you want to configure your Webpack based on say, node your environment variables or basically if you want to do any sort of conditional checking after the lazy loading of all the environment variables and everything has been done. Instead of the second option would be that we use Configure Webpack as a method. And in this case what happens is that we get config which is the Webpack config object and then we have two options. We can either directly go and mutate the config object itself and those changes would be applied to Webpack or we can return a new object in that instead. And this new object will then be merged into the existing Webpack config and then the final output of that would then be applied as the final Webpack config. So in both these cases we are able to configure Webpack for our needs, for our requirements without having to work with the Webpack configuration itself directly through view config. But this was very straightforward where we are doing some higher level things. We're just introducing some new plugins or maybe we want two different builds for our test environment or production environment and we can do those small things over here. But what if we want to get deep into Webpack configuration and make some more changes, do introduce some new loaders, stuff like that. And to do that view CLI introduces us to chain Webpack. So chain Webpack. So what happens is that behind the scene Webpack uses a library called chain Webpack chain and it maintains the whole config object the way we saw in the previous examples where you can either mutate that config object or you can return a new config object and it would be merged. So for the merging it uses Webpack merge whereas to maintain the final state of the config it uses Webpack chain and chain Webpack actually exposes some APIs which we can use to make changes to those config configurations in a way that will at least not break things. So and it will even make maintainability easier so you can have named loaders that you can then later refer to by their names and you can tap and find get their config objects and then make changes whatever you would want over there directly. So this allows us to have a very fine grain control over the internal config of Webpack again through Web view config files itself. So there are a few things that we can do so a few which would want to see first of all would be to modify and would modify options of a loader. So as we talked about in the introduction loaders tell Webpack how to consume different sorts of resources and assets which are not JavaScript. So but at the same time we might also want to make certain changes to the default configurations because as I mentioned a view CLI three comes with a lot of reconfigured configurations and they do work in most of the cases but in cases where we want to make certain changes to these configurations chain Webpack will come in handy. So over here like for example what this example shows is how we can find the view loader module view loader loader which is referred to as a module within Webpack and we can use the tap method to find a copy of the options object that this particular loader is using and then we can make whatever changes we want to make to this view loader configuration directly over here. So view CLI will give us view loader with default configuration any changes that we would want to make to view loader configuration can be done directly using chain Webpack option. Another thing would be to add a new loader. So obviously view CLI by default supports a wide range of loaders for different sorts of preprocessors and other stuff but that doesn't mean we might not need to introduce new loaders because it's possible we might want to consume a new resource which was not part of it. So even to do that we would again use the chain Webpack option for that and as we get the config parameter over here we can directly define a rule. We can set a regx in test which would be used to match against that particular resource type whether as a file import or as a language block within our single file components and then we define which loader to use and that's pretty much it. So this way any file or any language block found with dot pug extension would be passed through the pug plane loader and this way Webpack would be able to process pug instead of vanilla HTML for our templating. Similarly, as I had mentioned Vue CLI gives us lots of configs out of the box. So there are certain base loaders as we refer to them because these are the default loaders that come out of the box with Vue CLI but it's possible that we might want to make or we might want to change options of one of these base loaders or we won't want to change the loader itself. So if we wanted to change one of the options we saw in one of the examples before how we would do that but in case we want to do away with the base loader and introduce our own loader we can again do that using same chain Webpack. In the example over here it's again pretty straightforward. We are assuming that there is already a module configured for rule SVG which it is in case of Vue CLI. In the next line you can see that we are clearing all we are using clear method. What it does is that it clears all the configurations that would still be there for the SVG loader. If we don't do that any new configuration that we add would actually be merged into the existing configuration but we don't want that over here. So we would just clear all the rules and then we'll just define the new loader which would replace the base loader. In our case it is Vue SVG loader which would allow us to inline the SVGs and so the last option that we would want to look at would be because so far we've only been talking about loaders, how to configure loaders, modify options but the same thing will apply for plugins as well. So if you want to define plugins we can use configure webpack to define these plugins but if you want to modify options of any of the existing plugins we can use chain webpack and instead of using module we will use plugin to refer to the plugin that we are targeting and again use the tap method to get the argument, the config for that particular plugin and then make whatever changes we would want to make. So over here in this case we are, if you want to change the default location of our index.html we can directly make that modification to the plugin configuration although you can do that in other ways as well. So this was where we were talking about webpack and the reason we were talking about webpack in such depth was because webpack forms the base for view loader and view loader is what super charges the development for us. Webpack does that as well specifically by supporting all the new resources that we would want to consume but view loader improves the developer experience by a margin and we will see some of the ways view loader does that for us. Like for example in so many talks today people have been referring to single file components as a matter of fact. It's not, browsers don't understand single file components but we write single file components as if it's pretty much like HTML and the reason for that is that view loader enables us to stop thinking about how the single file component will be consumed by the browser. It abstracts that part for us and we only need to focus on what the component is supposed to do and how it is supposed to be rather than how it would reach the browser and how the browser would understand it. So that's like one of the examples which I found interesting given how comfortable all of us are with so many things that are actually not natively supported by browsers. So one of the things is asset URL handling. Now assets are a pain and making sure that all your assets are there in each of the builds is something that has always required a bit of developer oversight but view loader helps us a lot with that and how it does that is that it takes any of the static resources, any of the static assets that we would be using in our application and it converts that into a module. And now then this module can be part of our view, our web pack dependency graph and then effectively it becomes a dependency and if the dependency is not there, our builds will fail. So this way we can ensure that any critical static asset that is required by our application is actually part of the bundle. And the good thing is that we don't need to do anything to get this feature, it works out of the box. And the thing to realize is that whenever we use something like an image src with a asset path, it actually gets converted into something like this which is actually requiring that particular resource and this is how it becomes a module request instead of being a direct asset request. View loader also helps us by providing, by helping us with paths to refer to these assets. So you have your absolute paths, you have your relative module paths which start from where you are and you have your module requests where you can use still or even add that which is actually a web pack alias but it would be available to us and these module requests actually point us to the root of our application so we can even refer to stuff, any of the static assets within say one of the packages in the node modules folder or something like that. So it makes handling assets a lot more easier for developers without having to do anything to configure or figure anything out. The next thing we would want to talk about is preprocessors. So in web pack, all, I mean, as we talked about web packs, web pack uses, we can use different sorts of preprocessors in our application and these preprocessors need to have their corresponding loaders so that web pack can know how to process these preprocessors. And how, one of the cool things about view loader is that it allows you to have more loaders on top of view loader so you can actually chain, view loader actually allows you to have, to configure and use different loaders on top of it and that is precisely how we would be using preprocessors. So what view loader helps us with is that it figures out what loader to use for what preprocessor and it does that by matching the lang attribute for the, or the file extension for that particular preprocessor that you are trying to use. And again, none of this has to be, I mean, it doesn't require any sort of developer effort. Most of the commonly used preprocessors are supported out of the box that you can opt for when you are scaffolding your project. If you, even if you don't do that, all you need to do is that add those dependencies to your applications package.json and everything else, the internal bindings will work without you having to worry about. So say at the time of configuring the project, you didn't think you would be needing stylus for your styling requirements, but later on you realize that you do need stylus. All you need to do is that just add stylus loader as one of your dependencies in your package.json and view loader will take care of matching your stylus files and passing them through the stylus preprocessor. So effectively what that helps us with is that instead of relying on one ila.js, HTML and CSS, we can opt for the language of our choosing, whatever is comfortable either for our development needs, code readability, maintainability, whatever be the reason, but we can opt for any of these instead of going for the one ila options that the browser will understand and view loader will offload all the transpiling and making sure that everything gets delivered to the browser in a language that it would understand. Next thing to talk about would be scope CSS. But before that I would like to talk a bit about CSS input, just CSS because as the front end developers, CSS is something that would have tricked us at some point or the other maybe more often than we would want to accept, but it's not viewed generally because of the fault of the developer per se. It's also because of the way CSS works and I'm not trying to talk anything negative about CSS. I know it's a design principle why CSS works that way, but it also has some side effects, a very good way of understanding why we fall into so many traps again and again with CSS would be to imagine if JavaScript work like CSS. So what would happen is that everything would be global, which sometimes is the case and used to be the case not so long ago and it was a mess and every scope being hosted to the global would have so many side effects that the developer would have to take extreme steps to make sure that everything works as expected, stuff like following very hard namespaces, ensuring that the team of developers is in sync with what is going on. And that is pretty much what happens with CSS because CSS is applied globally and a single element can be targeted by multiple CSS rules across multiple CSS files, adds to that complexity and there are certain ways to handle this, particularly stuff like your BEM approach where you, but that requires a lot of effort from the developer and failing to adhere to those specifications can have a bigger repercussion. So we have been seeing a lot of CSS, we have been seeing lots of solutions to handle the CSS issue for us. One common way is CSS in JS, JS in CSS, whichever one is the right one. But the beauty of view is that I really admire the way they went about handling scoped CSS. So what view does is that when you add the scoped attribute to a style tag, you are basically telling view that you would want this style only to apply to that particular component. So we are talking about the single file component over here and we can have a style with the scoped attribute over here. And what effectively will happen is that you will add a data property to the targeted element as well as to the style that is targeting that element and that pretty much that's it. That way we are able to ensure that our styles don't apply anywhere else than what we are allowing it to. And in our case of scoped CSS, it would be that particular component. So yeah, this is a very clean solution according to me. I really like this approach. And it's not that scoped styles would limit you. So if you needed global styles within your single file components, along with scoped styles, you can do that very well. You can have a scoped style and you can have a global style within the same component and which style will impact what part will depend upon whether that style resides in the scoped part or the global part. So scoped CSS is not the only CSS solution that we get from view loader. The second solution that we get is CSS modules. Now CSS modules is a project. If I'm not wrong, by the same person who maintains webpack, I'm not really sure on that, but there is a very, I mean it provides very close integration with webpack. So if you're not familiar with CSS modules, CSS modules, basically what it does is that it's, it takes your styles. It converts them into the most simplest description would be an object. And then you can then refer to this object and then you can pick and choose which style to apply where rather than having to apply classes and stuff like that. So an example would be something like this. And as you can see, our style tag now has the attribute module instead of the attribute scope, which tells view loader that this would be the modules, CSS module implementation that it will be needed over here. One more thing would be that to have CSS modules, you either need to use CSS loader and configure it to, I mean you have to set the modules flag to true. If you don't do that, you can still consume a CSS modules, but then you have to add the dot module, dot CSS sort of a nomenclature for that. So just you can simply tweak the CSS loader's configuration using a chain web pack function that we saw and you can enable modules for your project. And once you do that, when you write a style in a module, it actually gets converted into object notation of sorts, which can then be referred to either in your template or in your script. So in your template, you get basically what it does is that it creates that object and it passes it to your view component as a computer property with the name dollar style. So in dollar style, you actually get your whole CSS as an object and then you can figure out or decide how you want to consume that CSS. So what is happening over here is that in the template part, you can see we can be directly doing style.red, style.bold and effectively this is just applying those two classes onto this particular paragraph tag. But you could see a more nuanced use of CSS modules where you want to pick and choose each and every small attribute. We can refer to that dollar style object directly in our scripts using this dollar style and we can then use it to configure or apply CSS within our scripts as well. So these two scoped CSS and CSS modules actually makes the developer's life a lot easier, especially when it comes to dealing with CSS. There are some other benefits as well like minified CSS, but we'll talk about that later. Next thing we would want to touch about would be custom blocks. So single file component, view single file components, support three blocks by default. So you have your template block, you have your script block and you have your style block. And then you can configure loaders to work with these blocks specifically depending upon the lang attribute for all of these blocks, but that's not the end of it. It also enables us to create custom blocks itself. So we can have a fourth block or a fifth block and then we can define the functionality of the behavior for that particular block and we can do that using custom loaders. So we'll go back to how we have been using a view to configure our webpack to tell the webpack how to process what part of our code base. It's pretty much the same thing. We would go about the same way. We would have a loader which would apply to that particular custom block. The difference being that instead of using the lang attribute, the custom block would form. So instead of having, for example, a script lang foo, we can directly have foo as the tag and have everything within that that becomes our custom module, which will be processed by the loader that we define for that particular custom block. And we can then decide how we want to use it in our applications. Lastly, one great tool that we get out of the arsenal is linting. Now, linting is something that most of us, I'm sure, have been using for a long time. There are two main flavors, ES lint and style lint, but what linting is basically a process of applying static analysis to our code base to ensure that there are no syntactical issues and so that the guidelines are being adhered to and followed across the teams, which actually helps in making the applications code base a lot more readable, modular, and to be honest, if you are strictly religiously following linting, it should lead you to a point where looking at the code, you shouldn't be able to tell who wrote it because everyone would be writing precisely a very similar sort of code thanks to ES lint and style lint. Now, ES lint targets by default the script block and the template block of our single file components and works out of the box. In case we want to apply these lintings to our styles, we can use style lint, although it's a bit tricky to take lots of iterations to actually nail down a style lint guide, which would work for you. I mean, it's easier to set up ES lint than it is to set up style lint, at least has been in my experience, but it gives you the same benefits. You can make sure that everyone adheres to similar styling guidelines, uses similar formats, and the result of it would again be more legible, maintainable, readable code, style code at the end of it. So take away. So I know we haven't talked much about stuff that is new as in stuff that you were not already using, most of you already, but it does help in having a better understanding of what goes on under the hood because Vue does a fantastic job of abstracting so many things for us that developers don't really need to bother themselves with these principles, but it's definitely a good knowledge to have. Specifically, as your apps get more larger and complex, you will need to utilize some of these options, if not all, and having the understanding goes a long way. So some of the key points I would just like to point out towards the end would be browser and browsers even today predominantly understand only HTML, JS and CSS, but we don't use these to build our applications. We use a hell of resources to build our applications lest we forget that browsers still don't understand anything other than HTML, JS and CSS. The second takeaway would be tools allow us to go beyond. So all these other things that we have been using over the years to build our applications, there have been some tool or the other which has helped us achieve that used to be task runners. Now we have come to bundlers, who knows what tomorrow is going to be like, but one thing is for sure, as long as browsers continue to support only HTML, CSS and JS to support all the developers requirements and requirements, you would need one tool or the other to ensure that what we write actually reaches the browser in a fashion that is understandable. The third point would be these tools have to be managed and maintained. At least that was distorted till very recent times. And it was paramount of the developers to mostly manage and maintain these tools, which was not a very straightforward thing to begin with. If any of you would have worked with grunt and stuff like that in larger applications, it becomes really difficult to keep track of what's going on, especially for anyone new coming into the project. And now what the current ecosystem provides us with the Vue CLI 3 and Webpack 4 is these tools don't need to be managed and maintained per se, you can obviously extend them, but things have started working out of the box, which is a really great thing for developers. So we can now focus specifically on building apps rather than how to manage them. Webpack, Vue CLI and Vue Loader, if you are working with Vue JS apps, these are the things which actually supercharge your developer experience, even if you would not have acknowledged that till now, under the hood, most of the heavy lifting is done by Webpack, Vue CLI and Vue Loader. They work together to provide us from stuff like single file components to something like hot-reload module, which is great for, especially when you are trying to tweak those finite weeks in a component. And all of that that we take for granted comes through Webpack, Vue CLI and Vue Loader. And the last thing which is clear now is that future is modular. Yes, modules has already have a very high adaptability, although I don't see legacy, browsers ever being able to do anything about it. So as soon as they get phased out, everything is going to be modular. At least that's how, that's the direction we are heading in. And using Webpack and Vue CLI, we can actually prepare ourselves for those times ahead by making sure that the components that we write today are modular and compatible with what we will be using tomorrow. So, thank you.