VueJS is on a crazy rise in popularity. In 12 months, Vue has doubled in weekly downloads going from 600k to 1.2M – ridiculous. And with bigger brands and developer teams getting on board, the current state of Vue, even before the release Vue3, is something way beyond the side project tool that it originally was.
One of the most interesting parts about Vue is its diverse audience. From hobby devs who just learned HTML/CSS all the way to senior developers wanting to switch frameworks, they truly need to fulfill the wishes of both ends of the spectrum.
Last month, Vue founder Evan You gave a talk at VueConf Toronto. In his talk, rather than going into the technical details and features of Vue 3.0, he instead decided to dive into the design pattern choices that the Vue Team made in implementing a lot of the Vue 3.0 features that they had planned.
These are some of the things he said that I found super interesting.
Challenges of Designing Vue3
As the project grew from You’s personal project to an extremely popular framework, the Vue team had to meet the needs of its developers. Like I said in the introduction they had a diverse audience with diverse use cases.
Some people only wanted to use Vue to add reactivity to legacy projects; others wanted a quick way to build prototypes; others, a framework to build a long-term, maintainable project.
As a framework that prioritizes its community first, You and his team was faced with a tough dilemma. They had to walk the tightrope and find the balance point. Focusing on easiness and simplicity lead to larger teams struggling to maintain a project. Focusing on adding complex tooling geared towards larger projects greatly raised the barrier of entry.
Finding this balance point and trying to make Vue attractive to as many people as possible drove a lot of the main changes during development. Some of the largest changes stemmed from having this mindset.
Approachability vs. Scalability
Ah yes. This was ultimately the underlying question when designing Vue.
How might we make Vue more scalable for huge projects while still keeping it approachable for all developers?
Currently, there are two ways to add Vue into a project.
- Pull Vue from a CDN – useful for people who merely want to inject some reactivity to a legacy project without needing a complete overhaul
- Vue-CLI – the complete package that most people think of when working in Vue
In Vue3, both of these methods are going to be viable options which will help make Vue a great resource for a variety of different projects.
Right now, one of the benefits that draws new people to Vue every day is its easiness and a gentle learning curve. Keeping this low entry barrier is important to You, who said “Approachability brings great value”.
However, with the growth of Vue, many development teams handling larger-scale projects exposed problems that only time could reveal. They had issues maintaining their project and issues with huge, confusing components, among others.
Vue2 Options API & Vue3 Composition API
Now the Composition API is one of the most well known things about Vue3. In a sentence, the Composition API allows you to group all your code for a specific feature in one place rather than spreading it all over a component.
Currently, Vue2 uses the Options API – in which a component object has a data, a methods, and a bunch of other options where you add code. While the Options API’s simplicity is what drove a ton of people to Vue, its scalability became an issue when dealing with huge components.
This is because with the Options API – a single feature (search, for example) will have it’s code split up all over the component’s options. This makes it hard to read and hard to trace.
To fix this, the Vue team decided to expose more of internal APIs of Vue (reactivity, watching changes) – making them standalone from components. This gives developers the ability to control exactly what is being exposed by each component. Instead of a bunch of different options, all you have to do is return the reactive data. This means that developers can put all the code for a certain feature in one place. Simple.
While this did cause a little bit of confusion in the Vue community when it was first introduced, it’s important to note that this feature is purely additive. The existing Options API will still work in the next iteration of Vue.
Furthermore, both APIs can be used also be used together to simply extract reusable code into a separate file. This is extremely useful for large existing projects that don’t want to refactor all their code.
By providing both of this choices, Vue3 once again will cater to all developers.
If you’re like me, you may be asking “Why Typescript?” and after listening to You’s talk, I’m looking forward to using Typescript in Vue3.
Template vs. JSX
Template vs JSX was one of the hottest topics used to compare Vue to React when it began to come out. However, with Vue working to become inclusive for all developers, it became essential to give people direct access to the render functions.
Greatly Improving Template Performance in Vue3
Listening to the talk, it seemed like this was one of the areas where You was really proud of his team’s work. They analyzed the slowdowns in the process and from what it seems, did a great job limiting them.
Currently, using a Virtual DOM contains a bottleneck – each component reactively tracks its dependencies. But watching is very slow because it compares screenshots by recursively walking through the whole element tree to detect changes.
One thing they noticed, was that in components, a majority of the node’s structure did not change. And if it did, with let’s say a v-if or something, then the content inside that v-if statement was mostly constant.
Using this idea, Vue partitions the template into different areas with dynamic node structures that are stable and won’t change and by subdividing this further and further it can greatly reduce the number of elements that need to be reactively watched.
Combining all these components creates a Block Tree or a template divided into blocks based on directives (v-if, v-for). Within each of these blocks the node structure is static and each block only needs a flat array to track its dynamic components. This eliminates the need to recursively check everything, drastically improving runtime.
Another thing that improves runtime is Static Hoisting. Essentially, there is no need to recreate elements without any dependencies on every render, so static hoisting instead creates one static element and reuses it.
According to some internal tests, template style in Vue3 is 120% faster than Vue2.
Power vs. Size
This topic came with what You describes as the dilemma of Vue2 – every new features increases the bundle size for every user regardless if they use it or not. To fix this, Vue3 will be a lot more modular. While this increases the number of imports developers will need, it ensures that they do not add unused libraries to their project.
With the goal of having the core of Vue3 be 10kb gzipped, adding everything as imports that can be treeshaken be Webpack is a great improvement.
In short, developers will not pay for features they never use.
Framework Coherences vs. Low-Level Flexibility
This issue is all about analyzing the scope of a framework. You discusses the current groups: small and large scope frameworks. A small scope is one where the framework gives you the building blocks and lets the community create solutions for a lot of the problems. A large scope framework has a lot of the solutions built-in.
Pros of a Small Scope Framework:
- need fewer concepts to get started for beginners
- more flexibility and user-innovations from the community
- smaller maintenance surface
Cons of a Small Scope Framework
- too many community sourced options gets overwhelming
- if there is no solution, the end-user will have to do lots of work
- community “mandated” patterns emerge that aren’t officially documented
Pros of a Large Scope Framework:
- common problems already have solutions that are well documented
- more cohesive as a framework because big libraries are centralized and not all community-sourced
Cons of a Large Scope Framework
- higher barrier to entry because of the amount of built-in solutions
- inflexible if built-in solution doesn’t fit the use case
- larger maintenance surface
Once again, You decided to blend these two concepts into what they’ve coined as a “Progressive” Scope. Here, there is a low barrier to entry with well documented solutions for common problems (router, state management).
Furthermore, there is a lot of low-level flexibility that gives people the ability to write custom compilers or render methods if they want to. This is perfect for all developers. People curious about Vue can get into it quickly with little startup time. Hardcore users can get into the nitty-gritty and try to tweak some low-level code.
You related this to an onion with all the different layers each of which just adds to the core. It’s also interesting how each layer kind of mirrors Vue’s growth as a framework. It started off with just reactivity, but as people wanted more features, the layers kept coming.
Conclusion on the Future of Vue3
I think that You’s talk was jampacked with information. It did a great job explaining the why behind so many of their design choices.
Vue3 seems like it truly is the best of both worlds – easy and approachable for curious people, powerful and scalable for long-term development process. I, for one, can’t wait for it to come.