Vue Amsterdam 2022 - Part I: State of the Vuenion

Welcome! Happy to see you in the first part of my Vuejs Amsterdam Conference 2022 summary series, in which I share a summary of all the talks with you. You can read my JSWorld Conference 2022 Summary 2022 series (in four parts) here, where I summarized all the talks of the first day.

(Recurring) Introduction

After two and a half years, JSWorld and Vue Amsterdam Conference were back in Theater Amsterdam between 1 and 3 June, and I had the chance to attend this conference for the first time. I learned many things, met many wonderful people, spoke with great developers, and had a great time. On the first day the JSWorld Conference was held, and on the second and third days, the Vue Amsterdam.

The conference was full of information with great speakers, each of whom taught me something valuable. They all wanted to share their knowledge and information with other developers. So I thought it would be great if I could continue to share it and help others use it.

At first, I tried to share a few notes or slides, but I felt it was not good enough, at least not as good as what the speaker shared with me. so I decided to re-watch each speech, dive deeper into them, search, take notes and combine them with their slides and even their exact words in their speech and then share it with you so that what I share with you is at least at the same level as what I learned from them

A very important point

Everything you read during these few articles is the result of the effort and time of the speaker itself, and I have only tried to learn them so that I can turn them into these articles. Even many of the sentences written in these articles are exactly what they said or what they wrote in Slides. This means if you learn something new, it is because of their efforts. (So if you see some misinformation blame them, not me, right? xD)

Last but not least, I may not dig into every technical detail or live codings in some of the speeches. But if you are interested and need more information, let me know and I’ll try to write a more detailed article separately. Also, don’t forget to check out their Twitter/Linkedin.

Here you can find the program of the conference:

JSWORLD Conference

State of the Vuenion

Evan You - Creator at Vue.js

The talk was an overview of the Eco System and all the new things that have been happening. On February 7th, 2022 Vue 3 has become the default version alongside the new Brand new Vuejs.org Website.

Evan explains the adoption of Vue3 by the Community, Eco System updates with the Release of Nuxt3 RC since April 21st, Vuetify 3 Beta released on May 19th, and VitePress 1.0 Alpha and the work in progress on Vite 3.0.

State of the Vuenion 2022 - Evan You

Vue 3 adoption

Currently, Vue 3 has around 800k weekly npm downloads (measured by npm downloads of @vue/runtime-core), which is +70% since the default version launch, and if we look back one year from now, that's 4x in the past year, and it counts for more than 25% of all Vue downloads and this number will probably get much higher by the end of the year.

Ecosystem updates

Nuxt 3

https://twitter.com/nuxt_js/status/1516888137716449280

Nuxt 3 is now in RC. A lot of work went into it and the core will also be working actively with Nuxt 3 to stabilize some of the final pieces such as suspense hopefully in 3.3.

Vuetify 3

To a lot of people, Nuxt and Vuetify are two of the major pieces that block them from upgrading from Vue 2 to Vue 3. But now, Vuetify 3 hit beta on May 19th too and that’s good news.

VitePress

VitePress has just released 1.0 alpha and has been used in the new Vue documentation.

They focused more on the lower-level details, but right now they are working on completely overhauling the VitePress default theme. Now it comes with dark mode and has a consistent design language with the official view documentation but with a distinction so that you know this is a VitePress site instead of the actual view documentation.

There are some small breaking changes but we are really excited because VitePress has really been proven to be a pleasure to work with when we're working on the official docs and it's super flexible and super powerful as well. We are still debating whether we should officially make it the to replace VuePress, just call the VuePress 3 or maybe it should remain a separate project but the idea is if you're looking for a Vue 3 powered static site generator VitePress will be the official recommendation.

Volar

If you're using v3 you probably know Volar which is the new recommended VSCode extension.

Starting march Vue has been sponsoring Johnson Chu who is the author of Volar, to work full time on improving it.

Johnson has been cranking out releases and bug fixes and working on refactoring the internal code base to make it more efficient and even cover more features

Vite 3.0 (WIP)

Another important piece of the new ecosystem is Vite and the team is working on version 3.

As you may know, node 12 went end of life, and that was the initial motivator for Vite 3, which drops the support for node 12.

This is not a big rewrite but it comes with a number of relatively minor breaking changes.

We always actively work with all the ecosystem partners who are building higher-level tools on top of Vite to ensure these changes comes with a reasonable amount of changes needed to upgrade.

If you’re using just the basic features of Vite you most likely won’t be affected much, also if you’re using a higher-level tool like Nuxt 3 or other frameworks on top of Vite, this upgrade path will probably be more or less transparent for you because the higher-level framework will absorb the underlying changes from Vite.

But there is still a chance of shipping some potentially breaking changes in return for big benefits:

• Moving Vite itself to full ESM

