Vue.js + Brunch: The Webpack Alternative You've Been Hungry For

Vue.js + Brunch: The Webpack Alternative You've Been Hungry For

Imagine if there was a build tool that you could use for Vue.js projects that compiled faster than Webpack, gave you a smaller bundle size and required only a few lines of configuration.

Brunch is that tool. In this article, I’ll show you how incredibly easy it is to set up a Vue.js + Brunch project, cover some of the pros and cons of Brunch, and serve up a few tasty brunch puns on the way.

To whet your appetite, take a look at this side-by-side comparison of a Webpack config and a Brunch config for the same, simple Vue.js project:

Webpack blues

Webpack is a crucial tool for building sophisticated, highly optimized web applications, and is encouraged by many influential web developers.

However, for newer developers, or those working on less ambitious projects, Webpack mostly occurs as a barrier. For Vue.js projects, users feel they must choose either to develop in a lo-fi ES5 environment without the cool features like single-file components, or, to develop in a highly sophisticated environment with as much time spent on build config as on app development.

Make room for Brunch

Brunch has been around since 2012, and while it is the default build tool for the Phoenix Elixir framework, it is still surprisingly obscure. That said, it has a dedicated group of users who love it for its core philosophy of “simplicity and speed”, something that Vue.js users may identify with.

Despite its obscurity, there are almost 80 community made plugins for most imaginable automations like transpiling, linting, optimizing etc. Brunch can do most of the things you’ll need in a Vue project too: wrap files as modules, concatenate them into a build file, compile Vue files, transpile JS and SASS and so on.

To be clear, Brunch is not as full-featured as Webpack and has certain limitations. For example, Brunch does not yet support dynamic imports, and it doesn’t process images and fonts.

read more

Migrating A VueJS App To Vuex

Migrating A VueJS App To Vuex

One of the difficult things about getting started with Vuex is that it is not so much a library as it is a design pattern. It follows that implementing Vuex is not so much about using an API, as it is about structuring your code to comply with the pattern. If you’re new to Vuex, this will be daunting.

In this article, I’ll demonstrate how to get started migrating Vuex into an existing Vue.js project. I’ll show you how to identify the parts of your app’s state that belong in Vuex, and those that don’t, how to refactor your component functions into mutations, actions and so on, and finally we’ll discuss the benefits accrued.

If you’re not sure why you should use Vuex, I recommend you read this post first WTF Is Vuex: A Beginner’s Guide to Vue’s Application Data Store.

Case study: Vue.js Cinema

As a case study, we’ll migrate a demonstration app I made called Vue.js Cinema to Vuex. It’s a single-file component-based Vue app that is a good enough candidate for Vuex as it has a significant amount of application state.

If you want to learn how to build Vue.js Cinema from scratch, it’s part of my Ultimate Vue.js Developers course.

Remember that Vuex’s purpose is to manage application state. It follows that in order to migrate Vue.js Cinema to Vuex, we must identify its state. We’ll see the state in the code shortly, but it’s helpful to first infer it by simply observing what the app does i.e. it displays a list of movies and session times that can be filtered by changing the day, or toggling time and genre filters.

What state belongs in Vuex?

By using Vue Devtools, or just inspecting the code, we can see the data of the instance and each component:

Our objective is not to move all data to the Vuex store. Instead, we want to target data which:

read more

Avoid This Common Anti-Pattern In Full-Stack Vue/Laravel Apps

Avoid This Common Anti-Pattern In Full-Stack Vue/Laravel Apps

If you want your Vue.js single-page app to communicate with a Laravel backend, you will, quite reasonably, think of using AJAX. Indeed, Laravel comes with the Axios library loaded in by default.

However, it’s not advisable to use AJAX to retrieve application state on the initial page load, as it requires an extra round-trip to the server that will delay your Vue app from rendering.

