Preparación

Necesitarás: una computadora, una unidad USB (o cualquier medio de almacenamiento extraíble), conexión a internet y habilidades básicas de búsqueda de información.

• Independientemente de la imagen de instalación que elijas, incluso para instalaciones sin conexión, se recomienda tener acceso a internet para garantizar la actualización del kernel y las herramientas. Si eres un usuario experimentado, puedes decidir por tu cuenta.
• Si usas Wi-Fi, asegúrate de que el nombre de la red esté en inglés, ya que el entorno tty no puede mostrar caracteres no ASCII, que aparecerán como bloques ilegibles.
• Si planeas configurar un arranque dual en el mismo disco, reserva suficiente espacio para Arch Linux: se recomienda al menos 100 GB para futuras instalaciones de software. Asegúrate de que la partición EFI tenga al menos 256 MB o crea un punto de montaje adicional.
• Verifica si la partición de Windows 10 utiliza cifrado BitLocker. Obtén la clave de recuperación con antelación y desactiva el "Inicio rápido" en las opciones de energía.

Antes de proceder, lee cuidadosamente y busca información sobre cualquier aspecto que no entiendas. Opera con precaución y realiza copias de seguridad regularmente: los datos son invaluables.

Creación del medio de instalación

1. Descarga la imagen de instalación únicamente desde la página oficial de descargas de Arch Linux. Ten en cuenta que Arch Linux es una distribución de lanzamiento continuo.
2. Si deseas compilar tu propio kernel, consulta la guía de Compilación tradicional del kernel.
3. Para la imagen de instalación oficial, se recomienda usar Ventoy para crear un USB booteable.

Instalación base

1. Arranque desde el medio de Arch Linux

Apaga la computadora, inserta la unidad USB y enciéndela. Ingresa al BIOS, selecciona el USB como dispositivo de arranque, elige la primera opción y presiona Enter para acceder al entorno de instalación de Arch Linux.

2. Verificación de UEFI

systemctl stop reflector.service
# Deshabilita la actualización automática de espejos, ya que las condiciones de red geográficas pueden causar problemas.

ls /sys/firmware/efi/efivars
# Si se muestra una lista de variables EFI, el sistema está arrancado en modo UEFI. La mayoría de las máquinas en 2025 usan UEFI.

3. Configuración de red

La instalación de Arch Linux requiere conexión a internet. La instalación sin conexión es más compleja; consulta la guía de Instalación sin conexión.

Para conexiones por cable, conecta el cable Ethernet, verifica si el LED de la interfaz parpadea y espera unos segundos para que se establezca la conexión.

En redes de campus, puede ser necesaria la autenticación a través de un enrutador superior. Consulta el proyecto nbtverify.

Para Wi-Fi, utiliza iwctl para conectarte.

lspci -k | grep Network
# Verifica si el adaptador inalámbrico está funcionando. Si estás seguro de que está operativo, puedes omitir este paso.

Comprueba si el kernel ha cargado el controlador de la red inalámbrica.

Deberías ver algo como: 00:14.3 Network controller: Intel Corporation Wi-Fi 6 AX201 (rev 20).

Si no aparece nada, verifica si la conexión inalámbrica está desactivada (blocked: yes).

rfkill list
# El adaptador inalámbrico suele llamarse wlan0.

ip link set wlan0 up
# Si aparece un error como “Operation not possible due to RF-kill”, ejecuta:
rfkill unblock wifi

# Conéctate a Wi-Fi usando iwctl
iwctl # Ingresa al modo interactivo
device list # Lista los dispositivos inalámbricos, por ejemplo, wlan0
station wlan0 scan # Escanea las redes
station wlan0 get-networks # Lista las redes Wi-Fi disponibles
station wlan0 connect wifi-name # Conéctate a la red. Los nombres no ASCII no son compatibles. Ingresa la contraseña cuando se solicite.
exit # Salir tras conectar

ping www.google.com # Prueba la conectividad de red

Para problemas de configuración de red, consulta Configuración de red/Inalámbrica.

5. Sincronización del reloj del sistema

timedatectl set-ntp true # Sincroniza la hora del sistema con la hora de la red
timedatectl status # Verifica el estado del servicio

6. Actualización de la lista de espejos (opcional para usuarios en España)

vim /etc/pacman.d/mirrorlist # Edita la lista de espejos si es necesario
Server = https://mirror.librelabucm.org/archlinux/$repo/os/$arch # Espejo de la UCM
Server = https://ftp.rediris.es/mirror/archlinux/$repo/os/$arch # RedIRIS
Server = https://mirrors.kernel.org/archlinux/$repo/os/$arch # Kernel.org

7. Creación de particiones Btrfs

Verificación de la información del disco

lsblk

Muestra la estructura actual de particiones. Verifica cuidadosamente el disco de destino para la instalación de Arch Linux.

Convenciones de nomenclatura de discos:

• Discos SATA: sda, sdb, sdc … Particiones: sda1, sda2, etc.
• Discos NVMe: nvme0n1, nvme1n1 … Particiones: nvme0n1p1, nvme0n1p2, etc.

Este ejemplo usa un disco SATA. Reemplaza /dev/sdx con tu disco real.

cfdisk /dev/sdx

Deberías ver una interfaz TUI amigable para particionar. 😄

Pasos para particionar

1. Crear partición Swap

• Usa las teclas de flecha para seleccionar Free space.
• Presiona [New], presiona Enter e introduce el tamaño (recomendado: 60%–100% de la RAM).
• Presiona [Type] y selecciona Linux swap.

2. Crear partición raíz (para Btrfs)

• Selecciona el Free space restante, presiona [New] y Enter.
• Introduce el tamaño (por defecto: usa todo el espacio restante).
• Mantén el tipo como Linux filesystem.

3. Escribir la tabla de particiones

• Selecciona [Write], escribe yes y presiona Enter.

  ⚠️ Nota: Los cambios no se aplicarán si no se escriben.

Formatear particiones

Volver a verificar los discos

fdisk -l

Formatear la partición EFI (si es nueva)

mkfs.fat -F32 /dev/sdxn

💡 Para usuarios con arranque dual, puedes reutilizar la partición EFI de Windows sin formatearla, pero asegúrate de que tenga suficiente espacio. Consulta Arranque dual con Windows.

Formatear la partición Swap

mkswap /dev/sdxn

Formatear la partición Btrfs

mkfs.btrfs -L myArch /dev/sdxn

Crear y montar subvolúmenes Btrfs

mount -t btrfs -o compress=zstd /dev/sdxn /mnt

# Crear subvolúmenes
btrfs subvolume create /mnt/@        # Subvolumen raíz
btrfs subvolume create /mnt/@home    # Subvolumen para /home

umount /mnt

⚠️ Recordatorio final

• ¡Revisa nuevamente todos los comandos y operaciones!
• Los errores pueden causar pérdida de datos, especialmente al eliminar particiones de Windows 😥.

8. Montar particiones, comenzando por la raíz

mount -t btrfs -o subvol=/@,compress=zstd /dev/sdxn /mnt # Montar el directorio /
mkdir /mnt/home # Crear el directorio /home
mount -t btrfs -o subvol=/@home,compress=zstd /dev/sdxn /mnt/home # Montar el directorio /home
mkdir -p /mnt/boot # Crear el directorio /boot
mount /dev/sdxn /mnt/boot # Montar el directorio /boot
swapon /dev/sdxn # Activar la partición de intercambio

df -h # Verificar montajes
free -h # Verificar el montaje de la partición de intercambio

9. Instalar el sistema

pacstrap /mnt base base-devel linux linux-firmware btrfs-progs
# Si usas el sistema de archivos Btrfs, instala el paquete btrfs-progs

pacman -S archlinux-keyring
# Si aparece un error de clave GPG, puede deberse a una imagen desactualizada. Actualiza archlinux-keyring para resolverlo.

pacstrap /mnt networkmanager vim sudo zsh zsh-completions
# Instala paquetes funcionales esenciales con pacstrap

10. Generar el archivo fstab

Genera el archivo fstab para definir las particiones del disco basadas en los montajes actuales.

genfstab -U /mnt > /mnt/etc/fstab

11. Entrar al nuevo sistema

arch-chroot /mnt
# ¿Desapareció el resaltado de código? ¡No te preocupes, has cambiado al chroot con éxito!

12. Configurar el nombre del host y la zona horaria

vim /etc/hostname
# Elige un nombre para el host (evita caracteres especiales o espacios para evitar problemas; no establecer un nombre de host puede causar fallos en algunas aplicaciones GUI).

vim /etc/hosts
# Edita el archivo hosts

Añade lo siguiente (reemplaza myarch con tu nombre de host, usa tabuladores para alinear):

127.0.0.1   localhost
::1         localhost
127.0.1.1   myarch.localdomain  myarch

ln -sf /usr/share/zoneinfo/Europe/Madrid /etc/localtime
# Crea un enlace simbólico para la zona horaria de Madrid

ls /usr/share/zoneinfo/
# Verifica las zonas horarias disponibles y actualiza el comando anterior si es necesario

13. Configuración del reloj de hardware

hwclock --systohc
# Sincroniza la hora del sistema con el reloj de hardware

14. Configuración de la localización

vim /etc/locale.gen
# Edita /etc/locale.gen, descomenta las líneas en_US.UTF-8 UTF-8 y es_ES.UTF-8 UTF-8
# Este paso define el idioma y el conjunto de caracteres para el software

locale-gen
# Genera las localizaciones

echo 'LANG=en_US.UTF-8' > /etc/locale.conf
# Configura locale.conf. No se recomienda usar localizaciones en español en tty, ya que pueden causar problemas de codificación

15. Establecer la contraseña de root

passwd root
# La entrada de la contraseña es invisible, ¡no es un problema del teclado! 😄

16. Instalar microcódigo

pacman -S intel-ucode # Para procesadores Intel
pacman -S amd-ucode # Para procesadores AMD

17. Instalar el cargador de arranque Grub

pacman -S grub efibootmgr os-prober
# grub es el cargador de arranque, efibootmgr escribe las entradas de arranque en NVRAM, os-prober permite detectar Windows 10

grub-install --target=x86_64-efi --efi-directory=/boot --bootloader-id=ARCH
# Instala grub en la partición EFI

vim /etc/default/grub
# Edita los parámetros de arranque

# Cambia "loglevel=3 quiet" a "loglevel=5 nowatchdog"
# Añade al final del archivo: GRUB_DISABLE_OS_PROBER=false

• Elimina el parámetro quiet de la línea GRUB_CMDLINE_LINUX_DEFAULT.
• Cambia loglevel de 3 a 5 para facilitar la depuración de errores.
• Añade nowatchdog para mejorar la velocidad de encendido/apagado.
• Habilita os-prober para detectar Windows 10.

grub-mkconfig -o /boot/grub/grub.cfg
# Genera el archivo de configuración de grub
# Si se detecta Windows 10, aparecerá una línea como: “Found Windows Boot Manager on /dev/nvme0n1p1@/EFI/Microsoft/Boot/bootmgfw.efi done”
# Si Windows está en otro disco, no aparecerá. Una vez en el sistema, vuelve a montar y ejecuta este comando nuevamente.

Consulta todos los parámetros en Arch Wiki.

18. Finalizar la instalación

exit # Regresa al entorno de instalación
umount -R /mnt # Desmonta las nuevas particiones
reboot # Reinicia

Tras reiniciar, inicia sesión con la cuenta root.

systemctl enable --now NetworkManager # Habilita y ejecuta el servicio NetworkManager
ping www.google.com # Prueba la conectividad de red

Para Wi-Fi:

nmcli dev wifi list # Lista las redes Wi-Fi cercanas
nmcli dev wifi connect "SSID de Wi-Fi" password "contraseña de red" # Conéctate a una red Wi-Fi específica

nmtui
# Personalmente, prefiero nmtui, ¡es más amigable! 😄

pacman -S fastfetch
fastfetch
# Instala fastfetch para verificar la información del sistema
# ¡Llega el momento clásico de neofetch! 😄

shutdown 0
shutdown -h now
poweroff
# Los tres comandos apagan el sistema. 😄 Apaga correctamente, ya que las políticas de energía aún no están configuradas.

¡Felicidades 🎉

¡Has instalado con éxito una versión mínima de Arch Linux sin interfaz gráfica!

La guía para la interfaz gráfica se incluirá en la próxima actualización, pero como siempre: ¡lee el manual!

Esta guía es solo un punto de partida, con la esperanza de inspirar a más entusiastas a unirse a la comunidad tecnológica.

Enlaces relacionados: NBTCA

• 📧 Correo de NBTCA: contact@nbtca.com
• 🌐 GitHub de NBTCA: https://github.com/nbtca

El renderizado del lado del servidor (SSR) mejora enormemente la “velocidad de carga de la primera pantalla” (FCP) de las aplicaciones web. El navegador recibe directamente el contenido HTML completo y lo renderiza de inmediato, por lo que el usuario puede ver la página muy pronto, algo muy favorable tanto para el SEO como para la percepción del usuario.

Sin embargo, en ese momento la página solo es una “carcasa estática”. Aunque parece haber terminado de cargar, los clics en botones y las interacciones con campos de entrada no producen ninguna respuesta. Para dar “vida” a esta página estática necesitamos un proceso llamado Hydration.

2. ¿Qué es Hydration?

Hydration es el proceso mediante el cual el framework JavaScript del cliente “toma el control” del HTML estático renderizado por el servidor.