• SSR build defaults to ESM output

  
  

  Both of these are also part of our overall efforts to make Vite an important factor in pushing the whole JS ecosystem towards pure ESM. So both of these will hopefully make the whole ecosystem transition process to ESM a bit faster.

  
  

• Non-blocking dependency discovery + optimization

  
  

  One of the reasons Vite can start up so fast despite having huge dependencies is that it scans your code base to look for dependencies and then pre-optimizes them.

  But the initial implementation comes with two limitations:

  
  

  1. The scan phase can be costly if your codebase is big.

  2. Sometimes the scan phase will fail to discover dependencies because some of the code may introduce the dependency after it's been transformed by an actual plugin, so it has to wait until the app loads.

     
     

  In 2.9 they introduced an improvement so that it no longer late discover dependencies and it can be non-blocking so it optimizes as it discovers them.

  
  

  In 3.0 it is going to make this whole process seamless: No longer need the scan phase, no more late discovered dependencies.

  
  

  Vite will discover dependencies as it serves your modules and it'll automatically wait for everything to be finalized to do one single optimization run.

  
  

• Esbuild-powered dep optimization for both development server and production builds, More consistent behavior between dev/prod

  
  

  For packages that are authored in commonJS, Vite used to use esbuild to process dependencies during development and rollup commonJS plugin to build the application for production, which creates inconsistency between development and production.

  In 3.0 the goal is to eliminate that by using esbuild for both phases to ensure the same outcome, especially for commonJS, and it is expected to land within the next month.

Vue Core

During April and May they spent approximately a whole month on v3 core bug squash, which resulted in massive patch releases (3.2.24~26), ~70 PRs merges, and ~140 closed issues.

All of this is a preparation for other work that’s paving the road for 3.3 because we want to make sure that we get a good sense of the current outstanding bugs and make sure that we have a stable foundation to build upon for the next generation of new features.

SFC Playground

SFC Playground has been the recommended way to provide bug reproductions for v3, but there are two categories of bugs that are hard to reproduce in the SFC Playground:

• Behavior inconsistency for <script setup> between production and development mode:

  We’ve seen quite a few bugs in this category in the past and most of them cannot be reproduced in the SFC Playground because the SFC Playground was production by default. So we added a toggle so that you can toggle between the prod/dev mode so you can actually show us the behavior inconsistency in the case that it happens.

  
  

  So, SFC Playground now supports switching between prod/dev mode for <script setup> compilation.

  
  

• SSR hydration mismatch bugs:

  In the past usually, you would have to create a whole repository with the full SSR setup just to show them a simple bug happening. But now SFC Playground supports SSR reproductions. That means the whole - Full compile → render → hydrate pipeline running in the browser - pipeline happens entirely in the browser and all you need to do is just toggle a button.

Vue 2.7

Many who are stuck on Vue 2 have been asking about it and it's been delayed for various reasons. But they finally started working on it and made great progress.

Scope

1. Porting Composition API to become a Built-in for Vue 2 instead of using @vue/composition-api plugin.

   You can directly do the same import { ref } from ‘vue’ as you would do in Vue 3 and these implementations are also more tightly integrated with Vue 2 reactivity system, so they are more efficient than the plugin version.

2. <script setup>

   For many people script setup has been essential to use composition API, because it just makes your life so much easier.

   If we are porting composition API to Vue 2 then it would make sense to also push setup because it’s such an essential part of the DX.

3. Improved TypeScript support

   They will not change the current shipped types of Vue 2, especially for Vue extend because they want to retain complete type compatibility for existing Vue 2 projects. Instead, they are going to have separate Vue 3 types also shipped in the types but you get them when you use the new defineComponent API that's available in Vue 3. defineComponent will also allow you to define components but with the types, that are directly ported back from Vue 3, which makes it easier for you to upgrade to Vue 3 as well and it also makes it easier for Volar to support both Vue 2 and Vue 3 at the same time.

Preparation Work

Vue 2 codebase is moved to TypeScript!

This is a huge shout-out to Pikax (Carlos) who spearheaded to work, made the huge pr and then also to David Walsh who helped with some cleanup, so i picked up from their work and managed to convert the whole codebase to typescript.

It is also now a pnpm monorepo, with a modernized test setup with Vitest.

Tests actually run much faster than Vue 3 now, so i need to really port the Vue 3 test to Vitest as well!

Vitest Is a new and fast unit test runner internally powered by Vite and has a fully Jest compatible interface.

Jest requires everything to have its own Jest version of it which is a painful process to configure with Vue-based setups, but if your project is running on Vite because Vitest is also powered by Vite, it’s going to be a smooth transition because Vitest can directly pick up your Vite configurations and you don’t need to configure it separately.

Current state

Composition API is already fully ported with actually named exports and full type support, but with similar restrictions from the @vue/composition-api plugin.

