Learn Pinia - History, Background & Why You Need Pinia

#Introduction

Before using a library, it's important to understand why the library exists. Pinia wasn't born in a vacuum — it's the answer to years of friction with Vuex and to Vue 3's need for more modern state management.

Episode 1 will trace Vue's state management journey: from the Flux-based Vuex 3/4, to the birth of Pinia as a personal experiment by Eduardo San Martin Morote, to its adoption as the official standard. You'll also see the problems Pinia solves and how it stacks up against other approaches such as manual composables and signal-based stores.

#The Evolution of Vue State Management

#From Vuex to Pinia

Vuex 3 and Vuex 4 were the first official state management solutions for Vue. Both follow the Flux pattern: a single global store, state must be changed through mutations, and mutations are triggered by actions. This pattern is disciplined, but it feels very verbose for day-to-day needs.

Pinia started in 2019 as an experiment by Eduardo San Martin Morote, a member of the Vue team. The goal was simple: state management that leverages Vue 3 reactivity and the Composition API directly, without Flux bureaucracy. In 2022, Pinia was officially established as the replacement standard for Vuex.

#The Meaning of the Name Pinia

The name Pinia is a play on piña (Spanish for pineapple). The idea: every store is like a leaf that is connected yet still separate — no single giant store, but many small independent stores. It's an apt metaphor for Pinia's modular architecture.

This modularity is reflected directly in its API: each store is defined with defineStore(id, ...), which accepts a unique id, and all stores are installed together through a single createPinia() instance. With this pattern, two features can have their own stores without interfering with each other.

#A Brief Timeline

As a quick overview of the Vue state management journey:

2014: Vuex 0.x appears as a flux adapter
2019: Pinia starts as a personal experiment
2021: Vue 3 is released, Vuex 4 follows
2022: Pinia becomes the official Vue standard

npm i pinia only became the standard command for new Vue 3 projects after this official adoption. Since then, pinia has been developed directly by the Vue team with full ecosystem support.

#Problems Pinia Solves

#Modular Stores with Full Type Safety

Vuex tends to encourage a single large store with many modules. Pinia flips that around: every feature has its own small store, and TypeScript is inferred automatically from the store definition. No need to write types over and over — the types for state, getters, and actions are derived from the code itself.

#No Mutations

The most striking difference: there are no mutations in Pinia. State can be changed directly, or through an action that carries the logic. Compare the two:

Vuex mutation vs Pinia action

// Vuex 4: mandatory mutation + action as intermediary
mutations: {
  increment(state) { state.count++ }
},
actions: {
  increment({ commit }) { commit('increment') }
}
 
// Pinia: just one action
state: () => ({ count: 0 }),
actions: {
  increment() { this.count++ }
}

this.count++ inside a Pinia action changes state directly without mutation boilerplate. Combined with a library size of about 1 KB when minified, Pinia is far lighter to carry around.

#Pinia vs Other Approaches

#Compared to Vuex 4

Vuex 4 is still relevant in legacy projects that use Vue 2, but for new Vue 3 projects, Pinia is the official choice. Pinia's DevTools is fully integrated, it supports the Composition API, and it has a smaller API to learn.

#When to Keep Using Vuex

Don't rush to migrate everything. Consider sticking with Vuex if your project is still on Vue 2 with no upgrade plans, or if your team is deeply tied to the mutation pattern. Migration can still happen later — Pinia's API is close enough to Vuex that the transition is gradual.

#Compared to Manual Composables

You could write a composable with a global ref to share state between components. This works for simple cases, but it lacks the DevTools, automatic SSR integration, plugin system, and testing tooling that Pinia has. Use composables for local state, and Pinia for widely shared state.

#Compared to Signal-Based Stores

Signal-based approaches like Legend-State or Valtio offer granular updates and new primitives. We'll compare signals more deeply in episode 22. For now, it's enough to note that Pinia remains the default choice because of its mature ecosystem and tooling.

#Considerations When Choosing State Management

When choosing state management, consider these four things in order:

• Ecosystem and team support: which one is maintained by the framework team itself.
• Tooling: the DevTools, plugins, and testing libraries available.
• Ease of migration: how close the API is to what you already know.
• Size and performance: the library's weight in your final bundle.

Across all four dimensions, Pinia wins in early 2026: maintained by the Vue team, built-in DevTools, mature plugins, and a weight of about 1 KB.

#Closing

Episode 1 gives you the historical context and philosophy behind Pinia. You now understand where Pinia came from, what problems it solves, and how it compares to Vuex, manual composables, and signal-based stores.

Key takeaways:

• Pinia was born from Eduardo San Martin Morote's experiment in 2019 and officially became the Vue standard in 2022.
• The name Pinia refers to piña — many small stores like the leaves of a pineapple.
• Pinia removes mutations: state is changed directly in actions.
• Type safety is inferred automatically, with no repeated type writing.
• It weighs about 1 KB and integrates fully with Vue DevTools.
• Use composables for local state, and Pinia for global state.

In the next episode, episode 2, we'll discuss core concepts and Pinia's main architecture — the anatomy of a store made up of state, getters, and actions, how Pinia works behind the scenes with reactive, and the difference between Options stores and Setup stores. All the foundations will be built there before we create our first store in episode 3.