El proceso es, a grandes rasgos, el siguiente:

1. El navegador descarga y ejecuta los paquetes JavaScript que necesita la página, como el runtime de React o Vue y el código de la aplicación.
2. El framework reconstruye el árbol de componentes en memoria.
3. El framework recorre el DOM renderizado por el servidor y conecta listeners de eventos, como onClick, a los nodos DOM correspondientes.
4. El framework garantiza que el estado de los componentes en el cliente coincida con el estado usado durante el renderizado en el servidor.

Solo entonces la página se vuelve realmente interactiva. Podemos imaginar Hydration así: recibes un modelo de LEGO ya montado (HTML), pero para hacer que una de sus piezas se mueva debes leer de principio a fin todo el manual de montaje (JS), comprobar la posición de cada bloque y, solo después, instalar una batería en esa pieza (conectar listeners de eventos).

3. El problema de Hydration: “una interfaz interactiva no interactiva”

Hydration resuelve la falta de interacción de las páginas SSR, pero también crea un nuevo cuello de botella de rendimiento, conocido como “valle inquietante” (Uncanny Valley) o “brecha de Hydration” (Hydration Gap).

El problema es el intervalo entre el momento en que el usuario ve el contenido de la página (FCP) y el momento en que esta puede responder realmente a sus interacciones (TTI). Durante ese intervalo, la página parece utilizable, pero en realidad está “congelada”.

Las causas son:

• Bloqueo por la descarga y ejecución de JS: El navegador debe descargar, analizar y ejecutar una gran cantidad de JavaScript antes de poder iniciar Hydration.
• Coste de arranque elevado: El framework debe realizar mucho trabajo en el cliente para reconstruir el árbol de componentes y conectar listeners, aunque el 90 % de la página sea contenido estático no interactivo.

4. Optimizaciones y alternativas a Hydration

Para resolver los problemas de rendimiento de Hydration, la comunidad ha explorado varios patrones más avanzados.

a. Hydration parcial (Partial Hydration)

La arquitectura de islas (Islands Architecture) popularizada por Astro es una implementación típica de Hydration parcial. Su idea central es que, de forma predeterminada, todos los componentes producen únicamente HTML estático (cero JS). Los componentes que necesitan interacción se pueden marcar explícitamente como “islas”.

Durante la compilación, Astro solo empaqueta y envía JavaScript para esos componentes “isla”. Así, el navegador solo hidrata unas pocas partes aisladas de la página, en lugar de la página completa, y reduce enormemente la cantidad de JavaScript que debe cargar y ejecutar al arrancar.

b. Hydration progresiva (Progressive Hydration)

Es una estrategia de optimización más granular que hidrata los componentes siguiendo un orden de prioridad. Por ejemplo, puede hidratar primero los componentes dentro del viewport o aquellos con los que el usuario está a punto de interactuar, y retrasar los componentes no críticos situados al final de la página.

c. Reanudabilidad (Resumability)

El framework Qwik propone un concepto revolucionario, la reanudabilidad (Resumability), cuyo objetivo es eliminar Hydration por completo.

Funciona de la siguiente manera:

1. Serialización: En el servidor, Qwik serializa todo el estado de la aplicación, las relaciones entre componentes, la información de los listeners de eventos y otros datos, y los incrusta en el HTML.
2. Reanudación: En el cliente, el diminuto runtime de Qwik (aproximadamente 1KB) no necesita reconstruir el árbol de componentes ni conectar todos los eventos al arrancar. Mediante un listener global, puede saber con precisión qué pequeño fragmento de código debe descargar y ejecutar cuando el usuario pulsa un botón concreto.

El objetivo de Qwik es lograr una interacción Instant-on. No “vuelve a ejecutar” el trabajo del servidor, sino que “reanuda” la ejecución desde el punto donde el servidor se detuvo.

Conclusión

Hydration es el puente entre el renderizado del servidor y la interacción del cliente, pero en las implementaciones tradicionales es un proceso costoso que puede perjudicar la experiencia del usuario. Los frameworks frontend modernos intentan dejar atrás este “mal necesario” mediante patrones innovadores como la Hydration parcial (Astro) y la reanudabilidad (Qwik), avanzando hacia un rendimiento extremo y una interacción más rápida.

Durante mucho tiempo, JavaScript fue prácticamente el único lenguaje del desarrollo frontend para la Web. Aunque ha tenido un enorme éxito, por ser un lenguaje dinámico e interpretado sigue encontrando límites de rendimiento al procesar tareas intensivas de CPU, como el renderizado 3D, la codificación y decodificación de vídeo o los cálculos complejos.

WebAssembly, abreviado WASM, nació precisamente para superar esta situación. No pretende sustituir a JavaScript, sino complementarlo con una herramienta potente que aporta a la plataforma Web un rendimiento y unas posibilidades sin precedentes.

2. ¿Qué es WebAssembly?

WebAssembly es un formato binario de instrucciones diseñado para una máquina virtual basada en pila. Es un lenguaje de bajo nivel parecido al ensamblador, pero no está pensado para que los desarrolladores lo escriban directamente.

En cambio, está diseñado como objetivo de compilación para lenguajes de alto nivel como C, C++, Rust y Go. Puedes escribir código en estos lenguajes de alto rendimiento, compilarlo en un archivo .wasm y ejecutarlo en el navegador a una velocidad cercana a la nativa.

Puntos clave:

• No sustituye a JavaScript: WASM y JavaScript trabajan como socios.
• Es un objetivo de compilación: escribes C++ o Rust y lo compilas a WASM.
• Es rápido, eficiente y portable: el rendimiento forma parte de su diseño desde el principio.

3. Cómo colaboran JavaScript y WASM

Un módulo WASM se ejecuta dentro de un entorno aislado. No puede acceder directamente al DOM, llamar a las API Web ni realizar solicitudes de red. Para todas esas operaciones necesita que JavaScript actúe como una capa intermediaria de «pegamento».

El modelo habitual de colaboración es el siguiente:

1. JavaScript se ocupa de la coordinación: el código JS gestiona la lógica general de la aplicación, procesa eventos del usuario y actualiza el DOM.
2. WASM se ocupa del cálculo: ante una tarea intensiva de cálculo, JS llama a las funciones exportadas por el módulo .wasm.
3. Intercambio de datos: JS y WASM pueden intercambiar datos con eficiencia, principalmente valores numéricos y bloques de memoria lineal.

Podemos imaginar JavaScript como un «director» y WebAssembly como un «ingeniero experto». El director se encarga de la comunicación y la coordinación, mientras el ingeniero resuelve los problemas técnicos más difíciles.

4. Casos de uso reales

WASM ya no es una tecnología experimental. Muchas aplicaciones Web de primer nivel lo usan para impulsar sus funciones principales:

• Figma: el motor de renderizado central de esta popular herramienta de diseño en línea está escrito en C++ y compilado a WASM, lo que permite una experiencia fluida de edición gráfica.
• Adobe Photoshop & Lightroom: Adobe llevó con éxito a la Web, mediante WASM, el núcleo en C++ de sus principales aplicaciones de escritorio, permitiendo usar un Photoshop potente desde el navegador.
• Google Earth: la nueva versión de Google Earth se ejecuta por completo en el navegador y WASM impulsa su complejo renderizado 3D del planeta.
• AutoCAD Web App: Autodesk compiló a WASM su gran motor CAD en C++, haciendo posible ejecutar una experiencia completa de AutoCAD en el navegador.

Estos casos demuestran que WASM ya puede llevar a la plataforma Web software complejo que antes se consideraba exclusivo de las aplicaciones de escritorio.

5. El futuro: WASI y más allá del navegador

La ambición de WASM no se limita al navegador. WASI (WebAssembly System Interface) es un estándar emergente que busca proporcionar a WASM un conjunto normalizado de API de sistema, como el acceso al sistema de archivos y a la red.

Esto significa que, en el futuro, los archivos .wasm podrían convertirse en un formato binario universal, multiplataforma y seguro, capaz de ejecutarse en cualquier lugar: desde servidores, donde podría competir con Docker, hasta nodos de computación perimetral y dispositivos del Internet de las cosas. Sería realmente «compilar una vez y ejecutar en cualquier lugar».

Conclusión

WebAssembly está transformando profundamente nuestra idea de los límites de una aplicación Web. Permite que JavaScript se concentre en lo que mejor hace —la interacción de la interfaz y la coordinación de la aplicación— y deja el techo de rendimiento en manos de módulos WASM compilados desde lenguajes de sistemas como Rust y C++. Para quienes desarrollan frontend, comprender las capacidades y los escenarios adecuados de WASM será clave para construir la próxima generación de aplicaciones Web de alto rendimiento.

En el desarrollo web llevamos mucho tiempo ante un dilema de experiencia de usuario:

• Aplicaciones multipágina (MPA): Su arquitectura es sencilla y estable, pero cada navegación realiza una carga completa, lo que provoca una “pantalla blanca” o un “destello” y rompe la continuidad de la experiencia.
• Aplicaciones de una sola página (SPA): El enrutamiento frontend ofrece una experiencia fluida sin recargas, pero obliga a los desarrolladores a gestionar manualmente animaciones de transición complejas, el estado y la división del código, con un coste de desarrollo elevado.

¿Existe una forma de conservar la sencillez de una MPA y obtener al mismo tiempo las transiciones fluidas de una SPA? La View Transitions API nació precisamente para eso.

2. ¿Qué es la View Transitions API?

La View Transitions API es una API nativa del navegador que ofrece un mecanismo para crear fácilmente transiciones animadas entre dos estados distintos del DOM.

Su flujo de trabajo principal es muy sencillo:

1. Al iniciar una transición, la API toma una “captura” de la página actual (el estado anterior).
2. Después se actualiza el DOM al nuevo estado mediante JavaScript.
3. La API también toma una “captura” de la nueva página (el estado nuevo).
4. Por último, el navegador crea una transición predeterminada y fluida, normalmente un fundido cruzado, entre la “captura anterior” y la “captura nueva”.

El navegador gestiona todo esto eficientemente a bajo nivel; nosotros solo tenemos que llamar a una función sencilla.

3. ¿Cómo se utiliza?

Usar View Transitions en una aplicación de una sola página es muy sencillo. Basta con envolver la lógica que actualiza el DOM en la función document.startViewTransition.

// 假设你有一个更新页面内容的函数
async function updatePageContent(url) {
  const response = await fetch(url);
  const newHtml = await response.text();
  // 用新内容替换旧内容 (具体实现取决于你的架构)
  document.body.innerHTML = newHtml;
}

// 在导航链接的点击事件中调用
document.querySelector('a').addEventListener('click', (event) => {
  event.preventDefault();
  const url = event.target.href;

  // 检查浏览器是否支持
  if (!document.startViewTransition) {
    updatePageContent(url); // 不支持则直接更新
    return;
  }

  // 使用 View Transition
  document.startViewTransition(() => updatePageContent(url));
});

¡Solo con esto, la navegación ya tendrá un efecto de fundido cruzado predeterminado!

4. Personalizar la animación de transición

El fundido predeterminado es excelente, pero el verdadero poder de la API está en su capacidad de personalización. Cuando se ejecuta startViewTransition, el navegador crea una estructura DOM que contiene los siguientes pseudoelementos:

• ::view-transition: Elemento raíz que contiene toda la transición.
• ::view-transition-old(root): La “captura” de la vista anterior.
• ::view-transition-new(root): La “captura” de la vista nueva.

Podemos sustituir el efecto predeterminado mediante una animation de CSS; por ejemplo, para crear una animación de entrada lateral:

@keyframes slide-in {
  from { transform: translateX(100%); }
}

::view-transition-new(root) {
  animation: slide-in 0.5s ease-out;
}

5. La “transformación” entre elementos: view-transition-name

La función más sorprendente de la API permite reconocer elementos diferentes de dos páginas como el mismo objeto y crear una animación de “transformación” fluida entre ambos.

Esto se consigue mediante la propiedad CSS view-transition-name.

Página A (lista):

<img src="thumbnail.jpg" style="view-transition-name: hero-image;" />

Página B (detalle):

<img src="full-size.jpg" style="view-transition-name: hero-image;" />

Al navegar de la página A a la página B, el navegador detecta que ambos elementos tienen el mismo view-transition-name. Entonces calcula automáticamente las diferencias de posición, tamaño y forma, y genera una transición fluida en lugar de un simple fundido. Esto funciona especialmente bien en transiciones de imágenes, tarjetas y elementos similares.

Conclusión

La View Transitions API aporta a la web la esperada capacidad nativa de crear transiciones. Simplifica enormemente efectos de interacción que antes requerían complejas bibliotecas de animación JavaScript y facilita más que nunca la creación de experiencias fluidas y cinematográficas. Con su integración en frameworks como Astro y Nuxt, y su futura adopción en aplicaciones multipágina, se convertirá sin duda en una habilidad estándar para los desarrolladores web modernos.

Los React Server Components (RSC) son un nuevo tipo de componente React que se renderiza durante la compilación o en el servidor. A diferencia de los componentes tradicionales renderizados en el navegador del cliente —ahora denominados «Client Components»—, el código de los RSC nunca se envía al cliente. El navegador solo recibe el HTML ya renderizado o un formato especial de transmisión en streaming.

Esto marca la evolución de React desde una biblioteca puramente del lado del cliente hasta un framework full-stack capaz de trabajar de forma fluida entre el servidor y el cliente.

