As a beginner to Vue.js development I doubt I’d really need to worry about following best practices, but it was good to skim through that information just to see what lies down the road. Likewise, I didn’t expect to get very much out of the “Extra Topics” section of Vue.js documentation but I skimmed through it anyway to see what I can pick up. More than I thought I would, actually!

I haven’t done enough web development to understand all of the scenarios outlined in “Ways of Using Vue” but I do understand several of them. And I think I understood enough of the rest to recognize situations if they should come up in a “Ah, that’s what document was talking about” way. The overarching lesson is that: Vue is happy to work in several different shapes and sizes.

I enjoyed getting a look under the hood with “Reactivity in Depth“. I don’t understand enough about JavaScript proxies to use it in my own code, but it was good to see some of the benefits and pitfalls of working within Vue’s usage of the mechanism. It mostly boils down to the fact a proxy is one level of indirection from the real object. Unfortunately, one of the downsides appears to be that additional effort must be made to make sure TypeScript understands data types through this layer of indirection.

Coming from a background of strongly-typed languages like C, I was not a fan of the free-form chaos freedom of JavaScript. Using TypeScript imposes some order to the madness, and I appreciate that. Vue.js itself was written with TypeScript and supports TypeScript Vue.js application code, but doing so wasn’t as straightforward as I had thought it might be. This is especially true of the simpler Options API, partly because JavaScript usage was so simple that additional effort to be TypeScript-friendly seems like a huge imposition. In contrast, Composition API takes more effort to write but it also resembles “normal” code more so TypeScript was a better fit. After reading through TypeScript sections and “Composition API FAQ” I wonder if I’d be better off focusing on the more powerful and TypeScript-friendly Composition API for my own Vue.js projects. I’ll push that decision off to later.

The “Rendering Mechanism” and “Render Functions and JSX” sections were a look under a hood of a different part of Vue.js: outputting Vue.js component data into HTML markup for the browser. I’m not as familiar with this problem space, so I didn’t understand all the problems solved by these approaches. I don’t foresee myself writing custom rendering functions, and hopefully I won’t have to debug standard rendering functions.

I enjoyed seeing some of the fun things possible with CSS animations in “Animation Techniques” but that’s further off in the future. I would want to get a functional understanding of building Vue.js applications before I worry about visual polish, and I would lean on libraries before I start fiddling with details for myself.

Speaking of the future, I appreciated “Vue and Web Components” because it addressed one of my open questions: how much of frameworks like Angular or Vue will remain relevant in the future as web standards evolve? Many of web development frameworks arose to solve problems people had with browser-supported standards. These fed into evolution of web standards and eventually, browsers incorporated those lessons rendering many web tools no longer relevant. This “Vue and Web Components” section explained how it’s not a conflict, at least today. Vue has features not yet on the roadmap for standardized web components. Furthermore: peaceful coexistance is possible: Vue components can be self-contained into a standard web component for use elsewhere, and Vue applications can consume standard web components. This is encouraging, and it’ll be interesting to see this situation evolve in the future. For now, I’m going to wrap up this Vue.js learning session.

As a Vue.js beginner, I doubt I’ll be building large scope projects in the near future. Despite that fact, I skimmed through solutions for scaling up a Vue.js application just to get a glimpse of what that involves. After that section of Vue.js documentation was “Best Practices”, and some of the items they called out were interesting.

When I tried out Vue.js Quick Start application, I was impressed by how small it was relative to the bare-bones boilerplate generated by Angular command line tools. I was curious what Vue.js would say about “Production Deployment” to make it even smaller and faster, and the answer is “not much”. The boilerplate build process with Vite apparently generates quite small code and any improvements would require domain-specific (and/or scenario-specific) optimizations.

Moving the focus from download size to runtime speed, there are a few tips for performance optimizations. As a Vue beginner, there weren’t much for me to absorb from this page. Either they are broad general optimization considerations that I’ve known from other contexts, or they dive into the deep weeds (what’s a shallowReactive?) that I didn’t yet understand.

I was glad to see Accessibility get its own section under Best Practices, but was mildly disappointed that its content appeared to be a rehash of general web accessibility concepts without any Vue-specific features. It would be nice if Vue directly help make building accessible sites easier, but I’ll settle for the topic at least getting mentioned even if generically.

