The open blogging platform. Say no to algorithms and paywalls.

Vue.js Vapor Mode and Other Roadmap Updates from Vue Amsterdam 2023

Vapor Mode is a compilation strategy that compiles a Vue SFC into JS output that is more performant and uses less memory. There are 2 ways to configure this

At the recent 2-day VueJS Amsterdam 2023 event, held from 8th to 10th February, Evan You revealed some exciting new features for Vue and provided updates on the 2023 roadmap.


TLDR/Top Highlights :

📍 Vue 2 reaching End-of-Life (EOL) support on 31st Dec, 2023

📍 Options API is here to stay

📍 Reactivity Transform will be removed from Vue core in v3.4

📍 Reactive props destructure

📍 Suspense will be finalized in Q2

📍 More SSR improvements including lazy hydration, v-ssr-only.

📍 _Vapor mode _--- anopt-in performance-oriented compilation mode

🚦What will happen to Vue 2

In order to bridge the technical gap between major versions, Vue 2.7 has been shipped with built-in composition API support as well as <script setup> feature. This is also to reduce some effort of upgrading to Vue 3.

The latest Vue 2.7 is the final 2.x release. This means there will be no more new feature releases planned for Vue 2. However, it will still receive the necessary support for bug fixes and security fixes, until the end of this year.

After 31st Dec 2023, Vue 2 will not be maintained by the VueJS core team anymore. There are a few options detailed in the official doc regarding this, which includes what could be done if you are not planning to migrate to Vue 3. One of the options will be to look into HeroDevs, as they will be supporting Vue 2.

🪦 RIP Reactivity Transform

When using ref to make something reactive, we can assign a new value to it and track it via the .value:

const count = ref(0);
console.log(count.value); // 0

Essentially, the Reactivity Transform allows us to omit those .value when writing reactive code. By default, it is disabled since it is still an experimental feature in RFC.

The Vue core team has decided to phase out this gradually in the coming months. One of the reasons is that the DX improvement is pretty limited. Without the .value, the distinction between reactive and non-reactive variables is now lost, and this inevitably introduces another mental overhead.

If you're using Reactivity Transfom in your existing codebase, you'll get deprecation warning starting from v3.3. By v3.4, it will be completely removed from the Vue core package. However, you still can use it from the Vue macros.

🙌 Reactive props destructure

Even though Reactive Transform does not pass RFC, there's something useful that came out of it, and this is the reactive props destructure.

At the moment, when we are destructuring props with defineProps like this, the reactivity is lost:

const { count } = defineProps<{ count: number }>(); // count loses reactivity

Hence, we either need to use props.x or remember to use toRefs:

const props = defineProps<{ count: number }>();
const { count } = toRefs(props); // count remains reactive here

With reactive props destructure, we can forget all that and simply destructure it in the usual JS way and we can even assign a default value like so:

const { count = 1 } = defineProps<{ count: number }>(); // count stays reactive

Currently, reactive props destructure is part of the Reactivity Transform RFC, but as Evan mentioned in the conference, we can expect this to be split out into a separate feature and it wiill likely to be included as a new feature in future Vue releases.

☁️ SSR Improvements

In coordination with the Nuxt team, the Vue team will be focussing on some SSR improvements in Q2. This includes finalizing the Suspense feature, which is currently still in experimental mode.

To put it simply, Suspense is a built-in component that offers a solution to display top-level loading/error states while waiting for nested async components to be resolved. Without it, we have to handle each of those async components' states separately.

Other than that, we can expect to see lazy hydration gets introduced. The idea is to let us define custom strategies on how we want our async component trees to be hydrated, for instance, only hydrating certain components when they are scrolled into view.

v-ssr-only is another new feature that the Vue team is exploring. This would allow us to declare a specific template as server-side rendering only. This can be useful when we have dynamic binding on a template where the piece of data is fetched from the database, but it's never going to change on the client side. In this case, when the client build is done, the compilation can be done differently with all the dynamic bindings ignored so that it doesn't have to do any work during hydration.

⚡️Vapor Mode

Before this, that's not much info regarding this seemingly exciting new ability that the Vue team is exploring. Early this year, Evan You briefly introduced it in his 2023 new year blog post.

Inspired by SolidJS, Vapor Mode offers an alternative compilation strategy. It compiles a Vue SFC into JavaScript output that is more performant, uses less memory, and requires less runtime support code compared to the current Virtual DOM-based output.

Sounds pretty amazing. What is even cooler is that all of this can be done without changing much on the existing codebase.

During the talk in Vue Amsterdam, we see some new details being shared on how we can opt-in for Vapor Mode. There are 2 ways to do this :

i. At the component level by including the .vapor filename postfix, eg Counter.vapor.vue :

<script setup> import Counter from './Counter.vapor.vue'</script>


ii. At the app level by dropping VDOM interop:

import { createApp } from "vue/vapor";
import App from "./App.vapor.vue";


With Vapor Mode, components can be compiled into a function call and we can stop worrying about having too many components and the memory overhead that comes with creating those component instances.

In the beginning, it is intended for Vapor Mode to only supports a subset of Vue API (<script setup> and Composition APIs) for the best performance. Hence, the plan is to make the Vapor component fully compatible with any other existing non-Vapor components. Achieving freely mixed usage (using Vapor components in a non-Vapor component and vice-versa) is also the end goal for the Vue team. We will likely see this somewhere around Q3 --- Q4.

These are just some of the highlights that I found interesting. There are many other insightful talks throughout the event, and you can follow up on their youtube channel for updates.

Continue Learning