2. ¿Qué problemas resuelven los RSC?

Los RSC surgieron principalmente para resolver los siguientes problemas fundamentales:

• Paquetes de JavaScript enormes: Las aplicaciones React tradicionales empaquetan y envían al cliente el código JS de todos los componentes, incluso el de aquellos que no son directamente interactivos, lo que ralentiza la carga inicial. Los RSC permiten conservar en el servidor una gran cantidad de componentes —como textos, diseños y visualizaciones de datos—, logrando que tengan un peso de JS igual a cero.
• Cascadas de peticiones (Request Waterfalls): El patrón típico para obtener datos en el cliente consiste en: renderizar un componente -> useEffect -> realizar una petición -> esperar los datos -> volver a renderizar. Si los componentes están profundamente anidados, se forma una cascada de peticiones que retrasa la presentación de la página. Los RSC pueden obtener los datos directamente en el servidor con async/await y transmitirlos junto con los componentes al cliente, resolviendo el problema de raíz.
• Acceso directo a recursos del backend: Los RSC se ejecutan en un entorno de servidor como Node.js, lo que significa que pueden acceder directa y seguramente a bases de datos, sistemas de archivos o APIs internas sin exponer endpoints adicionales al cliente.

3. Server Components frente a Client Components

Comprender la diferencia entre ambos es la clave para dominar los RSC.

Regla práctica: Considera todos los componentes como Server Components de forma predeterminada. Solo cuando el componente necesite useState, useEffect o gestionar eventos del usuario como onClick, añade la directiva "use client"; al principio del archivo para marcarlo como Client Component.

4. ¿Cómo trabajan juntos?

Una aplicación React moderna será una combinación de ambos. Por ejemplo, en la página de un artículo de blog:

• PageLayout (Server Component): Se encarga del diseño general.
• ArticleContent (Server Component): Obtiene los datos del artículo desde una base de datos o un archivo Markdown y los renderiza.
• LikeButton (Client Component): Contiene useState y un evento onClick para gestionar la interacción de «Me gusta».
• Comments (Client Component): Obtiene y muestra los comentarios e incluye interacciones como el envío de formularios.

Los Server Components pueden reservar en el servidor los «huecos» que ocuparán los Client Components y, finalmente, el navegador ensambla ambos de forma fluida.

Conclusión

React Server Components representa un profundo cambio de paradigma que amplía las capacidades de React desde el navegador hasta el servidor y aporta ventajas considerables de rendimiento y una mejor experiencia de desarrollo. Aunque introduce un nuevo modelo mental, su uso práctico mediante frameworks como el App Router de Next.js está convirtiendo rápidamente a RSC en un nuevo estándar para crear aplicaciones Web escalables y de alto rendimiento.

En una aplicación Node.js accedemos a las variables de entorno mediante process.env. Es un mecanismo sencillo y eficaz, pero tiene un problema inherente: no ofrece seguridad de tipos.

Los valores del objeto process.env son string o undefined. Esto provoca varios problemas habituales:

• Un undefined inesperado: si olvidas definir una variable en el archivo .env o en el servidor, process.env.MY_VAR será undefined en tiempo de ejecución. Esto puede causar un TypeError en una parte profunda de la lógica.
• Tipos que no coinciden: quizá esperes que un número de puerto sea de tipo number, pero process.env.PORT siempre es una cadena y tienes que llamar manualmente a parseInt en cada lugar donde lo utilizas.
• Lógica de validación dispersa: solemos escribir código defensivo en distintos rincones, como const port = process.env.PORT || 3000;, lo que desordena la gestión de las variables de entorno.

2. Principio fundamental: fallar cuanto antes

Para una configuración crítica como las variables de entorno, una buena práctica es fallar cuanto antes (Fail-Fast).

Esto significa que la aplicación debe comprobar al comienzo del arranque si se han proporcionado todas las variables obligatorias y si su formato es correcto. Ante cualquier problema, debe lanzar inmediatamente un error y detenerse, en lugar de fallar más adelante, en un momento imprevisible, debido a una configuración incorrecta.

Así descubrimos los problemas de configuración de inmediato durante el despliegue o el desarrollo, y no cuando una persona accede a la aplicación.

3. Validación con seguridad de tipos mediante Zod

Zod es una biblioteca de declaración y validación de esquemas diseñada primero para TypeScript. Resulta especialmente adecuada para resolver el problema de seguridad de tipos de las variables de entorno.

Nuestra estrategia es:

1. Definir un esquema Zod para todas las variables de entorno.
2. Analizar process.env con ese esquema al arrancar la aplicación.
3. Si el análisis falla —es decir, si no pasa la validación—, Zod lanza un error y el arranque de la aplicación falla.
4. Si el análisis tiene éxito, obtenemos un objeto completamente tipado que utilizamos en toda la aplicación.

Ejemplo de implementación

Primero, instala Zod: pnpm add zod

Después, crea un archivo dedicado a las variables de entorno, por ejemplo src/env.ts:

// src/env.ts
import { z } from 'zod';

// 1. 定义 Schema
const envSchema = z.object({
  NODE_ENV: z.enum(['development', 'production', 'test']).default('development'),
  DATABASE_URL: z.string().min(1, 'DATABASE_URL is required.'),
  PORT: z.coerce.number().int().positive().default(3000),
  // z.coerce 会尝试将字符串转换为数字
});

// 2. 解析和导出
// .parse 会在验证失败时抛出错误，实现 "Fail-Fast"
export const env = envSchema.parse(process.env);

Ahora puedes importar desde src/env el objeto env en cualquier otra parte de la aplicación.

// src/server.ts
import { env } from './env'; // 导入经过验证和类型化的 env 对象

// env.PORT 的类型是 `number`，而不是 `string | undefined`
const port = env.PORT;

// env.NODE_ENV 的类型是 'development' | 'production' | 'test'
if (env.NODE_ENV === 'development') {
  console.log('Running in development mode');
}

// 如果 DATABASE_URL 未设置，应用在启动时就已经崩溃了，
// 所以在这里我们可以放心地认为它是存在的，并且类型是 `string`。
connectToDatabase(env.DATABASE_URL);

4. Ventajas

Este patrón aporta beneficios inmediatos:

• Seguridad de tipos completa: cuando accedes a env.PORT en el código, TypeScript sabe que es un number.
• Documentación y validación centralizadas: el propio archivo env.ts se convierte en la documentación oficial de las variables de entorno y reúne toda la lógica de validación.
• Ejecución fiable: evita errores en tiempo de ejecución provocados por variables de entorno mal escritas, ausentes o con formato incorrecto.
• Fallo temprano: cualquier problema de configuración se descubre inmediatamente durante el despliegue o el desarrollo.

Conclusión

Adelantar la validación de las variables de entorno al arranque de la aplicación y utilizar una herramienta como Zod para garantizar la seguridad de tipos es una práctica de ingeniería con una excelente relación entre esfuerzo y beneficio. Mejora notablemente la robustez de la aplicación y la confianza de quienes la desarrollan, y constituye una parte imprescindible de un proyecto TypeScript moderno.

A comienzos de 2024, el equipo de Vue publicó la versión 3.4, cuyo nombre en clave es «Slam Dunk». Aunque no es una versión tan revolucionaria como la 3.0, incorpora mejoras importantes en dos áreas clave: la optimización interna del rendimiento y la mejora de la experiencia de desarrollo.

Los cambios más destacados incluyen la reescritura del sistema reactivo, la estabilización de la API defineModel y una sintaxis de v-bind más concisa.

2. Reescritura del sistema reactivo

Vue 3.4 incluye una importante reescritura de su sistema reactivo central. El objetivo principal de este trabajo es mejorar la eficiencia de las propiedades calculadas con computed.

En versiones anteriores, una propiedad calculada podía volver a evaluarse innecesariamente aunque sus dependencias no hubieran cambiado realmente. Gracias a un seguimiento de dependencias más inteligente, la nueva versión garantiza que el cálculo solo se active cuando sea verdaderamente necesario, reduciendo los rerenderizados innecesarios de componentes.

Para la mayoría de quienes desarrollan, esto es una «comida gratis»: no hay que modificar el código y basta con actualizar a la versión 3.4 para obtener automáticamente la mejora de rendimiento.

3. defineModel: enlace bidireccional elegante para componentes

Antes de la versión 3.4, implementar en un componente un enlace bidireccional similar a v-model exigía bastante código repetitivo:

Antes 👎:

<script setup>
const props = defineProps(['modelValue'])
const emit = defineEmits(['update:modelValue'])

// 通常需要一个计算属性来包装
const value = computed({
  get: () => props.modelValue,
  set: (val) => emit('update:modelValue', val)
})
</script>

<template>
  <input v-model="value" />
</template>

Vue 3.4 lleva la API defineModel de la fase experimental a una versión estable. Ahora, el mismo comportamiento solo requiere una línea de código:

Ahora (Vue 3.4) 👍:

<script setup>
const model = defineModel()
</script>

<template>
  <input v-model="model" />
</template>

La macro defineModel registra automáticamente la prop modelValue y el evento update:modelValue, y devuelve un ref que se puede leer y escribir directamente. Esto simplifica enormemente el desarrollo de componentes compatibles con v-model.

4. Forma abreviada de v-bind para nombres iguales

Otra mejora sintáctica de la experiencia de desarrollo es la forma abreviada de v-bind cuando los nombres coinciden. Si la prop que se pasa a un componente tiene el mismo nombre que una variable definida en <script setup>, ahora se puede omitir el valor del atributo.

Antes 👎:

<script setup>
const id = 'my-id'
const title = 'Hello Vue'
</script>

<template>
  <MyComponent :id="id" :title="title" />
</template>

Ahora (Vue 3.4) 👍:

<script setup>
const id = 'my-id'
const title = 'Hello Vue'
</script>

<template>
  <MyComponent :id :title />
</template>

Este pequeño cambio hace que el código de las plantillas sea más limpio y fácil de leer.

Conclusión

Vue 3.4 es una iteración sólida. Mediante optimizaciones de rendimiento en las capas internas y la simplificación de las API de alto nivel, refuerza la filosofía de Vue como framework «progresivo»: ofrece sólidas garantías de rendimiento para aplicaciones grandes y, al mismo tiempo, ventajas prácticas para el trabajo diario. Destaca especialmente la estabilización de defineModel, que resuelve un problema persistente al encapsular componentes y es el aspecto más elogiable de esta actualización.

En el desarrollo frontend moderno, un proyecto suele necesitar una combinación compleja de herramientas para funcionar con fluidez:

• Linter: ESLint comprueba la calidad del código JavaScript/TypeScript.
• Formateador: Prettier unifica el estilo del código.
• Compilador: Babel o TypeScript (tsc) transforman el código.
• Empaquetador: Webpack, Rollup o Vite empaquetan la aplicación.

Gestionar la configuración, los plugins, las versiones y las interacciones de estas herramientas ya supone por sí solo una cantidad considerable de trabajo. Es lo que se conoce como «fatiga de herramientas». Durante años, la comunidad ha explorado la posibilidad de una cadena de herramientas todo en uno, con la esperanza de resolver todos los problemas con una sola herramienta.

2. La visión de Rome y el nacimiento de Biome

Rome fue un proyecto ambicioso iniciado por Sebastian McKenzie, antiguo empleado de Facebook y autor de Babel, con el objetivo de reescribir en TypeScript toda la cadena de herramientas frontend. Su visión era ofrecer una herramienta unificada, de alto rendimiento y sin configuración. Sin embargo, tras años de desarrollo e intentos de comercialización, Rome Labs anunció en 2023 el cese de sus operaciones.

Por suerte, el código central de Rome era de código abierto. La comunidad actuó con rapidez, creó un fork llamado Biome y confió su mantenimiento a una organización comunitaria dedicada a heredar y materializar la visión original de Rome.

3. ¿Qué es Biome?

Biome es una cadena de herramientas frontend de alto rendimiento reescrita en Rust. Busca ofrecer una experiencia de desarrollo unificada y extremadamente rápida que sustituya a una serie de herramientas independientes como ESLint y Prettier.

A finales de 2023, las funciones principales de Biome se concentraban sobre todo en el Linter y el Formateador, donde ya demostraba una capacidad impresionante.

Principales ventajas:

• Rendimiento excepcional: Gracias a Rust, Biome funciona mucho más rápido que ESLint y Prettier, escritos en JavaScript. En bases de código grandes, la mejora puede alcanzar un orden de magnitud.
• Configuración unificada: Un único archivo biome.json permite gestionar el comportamiento de todas las herramientas y sustituir archivos dispersos como .eslintrc, .prettierrc y .editorconfig.
• Diagnósticos detallados: El Linter de Biome no solo señala los errores, sino que también ofrece abundante contexto y sugerencias de corrección para ayudar a los desarrolladores a entender la raíz del problema.
• Compatibilidad con Prettier: El formateador de Biome busca ser compatible con más del 95% de las reglas de Prettier, por lo que el coste de migrar desde Prettier es muy bajo.

4. Primeros pasos

Puedes probar rápidamente Biome en tu proyecto mediante npx:

# 检查当前项目中的代码问题
npx @biomejs/biome check ./src

# 自动修复可修复的 lint 问题
npx @biomejs/biome check --apply ./src

# 格式化代码
npx @biomejs/biome format --write ./src