For Security, it was great that their first and foremost item is Never Use Untrusted Templates. Good tip! About half of the rest of this page are variations on the same theme, giving examples of how user-provided information can be abused and how developers need to design against those abuses. Vue has minor protections in place, such as automatic escaping of strings, but it’s not foolproof. The developer must stay on guard.

These are all good tips, putting me in a good mood to finish off this set of Vue.js developer guides.

Reading through Vue.js documentation on “Built-in Components” I learned about powerful tools doing things a Vue application developer could not do on their own. But as a practically matter, I don’t think a beginner like myself would need to worry about them just yet. The same goes for the next section: “Scaling Up”, but I still wanted to skim through to see what scaling problems Vue thought deserved solving. This section was shorter than I had anticipated, because a lot of complexity has been delegated to other tools. These core Vue.js documentation pages would link to their documentation.

The section actually starts small by talking about Vue components and the Single-File Component (SFC) format because that is the basic unit of building large Vue apps. One of the first items is actually a pointer to scaling down via petite-vue for the progressive enhancement (sprinkle tiny bits of Vue in static site) usage scenario. Then it talks about tooling like an extension for editing Vue code in Visual Studio Code, and browser extension for debugging Vue code in browser.

The topic then moves to testing. Generic web application testing frameworks would work, but the Vitest test runner is optimized for unit testing Vue components. Once we get beyond unit tests, there’s a pointer to Cypress and a link to a Vitest vs. Cypress comparison.

For client-side routing, documentation gives a simple router implementation and a reference to Vue Router for a full power routing solution. For state management, we again have a simple implementation and a reference to Pinia for a more complete solution.

Server-side rendering (SSR) can get very complex, so the discussion started with the very important question: do we really need it? Sometimes goals can be satisfied with static-site generation (SSG) in which case we can use VitePress. But if actual SSR is required, there are multiple paths depending on the developer’s desire for control. Higher-level tools include Nuxt.js, which can also do static-site generation. And Quasar, which proclaims PWA capability as well as compiling to mobile apps and browser extensions. Plus it features its own Material Design compliant UI components, making it appear to be the “and the kitchen sink” solution. Which, depending on the project, may or may not be a fit for following best practices.

While reading Vue.js documentation on reusability, I learned of VueUse library filled with composable code available for use in our Vue apps. With that in mind, I was curious about the next section of documentation: “Built-in Components.” What’s special about these components? They must enable features requiring internal Vue support and could not be done (at least not efficiently) by an external code module. From what I can tell, they have one thing in common: they hook into platform changes to component structure.

First example supports transition animations. CSS defines a transition animation mechanism but that only applies to changing properties on an object. Animating the objects themselves being changed requires support like Vue’s <Transition> for individual components and <TransitionGroup> for elements in a list. By default, adding or removing components from the application means an abrupt and instantaneous change that may leave the user disoriented. These components allow designer to add transition animation to visually guide the user through such changes for a better user experience. Both by adding/removing classes to trigger CSS transition animation plus JavaScript hooks for whatever can’t be done via CSS.

An example of a feature that requires framework level support is Transition Mode, which manages how the old and new components interact to mitigate visually jarring artifacts. Moving from “mitigating a bad thing” to “enabling a great thing” is the Move Transitions demo for <TransitionGroup>, a great way to visually inform a user of changes in a list. After seeing that, I’ve become a fan of <Transition> / <TransitionGroup>. Sure, they can be abused just like all mechanisms designed to attract user attention (Die <blink> Die) but there’s plenty of room for subtle and tasteful designs. On the downside, I’m not a fan of Named Transitions which introduces more name magic to Vue.

In the spirit of Vue keeping things lightweight and not reinventing wheels, <Transition> / <TransitionGroup> only enables transitions, they do not define any animations themselves. This page links to animation libraries (Animate.css, GreenSock, Anime.js, Motion One) that it plays well with.

As much as I love some of the animations demonstrated here, as a practical matter I’m not likely to use any of these directly in the near future. If I start building projects with Vue, I’ll start without worrying about visual polish. For a first pass on visual polish, I’ll probably use something like Vue Material. Crafting my own visual styles with transition animations will be much further down the line, if ever.

