El Problema de la Complejidad

Se han lanzado aplicaciones en React que se volvieron imposibles de mantener, apps de Vue donde el flujo de datos era opaco, y apps de Angular donde implementar una funcionalidad simple tomaba una semana porque los efectos secundarios eran imposibles de rastrear.

Cada proyecto comenzó de manera simple—pero la complejidad siempre encontró la forma de colarse.

El problema no era el framework en sí; era que los frameworks permitían que la complejidad se infiltrara silenciosamente. Nada impedía agregar otro store global. Nada advertía cuando un componente dependía de diecisiete partes diferentes del estado. Nada obligaba a considerar dónde vivían los datos ni cómo fluían.

Svelte 5 es diferente—no porque sea "mágico", sino porque tiene opiniones que hacen de la simplicidad el camino predeterminado.

Esta serie se enfoca en construir sistemas que permanezcan calmados—no solo al principio, sino después de seis meses, un año, o incluso cuando los miembros del equipo cambian.

Qué Significa CALM

CALM es tanto un acrónimo como una promesa:

- **Contained (Contenido):** Cada pieza de estado tiene un único propietario explícito.
- **Automatic (Automático):** La reactividad ocurre sin conexiones manuales.
- **Local:** El estado vive lo más cerca posible de donde se usa.
- **Minimal (Mínimo):** Cada dependencia, abstracción y funcionalidad debe ganarse su lugar.

Juntos, estos principios definen un modelo mental que es fácil de entender, previene la complejidad accidental, permite modificar funcionalidades con confianza, y asegura la mantenibilidad a largo plazo

`Contained:` Propiedad que Puedes Ver

El estado pertenece a un lugar específico. No "en algún lugar de la app." No "en un store al que cualquier cosa puede acceder." El estado siempre debe tener un hogar claro. Un lugar al que puedas señalar.

+---------------------+
|  +page.server.ts    |
|   (authoritative)   |
+----------+----------+
           |
           v data flows down
+---------------------+
|   +page.svelte      |
|  $state (UI only)   |
+----------+----------+
           |
           v props
+---------------------+
|  Child Components   |
|  (read via props)   |
+---------------------+

One owner, many readers, controlled mutation

En Svelte 5 con SvelteKit, el estado está contenido por defecto:

El estado de ruta vive en las funciones load y en los componentes de página
El estado de componente vive en el componente que lo necesita
El estado global es poco frecuente y existe solo cuando se requiere de forma explícita

<!-- Component with contained state -->
<script>
	let isOpen = $state(false)
</script>