Crea un archivo biome.json para personalizar las reglas y la configuración:

{
  "$schema": "https://biomejs.dev/schemas/1.4.1/schema.json",
  "organizeImports": {
    "enabled": true
  },
  "linter": {
    "enabled": true,
    "rules": {
      "recommended": true
    }
  }
}

5. Perspectivas de futuro

La hoja de ruta de Biome es muy clara: sobre la base de estabilizar el Linter y el Formateador, implementará gradualmente un Compilador, Empaquetador, Ejecutor de pruebas y otras funciones, hasta convertirse en una verdadera cadena de herramientas todo en uno.

Aunque todavía es joven, su excelente rendimiento, su modelo abierto impulsado por la comunidad y su atención a la experiencia de desarrollo ya han convertido a Biome en una nueva fuerza imposible de ignorar entre las herramientas frontend. Para los equipos que buscan simplificar su conjunto de herramientas y mejorar la eficiencia del desarrollo, Biome ofrece una opción de futuro muy atractiva.

Durante más de una década, Node.js ha sido sinónimo de JavaScript en el servidor. Aunque Deno propuso ideas nuevas sobre seguridad y API modernas, la posición de Node.js nunca pareció verse realmente amenazada. Sin embargo, en septiembre de 2023, el lanzamiento oficial de Bun 1.0 indicó que esto podría cambiar.

Bun no es simplemente otro runtime de JavaScript, sino un kit de herramientas todo en uno, diseñado desde cero y centrado en el rendimiento, que busca cubrir todo el ciclo de vida desde el desarrollo hasta el despliegue.

2. El núcleo de Bun: velocidad, velocidad y más velocidad

El principal objetivo de diseño de Bun es el rendimiento. Para lograrlo, tomó varias decisiones técnicas particulares:

• El lenguaje Zig: Bun está implementado en Zig, un lenguaje moderno de programación de sistemas centrado en el rendimiento y el control de la memoria, lo que permite optimizar al máximo los detalles de bajo nivel.
• El motor JavaScriptCore: A diferencia de Node.js y Deno, que utilizan el motor V8 de Google, Bun eligió JavaScriptCore (JSC) de Apple. JSC es conocido por arrancar más rápido y consumir generalmente menos memoria.

Estas decisiones permiten que Bun muestre cifras de rendimiento sorprendentes al iniciar scripts, en la velocidad de bun install y en la eficiencia de ejecución de sus API integradas.

3. Mucho más que un runtime

El diseño todo en uno de Bun es otro de sus rasgos distintivos. No es solo un sustituto del comando node; también incorpora:

• Gestor de paquetes: bun install es varias o incluso decenas de veces más rápido que npm install. Utiliza una caché global de módulos y algoritmos eficientes de resolución de dependencias para reducir considerablemente el tiempo de instalación.
• Herramienta de compilación/empaquetador: Bun incluye un empaquetador de alto rendimiento capaz de convertir directamente un proyecto en un ejecutable o en código para el navegador, con un rendimiento comparable al de esbuild.
• Transpilador nativo: Puedes ejecutar directamente archivos TypeScript (.ts) y JSX (.jsx, .tsx) sin configurar antes tsc o babel. Bun los transforma a gran velocidad durante la ejecución.
• Ejecutor de pruebas: bun test ofrece un entorno de pruebas muy compatible con Jest, pero con una velocidad de ejecución mucho mayor.

Esto significa que, para un proyecto nuevo, quizá solo necesites instalar la herramienta bun para completar todo el proceso de desarrollo, pruebas y empaquetado.

4. Compatibilidad con Node.js

Para facilitar la migración, el equipo de Bun ha dedicado un gran esfuerzo a la compatibilidad con las API de Node.js. Incluye soporte para la resolución de node_modules, módulos CommonJS (require) y ESM (import), así como numerosos módulos centrales de Node.js, como fs, path y http.

En teoría, muchos proyectos existentes de Node.js pueden ejecutarse directamente con bun y beneficiarse de inmediato de mejoras de rendimiento.

5. Desafíos y futuro

La aparición de Bun desafía la filosofía, arraigada desde hace tiempo en el mundo frontend, de «combinar pequeñas herramientas especializadas». Su modelo amplio e integrado ofrece una comodidad incomparable y un gran rendimiento desde el primer momento, aunque también puede sacrificar parte de la flexibilidad.

Node.js posee un ecosistema enorme y maduro que Bun difícilmente podrá igualar a corto plazo. Sin embargo, el lanzamiento de Bun 1.0 marcó que ya estaba preparado para producción. Su asombroso rendimiento y su experiencia de desarrollo integrada resultan irresistibles para proyectos nuevos y equipos que buscan la máxima eficiencia.

Independientemente de que Bun llegue o no a destronar a Node.js, su aparición ya ha dado un nuevo impulso a la evolución de la cadena de herramientas JavaScript y ha establecido un nuevo referente de rendimiento.

Si escribiste código frontend hace algunos años, seguro que conoces Sass o Less. Estos preprocesadores CSS ofrecen una función que encanta a casi todos los desarrolladores: el anidamiento de selectores. Permite escribir las reglas de los selectores hijos dentro del selector padre, como al escribir HTML, lo que mejora enormemente la legibilidad y organización del código.

// Sass 语法
nav {
  ul {
    margin: 0;
    padding: 0;
    list-style: none;
  }

  li { display: inline-block; }

  a {
    display: block;
    padding: 6px 12px;
    text-decoration: none;
  }
}

Durante años dependimos de herramientas de compilación para convertir esta sintaxis en CSS normal que los navegadores pudieran entender. Pero ahora la situación ha cambiado.

2. Llega el anidamiento nativo de CSS

Desde principios de 2023, los principales navegadores —Chrome, Safari y Firefox— anunciaron sucesivamente su compatibilidad con el módulo nativo CSS Nesting. Esto significa que podemos escribir reglas anidadas directamente en archivos .css, sin ningún preprocesamiento.

El ejemplo anterior se puede escribir con CSS nativo así:

/* 原生 CSS 语法 */
nav {
  ul {
    margin: 0;
    padding: 0;
    list-style: none;
  }

  li { display: inline-block; }

  a {
    display: block;
    padding: 6px 12px;
    text-decoration: none;
  }
}

Sí, ¡parece exactamente Sass!

3. El importante papel de &

Al igual que en los preprocesadores, el símbolo & también desempeña un papel fundamental en el anidamiento nativo: representa al selector padre. Resulta especialmente útil al trabajar con pseudoclases, pseudoelementos o selectores combinados.

.card {
  background: white;
  border-radius: 8px;

  /* & 代表 .card */
  &:hover {
    box-shadow: 0 4px 12px rgba(0,0,0,0.1);
  }

  /* & 代表 .card，组合成 .card.dark-mode */
  &.dark-mode {
    background: #333;
  }

  /* & 代表 .card，组合成 .card > .header */
  > .header {
    font-weight: bold;
  }
}

4. Una diferencia pequeña pero importante respecto a Sass

En Sass puedes anidar directamente un selector de clase, por ejemplo .card { .title { ... } }. Esto no estaba permitido en las primeras versiones de la especificación nativa CSS Nesting: toda regla anidada tenía que empezar con un símbolo como &, >, + o ~.

Aunque la especificación más reciente ha relajado esta restricción y permite anidar directamente selectores de tipo, como article { h1 { ... } }, al anidar selectores de clase sigue siendo una buena práctica utilizar & para ser explícitos y evitar ambigüedades.

/* 推荐写法 */
.article {
  & .author-name {
    font-style: italic;
  }
}

/* 不推荐的写法 (在某些早期实现或严格解析器中可能无效) */
.article {
  .author-name {
    font-style: italic;
  }
}

El uso de & expresa claramente que .author-name es descendiente de .article.

5. Compatibilidad de navegadores y futuro

En septiembre de 2023, todos los navegadores modernos principales —Chrome 112+, Safari 16.5+ y Firefox 117+— ya eran compatibles con CSS Nesting. Esto significa que podemos empezar a adoptarlo gradualmente en producción.

La llegada del anidamiento nativo de CSS es otro hito importante en la evolución de la propia plataforma web. Reduce nuestra dependencia de las herramientas de compilación, vuelve CSS más potente y expresivo, y permite a quienes comienzan en el desarrollo frontend escribir y entender los estilos de una forma más intuitiva.

Antes de la aparición de Utility-First, contábamos con muchas metodologías CSS excelentes para organizar los estilos, por ejemplo:

• BEM (Block, Element, Modifier): Utiliza la convención de nombres block__element--modifier para mantener los estilos independientes y fáciles de mantener.
• OOCSS (Object-Oriented CSS): Promueve la separación entre estructura y apariencia, y entre contenedor y contenido.
• CSS-in-JS: Escribe CSS directamente dentro de componentes JavaScript para encapsular los estilos a nivel de componente.

Estos métodos resolvieron hasta cierto punto la contaminación global de CSS y la organización del código, pero también suelen traer problemas nuevos: el esfuerzo mental de poner nombre a innumerables clases, la molestia de cambiar entre archivos y el posible coste en tiempo de ejecución de CSS-in-JS.

2. ¿Qué es Utility-First?

Utility-First es una filosofía CSS que propone ofrecer una serie de clases utilitarias de propósito único y nombre estable, y construir interfaces complejas combinando esas clases.

Por ejemplo, en lugar de crear una clase .card y definir su display, padding y box-shadow en un archivo CSS, se escribe directamente lo siguiente en HTML:

<div class="block p-6 rounded-lg shadow-lg bg-white">
  
</div>

Aquí, block, p-6, rounded-lg y las demás clases utilitarias se ocupan cada una de una sola tarea pequeña.

3. Tailwind CSS: el modelo de Utility-First

Tailwind CSS es actualmente el framework CSS Utility-First más popular. Ofrece un conjunto extremadamente completo de clases utilitarias que cubre casi todas las propiedades CSS de uso habitual.

Ventajas principales:

• Desarrollo extremadamente rápido: Casi nunca hay que salir del archivo HTML. Al combinar clases atómicas se puede construir rápidamente prácticamente cualquier diseño, lo que aumenta enormemente la eficiencia del prototipado y el desarrollo.
• Un sistema de diseño obligatorio: Como todos los estilos —colores, espaciado y tamaños de fuente— proceden de una configuración predefinida (theme), el equipo puede mantener fácilmente la coherencia de la interfaz y evitar los “números mágicos”.
• Sin preocupaciones por los nombres: “Los dos grandes problemas de la informática son la invalidación de caché y poner nombres.” Tailwind permite olvidarse casi por completo de nombrar clases CSS.
• Rendimiento excepcional: Durante la compilación de producción, Tailwind analiza los archivos y elimina todas las clases CSS que no se utilizan mediante PurgeCSS (o su motor JIT integrado), por lo que el archivo CSS final suele ser muy pequeño.

4. ¿“Infierno de nombres de clase”? — Otra perspectiva sobre las desventajas

La crítica más habitual a Tailwind es que hace que el HTML sea muy voluminoso y difícil de leer, como si se regresara a la época de los “estilos inline”.

<button class="py-2 px-4 font-semibold rounded-lg shadow-md text-white bg-blue-500 hover:bg-blue-700">
  Click me
</button>

Sin duda requiere un periodo de adaptación. Sin embargo, sus defensores sostienen que:

1. Los estilos y la estructura ya están estrechamente acoplados, por lo que colocarlos juntos puede facilitar el mantenimiento.
2. Al extraer componentes reutilizables, como componentes de React o Vue, esta aparente “confusión” se puede encapsular.

Para las combinaciones de estilos que deben reutilizarse, Tailwind ofrece la directiva @apply:

/* in your css file */
.btn-primary {
  @apply py-2 px-4 font-semibold rounded-lg shadow-md text-white bg-blue-500 hover:bg-blue-700;
}

Así se puede utilizar .btn-primary en HTML. No obstante, la recomendación oficial de Tailwind es resolver la reutilización mediante componentes.

Conclusión

El éxito de Utility-First y Tailwind CSS marca un cambio en la idea de la “separación de responsabilidades” en el desarrollo frontend: se pasa de la separación de lenguajes (HTML/CSS/JS) a la separación de componentes. Mediante un enfoque aparentemente “primitivo”, resuelve muchos problemas prácticos del desarrollo web moderno y ofrece a los desarrolladores un atajo hacia interfaces eficientes, coherentes y de alto rendimiento.

Las pruebas end-to-end (E2E) son la última línea de defensa para garantizar la calidad de una aplicación. Simulan acciones reales del usuario —clics, escritura y navegación— para comprobar que el flujo completo funciona correctamente. Sin embargo, las pruebas E2E también tienen fama de ser «frágiles» e «inestables»:

• Comportamiento asíncrono: cuando se ejecuta el script, es posible que los elementos del DOM todavía no se hayan cargado y la prueba falle. Quienes desarrollan tienen que añadir muchos wait o sleep manuales, lo que vuelve las pruebas poco fiables.
• Compatibilidad entre navegadores: conseguir que las pruebas sean estables en todos los navegadores principales —Chrome, Firefox y Safari— supone un gran reto.
• Depuración difícil: cuando una prueba falla en un entorno CI/CD, reproducir y localizar el problema es complicado por la falta de instantáneas del momento y registros de red.

Para resolver estos problemas surgió una nueva generación de herramientas de pruebas, y Playwright es una de las más destacadas.

2. ¿Qué es Playwright?