I’m equally unlikely to use anything else in Vue’s “Built-in Components” section. <KeepAlive> keeps a <component> node alive to keep its state, in the expectation of eventual reinsertion back into the tree. <Teleport> moves visual elements somewhere outside of their proper location in Vue component hierarchy, useful for global model display dialog boxes. And <Sense> is still an experimental feature for consolidating visual feedback of multiple child asynchronous operations. (One spinning “waiting” animation instead of each component having their own.) <Sense> combined with <Transition> and <KeepAlive> to handle Vue Router changes is far too advanced of a technique for this beginner to worry about.

Which is true of most of the rest of Vue.js guides, but I wanted to skim over them anyway starting with “Scaling Up”.

Vue’js documentation’s “Components In-Depth” section gave me a pretty good idea of how Vue components are implemented and interact with each other. It’s a powerful mechanism of code organization and reuse, and I found it strange Codecademy’s “Learn Vue.js” course didn’t go into any details on componentization at all. Still, as useful as Vue components are, they can’t do everything and there are a few other mechanisms for code reusability in Vue.js. After reading “Reusability” section, my takeaway is that a beginner should know how to use these mechanisms: both to recognize their presence in example code and benefiting from work shared by others. In contrast, implementing these mechanisms is a more advanced topic a beginner can postpone until later.

The most significant page in this section is the first one: Vue Composables. These are self-contained packages of pure logic without a visual representation. In that regard it has some resemblance to Angular services but more limited in scope (which probably also means it is lighter weight.) It is possible to implement composable capability as a standard Vue component with no visual template (renderless component) but that incurs wasted overhead. For an even better idea of how a composable relate to other code reuse mechanisms, there’s a comparisons section on this page.

I was most fascinated by the async state composable example, because it seems to be a way to solve many of the problems RxJS wants to solve but with less of a learning curve. Also, this is optional versus RxJS which is required to make real use of Angular. But if we really want RxJS, there exist Vue composable to interoperate with RxJS. It is part of VueUse, a collection of Vue composition utilities that cover a lot of ground. I see stuff to help with concepts like an app going full screen, an app that wants to keep the device awake, and to help an app communicate over web sockets. Some of these aren’t terribly complex to implement on our own (like full screen) but using one of these composable component might be even easier.

Following the long and instructive page on Vue composable, there were two more pages far shorter in length. First is custom directives, a mechanism for installing and using code that needs direct low-level HTML DOM manipulation. It reads like a niche tool useful as a tool of last resort for things that can’t be done any other way. The page ends with “In general, it is not recommended to use custom directives on components.” And second page covers plugins, a mechanism to install functionality at the app level. We are warned to use plugins sparingly as too many of them start running into name conflicts and other general downsides of global code. This is partly because a plugin interacts with the rest of the app via non-plugin-specific mechanisms like Provide/Inject, custom directives, and attaching to global properties (app.config.globalProperties). The example on page shows two ways to do internationalization string plugin: attached to global properties, and provide/inject.

That’s a lot of different ways we can package Vue code to be reusable, but they’re limited in how they can participate in framework-level activities. For those, we need to use Vue’s built-in components.

Vue.js documentation “Essentials” section ended with a page on “Component Basics”. That lead to the next section “Components In-Depth” covering more details on how and when to use Vue.js components and how they interact with other components in the app. After reading the section, a few items caught my attention that may or may not be significant once I start getting hands-on with Vue.

Naming

Names for Vue.js components are PascalCase by convention but that has problems with using them in HTML attributes that are liable to coerce everything to lowercase. The same problem applies to Vue.js events which are camelCase by convention. Vue.js includes magic to look at equivalent kebab-case names. I guess it solves the problem but seems like a source for future problems. What if multiple cased versions exist in code, which one runs first?

Name collisions could also happen due to a feature called “fallthrough attributes”. A component with its own “click” could have another “click” fall through from above. Which one has priority? A declared emitted “click” handler would override native “click”. A fallthrough “click” and an emitted “click” would… both be called? Wild.

I like that Vue.js works to magically fix up these kinds of problems, but I’m uncomfortable magic renaming mechanisms exist. Historically they were a high risk for bugs.

Props and Events

