The transpilation of JavaScript

The story starts basically with the realization that modern JavaScript variants, like React, Vue and TypeScript, don't work well in browsers. The JavaScript engine of browsers is often choosing for older language support with less trouble. Even the ES6 standard, which was dubbed ES2015 is still not completely adopted across all browsers.

Luckily enough, there is Babel that allows you to translate one JavaScript flavor to another. And nowadays, it seems that everybody is using Webpack to allow for a local development stack (hot module reloading, local webserver) that drives Babel. Vue Storefront has done so as well: Their Vue-based PWA comes with TypeScript, Vue obviously and regular ES6 code and this is translated using Webpack into code that runs in your browser.

The Webpack configuration of Vue Storefront 1

The Webpack configuration of Vue Storefront 1 is a bit more fancy though. First of all, their package.json scripts don't run a Webpack server instance right away, but instead use ts-node (so a Node client that supports TypeScript) to kickstart a complexer Webpack configuration with many features on board.

One of the benefits here is that you can use TypeScript to make definitions for Webpack. You wouldn't able (?) to use TypeScript directly in a Webpack configuration because you need Webpack to translate that TypeScript first. Instead, the VSF CLI scripts kick off part of the application, that then determines various things on the fly: The theme name, language files, the Webpack configuration itself for either production or development.

Compilation times in a default Vue Storefront 1 environment

However, this approach increases loading times, which leads into developers being unhappy. When you type in yarn dev in a Vue Storefront environment, you can easily expect a compilation time of a minute or more. In my case, I'm often waiting for 40 to 50 seconds (Ubuntu, SSD drive, plenty of RAM, no apps open).

Worse, once the development server is running and you modify some component (Home.vue), you'll need to wait for another 4-6 seconds before this incremental compilation is loading as well.

The reason is SSR

So I dived into this to see if we could improve things. And it surprised to me to find out that actually the development environment was still running production code: The approach Vue Storefront took was to kickstart their own Express server, use the Webpack API within it and load all that needed to be loaded.

However, on top of this, the client code would be compiled into the dist/ folder (which basically boils down to the code being the real-life production code that normally would be uploaded to a production environment, aka yarn build) which was then rendered by yet another part of the same client. This sounds complex, it is, but it holds one secret ingredient: Thanks to this approach, the development server is able to produce static HTML pages that include the actual HTML that would normally be rendered dynamically in the browser: Server Side Rendering (SSR) within a local development environment.

I don't want SSR in development

Definitely, I would not recommend going live with a Vue Storefront app without having tested SSR properly. And the default configuration allows me to test this properly. But at the cost of a slow compilation time. The reality is also that an average frontend developer is actually more busy with creating Vue components, writing SCSS, extending upon Vuex, then testing SSR. On a regular day, you don't want SSR to be enabled and then slow down your environment.

So I sat down and started to write a Webpack configuration from scratch, while still borrowing the necessary elements from the original Vue Storefront app (aliases, rules): github.com/yireo-training/vsf1-local-webpack - an open source project, free to use and open to contribute.

Loading times with my custom Webpack configuration

The loading times are awesome. The initial compilation time with the default Webpack is about 60 seconds. For me, my custom Webpack requires 30 seconds. Even better, I make use of the hard-source-webpack-plugin plugin which maintains a cache of compiled files. Killing yarn dev and restarting it again takes less than 5 seconds.

Also, while the development server is running, an incremental build (yarn build) takes only 1 or 2 seconds. It is speeding things up tremenduously for me.

Setting things up

The README of the GitHub project explains how to go through the various steps. The setup requires the Webpack configuration and a public/index.html to be copied to your own Vue Storefront app. Plus, it requires you to copy images from your themes assets folder to public - an issue that is hopefully improved in the future.

Next, the Webpack plugins hard-source-webpack-plugin and uglifyjs-webpack-plugin need to be installed. Plus, there is a specific bug in dayjs (something with a TypeScript definition file) that requires a specific downgrade.

Happy dev

Once you follow the procedure, you will add a new command happydev to your Node scripts and you are good to go with yarn happydev.

Let me know if this works for you too. And it would be happy to see some improvements come in via GitHub Pull Requests.