Playwright es una biblioteca de Node.js desarrollada por Microsoft para automatizar los navegadores Chromium (Chrome y Edge), Firefox y WebKit (Safari). Fue creada por miembros clave del equipo que desarrolló originalmente Google Puppeteer. Puede considerarse su sucesora espiritual, pero con un diseño más moderno y potente.

3. Principales ventajas de Playwright

a. Pruebas realmente mult navegador

Esta es la ventaja más notable de Playwright. Con una única API unificada puedes escribir pruebas que se ejecuten en los tres motores principales. Así resulta sencillo descubrir y corregir errores que solo aparecen en un navegador concreto, como Safari.

b. Esperas automáticas (Auto-Waits)

Playwright resuelve de raíz los problemas de asincronía. Antes de ejecutar una acción, como page.click(), realiza automáticamente una serie de comprobaciones de operabilidad, por ejemplo:

• Esperar a que el elemento aparezca en el DOM.
• Esperar a que el elemento sea visible.
• Esperar a que una animación deje de cubrir el elemento.
• Esperar a que el elemento pueda recibir eventos.

Esto significa que casi nunca es necesario escribir esperas manuales, lo que mejora sustancialmente la estabilidad de las pruebas.

c. Potentes herramientas complementarias

• Codegen (generador de código): es una función revolucionaria. Puedes ejecutar pnpm exec playwright codegen example.com y Playwright abrirá una ventana del navegador. Todas las acciones que realices se grabarán automáticamente y se convertirán en código de prueba. Esto reduce enormemente la barrera de entrada para escribir pruebas E2E.

• Trace Viewer (visor de trazas): es la «máquina del tiempo» de Playwright. Cuando una prueba falla, puedes generar un archivo con la traza completa. Al abrirlo con Trace Viewer puedes:

  • Consultar una instantánea del DOM en cada paso de la prueba.
  • Consultar el registro completo de solicitudes de red.
  • Consultar los mensajes y errores de la consola.
  • Moverte en ambos sentidos por la línea temporal para ver de forma intuitiva los cambios de la página antes y después de cada acción.

Esto hace que depurar fallos de CI sea más sencillo que nunca.

4. Un ejemplo de prueba sencillo

La API de Playwright tiene un diseño muy intuitivo.

import { test, expect } from '@playwright/test';

test('页面应有正确的标题', async ({ page }) => {
  await page.goto('https://playwright.dev/');

  // 断言页面的 title 包含 "Playwright"
  await expect(page).toHaveTitle(/Playwright/);
});

test('点击 "Get started" 链接应跳转到介绍页', async ({ page }) => {
  await page.goto('https://playwright.dev/');

  // 通过角色和名称定位并点击链接
  await page.getByRole('link', { name: 'Get started' }).click();

  // 断言 URL 包含 "intro"
  await expect(page).toHaveURL(/.*intro/);
});

Conclusión

Gracias a su excelente compatibilidad entre navegadores, sus fiables esperas automáticas y unas herramientas de depuración inigualables —especialmente Trace Viewer—, Playwright ha establecido un nuevo estándar para las pruebas E2E de aplicaciones Web modernas. No solo mejora la estabilidad y la fiabilidad de las pruebas, sino también la experiencia al escribirlas mediante herramientas como Codegen. Si buscas para tu proyecto una solución de automatización moderna y potente, Playwright es sin duda una de las mejores opciones.

La esencia del desarrollo frontend consiste en «convertir el estado en una interfaz de usuario». A lo largo de los años hemos presenciado la evolución continua de los modelos reactivos: desde la manipulación manual del DOM, pasando por los patrones MVC/MVVM, hasta el DOM virtual (Virtual DOM) popularizado por React. Al procesar por lotes los cambios de estado y realizar el Diffing a nivel de componente, el VDOM simplificó enormemente el desarrollo de interfaces.

Sin embargo, el VDOM no es una solución universal. El coste de volver a renderizar y hacer Diffing a nivel de componente puede convertirse en un cuello de botella en ciertos escenarios muy dinámicos. En los últimos años, un paradigma más antiguo pero optimizado mediante compiladores modernos —la reactividad de granularidad fina (Fine-Grained Reactivity)— ha vuelto al centro del escenario, y su principal vehículo son los Signals.

2. ¿Qué son los Signals?

Un Signal es una primitiva reactiva (Reactive Primitive) que encapsula un valor y puede notificar automáticamente a todas sus dependencias cuando dicho valor cambia. A diferencia de los frameworks VDOM, que rastrean los cambios a nivel de componente, un Signal crea automáticamente un grafo de dependencias en el punto donde se leen los datos.

Cuando se actualiza el valor de un Signal, solo se vuelven a ejecutar los cálculos (Memo) o efectos secundarios (Effect) que dependen directa o indirectamente de él. Así se consiguen actualizaciones precisas y «quirúrgicas» del DOM, sin necesidad de realizar Diffing sobre un VDOM.

Su núcleo suele estar formado por tres primitivas:

• createSignal(value): Crea una unidad de estado reactiva.
• createEffect(() => {}): Crea un efecto secundario que rastrea automáticamente sus dependencias y responde a los cambios.
• createMemo(() => {}): Crea un cálculo reactivo derivado y almacenado en caché.

// SolidJS 语法示例
const [count, setCount] = createSignal(0);

const doubleCount = createMemo(() => count() * 2);

createEffect(() => {
  console.log(`The double count is: ${doubleCount()}`);
});

setCount(1); // 这将触发 memo 重新计算，并触发 effect 重新执行

Un modelo mental fundamental es que, en un framework basado en Signals como SolidJS, la propia función del componente solo se ejecuta una vez durante la inicialización. Las actualizaciones posteriores están completamente impulsadas por el sistema reactivo, no por una nueva renderización del componente.

3. Adopción generalizada en el ecosistema

Los Signals no son un concepto totalmente nuevo; sus ideas se remontan a frameworks tempranos como Knockout.js. Sin embargo, gracias a los compiladores modernos de JavaScript, han cobrado nueva vida y han sido adoptados ampliamente por los principales frameworks:

• SolidJS & Qwik: Están construidos por completo sobre Signals y son implementaciones de referencia de este paradigma.
• Preact: Incorporó soporte oficial mediante el paquete @preact/signals, que puede integrarse en proyectos existentes de Preact/React.
• Vue: ref y computed de su Composition API son, en esencia, una implementación de Signals.
• Svelte 5: La próxima actualización «Runes» supone una reestructuración del modelo reactivo de Svelte, inspirada y basada en el paradigma de Signals.
• Angular: Sus versiones recientes también han incorporado Signals como nuevas primitivas reactivas.

Esta convergencia entre frameworks demuestra el valor de los Signals como modelo reactivo eficiente y predecible.

4. Ventajas y concesiones

Ventajas:

1. Rendimiento excelente: Al evitar el VDOM y las nuevas renderizaciones a nivel de componente, suele ofrecer resultados sobresalientes en las pruebas de rendimiento.
2. Previsibilidad: El flujo de las actualizaciones de estado es claro y fácil de comprender y depurar.
3. Bajo uso de memoria: No es necesario mantener una representación virtual de todo el árbol de componentes.

Concesiones:

1. Cambio de modelo mental: Los desarrolladores acostumbrados al ciclo de renderización de React deben adaptarse al nuevo modelo en el que «el componente solo se ejecuta una vez».
2. Integración con el ecosistema: Aunque los Signals son potentes por sí mismos, su integración profunda con el enorme ecosistema VDOM de React —por ejemplo, con ciertas bibliotecas de UI— puede requerir trabajo adicional de adaptación.

Conclusión

El resurgimiento de los Signals marca una evolución importante en los paradigmas de gestión de estado del frontend. Devuelve la atención de los desarrolladores desde «cómo se renderiza un componente» hacia la cuestión más esencial de «cómo fluye el estado». Gracias a su profunda integración con los compiladores, los Signals ofrecen una excelente experiencia de desarrollo y, al mismo tiempo, abren nuevas posibilidades en los límites de rendimiento de las aplicaciones Web.

En el desarrollo tradicional con frontend y backend separados, la API es el «contrato» entre ambos. Normalmente mantenemos ese contrato de estas maneras:

• API RESTful: mediante herramientas como OpenAPI (Swagger), que generan y mantienen documentación detallada de la API.
• GraphQL: mediante un estricto Schema Definition Language (SDL), que define las estructuras de datos y las operaciones.

Estas soluciones funcionan, pero comparten un problema: el contrato y la implementación están separados. Cuando alguien del frontend llama a una API, confía en que devolverá la estructura descrita en la documentación o el esquema. Si cambia la implementación del backend —por ejemplo, se renombra un campo— y la documentación o el esquema no se actualizan a tiempo, la discrepancia solo aparece en tiempo de ejecución y provoca un error.

¿Existe una forma de mantener este «contrato» sincronizado automáticamente con la implementación e incluso descubrir discrepancias durante la compilación?

2. La idea central de tRPC: compartir tipos, no esquemas

tRPC (TypeScript Remote Procedure Call) propone una solución radical pero muy sencilla: si tanto el frontend como el backend usan TypeScript, ¿por qué no compartir directamente los tipos?

tRPC permite escribir funciones TypeScript normales como API del backend y llamarlas directamente desde el frontend, con inferencia de tipos y autocompletado completos, como si fueran funciones de un módulo local.

No depende de ningún esquema ni de generación de código. El único «contrato» son los propios tipos de TypeScript.

3. ¿Cómo funciona?

La magia de tRPC procede de la inferencia de tipos y de una pequeña capa de encapsulación ingeniosa.

a. Backend: definir el router de la API

En el backend —normalmente un servicio Node.js— se utilizan las funciones de tRPC para crear uno o varios «routers». Cada router reúne un conjunto de «procedures» invocables, es decir, los endpoints de la API.

// server/router.ts
import { initTRPC } from '@trpc/server';
import { z } from 'zod'; // 使用 Zod 进行运行时校验

const t = initTRPC.create();

export const appRouter = t.router({
  // 定义一个名为 `getUser` 的查询 procedure
  getUser: t.procedure
    .input(z.object({ userId: z.string() }))
    .query(({ input }) => {
      // 在这里查询数据库或执行其他逻辑
      const user = { id: input.userId, name: 'Alex' };
      return user;
    }),

  // 定义一个名为 `createUser` 的变更 procedure
  createUser: t.procedure
    .input(z.object({ name: z.string() }))
    .mutation(({ input }) => {
      const user = { id: `${Math.random()}`, name: input.name };
      return user;
    }),
});

// 导出 router 的类型定义
export type AppRouter = typeof appRouter;

b. Frontend: crear el cliente y llamar a la API

En el frontend solo hay que importar del backend AppRouter como tipo. Es importante observar que solo se importa un tipo, no código del servidor.

// client/trpc.ts
import { createTRPCReact } from '@trpc/react-query';
import type { AppRouter } from '../server/router'; // 只导入类型

export const trpc = createTRPCReact<AppRouter>();

Ahora puedes llamar a la API desde un componente React como si fuera una función local, con seguridad de tipos y autocompletado completos.

// client/components/UserInfo.tsx
import { trpc } from '../trpc';

function UserInfo({ userId }: { userId: string }) {
  // `useQuery` 的第一个参数是 procedure 的路径
  // 你输入 `trpc.` 时，IDE 会自动提示 `getUser` 和 `createUser`
  const userQuery = trpc.getUser.useQuery({ userId });

  if (userQuery.isLoading) {
    return <div>Loading...</div>;
  }

  // `userQuery.data` 的类型被自动推断为 { id: string; name: string }
  return <div>User: {userQuery.data?.name}</div>;
}

Si ahora quien desarrolla el backend cambia el campo que devuelve getUser de name a fullName, userQuery.data?.name producirá inmediatamente un error de compilación de TypeScript en el frontend, en lugar de descubrirse en tiempo de ejecución.

4. ¿Por qué elegir tRPC?

• Seguridad de tipos absoluta de extremo a extremo: es su principal valor. Elimina toda una clase de errores causados por contratos de API que no coinciden.
• Excelente experiencia de desarrollo: el autocompletado del IDE evita consultar documentación o adivinar la estructura de la API. Refactorizar se vuelve extraordinariamente sencillo y seguro.
• Sin generación de código: no hay pasos adicionales de compilación, por lo que el ciclo de respuesta es muy rápido.
• Ligero y flexible: tRPC es muy pequeño y puede integrarse con cualquier framework frontend y servicio backend.

Conclusión

tRPC aporta una fluidez sin precedentes al desarrollo TypeScript full-stack. Al eliminar la dependencia de la documentación de API y los esquemas, hace que la colaboración entre frontend y backend sea directa y extremadamente segura. Sus ventajas son aún mayores en una arquitectura monorepo. Si estás construyendo una aplicación TypeScript full-stack, tRPC es una herramienta revolucionaria a la que merece la pena dedicar tiempo.

Los frameworks frontend modernos como React, Vue y Svelte han mejorado enormemente la experiencia de desarrollo al crear aplicaciones web complejas. Pero cuando los usamos para crear blogs, portafolios, documentación o sitios de marketing, surge una pregunta: ¿de verdad necesitan estos sitios, centrados principalmente en presentar contenido, cargar toda la página como una aplicación de una sola página (SPA)?