Props are intended to be one-way, from parent to child. But because it’s valid to pass objects, a child can modify those object instance and potentially change parent state. For performance reasons, Vue doesn’t try to detect or prevent such “deep change”. Documentation boils down to “Don’t do that” though it did describe a few potential scenarios and their workarounds. The right way for a child to communicate with parent is with emitted events, which are raised only on its direct parent.

Props go from parent to immediate child, emitted events are raised from child to immediate parent. Going beyond that (communicating across multiple layers in the hierarchy) could get messy. I saw mention for one mechanism called State Management, which will be covered in the “Scaling Up” section. There’s also the Provide/Inject mechanism, which isn’t exactly the same as Angular services but has a few similarities. To make them properly reactive values require computed() which is normally just for Vue.js Composition API. To read more about computed(), we are instructed to go back and read certain documentation sections while set to Composition API and not Options API.

Props can have default values when not assigned by parent and/or marked as “required”. To help keep objects well-behaved, we can validate values for props to ensure information coming in to a component is within expected range. We can also validate events, which isn’t a mechanism that shows up very often. Usually, events going out are assumed to be within expected range because it was generated within that component. Or maybe I’m misunderstanding the Vue.js mechanism.

Going Bigger

As mentioned earlier (in the context of state management) there’s an entire section dedicated to scaling up to larger and more complex projects. But we do get a preview of several mechanisms because they rightly belong in “Components In-Depth”

One item I had wondered about upon learning v-model was how that would work across component boundaries. The short version: Either (1) bind to a native input component inside the custom component template, or (2) bind to a writable computed value with getter and setter.

I think I have a good grasp of slots, but not scoped slots. It took me three readings to understand it is a (convoluted at first glance) way for information to cross parent/child component boundary. This will definitely take several rounds of hands-on practice (and painful debugging sessions) to master.

Symbols keys were brought up as a way to avoid Provide/Inject naming ambiguity in large projects because they potentially have global scope. This is the first I remember seeing symbol keys, I expect to get more information about it elsewhere in documentation.

Vue.js apps that grow big enough to worry about download size can split components off to be loaded asynchronously on demand. Vite recognizes this mechanism as a breakpoint for bundling purposes. I have yet to come across its Angular counterpart. Possibly lazy loading?

Building and using components are great, but they are not the end of the Vue story on code reusability.

I went through a short tutorial on Vue.js site and found it to be a succinct overview. It doesn’t go very deep in any single topic, instead introducing a breadth of Vue concepts with links for deeper reading. The recommended step to follow that tutorial is the documentation section labeled “Essentials”. It was instructive reading and some items I found notable were:

HTML

Vue.js essentials logically started with Creating an Application where I was happy to learn HTML is at the forefront acting as I thought markup should. An Vue application instance mounts to an element on the page. This is in contrast to Angular (and what I understood of webpack) where JavaScript is at the forefront and primary job of index.html is to load that JavaScript. It has almost no content of its own.

Because of this, innerHTML markup on Vue-bound components can act as template for that component. Which is convenient, but I wonder if there’s a way to have fallback text to show the user before Vue loads. Or if Vue fails to load because the user turned off JavaScript in their browser.

Another effect of this architecture is that it’s valid to have multiple Vue applications on a single page, each mounted on a different HTML container element. I don’t think I can do this with Angular, which I’ve only ever seen control the entire page.

Or maybe I can mount no Vue application at all? I don’t understand the nuts and bolts yet, but it seems feasible to let the markup load quickly for the user to see. And sometime after that, mount Vue components as needed.

A downside of this approach is that Vue might have stuffed too much into the HTML file. One example is Vue dynamic arguments, which look just like HTML attributes to the browser and is liable to get coerced to lowercase by browser’s parser causing “name not found” errors.

Reactivity

The Reactivity Fundamentals section was the first Vue documentation section where I saw large differences between Vue’s ‘Options API’ and ‘Composition API’ variations. Using options API means letting Vue handle everything behind the scenes, but using composition means the author has to be aware of what goes on behind that curtain and have to correctly participate in the process.

A core part of Vue 3 is the use of JavaScript proxy around component data so Vue knows when data has changed and need to react accordingly. Some notable side effects are that this pointer behaves slightly differently. We should avoid arrow functions and avoid tracking state outside of data. If we inadvertently share static data across instances, that will become a source of problems.

