Vue.js Developers

Looking for a Vue.js expert?

We can connect you with highly skilled Vue developers to build your next web project or join your team remotely.

Skills we offer:

  • Single-page app development
  • Full-stack app development (Node or Laravel)
  • Frontend unit testing & E2E testing
  • Project consultancy

Get in touch to discuss your requirements!

Latest Blog Posts

Don't Forget Browser Button UX In Your Vue.js App

Don't Forget Browser Button UX In Your Vue.js App

When building single-page applications many Vue developers forget about UX for browser button navigation. They mistakenly assume that this kind of navigtion is the same as hyperlink navigation when in fact it can be quite different.

Unlike hyperlink navigation, if a user goes forward and back between pages they expect the page to still look like it did when they return or they’ll consider the UX “weird” or “annoying”.

For example, if I were browsing a thread on Hacker News and I scroll down to a comment and collapse it, then I clicked though to another page, then I clicked “back”, I’d expect to still be scrolled down to the comment and for it to still be collapsed!

Hacker News comments

In a Vue.js app, though, this is not the default behaviour; scroll position and app data are not persisted by default. We need to consciously set up our app to ensure we have a smooth and predictable UX for the browser navigation buttons.

Configuring Vue Router

Vue Router’s role in optimal back and forward UX is in controlling scroll behavior. A user’s expectations with this would be:

read more

Faking Server-Side Rendering With Vue.js and Laravel

Faking Server-Side Rendering With Vue.js and Laravel

Server-side rendering (SSR) is a design concept for full-stack web apps that provides a rendered page to the browser. The idea is that the page can be shown while the user waits for scripts to be downloaded and run.

If you aren’t using a Node.js server for your app then you’re out of luck; only a Javascript server can render a Javascript app.

However, there are alternative to SSR that may be good enough, or even better, for some use cases. In this article I’m going to explain a method I use to “fake” server-side rendering using Vue.js and Laravel.

Pre-rendering

Pre-rendering (PR) tries to achieve the same outcome as SSR by using a headless browser to render the app and capture the output to an HTML file, which is then served to the browser. The differnce between this and SSR is that it is done ahead of time, not on-the-fly.

Limitation: user-specific content

Some pages, like the front page of your site, will probably contain general content i.e. content that all users will view the same. But other pages, like admin pages, will contain user-specific content, for example a user’s name and birth date.

The limitation of PR is that it can’t be used for pages that contain such content. As I just said, the pre-rendered templates are only made once and can’t be customised. SSR does not have this limitation.

Faking server-side rendering

My fake SSR method for Vue and Laravel is to pre-render a page, but replace any user-specific content with Laravel Blade tokens. When the page is served, Laravel’s view helper will replace the tokens with user-specific content.

So before pre-rendering your page will have this:

<div id="app"></div>

After pre-rendering you’ll have this:

<div id="app">
    <div>
        Hello {{ $name }}, your birthday is {{ $birthday }}
    </div>
</div>

And when the page is served by Laravel your browser receives the following, which is exactly what it would receive from SSR:

<div id="app" server-rendered="true">
    <div>
        Hello Anthony, your birthday is 25th October.
    </div>
</div>

With this method we get all the benefits of SSR but it can be done with a non-Node backend like Laravel.

read more

Pre-Render A Vue.js App (With Node Or Laravel)

Pre-Render A Vue.js App (With Node Or Laravel)

Server-side rendering is all the rage right now. But it’s not without its downsides. Pre-rendering is an alternative approach that may even be better in some circumstances.

In this article we’ll explore how pre-rendering works with Vue.js and look at two examples; one with a Node.js project, one with a Laravel project.

Server-side rendering

One of the downsides to Javascript-based apps is that the browser receives an essentially empty page from the server. The DOM cannot be built until the Javascript has been downloaded and run.

This means that the user has to wait a bit longer to see anything. It can also have an impact on SEO if crawlers can’t see content of the page quickly.

Server-side rendering (SSR) overcomes this issue by rendering the app on the server so that the client receives the complete DOM content when the page is loaded, before Javascript is even run.

So instead of the browser receiving this from the server:

<head> ... </head>
<body>
<div id="app">
  <!--This is empty, Javascript will populate it later-->
</app>
</body>

With SSR it receives a page with complete content:

<head> ... </head>
<body>
<div id="app">
  <div class="container">
    <h1>Your Server-Side Rendered App</h1>
    <div class="component-1">
      <p>Hello World</p>
      <!--etc etc. This was all rendered on the server-->
</app>
</body>

Server-side rendering cons

  • Your app will need to be executable on the server, so you’ll need to design your code to be “universal” i.e. it works in both the browser and a Node server.

    read more

7 Ways To Define A Component Template in Vue.js

7 Ways To Define A Component Template in Vue.js

There’s plenty of choice when it comes to defining component templates in Vue. By my count there are at least seven different ways:

  • String
  • Template literal
  • X-Templates
  • Inline
  • Render functions
  • JSX
  • Single page components

And maybe more!

In this article we’ll go through examples of each and address the pros and cons so you know which one is the best to use in any particular situation.

1. Strings

By default a template will be defined as a string in your JS file. I think we can all agree that templates in a string are quite incomprehensible. This method doesn’t have much going for it other than the wide browser support.

Vue.component('my-checkbox', {
	template: `<div class="checkbox-wrapper" @click="check"><div :class="{ checkbox: true, checked: checked }"></div><div class="title"></div></div>`,
	data() {
		return { checked: false, title: 'Check me' }
	},
	methods: {
		check() { this.checked = !this.checked; }
	}
});

2. Template literals

ES6 template literals (“backticks”) allow you to define your template across multiple lines, something you can’t do in a regular Javascript string. These are much easier to read and are supported now in many new browsers, though you should probably still transpile down to ES5 to be safe.

read more

Reactivity In Vue.js (And Its Pitfalls)

Reactivity In Vue.js (And Its Pitfalls)

One thing we love about Vue is the reactivity system. If we change a data value it triggers an update of the page to reflect that change.

For example:

var app = new Vue({
  el: '#app',
  data: {
    message: "Hello World"
  }
});

setTimeout(function() {
  app.message = "Goodbye World";
}, 2000)
<div id="app">
  <!--Renders as "Hello World"...-->
  <!--Then after 2 seconds re-renders as "Goodbye World"-->
  {{ message }}
</div>

Data properties, like message in this example, are reactive, meaning they will trigger a re-render if changed.

Pitfalls of automatic reactivity configuration

Vue configures reactivity automatically whenever you create a data property, computed property, bind a prop etc. This automatic setup is great when coding an app because it:

read more