La respuesta suele ser «no». En este tipo de sitios, la necesidad principal del usuario es acceder rápidamente al contenido. Un exceso de JavaScript, en cambio, retrasa el tiempo hasta la interactividad (TTI) y perjudica tanto la experiencia de usuario como el SEO.

Astro nació precisamente para resolver este problema.

2. La idea central de Astro: contenido primero y cero JS por defecto

Astro es un generador de sitios estáticos (SSG) moderno cuya idea central es priorizar el contenido. Su objetivo es realizar tanto trabajo como sea posible durante la compilación y enviar al navegador la menor cantidad posible de JavaScript.

Para lograrlo, Astro propuso dos grandes innovaciones:

• Cero JavaScript por defecto (Zero-JS by Default): Astro renderiza durante la compilación todos tus componentes de interfaz, ya estén escritos en React, Vue o Svelte, como HTML puro. Así, el navegador recibe una página estática y no necesita cargar el runtime JS de ningún framework, por lo que la carga es extremadamente rápida.
• Arquitectura de islas (Islands Architecture): Esta es la esencia de Astro. En un «océano» de HTML estático, cualquier componente que necesite interacción en el cliente puede marcarse como una «isla». Astro empaqueta y carga de forma independiente el JavaScript que necesitan esas islas, mientras el resto de la página permanece completamente estático.

3. ¿Cómo funcionan las «islas»?

En Astro puedes marcar un componente como una isla interactiva añadiendo una directiva client:*.

Por ejemplo, supongamos que tenemos un componente contador escrito en React llamado Counter.jsx. Podemos usarlo en una página de Astro de esta manera:

---
// src/pages/index.astro
import Counter from '../components/Counter.jsx';
---
<html>
  <body>
    <h1>Astro 示例</h1>
    <p>这是一个静态的段落，它不会加载任何 JS。</p>

    {/* 这个组件是一个交互式岛屿 */}
    <Counter client:load />

    <p>这是另一个静态段落。</p>
  </body>
</html>

La directiva client:load le indica a Astro:

1. Renderizar en el servidor el HTML inicial del componente Counter.
2. Crear un paquete JS independiente para el componente Counter.
3. Cargar automáticamente ese paquete JS al cargar la página y «activar» (hydrate) el componente para que sea interactivo.

Astro también ofrece directivas de carga más precisas, como client:idle (cargar cuando el navegador esté inactivo) y client:visible (cargar cuando el componente entre en el viewport), llevando la optimización del rendimiento aún más lejos.

4. Independencia de frameworks

Otro gran atractivo de Astro es su apertura a los frameworks de interfaz. En un mismo proyecto de Astro puedes usar al mismo tiempo componentes de distintos frameworks como React, Vue, Svelte, SolidJS y Lit. Esto proporciona a los equipos una enorme flexibilidad para colaborar y elegir tecnologías.

Conclusión

Astro no pretende sustituir a React o Vue, sino ofrecer una solución mejor para escenarios concretos. Si tu proyecto es un sitio centrado en el contenido y con requisitos muy exigentes de rendimiento y SEO —por ejemplo, este mismo blog está creado con Astro—, Astro es sin duda una opción excelente que merece explorarse en profundidad. Combina a la perfección las ventajas de rendimiento de los sitios estáticos con la experiencia de desarrollo de los frameworks modernos.

En diciembre de 2022, el equipo de Svelte anunció oficialmente el lanzamiento de SvelteKit 1.0. Fue un hito tanto para la comunidad de Svelte como para todo el ámbito del frontend. SvelteKit ya no es simplemente «el Next.js o Nuxt.js de Svelte»: incorpora una filosofía de diseño propia y distintiva, y pretende ofrecer una forma más sencilla, flexible y eficiente de crear aplicaciones Web.

¿Qué es SvelteKit?

Si conoces Svelte, probablemente sepas que Svelte en sí es un framework de componentes. Mediante un compilador radical, transforma tus archivos .svelte en código JavaScript imperativo y eficiente durante la compilación, logrando un rendimiento extraordinario y una sobrecarga en tiempo de ejecución extremadamente pequeña.

SvelteKit, por su parte, es un framework de aplicaciones construido sobre Svelte. Se ocupa de todo lo necesario para crear una aplicación completa: enrutamiento, renderización del lado del servidor (SSR), carga de datos, adaptadores de despliegue y mucho más, para que puedas centrarte en desarrollar la lógica de negocio.

Resumen de sus características principales

1. Enrutamiento basado en el sistema de archivos

Al igual que Next.js, SvelteKit genera automáticamente las rutas a partir de la estructura de tu sistema de archivos. La estructura de archivos del directorio src/routes se corresponde directamente con las URLs de la aplicación.

• src/routes/+page.svelte -> /
• src/routes/about/+page.svelte -> /about
• src/routes/blog/[slug]/+page.svelte -> /blog/some-post

Este enfoque de convención sobre configuración simplifica enormemente la gestión de rutas.

2. Modos de renderización flexibles

SvelteKit permite controlar con precisión el modo de renderización a nivel de página. La renderización del lado del servidor (SSR), la generación de sitios estáticos (SSG) o una combinación de ambas se pueden implementar en la misma aplicación. Incluso puedes desactivar SSR para una sola página y convertirla en una aplicación de página única (SPA) puramente del lado del cliente.

3. La función load universal

SvelteKit unifica el modelo de carga de datos. Junto a cada página o diseño, puedes crear un archivo +page.js o +page.server.js y exportar una función load.

• En +page.js, la función load se ejecuta tanto en el servidor como en el cliente.
• En +page.server.js, la función load se ejecuta únicamente en el servidor, por lo que puedes acceder de forma segura a una base de datos o API privada.

Los datos devueltos por la función load se pasan automáticamente al componente +page.svelte correspondiente.

// src/routes/blog/[slug]/+page.server.js
import * as db from '$lib/server/database';

export async function load({ params }) {
  const post = await db.getPost(params.slug);
  return { post };
}

4. Adaptadores

«Escribe una vez, despliega en cualquier lugar» es una de las promesas fundamentales de SvelteKit. Mediante los adaptadores, SvelteKit puede empaquetar tu aplicación en el formato adecuado para cualquier plataforma de destino.

• @sveltejs/adapter-node: Para desplegar en un servidor Node.js tradicional.
• @sveltejs/adapter-vercel: Adapta la aplicación a la plataforma Vercel.
• @sveltejs/adapter-static: Prerenderiza toda la aplicación como archivos estáticos, adecuados para cualquier alojamiento estático.
• También existen más adaptadores oficiales y de la comunidad para plataformas como Netlify y Cloudflare Workers.

Conclusión

El lanzamiento de SvelteKit 1.0 marcó la madurez del ecosistema Svelte. Combina el rendimiento extremo del compilador de Svelte con un framework de aplicaciones cuidadosamente diseñado, y ofrece a los desarrolladores una experiencia potente y agradable. Si buscas un framework versátil capaz de crear desde páginas estáticas sencillas hasta aplicaciones dinámicas complejas, sin duda merece la pena probar SvelteKit.

«¿Cómo se puede gestionar el estado con elegancia?» Esta es una cuestión fundamental que todo desarrollador de React debe afrontar a medida que crece un proyecto. Desde el estado sencillo dentro de un componente hasta el estado global complejo compartido entre componentes, la comunidad de React ha explorado numerosas soluciones. Su evolución también refleja una comprensión cada vez más profunda del desarrollo basado en componentes.

Primera etapa: una época sencilla — useState y Props Drilling

Al principio solo teníamos useState (o this.state en los componentes de clase). Cuando varios componentes necesitaban compartir un estado, la recomendación oficial de React era «elevar el estado» (Lifting State Up). El estado se trasladaba al ancestro común más cercano de esos componentes y después se transmitía, junto con su función de actualización, mediante props.

Cuando la jerarquía de componentes se hacía profunda, este patrón provocaba Props Drilling: algunos componentes intermedios recibían props únicamente para pasarlas a descendientes más profundos, sin utilizarlas ellos mismos. Esto aumentaba el acoplamiento entre componentes y dificultaba la refactorización y el mantenimiento.

Segunda etapa: la respuesta oficial — Context API

Para resolver el props drilling, React proporcionó oficialmente la Context API. Esta permite crear un «contexto», proporcionar (Provide) un valor en la parte superior del árbol de componentes y consumirlo (Consume) directamente desde un componente descendiente a cualquier profundidad, sin transmitirlo manualmente nivel por nivel.

// 1. 创建 Context
const ThemeContext = React.createContext('light');

// 2. 在顶层提供值
<ThemeContext.Provider value="dark">
  <App />
</ThemeContext.Provider>

// 3. 在子组件中消费
const theme = useContext(ThemeContext); // 'dark'

Sin embargo, la Context API también tiene una «trampa»: el rendimiento. Cada vez que cambia el Provider y su value, todos los componentes que consumen ese Context vuelven a renderizarse, incluso si solo les interesa una pequeña parte del objeto value. Por ello, la Context API no resulta adecuada para gestionar estados globales complejos que cambian con frecuencia.

Tercera etapa: la era de la unificación — Redux

Antes de que la Context API madurara, Redux irrumpió en escena y se convirtió rápidamente en el estándar de facto para gestionar el estado de aplicaciones grandes y complejas. Inspirándose en la arquitectura Flux y en la programación funcional, aportó:

• Una única fuente de verdad (Single Source of Truth): El state de toda la aplicación se almacena en un único store.
• El State es de solo lectura: La única forma de cambiar el state consiste en hacer dispatch de una action.
• Las modificaciones se realizan con funciones puras: Un reducer recibe el state anterior y una action, y devuelve el nuevo state.

Gracias a su previsibilidad, sus potentes herramientas de depuración (viaje en el tiempo) y su abundante ecosistema de middleware, Redux resolvió los problemas de gestión de estado en aplicaciones grandes. Pero su defecto era igualmente evidente: una gran cantidad de código repetitivo (Boilerplate). Para implementar una función sencilla, los desarrolladores tenían que escribir Actions, Reducers y Dispatchers, con una carga mental considerable.

Cuarta etapa: el renacimiento — soluciones ligeras y Hooks-First

Con la popularización de React Hooks y la reflexión sobre la complejidad de Redux, la comunidad comenzó a crear una nueva generación de bibliotecas de gestión de estado más ligeras. Todas compartían APIs concisas, modelos mentales sencillos y un uso completo de las capacidades de Hooks.

Zustand es un ejemplo destacado. Proporciona una función create extremadamente sencilla para crear un store y, además:

• No requiere Provider: El Store existe fuera del árbol de componentes de React y se puede importar desde cualquier lugar.
• API mínima: Se accede al estado y se actualiza mediante un único Hook.
• Suscripciones selectivas y mejor rendimiento: Cada componente puede suscribirse únicamente a la parte del state que necesita, evitando el problema de rendimiento de la Context API.

const useStore = create(set => ({
  count: 0,
  inc: () => set(state => ({ count: state.count + 1 })),
}));

function Counter() {
  // 只订阅 count 的变化
  const count = useStore(state => state.count);
  return <h1>{count}</h1>;
}

Conclusión: no hay una solución universal, elige según tus necesidades

La evolución de la gestión de estado en React nos enseña que no existe una «mejor solución» válida para siempre, sino la solución más adecuada para cada situación.

• useState: Siempre es la primera opción para el estado local de un componente.
• Context API: Adecuada para datos globales que no cambian con frecuencia, como el tema o la información de autenticación del usuario.
• Zustand / Jotai: Para la mayoría de las aplicaciones que necesitan estado global del lado del cliente, ofrecen un equilibrio excelente entre rendimiento y experiencia de desarrollo.
• Redux (Redux Toolkit): Sigue siendo una opción fiable para aplicaciones enormes que requieren normas estrictas de flujo de datos, middleware complejo y potentes funciones de depuración.

Webpack es un empaquetador de módulos extremadamente potente y configurable que durante años ha sido la base de los proyectos frontend. Sin embargo, a medida que los proyectos crecen, su idea central basada en el empaquetado también genera cuellos de botella de rendimiento:

• Arranque en frío lento: Cada vez que se inicia el servidor de desarrollo (dev-server), Webpack debe recorrer todo el grafo de dependencias y empaquetar todos los módulos en memoria. En proyectos grandes, este proceso puede tardar varios minutos.
• Actualizaciones en caliente (HMR) lentas: Cuando modificas un archivo, Webpack debe volver a calcular y sustituir los módulos relacionados. Aunque esto es más rápido que actualizar toda la página, en proyectos grandes la demora puede alcanzar varios segundos o incluso más de diez, interrumpiendo el flujo de desarrollo.

2. ¿Cómo resuelve Vite estos problemas?

Vite, cuyo nombre significa «rápido» en francés, toma otro camino. Aprovecha el soporte de los navegadores modernos para módulos ES nativos (ESM) y divide el proceso de compilación en dos partes:

• Durante el desarrollo: Vite inicia un servidor sin empaquetar previamente todos los módulos. En su lugar, intercepta las peticiones de módulos del navegador y transforma y sirve el código fuente bajo demanda. Por ejemplo, el navegador solicita main.js y Vite lo entrega; main.js importa Button.vue, el navegador vuelve a enviar una petición y Vite entrega el Button.vue transformado. Así, el servidor de desarrollo arranca casi al instante.
• En producción: Vite utiliza Rollup, otro empaquetador eficiente, para generar recursos estáticos muy optimizados.

Este modelo transforma por completo la experiencia de desarrollo, con un arranque fulminante y actualizaciones en caliente medidas en milisegundos.

