9 skills de frontend que necesitas saber sí o sí en 2026
El frontend se ha movido al servidor, ha dejado de repintarlo todo y por fin tiene herramientas de diseño propias. Esto es lo que hay que saber.
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 realmente. 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. Cada uno lo llama de una forma, pero el mecanismo es el mismo.
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. Con las tres te ahorras la mitad del CSS que escribías para tapar problemas del propio CSS.
4. Core Web Vitals, y sobre todo INP
Core Web Vitals son las tres notas que Google le pone a tu página para saber si se siente rápida. LCP (Largest Contentful Paint) es cuánto tarda en verse lo más grande de la pantalla, normalmente la imagen o el título principal. CLS (Cumulative Layout Shift) es cuánto baila el contenido mientras carga: ese salto que hace que pulses el botón equivocado. E INP (Interaction to Next Paint) es la que más cuesta aprobar.
INP mide cuánto tarda la página en reaccionar cuando tocas algo: pulsas un botón y pasan unos milisegundos hasta que ves que algo ha cambiado. Si tu página tiene demasiado JavaScript haciendo cosas, ese tiempo crece y el usuario nota que va a tirones. Y esto no va solo de posicionar en Google: es la diferencia entre que una web se sienta bien o se sienta regular.
5. Accesibilidad que se pueda usar
Accesibilidad no es poner aria-label en todos lados, es que la página 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. Además, 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 y montar el estado de la animación a mano.
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. Son diez líneas de CSS y la web pasa a sentirse como una app.
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 (Static Site Generation, generación estática) lo genera al construir el sitio y sirve el mismo fichero a todo el mundo. ISR (Incremental Static Regeneration, regeneración estática incremental) lo genera una vez y lo rehace cada cierto tiempo. SSR (Server-Side Rendering, renderizado en el servidor) lo genera en cada petición, con los datos del momento.
PPR (Partial Prerendering, prerenderizado parcial) 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 bien usado
Casi todo el mundo usa TypeScript como un corrector ortográfico: pone el tipo de los parámetros y sigue a lo suyo. Usarlo bien 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, que solo puede ser 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, lo que se llama tests E2E (end-to-end, de punta a punta): abre un navegador real, 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. Con saber qué es cada cosa y cuándo se usa ya vas por delante de la mayoría.