I see many full-stack Vue/Laravel apps architected in this way. An alternative to this anti-pattern is to inject initial application state into the head of the HTML page so it’s available to the app as soon as it’s needed. AJAX can then be used more appropriately for subsequent data fetches.

Using this approach can get messy, though, if your app has different routes requiring different initial state. In this article, I’ll demonstrate a design pattern that makes it very simple to implement this injection approach, and allows for a lot of flexibility even in multi-route apps.

As you’ll shortly see, an example app I created is interactive 25% sooner when implementing this design pattern.

Passing Data To Vue From Laravel

Here’s an example full-stack Vue/Laravel app I built for Oldtime Cars, a fictitious vintage car retailer. The app has a front page, which shows available cars, and a generic detail page, which shows the specifics of a particular model.

This app uses Vue Router to handle page navigation. Each page needs data from the backend (e.g. the name of the car model, the price etc), so a mechanism for sending it between Vue and Laravel is required. The standard design pattern is to setup API endpoints for each page in Laravel, then use Vue Router’s beforeRouteEnter hook to asynchronously load the data via AJAX before the page transitions.

The problem with such an architecture is that it gives us this sub-optimal loading process for the initial page load:

Eliminating the AJAX request here would make the page interactive much sooner, especially on slow internet connections.

read more

How To Publish Your Vue.js Component On NPM

How To Publish Your Vue.js Component On NPM

You’ve made an awesome component with Vue.js that you think other developers could use in their projects. How can you share it with them?

In this article I’ll show you how to prepare your component so that it can be packaged and published on NPM. I’ll use an example project and demonstrate the following:

  • Ensuring dependencies are not included in the package
  • Using Webpack to create separate builds for the browser and Node
  • Creating a plugin for the browser
  • Important configuration of package.json
  • Publishing on NPM

Case study project: Vue Clock

I’ve created this simple clock component which I’m going to publish on NPM. Maybe it’s not the coolest component you’ve ever seen, but it’s good enough for demonstration.

Vue Clock Demo

Here’s the component file. There’s nothing too special here, but note that I’m importing the moment library in order to format the time. It’s important to exclude dependencies from your package, which we’ll look at shortly.

Clock.vue

<template>
  <div></div>
</template>
<script>
  import moment from 'moment';

  export default {
    data() {
      return {
        time: Date.now()
      }
    },
    computed: {
      display() {
        return moment(this.time).format("HH:mm:ss");
      }
    },
    created() {
      setInterval(() => {
        this.time = Date.now();
      }, 1000);
    }
  }
</script>

read more

Critical CSS and Webpack: Automatically Minimize Render-Blocking CSS

Critical CSS and Webpack: Automatically Minimize Render-Blocking CSS

“Eliminate render-blocking JavaScript and CSS”. It’s the one Google Page Speed Insights suggestion that I always get stuck with.

When a web page is accessed, Google wants it to only load what’s useful for the initial view, and use idle time to load anything else. That way, the user can see the page as early as possible.

There are many things we can do to minimize render-blocking JavaScript e.g. code splitting, tree shaking, caching and so on.

But what about CSS? For this, we can minimize render-blocking by isolating the CSS needed for above-the-fold content (a.k.a. the critical CSS) and loading that first. We can then load the non-critical CSS afterwards.

Isolating critical CSS is something that can be done programmatically, and in this article I’ll show you how to delegate it to your Webpack pipeline.

What does render-blocking mean?

If a resource is “render-blocking”, it means the browser can’t display the page until the resource is downloaded or otherwise dealt with.

Typically, we will load our CSS in a render-blocking way by linking to our stylesheet in the head of the document, like this:

<head>
  <link rel="stylesheet" href="/style.css">
  ...
</head>
<body>
  <p>I can't be seen until style.css has been loaded!</p>
</body>

When this page is loaded by a web browser, it will read it from top to bottom. When the browser gets to the link tag, it will start downloading the stylesheet straight away, and will not render the page until it’s finished.

read more