3. Pasos prácticos para la migración

Migrar un proyecto existente de Webpack a Vite suele implicar los siguientes pasos:

a. Instalar dependencias y crear el archivo de configuración

Primero, instala Vite:

pnpm add -D vite @vitejs/plugin-react # 或 @vitejs/plugin-vue

Después, crea vite.config.js en la raíz del proyecto:

import react from '@vitejs/plugin-react'
import { defineConfig } from 'vite'

export default defineConfig({
  plugins: [react()],
})

b. Mover index.html

Webpack suele colocar index.html en el directorio public e inyecta automáticamente el JS empaquetado. Vite considera index.html como el punto de entrada de la aplicación. Debes moverlo a la raíz del proyecto y añadir manualmente la referencia al script:

<body>
  <div id="root"></div>
  <script type="module" src="/src/main.jsx"></script>
</body>

c. Sustituir los plugins de Webpack

Debes encontrar plugins de Vite equivalentes a los Loaders y Plugins de Webpack. El ecosistema de la comunidad es muy amplio y existen soluciones para la mayoría de las necesidades.

d. Gestionar las variables de entorno

En Webpack estamos acostumbrados a utilizar process.env.NODE_ENV. En Vite, las variables de entorno se consultan mediante import.meta.env, por ejemplo import.meta.env.VITE_API_URL.

e. Configurar alias de rutas

Configurar alias de rutas en vite.config.js es muy sencillo:

import path from 'node:path'
// vite.config.js
import { defineConfig } from 'vite'

export default defineConfig({
  // ...
  resolve: {
    alias: {
      '@': path.resolve(__dirname, './src'),
    },
  },
})

4. Resultados tras la migración

Después de migrar a Vite, la impresión más inmediata es la velocidad.

• El servidor de desarrollo pasó de tardar 50 segundos a 2 segundos en arrancar.
• Las actualizaciones en caliente pasaron de una media de 3–5 segundos a unas decenas de milisegundos casi imperceptibles.
• El archivo de configuración (vite.config.js) quedó mucho más sencillo que webpack.config.js.

Conclusión

Aunque durante la migración quizá haya que resolver algunos problemas de configuración propios del proyecto, pasar de Webpack a Vite mejora enormemente la experiencia de desarrollo. Si todavía soportas un proceso de compilación lento, este es el mejor momento para adoptar Vite.

Las soluciones CSS-in-JS, como styled-components y Emotion, transformaron la gestión de estilos en el desarrollo basado en componentes al permitir escribir CSS dentro de archivos JavaScript o TypeScript. Aportan numerosas ventajas:

• Ámbito de componente: Los estilos quedan asociados al componente de forma predeterminada, lo que resuelve los conflictos globales de nombres CSS.
• Estilos dinámicos: Se pueden crear fácilmente estilos dinámicos a partir de las props o el state del componente.
• Código conjunto: Los estilos y la lógica del componente viven en el mismo archivo, lo que facilita su mantenimiento y organización.

Sin embargo, estas comodidades no son gratuitas. El núcleo de las bibliotecas CSS-in-JS tradicionales es el runtime. Cuando un componente se monta en el navegador, el runtime JavaScript de la biblioteca CSS-in-JS:

1. Analiza el CSS de los template strings o los objetos.
2. Genera nombres de clase únicos.
3. Inyecta dinámicamente los estilos en el <head> del documento, dentro de etiquetas <style>.

Este proceso aumenta el tamaño del paquete JavaScript y añade cierto coste computacional durante el arranque y el renderizado de la aplicación, lo que afecta al rendimiento.

2. La salida del “runtime cero”

Para resolver el problema del rendimiento en tiempo de ejecución, la comunidad propuso un enfoque nuevo: CSS-in-JS sin runtime (Zero-Runtime).

La idea central es conservar la experiencia de desarrollo de CSS-in-JS, pero completar todo el trabajo durante la compilación (build time). Una herramienta de compilación, normalmente un plugin de Babel o Vite, analiza el código, encuentra todos los usos de CSS-in-JS y entonces:

1. Extrae el texto CSS.
2. Genera archivos .css estáticos.
3. Sustituye el código CSS-in-JS original por nombres de clase únicos generados.

Como resultado, el paquete JavaScript entregado al navegador no contiene ninguna biblioteca CSS-in-JS en tiempo de ejecución, y el resultado equivale a archivos CSS estáticos escritos a mano y altamente optimizados.

3. Principales soluciones sin runtime

a. Linaria

Linaria es una de las pioneras del CSS-in-JS sin runtime. Permite utilizar la conocida sintaxis de template literals etiquetados con styled.

// YourComponent.js
import { styled } from '@linaria/react';

const Title = styled.h1`
  font-size: 2rem;
  color: tomato;
`;

// 构建时，这会被转换为：
// <h1 class="Title_a1b2c3d">...</h1>
//
// 并在一个静态 .css 文件中生成：
// .Title_a1b2c3d {
//   font-size: 2rem;
//   color: tomato;
// }

b. vanilla-extract

Desarrollado por el equipo de SEEK, vanilla-extract va un paso más allá y utiliza TypeScript para crear estilos completamente seguros en cuanto a tipos. Todas las definiciones de estilo son variables exportadas desde archivos .css.ts, con una potente inferencia de tipos y autocompletado.

// styles.css.ts
import { style } from '@vanilla-extract/css';

export const title = style({
  fontSize: '2rem',
  color: 'tomato',
});

c. Panda CSS

Panda CSS es un competidor más reciente. Inspirado en Tailwind CSS, ofrece una experiencia de desarrollo basada en “Style Props” y, al mismo tiempo, garantiza una salida sin runtime.

import { css } from '../styled-system/css';

function MyComponent() {
  return <div className={css({ fontSize: '2rem', color: 'tomato' })} />;
}

4. Ventajas y compromisos

Ventajas:

• Rendimiento excepcional: El resultado final es CSS estático, sin coste de un runtime JavaScript.
• Paquetes más pequeños: No es necesario cargar una biblioteca CSS-in-JS en el cliente.
• Potente experiencia de desarrollo: Se mantienen las ventajas del ámbito por componente, la seguridad de tipos de TypeScript y la colocación conjunta del código.

Compromisos:

• Dependencia durante la compilación: Debe integrarse en el proceso de build, por lo que la configuración resulta algo más compleja.
• Dinamismo limitado: No puede generar estilos completamente nuevos a partir de valores que solo existen en tiempo de ejecución, como datos procedentes de una API. No obstante, técnicas como las variables CSS pueden cubrir la mayoría de los casos dinámicos.

Conclusión

El CSS-in-JS sin runtime es una corrección del rumbo del paradigma CSS-in-JS tradicional. Separa de forma inteligente la “experiencia durante el desarrollo” del “rendimiento en tiempo de ejecución”, para que ya no tengamos que elegir entre ambos. Para las aplicaciones web modernas que buscan un rendimiento extremo y paquetes más pequeños, ofrece una solución casi perfecta.

Gracias al proceso anual de publicación del comité TC39, el lenguaje JavaScript sigue evolucionando cada año. ECMAScript 2022 (ES2022) incorpora varias funciones nuevas destinadas a mejorar la experiencia de desarrollo y la legibilidad del código. Veamos algunas de las más destacadas.

1. await en el nivel superior

Esta es una de las funciones más esperadas de ES2022. Antes, la palabra clave await solo podía utilizarse dentro de una función async. Esto resultaba muy incómodo al gestionar operaciones asíncronas en el nivel superior de un módulo, y normalmente había que envolver el código asíncrono en una IIFE (expresión de función invocada inmediatamente).

Antes 👎:

// data.js
import { fetchData } from './api.js';

let data;
(async () => {
  data = await fetchData();
  // ... 只能在这里使用 data
})();

export { data }; // 导出时 data 还是 undefined

Ahora (ES2022) 👍:

// data.js
import { fetchData } from './api.js';

const data = await fetchData();

export { data }; // 模块会等待 await 完成后再被其他模块评估

Top-level await simplifica enormemente situaciones como la carga dinámica de módulos o la inicialización de dependencias, y hace que el código asíncrono resulte más intuitivo.

2. El método de indexación .at() para arrays y cadenas

En JavaScript, para obtener el último elemento de un array normalmente hay que escribir arr[arr.length - 1], una expresión larga y propensa a errores. ES2022 incorpora el método .at(), que unifica el uso de índices hacia delante y hacia atrás.

El método .at() recibe un entero. Si es positivo, devuelve el elemento del índice correspondiente; si es negativo, cuenta desde el final.

Antes 👎:

const arr = [1, 2, 3, 4, 5];
const lastElement = arr[arr.length - 1]; // 5
const secondToLast = arr[arr.length - 2]; // 4

Ahora (ES2022) 👍:

const arr = [1, 2, 3, 4, 5];
const lastElement = arr.at(-1); // 5
const secondToLast = arr.at(-2); // 4

// 同样适用于字符串
const str = 'hello';
console.log(str.at(-1)); // 'o'

3. Object.hasOwn(obj, prop)

Para comprobar si un objeto posee una propiedad propia, en lugar de una heredada, solemos usar Object.prototype.hasOwnProperty.call(obj, prop). Esta forma es muy engorrosa y puede fallar en algunos casos, como con objetos creados mediante Object.create(null).

Object.hasOwn() ofrece un método estático más corto y fiable.

Antes 👎:

const obj = { a: 1 };
console.log(Object.prototype.hasOwnProperty.call(obj, 'a')); // true
console.log(Object.prototype.hasOwnProperty.call(obj, 'toString')); // false

Ahora (ES2022) 👍:

const obj = { a: 1 };
console.log(Object.hasOwn(obj, 'a')); // true
console.log(Object.hasOwn(obj, 'toString')); // false

4. Otras funciones destacables

• Error Cause: El constructor Error ahora puede recibir un segundo argumento para indicar la “causa” del error, lo que facilita la creación de cadenas de errores más claras.

  try {
    // ...
  } catch (err) {
    throw new Error('New error message', { cause: err });
  }
  

• Índices de coincidencia de RegExp (bandera /d): Al usar la bandera /d, el resultado de una expresión regular también proporciona los índices inicial y final de cada grupo de captura.

Conclusión

Aunque las novedades de ES2022 no suponen una revolución, refinan JavaScript en los detalles, resuelven muchos problemas que los desarrolladores arrastraban desde hacía tiempo y hacen que el código sea más conciso y robusto.

Redux es, sin duda, la biblioteca de gestión de estado más conocida y potente del ecosistema React. Funciones como su flujo de datos unidireccional y la depuración con viaje en el tiempo la convierten en una opción fiable para aplicaciones grandes y complejas. Sin embargo, en muchos proyectos pequeños y medianos, el «código repetitivo» (Boilerplate) de Redux suele causar dolores de cabeza:

• Actions & Action Creators: Definir numerosos tipos de action y funciones creadoras.
• Reducers: Escribir enormes sentencias switch para gestionar distintas actions.
• Dispatch & Selectors: Hacer dispatch de actions mediante dispatch y suscribirse a cambios de estado con useSelector dentro de los componentes.
• Context Provider: Envolver la raíz de la aplicación en un <Provider>.

Todo esto hace que añadir incluso un estado sencillo exija modificar varios archivos y convierte el proceso en algo engorroso.

2. Zustand: un soplo de aire fresco

Zustand («estado» en alemán) es una biblioteca ligera de gestión de estado desarrollada por el equipo de Poimandres, creadores de react-three-fiber. Su filosofía de diseño es el minimalismo y la no intrusión.

Características principales:

• Muy poco código: Para implementar una función, Zustand suele requerir solo una fracción del código necesario con Redux.
• Basado en Hooks: Todo gira en torno a un Hook personalizado, de acuerdo con las prácticas del desarrollo moderno con React.
• No requiere Context Provider: No necesitas envolver la parte superior de la aplicación en ningún Provider. El Store es independiente del árbol de componentes y se puede importar y utilizar desde cualquier lugar.
• Fácil de aprender: La API es extremadamente sencilla y su uso principal se aprende en pocos minutos.

3. Uso principal

El uso de Zustand se divide en dos pasos: crear el Store y utilizarlo en un componente.

a. Crear el Store

Puedes definir el store en cualquier archivo .js o .ts.

// src/store.js
import { create } from 'zustand';

const useBearStore = create((set) => ({
  bears: 0,
  increasePopulation: () => set((state) => ({ bears: state.bears + 1 })),
  removeAllBears: () => set({ bears: 0 }),
}));

export default useBearStore;

La función create recibe un callback cuyo argumento es la función set, similar al setState de React. Aquí defines el estado y los métodos que lo actualizan.

b. Utilizarlo en un componente

Úsalo en cualquier componente como si fuera un Hook normal.

// src/components/BearCounter.jsx
import useBearStore from '../store';

function BearCounter() {
  const bears = useBearStore((state) => state.bears);
  return <h1>{bears} around here ...</h1>;
}

Observa que nos suscribimos mediante la función selectora (state) => state.bears al estado bears. Esto es importante porque garantiza que el componente solo vuelva a renderizarse cuando cambie bears, evitando costes de rendimiento innecesarios.

// src/components/Controls.jsx
import useBearStore from '../store';

function Controls() {
  const increasePopulation = useBearStore((state) => state.increasePopulation);
  return <button onClick={increasePopulation}>one up</button>;
}

Obtener una action es igual de sencillo.