Vue 2.7 is currently in the alpha stage and 2.7.0-alpha.4 was released on npm under v2-alpha distribution tag, and they are focused on compatibility and stability testing.

Next Steps

The next step is to port <script setup> support .

There is a lot of logic — e.g. @vue/component-compiler-utils - that is split into separate packages and should move back into the Vue 2 repo similar to how v3 does it which makes it easier to sync changes across the places and keep everything consistent.

The new single file compiler logic will be exposed as vue/compiler-sfc the same way as Vue 3. This also means when you upgrade to 2.7 and opt in to the new setup, it will be fully compatible with the existing setups. You can then just remove vue-template-compiler as a peer dependency and then upgrade to vue-loader 16+ or just directly use @vitejs/plugin-vue because the single file component compiler will have the exact same interface as Vue 3.

Our goal is so that once you upgrade to 2.7, you’ll be able to just leverage the latest versions of Vue loader or the Vite plugin Vue for both Vue 2 and Vue 3 so you no longer need to use a separate Vite plugin Vue 2 or you’re stuck on the old version of Vue loader.

It will reach Beta after <script setup> is ported and the estimated release is the end of June 2022.

Implications

2.7 will be the final minor release of Vue 2.x and there will be no new features added to Vue 2.

We will still fix bugs obviously, we'll make sure view 2.7 has a smooth upgrade path.

Vue 2 will have 18 months of LTS starting from the release of 2.7 stable. That means Vue will be End Of Life by the end of the year 2023.

We may consider offering extended support on a case-by-case basis so this will likely be a paid service. So if you’re interested, you can register interest at link.vuejs.org/xlts. So we do want to make sure that our main bandwidth is invested in Vue 3 and into the future but also understand that some of Vue 2 users may have reasons to have to stay on Vue 2 for longer than expected so we want to make sure there is a good solution for users in that scenario.

Vue 3.3

Major planned features

• Stabilize Suspense
• Stabilize Reactivity Transform
• SSR Improvements
  • Lazy / Conditional hydration for async components
  • Improved SSR mismatch warnings
• Support imported types in <script setup> type-based-macros

Work on this version starts after the 2.7 stable release and hopefully get it ready by Q3 2022.

Experimental New Compilation Strategy

This is a truly experimental early exploration phase of the feature! So it even may not land!

The majority of users use Vue through the template and most of us in our day-to-day work interact with Vue through the single-file component format and this is a source format.

Vue as a framework has the opportunity to compile the file into vanilla JavaScript and CSS, and this step allows Vue to be a super compiler-oriented framework.

This new compilation strategy is inspired by solid.js. Instead of compiling templates into Virtual DOM render functions, it compiles them into imperative DOM initialization and reactive binding setup code.

Imagine this component:

// <script setup>
import { ref } from 'vue'
const count = ref(0)

<template>
	<div>
		<button
			:id="`foo-${count}`"
			:class="{ red: count % 2 }"
			@click="count++"
		>{{ count }}</button>
	</div>
</template>

This button contains several bindings.

The output code will look something like this:

import { ref, effect } from 'vue'
import {template, on, setClass, setAttr, setText } from 'vue/vapor'

const t0 = template(`<div><button>`)

export default () => {
	const count = ref(0)
	
	let div = t0()
	let button = div.firstChild
	let _button_class, _button_id, _button_text
	effect(() => {
		setClass(button, _button_class, (_button_class = {red: count.value % 2 }))
		setAttr(button, 'id', _button_id, (_button_id = `foo-${count.value}`))
		setText(button, _button_text, count.value)
	})
	on(button, 'click', () => count.value++)
	return div
}

The general idea is instead of generating a virtual DOM representation of the tree first and then walking it to initialize the actual DOM, we will analyze the base HTML structure of the template during compilation time and stringify it into the plain HTML without those bindings, then we initialize them directly using a template clone node which is faster than initializing all these nodes individually and stitch them together.

Then we generate imperative code that directly locates the nodes that need bindings. Then we generate code that set up the effect directly by setting up reactive updates for class, attribute bindings, and inner text.

Some of the benefits:

• Better v-for performance even without v-memo
• Significantly lower memory usage
• Significantly lighter base runtime size (if fully opt-in)
• Potentially lighter component abstraction cost

Adoption Strategy:

1. Opt-in at the component level
   • Embed in the existing Vue 3 virtual DOM-based app
   • Fully compatible with existing libraries
2. Opt-in at the app level

   • Entirely drops Virtual DOM runtime

   • Cannot use Virtual DOM-based components

   • Suitable for extremely performance-sensitive use cases

     
     

This doesn't really change the development aspect of it. The template syntax and the way you write your components will remain exactly the same. This is purely just how the compiler handles the output.

End of The First Talk

I hope you enjoyed this part and it can be as valuable to you as it was to me.

Over the next few days, I’ll share the rest of the talks with you. Stay tuned…

Also published here.