<button onclick={() => (isOpen = !isOpen)}> Toggle </button>
{#if isOpen}
	<div class="dropdown">...</div>
{/if}

La propiedad ahora es explícita y rastreable. Eliminar un componente elimina su estado. Los nuevos desarrolladores pueden entenderlo mirando una sola carpeta.

Cuando miras un componente, deberías poder responder: "¿De dónde vienen estos datos?" Si la respuesta es "tendría que revisar cinco archivos diferentes", algo salió mal.

El estado contenido significa:

Puedes entender un componente leyéndolo
Puedes eliminar una ruta sin romper partes distantes de la app
Puedes incorporar a un nuevo desarrollador mostrándole una sola carpeta

`Automatic:` Reactividad Sin Esfuerzo

La reactividad debe ser automática. No deberías tener que recordar llamar a setState. No deberías tener que envolver cosas en useMemo para evitar re-renders. No deberías tener que pensar en los arreglos de dependencias.

    $state            $derived             UI
+--------------+   +--------------+   +--------------+
|  count = 0   | > | doubled = 0  | > | renders "0"  |
+--------------+   +--------------+   +--------------+
       |
       | count++
       v
+--------------+   +--------------+   +--------------+
|  count = 1   | > | doubled = 2  | > | renders "2"  |
+--------------+   +--------------+   +--------------+

No dependency arrays. No manual subscriptions. It just works.

Los runes de Svelte 5 hacen que la reactividad sea automática:

<script>
	let count = $state(0)
	let doubled = $derived(count * 2)
</script>

<button onclick={() => count++}>
	{count} × 2 = {doubled}
</button>

Cambias count. La UI se actualiza. No tienes que pensar en ello.

Esto no es pereza—es corrección. La reactividad manual es una fuente de bugs. Dependencias olvidadas. Closures desactualizadas. Re-renders innecesarios. Svelte elimina la categoría por completo.

La reactividad automática significa:

Menos código que escribir
Menos bugs que corregir
Más tiempo para pensar en tu problema real

`Local:` Mantén el Estado Donde Pertenece

Piensa localmente. Actúa localmente. El estado debe vivir lo más cerca posible de donde se usa.

 X Premature lifting          OK Local-first

+-------------------+        +-------------------+
|       App         |        |       App         |
| isOpen = $state   |        |                   |
+---------+---------+        +---------+---------+
          |                            |
    +-----+-----+                +-----+-----+
    |           |                |           |
    v           v                v           v
+-------+   +-------+        +-------+   +-------+
|  Nav  |   | Main  |        |  Nav  |   | Main  |
+-------+   +---+---+        +-------+   +---+---+
                |                            |
                v                            v
          +-----------+            +------------------+
          | Dropdown  |            |    Dropdown      |
          | (needs    |            | isOpen = $state  |
          |  isOpen)  |            |   (owns it!)     |
          +-----------+            +------------------+

State lives where it's used. Lift only when proven necessary.

El instinto de "elevar el estado" o "ponerlo en un store" suele ser prematuro. La mayoría del estado no necesita compartirse. La mayoría del estado lo usa un componente, o una ruta, o un pequeño árbol de componentes.

El pensamiento local primero significa:

Comenzar con $state en el componente que lo necesita
Solo elevar cuando realmente necesitas compartir
Solo ir global cuando has demostrado que lo local no funciona

<!-- This is usually enough -->
<script>
	let isOpen = $state(false)
</script>

<button onclick={() => (isOpen = !isOpen)}> Toggle </button>

{#if isOpen}
	<div class="dropdown">...</div>
{/if}

Sin store. Sin context. Sin prop drilling. Solo el estado donde se necesita.

El estado global no es malo—simplemente es costoso. Cada pieza de estado global es una dependencia que cualquier componente podría tener. Es algo que todo el equipo necesita entender. Es un punto de acoplamiento que hace el refactoring más difícil.

Local primero significa pagar ese costo solo cuando obtienes un valor real a cambio.

`Minimal:` Cada Dependencia Debe Ganarse su Lugar

El mejor código es el código que no escribiste. La mejor abstracción es la que no creaste.

+------------------------------------------+
|       Need state management?             |
+---------------------+--------------------+
                      |
         +------------+------------+
         |                         |
         v                         v
+-----------------+      +-----------------+
| One component?  |      | Multiple routes?|
+--------+--------+      +--------+--------+
         |                        |
         v                        v
+-----------------+      +-----------------+
|   Use $state    |      |    Use load     |
|  (no library)   |      |    functions    |
+-----------------+      +-----------------+

Every abstraction must earn its place. Start simple.

Mínimo significa:

No agregar una librería hasta que hayas sentido el dolor que resuelve
No crear una abstracción hasta que hayas escrito el mismo código tres veces
No optimizar hasta que hayas medido

Svelte ayuda aquí también. Dado que la reactividad está integrada, no necesitas librerías de gestión de estado. Dado que el compilador es inteligente, no necesitas wrappers de memoización. Dado que la sintaxis está cerca del HTML, no necesitas librerías de componentes para cosas básicas.

Mínimo no significa "nunca uses librerías." Significa que cada dependencia debe ganarse su lugar. Cada abstracción debe justificar su existencia.

<!-- You probably don't need a Modal component library -->
<dialog bind:this={dialog}>
	<h2>Are you sure?</h2>
	<button onclick={() => dialog.close()}>Cancel</button>
	<button onclick={confirm}>Confirm</button>
</dialog>

La Promesa

Esta serie te enseñará a construir sistemas CALM con Svelte 5. Al final, tendrás:

Un modelo mental — Entenderás por qué ciertos patrones funcionan y otros no. No solo "cómo usar $state" sino "cuándo debería existir el estado y dónde debería vivir."

Un conjunto de patrones — Enfoques concretos y reutilizables para problemas comunes. Carga de datos. Manejo de formularios. Límites de error. Comunicación entre componentes. Patrones que escalan.

Confianza — El conocimiento de que no te estás perdiendo algo importante. Que no necesitas aprender doce técnicas avanzadas más. Que lo que sabes es suficiente.

No cubriremos todas las funcionalidades. Cubriremos las funcionalidades que importan para construir sistemas calmados. El resto puedes aprenderlo cuando—y si—lo necesitas.

Lo Que No Haremos

No vamos a:

Perseguir cada nueva funcionalidad — Las APIs experimentales son emocionantes, pero los sistemas calmados se construyen sobre bases estables
Abstraer prematuramente — Escribiremos código "aburrido" que sea fácil de entender
Optimizar antes de medir — Confiaremos en el compilador hasta tener evidencia de que no deberíamos
Agregar complejidad para sentirnos productivos — Resistiremos el impulso de diseñar arquitecturas cuando deberíamos estar construyendo

El Camino

Esto es lo que viene:

Fundamentos — Los runes que realmente necesitas (pista: son seis)
Modelos Mentales — Cómo pensar sobre el flujo de datos, la mutación, el estado derivado y los efectos secundarios
Construcción — Patrones prácticos de SvelteKit para enrutamiento, carga de datos, manejo de formularios y comunicación entre componentes
Mantenimiento — Patrones que mantienen tu app simple a medida que crece, incluyendo los errores que debes evitar
Proyecto Final — Una aplicación completa que demuestra todo, para que puedas ver cómo encajan las piezas

Cada publicación se basa en la anterior. Cada patrón gana su lugar. Al final, tendrás todo lo que necesitas.

Para Quién Es Esto

Esta serie es para desarrolladores que:

Han sufrido por la complejidad y quieren algo más simple
Son nuevos en Svelte y quieren comenzar con buenos hábitos
Conocen Svelte 4 y quieren entender la forma de hacer las cosas en Svelte 5
Están cansados de tutoriales que muestran juguetes en lugar de patrones reales

No es para desarrolladores que:

Quieren dominar cada rincón del framework
Necesitan conocer las funcionalidades experimentales ahora mismo
Prefieren documentación de referencia exhaustiva a guías con opiniones

Comencemos

Calmado no significa trabajar más lento. Significa construir sistemas que no te peleen. Sistemas donde el código que escribiste hace seis meses todavía tiene sentido. Sistemas donde las nuevas funcionalidades van al lugar obvio.

Svelte 5 hace esto posible. Esta serie te mostrará cómo.

A continuación: los seis runes que realmente necesitas. Ni más, ni menos.

Bienvenido a CALM con Svelte 5.