9 skills de frontend que necesitas saber sí o sí en 2026

1. Server Components y streaming

Durante años todo se pintaba en el navegador: el servidor mandaba un HTML vacío y un montón de JavaScript que se encargaba del resto. El precio es una pantalla en blanco mientras se descarga y se ejecuta todo ese código, y una factura que la paga siempre el móvil más lento.

Un componente de servidor se ejecuta antes, donde están los datos, y manda el HTML ya hecho. Su JavaScript no viaja nunca al navegador. Y con streaming no hace falta esperar a que esté todo: la página llega a trozos y se ve la primera parte mientras la segunda se sigue cocinando.

2. Signals y el fin del re-render

En el modelo clásico, cuando un estado cambia el framework vuelve a ejecutar ese componente y todos los que cuelgan de él, y después compara el resultado con lo que había para ver qué ha cambiado de verdad. Funciona, pero trabaja de más y tú acabas poniendo parches para que trabaje menos.

Una signal es un valor que sabe quién lo está leyendo. Cuando cambia avisa solo a esos sitios, y no se vuelve a ejecutar nada más. Solid lo lleva desde el primer día, Angular lo ha adoptado y React ha llegado a lo mismo por otro camino con su compilador. Da igual el nombre: la idea es idéntica.

3. CSS moderno: container queries y :has()

Una media query pregunta cuánto mide la ventana. El problema es que a tu tarjeta la ventana le da igual: lo que necesita saber es cuánto mide el hueco donde la han metido, y ese hueco no es el mismo en la portada que dentro de una barra lateral.

Una container query pregunta justo eso, y el componente deja de depender de dónde lo pongas. Súmale :has(), que por fin permite dar estilo a un padre según lo que lleva dentro, y las capas de cascada para decidir quién pisa a quién. Entre las tres se llevan por delante la mitad del CSS que escribías para pelearte contigo mismo.

4. Core Web Vitals, y sobre todo INP

Core Web Vitals son tres números con los que Google mide si tu página se siente rápida. LCP: cuánto tarda en aparecer lo importante. CLS: cuánto se mueve el contenido mientras carga, que es lo que hace que pulses el botón equivocado. E INP, el que sustituyó al viejo FID y el que más cuesta aprobar.

INP mide lo que tarda la interfaz en responder cuando el usuario toca algo: desde el clic hasta que se ve el cambio en pantalla. Si tu JavaScript bloquea el hilo principal, ahí se nota y no hay caché que lo tape. Y esto no va de SEO: es literalmente la sensación de que la web va bien o va regular.

5. Accesibilidad de verdad

Accesibilidad no es rociar aria-label por encima. Es que se pueda usar sin ratón, que se vea dónde está el foco, que cada campo tenga su etiqueta asociada y que el error se cuente con palabras y no solo con un borde rojo, porque quien no distingue el rojo no lo va a ver.

Se comprueba en dos minutos: recorre tu pantalla entera con el tabulador. Si no llegas a algún sitio, o no sabes en cuál estás, ya tienes trabajo. Y hay un premio de propina: casi todo lo que arreglas por accesibilidad mejora el marcado, y con él lo que entienden Google y los buscadores de IA.

6. View Transitions API

Animar un cambio de pantalla es el punto exacto donde una web se delata frente a una app: el contenido salta de golpe y se nota que estamos en un navegador. Hasta hace nada, arreglarlo pedía una librería, montar el estado a mano y cruzar los dedos.

La View Transitions API lo hace el navegador solo. Le dices que este elemento de la pantalla vieja y aquel de la nueva son el mismo, y él interpola entre los dos. Y funciona entre páginas distintas, no solo dentro de una aplicación de una sola página. Es lo más barato que puedes hacer para que algo parezca caro.

7. Estrategias de render: SSG, ISR, SSR y PPR

Las siglas asustan, pero la pregunta es una sola: ¿cuándo se genera el HTML? SSG lo genera al construir el sitio y sirve el mismo fichero a todo el mundo. ISR lo genera una vez y lo rehace cada cierto tiempo. SSR lo genera en cada petición, con los datos del momento.

PPR es la que hay que entender este año, porque parte la página en dos. Lo que es igual para todos se genera de antemano y sale al instante; el trozo personalizado —tu carrito, tu nombre, tu saldo— se rellena después. Dejas de tener que elegir entre rápido y actualizado para la página entera.

8. TypeScript de verdad

Casi todo el mundo usa TypeScript como un corrector ortográfico: pone el tipo de los parámetros y sigue a lo suyo. Usarlo de verdad es otra cosa: es conseguir que los estados imposibles no se puedan ni escribir.

El ejemplo de siempre es una petición con isLoading, data y error a la vez: ese tipo permite estar cargando y roto al mismo tiempo, algo que no pasa nunca. Una unión discriminada —cargando, o datos, o error con su mensaje— hace que ese caso ni compile. Deriva los tipos de los datos en vez de escribirlos dos veces y el any desaparece solo.

9. Testing de interfaz con Playwright

Probar frontend no es comprobar que una función suma bien. Es comprobar que el usuario puede hacer aquello a lo que ha venido. Testing Library va por ahí: los elementos se buscan como los busca una persona, por su texto y por su rol, nunca por la clase de CSS.

Playwright es el nivel de arriba: abre un navegador de verdad, recorre el camino entero y avisa si algo se ha movido. Pocos y bien elegidos, los flujos que te dan de comer: registro, pago, el formulario principal. Todo lo demás, con tests de componente, que van mil veces más rápido y no se rompen solos.

Resumen

• Servidor primero: lo que no viaja al navegador no cuesta nada.
• Signals: se actualiza solo lo que lee el dato que cambió.
• Container queries en vez de media queries.
• INP es la métrica que te va a suspender.
• El tabulador es la prueba de accesibilidad de dos minutos.
• View Transitions: lo que parece caro, gratis.
• PPR: rápido y actualizado en la misma página.
• Tipos que prohíban los estados imposibles.
• Playwright solo para los flujos que dan de comer.

Ninguna de las nueve se aprende en una tarde, y tampoco hace falta. Pero el frontend de 2026 se parece muy poco al de hace tres años: se ha mudado al servidor, ha dejado de repintarlo todo y por fin tiene herramientas de diseño dentro del propio CSS. Sabiendo qué es cada cosa y cuándo toca cada una, lo demás lo pone la práctica.