The reactivity infrastructure leads to a significant difference between computed properties and methods. Computed values are updated only when their reactive dependencies (through their proxies) are updated. This allows performance optimizations like returning a cached value rather than running the computation again. In contrast, methods are always called.

Compared to Angular, Vue’s reactivity system is much more constrained in scope. Nothing like Angular’s use of RxJS, which was its own big sprawling thing.

Components

The Vue Essentials section ends with Component Basics which lived up to its name covering the very basics of Vue components. Enough for us to understand how the various concepts tie together, even if we don’t understand them in detail just yet. For those that want to get deeper, there are plenty of links for more details.

Communication between components and their parents are usually handled in one of three channels: (1) Hosts can set value on a component’s props. (2) Component can emit events to handlers on the host. (3) Host can send template fragment via slots. Hosts can dynamically control what components are loaded with <component> which seems like a very powerful tool, illustrated with a simple tabbed interface where each tab is a different component.

Compared to Angular, I didn’t see a mechanism for code to interact with components beyond parent-child relationships. The good news is that there’s no counterpart to the headache of Angular service registration and injection. The bad news is that I don’t know how to get similar functionality in Vue. [UPDATE: I found Vue’s Provide/Inject.]

Infrastructure

Vue Playground is used for live code examples that we can play with in the browser. It seems to be an openly available tool, I didn’t see any restrictions constraining it to Vue documentation examples. This is a very promising option for experimenting with Vue concepts hands-on later.

At several locations, there were links to video courses on Vue School. Normally, I’m not a fan of video instruction but perhaps I should at least try a few of their free courses to see how well I can learn. The bar is high: it needs to be pretty impressive for me to start paying a subscription!

The “Essentials” section ends with a page “Component Basics”, good preparation for me to read the next section: “Components in Depth”

After a brief detour exploring Vite’s support for legacy browsers like IE11, I returned to learn more about Vue.js from its own tutorial. Vue advertised itself as flexible in many ways and this is immediately visible on the first page of the tutorial: in the upper left corner we have two choices to make. Options vs. Composition API, and HTML vs. SFC format. Combined, it implies the tutorial can show us how to use Vue four different ways and would be a great resource for some direct comparisons.

SFC format integrate a component’s HTML template, CSS, and JavaScript/TypeScript all in a single *.vue file. These files are processed by a build-time tool like Vite to generate files actually going into a browser. In contrast, the HTML format is intended for using Vue without build tools. All of Vue is linked from the HTML and all script lives in the HTML as well for direct browser consumption.

Options API is the format used by Codecademy’s Vue.js course as well. It imposes a particular organization to Vue component data. Composition API does not impose such structure and so the JavaScript can be organized however you like but it also comes with requirement for managing overhead we wouldn’t have to worry about with Options API. In terms of expressive power, Options API is implemented using Composition API. Meaning anything we can do with Options we can do with Composition, but the reverse is not necessarily true.

For my first pass, I will leave things at default recommended for Vue beginners: Options API in SFC format. This tutorial is very short, with just 15 sections. Or more accurately 13 sections when accounting for the fact not much material is covered by the first page introduction or last page conclusion. The implementation structure is an in-browser learning environment similar in concept to Codecademy’s learning environment. The upside is that we don’t have to set up a local development environment, the downside is that we don’t get to see how a Vue development environment would look.

Vue’s tutorial covers a few important concepts with some overlap with Codecademy’s course (interpolation, directives, data/computed/method/watch) and some areas are different. It didn’t get into forms as Codecademy did, but did get into componentization, lifecycle hooks, and props/emits/slots which Codecademy’s course did not.

Both of those are shallower and more superficial than something like Angular’s “Tour of Heroes” tutorial, which went into far more depth starting with setting up a local development environment. If I want a Vue tutorial with that level of depth I will have to look elsewhere. Still, they were instructive and I’m glad I’ve gone through both Codecademy’s course and Vue.js tutorial. They prepared me to go deeper with Vue documentation starting with the “Essentials” section.

One tangential item I learned from this tutorial is the site https://jsonplaceholder.typicode.com/ for a publicly accessible free static mockup of generic API endpoints returning ipsum lorem data. This could come in handy for my own experiments in the future.