Angular vs Svelte, lo que cambié al mudarme de framework

Con Angular estuve cómodo mucho tiempo. Me gustaba que todo viniera resuelto de fábrica: inyección de dependencias, un router serio, RxJS para todo lo asíncrono… para un proyecto grande, con varias personas tocando el mismo código, esa estructura tan marcada ayuda. Cada archivo sabe exactamente dónde va y qué forma tiene.

El problema me llegó con los proyectos pequeños, que son la mayoría de los que hago. Montar un Angular para una landing con dos formularios se sentía como llevar un traje de buceo a la piscina del hotel.

La primera vez que probé Svelte

Fue casi por aburrimiento, un fin de semana. Lo primero que noté no fue ninguna característica concreta, sino la cantidad de código que no tenía que escribir. Sin decoradores, sin módulos que registrar, sin ngOnInit para todo. Una variable reactiva era, literalmente, una variable.

Eso al principio me dio desconfianza — llevaba años pensando que “menos código visible” significaba “más magia oculta que un día te muerde”. Pero al mirar el HTML compilado, la magia resultó ser bastante razonable: Svelte no manda un framework entero al navegador, compila tu componente a JavaScript normal que actualiza el DOM donde hace falta y punto.

Lo que sí echo de menos

No todo es más bonito al otro lado. En Angular nunca me preocupé por cómo estructurar servicios compartidos entre componentes — el propio framework te obliga a pensarlo bien desde el principio. En Svelte he tenido que aprender esa disciplina por mi cuenta, y al principio metí bastante estado directamente en componentes que debería haber sacado antes a un store.

También echo de menos el tipado tan agresivo de un proyecto Angular bien configurado. Con TypeScript y Svelte se puede llegar a un nivel parecido, pero hay que currárselo un poco más.

Dónde uso cada uno

Angular lo sigo recomendando para proyectos grandes de equipo, sobre todo si ya hay gente en el equipo que viene de ese mundo. Para todo lo demás — que en mi caso es casi todo — Svelte gana por goleada: menos piezas que mantener, menos JavaScript que el usuario tiene que descargar, y un código que se lee de arriba a abajo sin tener que saltar entre cinco archivos para entender qué hace un componente.