4. Actions asíncronas

Zustand también gestiona las operaciones asíncronas de forma muy natural. No necesitas ningún middleware como redux-thunk o redux-saga.

const useAsyncStore = create((set) => ({
  data: null,
  fetchData: async (url) => {
    const response = await fetch(url);
    const data = await response.json();
    set({ data });
  },
}));

Conclusión

Zustand no pretende sustituir completamente a Redux. Redux conserva sus ventajas en cuanto a normas estrictas, trazabilidad y un enorme ecosistema.

Sin embargo, para la gran mayoría de las aplicaciones React, Zustand ofrece una opción más sencilla y rápida, con menor carga mental. Si estás cansado de las formalidades de Redux o tu próximo proyecto necesita un gestor de estado ágil y flexible, Zustand es sin duda una excelente alternativa que merece la pena probar.

Un Monorepo, o repositorio de código único, es una estrategia que almacena varios proyectos o paquetes independientes en un mismo repositorio. Frente al modelo Polyrepo, donde cada proyecto tiene su propio repositorio, un Monorepo ofrece varias ventajas destacadas:

• Código compartido: Compartir componentes, funciones auxiliares o definiciones de tipos entre distintos proyectos resulta muy sencillo.
• Commits atómicos: Si el cambio de una función afecta a varios paquetes, puede completarse en un solo commit, lo que garantiza la coherencia de las versiones.
• Gestión de dependencias simplificada: Todos los proyectos comparten un mismo node_modules, o lo optimizan mediante workspaces de pnpm/yarn, reduciendo conflictos de dependencias y diferencias entre versiones.

Sin embargo, cuando el repositorio crece, el Monorepo también presenta un desafío: el rendimiento de compilación.

2. Los puntos débiles de un Monorepo

Imagina que tu repositorio contiene docs, webapp y una biblioteca compartida de componentes ui. Si solo corriges un error tipográfico en docs, lo último que quieres es que todos los proyectos del repositorio, incluidos webapp y ui, vuelvan a compilarse y probarse.

Las herramientas tradicionales de gestión de Monorepos, como Lerna, presentan limitaciones en la coordinación de tareas y la caché de compilación, lo que provoca:

• Trabajo repetido: Cada ejecución de CI/CD compila y prueba todo desde cero, aunque la mayor parte del código no haya cambiado.
• Tiempos de compilación largos: No se pueden aprovechar eficazmente varios núcleos de CPU para ejecutar tareas en paralelo.
• Scripts complejos: Es necesario escribir scripts complicados en package.json para controlar manualmente el orden de ejecución de las tareas.

3. Turborepo: creado para la velocidad

Turborepo es un sistema de compilación de alto rendimiento diseñado para Monorepos JavaScript/TypeScript y adquirido posteriormente por Vercel. Resuelve los problemas anteriores mediante dos tecnologías fundamentales: las compilaciones incrementales y la caché remota.

a. Compilaciones incrementales y pipelines de tareas

Turborepo permite definir las dependencias entre tareas en un archivo turbo.json situado en la raíz.

// turbo.json
{
  "$schema": "https://turbo.build/schema.json",
  "pipeline": {
    "build": {
      "dependsOn": ["^build"],
      "outputs": ["dist/**", ".next/**"]
    },
    "test": {
      "dependsOn": ["build"],
      "outputs": []
    },
    "lint": {
      "outputs": []
    },
    "dev": {
      "cache": false
    }
  }
}

• dependsOn: ["^build"]: El símbolo ^ indica que la tarea build de un paquete depende de las tareas build de todos los paquetes de los que depende. Turborepo ejecuta las tareas en el orden paralelo más eficiente de acuerdo con este grafo.
• outputs: Indica a Turborepo qué archivos de salida produce la tarea.

Cuando ejecutas pnpm turbo build, Turborepo calcula qué archivos han cambiado y solo vuelve a compilar los paquetes afectados. Si el código fuente y las dependencias de un paquete no han cambiado, Turborepo utiliza directamente el resultado de la compilación anterior, un proceso instantáneo.

b. Caché remota

Esta es la «función estrella» de Turborepo. No solo almacena en caché los resultados de compilación en tu equipo local, sino que también puede subirlos a un servidor remoto compartido, como Vercel o tu propio bucket de S3.

Esto significa que:

• Tu compañero puede descargar la caché después de obtener el código más reciente si tú ya has compilado la parte que necesita, sin tener que volver a compilarla localmente.
• El servidor de CI/CD también puede conectarse a esta caché remota. Después de que un PR se compile y almacene en caché dentro de CI, otros desarrolladores y tareas posteriores de CI podrán aprovechar el resultado de inmediato.

Esto puede reducir el tiempo de compilación de todo el equipo de decenas de minutos a unos pocos minutos o incluso decenas de segundos.

Conclusión

Turborepo no inventó el Monorepo, pero al introducir sistemas avanzados de caché y planificación de tareas mejora enormemente la experiencia de desarrollo en un Monorepo y resuelve su principal cuello de botella de rendimiento. Si utilizas o piensas adoptar una arquitectura Monorepo, Turborepo es sin duda una herramienta potente que puede ahorrar muchísimo tiempo a ti y a tu equipo.

Desde que React popularizó el DOM virtual (Virtual DOM), el VDOM parece haberse convertido en un elemento estándar de los frameworks frontend modernos. Al mantener en memoria una representación virtual de la interfaz y utilizar un algoritmo de diff para calcular el mínimo de actualizaciones del DOM, mejora tanto la experiencia de desarrollo como el rendimiento en la mayoría de los casos.

Pero el VDOM no es gratuito. Ocupa memoria y el proceso de diff también tiene un coste computacional. De ahí surge una pregunta: ¿podemos evitar el VDOM y aplicar los cambios de estado directamente y con precisión al DOM, sin renunciar a una experiencia de desarrollo declarativa similar a React?

SolidJS ofrece su respuesta.

2. El núcleo de SolidJS: reactividad granular (Fine-Grained Reactivity)

SolidJS es un framework JavaScript declarativo y reactivo. Aunque utiliza JSX y se parece mucho a React, sus principios internos son completamente diferentes.

El compilador de SolidJS transforma el código JSX en operaciones nativas del DOM óptimas. No utiliza un VDOM, sino que crea un grafo de dependencias formado por “señales” (Signals) reactivas. Cuando cambia el valor de una señal, solo vuelven a ejecutarse los “efectos” (Effects) o cálculos (Memos) suscritos a ella.

Un modelo mental revolucionario: ¡los componentes solo se ejecutan una vez!

En React, cuando cambian el state o las props, toda la función del componente vuelve a ejecutarse. En SolidJS, en cambio, la función del componente solo se ejecuta una vez de principio a fin.

import { createSignal } from 'solid-js';

function Counter() {
  console.log('Component function runs!'); // 这句话只会在组件挂载时打印一次

  const [count, setCount] = createSignal(0);

  const increment = () => setCount(count() + 1);

  return (
    <button type="button" onClick={increment}>
      Count: {count()}
    </button>
  );
}

Al pulsar el botón, solo se actualizan el lector de la señal count() y el nodo de texto del DOM que depende de ella. La propia función Counter no vuelve a ejecutarse. Esta actualización “quirúrgica” es la fuente del rendimiento excepcional de SolidJS.

3. APIs principales

El sistema reactivo de SolidJS se compone principalmente de tres primitivas fundamentales:

• createSignal(initialValue): Crea una señal reactiva y devuelve un getter y un setter: [count, setCount].
• createEffect(() => {}): Crea un “efecto” que rastrea automáticamente todas las señales leídas en su interior y vuelve a ejecutarse cuando cambia cualquiera de ellas. Es ideal para realizar efectos secundarios, como manipular el DOM manualmente.
• createMemo(() => {}): Crea un valor calculado derivado y almacenado en caché. Solo vuelve a calcularse cuando cambia alguna de las señales de las que depende.

import { createSignal, createEffect } from 'solid-js';

function App() {
  const [firstName, setFirstName] = createSignal('John');
  const [lastName, setLastName] = createSignal('Smith');

  // createEffect 会在 firstName 或 lastName 变化时自动运行
  createEffect(() => {
    console.log(`Full name: ${firstName()} ${lastName()}`);
  });

  // ...
}

4. ¿Por qué elegir SolidJS?

• Rendimiento excepcional: SolidJS suele ocupar los primeros puestos en distintas pruebas de rendimiento independientes, con resultados muy cercanos al código JavaScript nativo.
• Tamaño de paquete extremadamente pequeño: Como no tiene un runtime de VDOM, su paquete principal es muy pequeño.
• Experiencia de desarrollo familiar: Si conoces React Hooks, puedes aprender SolidJS con rapidez. La combinación de JSX y primitivas reactivas es potente e intuitiva.
• Reactividad real: Su modelo se acerca más a MobX o a la Composition API de Vue, pero el compilador permite conseguirlo sin coste en tiempo de ejecución.

Conclusión

SolidJS representa una dirección importante en la evolución de los frameworks frontend: hacer más trabajo durante la compilación mediante el compilador para obtener menos código en tiempo de ejecución y un mayor rendimiento. Demuestra que es posible liberarse de las restricciones del DOM virtual sin sacrificar una experiencia de desarrollo declarativa. Para las aplicaciones que buscan el máximo rendimiento, SolidJS ofrece una opción muy atractiva.

La Fetch API ha sustituido al anticuado XMLHttpRequest como método estándar para realizar peticiones HTTP en el navegador. Está basada en Promises y ofrece una forma más sencilla y potente de hacer peticiones.

Sin embargo, la Fetch API no proporciona de forma predeterminada un mecanismo directo para cancelar peticiones. Esta función es muy importante en muchas situaciones:

• Optimización del rendimiento: Cuando el usuario cambia rápidamente de página o introduce términos de búsqueda, cancelar las peticiones antiguas que ya no son necesarias ahorra ancho de banda y recursos del servidor.
• Evitar condiciones de carrera: En un escenario de búsqueda mientras se escribe, una petición antigua puede responder más tarde que una nueva y hacer que la interfaz muestre datos obsoletos.
• Prevenir fugas de memoria: Si un componente se desmonta antes de que termine una petición iniciada durante su ciclo de vida, intentar actualizar un componente que ya no existe puede provocar errores o fugas de memoria.

2. AbortController: una señal de cancelación de propósito general

AbortController es una API Web de propósito general que proporciona un mecanismo para abortar una o varias peticiones Web. Es independiente de la Fetch API, pero funciona perfectamente con Fetch.

La idea central de AbortController es:

1. Crear una instancia de AbortController.
2. Obtener un objeto AbortSignal de esa instancia.
3. Pasar el AbortSignal a una API Web que se pueda abortar, como fetch.
4. Cuando sea necesario cancelar, llamar al método de la instancia de AbortController, abort().

3. Combinar AbortController con Fetch

Veamos mediante un ejemplo cómo usar AbortController para cancelar una petición Fetch.

const controller = new AbortController();
const signal = controller.signal; // 获取信号对象

async function fetchDataWithCancellation(url) {
  try {
    console.log('Fetching data...');
    const response = await fetch(url, { signal }); // 将信号传递给 fetch
    const data = await response.json();
    console.log('Data received:', data);
    return data;
  } catch (error) {
    if (error.name === 'AbortError') {
      console.log('Fetch request was aborted.');
    } else {
      console.error('Fetch error:', error);
    }
  }
}

// 示例用法
const promise = fetchDataWithCancellation('https://jsonplaceholder.typicode.com/posts/1');

// 假设在 500 毫秒后，我们决定取消这个请求
setTimeout(() => {
  controller.abort(); // 调用 abort() 方法取消请求
  console.log('Request aborted by timeout.');
}, 500);

Cuando se llama a controller.abort(), la petición fetch se interrumpe inmediatamente y lanza un AbortError. Debes capturar este error en el bloque catch y comprobar error.name === 'AbortError' para distinguir una cancelación de otros errores de red.

4. Casos de uso reales

a. Búsqueda mientras se escribe (Search-as-you-type)

Cuando el usuario escribe rápidamente en un cuadro de búsqueda, cada entrada puede activar una nueva petición. Podemos cancelar la petición anterior que siga pendiente y conservar únicamente la más reciente.

let currentController = null;

document.getElementById('searchInput').addEventListener('input', (event) => {
  if (currentController) {
    currentController.abort(); // 取消上一个请求
  }
  currentController = new AbortController();
  const signal = currentController.signal;

  const query = event.target.value;
  if (query.length > 2) {
    fetchDataWithCancellation(`/api/search?q=${query}`, signal);
  }
});

b. Cancelar una petición al desmontar un componente

En frameworks como React o Vue, cancelar al desmontar un componente las peticiones pendientes que este inició ayuda a evitar fugas de memoria y actualizaciones innecesarias de la interfaz.

// React 示例
useEffect(() => {
  const controller = new AbortController();
  fetchDataWithCancellation('/api/data', controller.signal);

  return () => {
    controller.abort(); // 组件卸载时取消请求
  };
}, []);

Conclusión

AbortController es una herramienta indispensable en el desarrollo Web moderno. Proporciona un mecanismo nativo de cancelación para la Fetch API y otras operaciones asíncronas, y ayuda a los desarrolladores a crear aplicaciones más robustas, eficientes y agradables de usar. Dominar AbortController es una de las habilidades esenciales para convertirse en un excelente desarrollador frontend.