Muy buenas a todos, este es mi primer post así que espero que os sea entretenido y además le sirva a alguien mi experiencia en el desarrollo web.

La verdad es que tener un blog es algo que por un lado siempre he querido pero por otro lado siempre me ha dado pereza. Siempre he pensado que me quedaría sin cosas nuevas para hablar y puede que así sea, no aseguro nuevos posts cada día o fin de semana, ni siquiera cada mes. Esto es algo más personal.

Si estoy escribiendo este post es porque literalmente no puedo seguir aguantándome las cosquillitas que siento cada vez que uso Sveltekit, es una cosa bárbara. Cada vez que me sorprende con una forma nueva de ahorrarme tiempo y esfuerzo gracias a lo jodidamente bien que está diseñado me da años de vida y me devuelve la ilusión por la programación.

Para resumir rápidamente de qué va todo esto: Sveltekit es la hostia. Punto. Es el mejor framework de js con diferencia que yo haya probado hasta la fecha (y los he probado casi todos). Si aún no le has dado un try te lo recomiendo.

¿Por qué Sveltekit es tan bueno?

La verdad, ni yo mismo lo sé. ¿Por qué es tan bueno? ¿Qué he hecho yo realmente para merecer vivir en el mismo espacio temporal que los dioses que han creado Sveltekit y siguen trabajando en él diariamente? Ya te digo yo que nada, ser buena persona supongo. Lo bueno es que aunque tú no seas tan buena persona también puedes disfrutarlo (la magia del Open Source 😉).

Cuando empecé en el mundo del desarrollo web recuerdo que no tenía ni puta idea de nada (y ya estaba trabajando xD). Sí sí, literalmente estaba aún sacándome el grado pero me enchufaron en un trabajo para que desarrollara una API (Spanish things supongo). Así que me metí de lleno a desarrollar la API que me pedían sin saber qué era una API o que diferencia había entre backend y API. Pero bueno, la cosa es que algo espabilado soy y lo pillé bastante rápido, así que armado con las tecnologías que me ordenaron, que por suerte no fue nada rollo php ni niguna pollaviejada así (gracias Cristian ❤️), sino que fue el maravilloso FastAPI, me fui adentrando en este bonito pero caótico mundo.

Comencé con un monorepo que contenía el front en Vue y el backend en FastAPI. Renderizaba el html desde el backend y se lo enviaba al front. Luego decidimos separarlo en dos proyectos separados y ahí aprendí a hacer fetch a mi API y trabajar con el JSON que devolvía. Y ese fue mi mundo durante casi 3 años.

Cada vez que pensaba en comenzar un proyecto o en desarrollar algo que necesitara de un front y una base de datos este era el único martillo que tenía, era 🌈 LA FORMA CORRECTA 🌈 de hacerlo. Hasta que me vicié a vídeos de youtubers americanos que comentaban todos los últimos trendings de la programación.

Claro, ahí comencé a ver fumadas como HTMX, ver que existían otros runtime de js aparte de Node.js y en general, que había un mundo inmenso de oportunidades y muchas formas de hacer las cosas, algunas más tediosas que otras.

Yo ya conocía Next.js y Nuxt pero solo de oídas, alguna vez intente hacer un pequeño proyecto personal pero nunca comprendí su utilidad. Hasta que probé Astro. Wow, Astro está DEMASIADO guapo. Cuando lo conocí, lo investigué, lo probé, lo lamí y lo saboreé fue espectacular, nunca había probado algo así. Un framework agnóstico, que puedes usar para crear páginas estáticas con islas dinámicas, con SSR, instalando tailwind con un solo comando y quinientas mil cosas más… me quedé alucinado. Entonces dije “tengo que probar esto de los metaframeworks” y ahí fue cuando empecé a aprender Next.js.

Metaframeworks o “MetaframeSOS”

La verdad, me está costando saber como escribir estas líneas porque me hace acordar de un pasado al cual me prometí que nunca volvería. Es demasiado traumático. Pero bueno, lo voy a intentar.

Tras varios días aprendiendo de qué cojones va el SSR y leyéndome prácticamente toda la documentación de Next, sentí que el desarrollo web tenía un nuevo sentido. Un sentido mucho más simple y eficaz. O sea, fue la misma sensación que cuando usé Linux. Llevaba toda la vida pensando que Windows era la única opción hasta que descubrí que había otra forma mejor de aprovechar tu sistema operativo.

Con Next vi que un monorepo no es algo malo. Es que ahora lo pienso y qué sentido tiene tener tu propia API separada en otro repositorio si vas a estar haciéndole cambios constantemente. Solo sirve para estar commiteando los cambios de dos repositorios diferentes cada vez que hagas un cambio como si fueras un puto mono. Pero bueno, fuera de eso, con el SSR vi que había una forma mejor de desarrollar una aplicación web que no sea SPA (mi go to desde que empecé).

El problema con Next fue cuando realmente lo probé en mis carnes. Oh Dios mío. Te juro que jamás volvería a ese infierno. Cuando ya pensaba que lo había entendido todo de repente me di cuenta de que no había entendido nada. O eso fue lo que Next.js me hizo sentir. Todo es SSR por defecto y cuando intentaba correr cualquier server action que no fuera desde un formulario todo se iba a la mierda. No entendía el flujo. No sabía que había un flujo. Fue una sucesión de cabezazos en la pared y vídeos de yankees los que me aclararon cómo debía funcionar todo. Todo tenía un orden específico, si querías ejecutar server actions debías hacerlo dentro de componentes renderizados en el servidor y luego importar estos componentes en una página renderizada en el cliente (porque si tiene algún contenido dinámico ya la página tiene que ser rederizada en el cliente, o al menos ese componente y luego importarlo, etc). Una movida vamos. Me pasaba casi más tiempo planeando dónde crear y desde dónde importar cada componente que desarrollando.

Por otro lado Next lo ha hecho muy bien. Es un framework de React y ha captado a la perfección la esencia de sobrecomplicar las cosas innecesariamente que tiene React. Yo tuve que usar React para desarrollar una aplicación web de videollamadas y fue tortuoso. Pasar de Vue a React es como pasar de coger el coche a coger la bicicleta para ir al trabajo. De repente cosas que hacía fácilmente en Vue eran complejas o muy verbose en React. Y NO PODÍA ENTENDER POR QUÉ.

¿Cómo puede ser que desarrollar lo mismo en React sea mucho más costoso y desagradable que desarrollarlo en Vue pero aún así React sea el estándar en la industria? Me pasó con Next como me pasó con React. Son el estándar de la industria y lo son por algo. “TIENEN QUE SER LOS MEJORES”. Pensé. Bueno, no solo pensé, me estaba autoconvenciendo continuamente de ello. Pasé innumerables horas programando en ambos tratando de encontrar eso que hace que la gran mayoría de los desarrolladores o las empresas elijan React o Next como frameworks principales para sus proyectos. Pero la triste realidad es que esta elección no se trata de elegir el framework más estable, o más eficiente o más rápido y cómodo para desarrollar, es simplemente el efecto Java.

En fin, que tras haber desarrollado ya prácticamente la mitad de mi proyecto en Next tuve que parar. Y tuve que parar no porque a cada error de compilación algo muriera dentro de mí. Ni por la amargura que me causaba tener que estar usando React y ver cientos de líneas de código para ALGO MUY SIMPLE (joder es que eran cosas muy simples). No. Tuve que parar por algo que se escapaba a mi control. Next es jodidamente lento y además una puta exigente con los recursos de mi pequeño y adorado Thinkpad x230. ¿Cómo puede ser que alguien haya hecho un framework que es imposible de correr en un ordenador que no tenga mínimo 16 GB de RAM y una CPU de la NASA? Literalmente mi thinkpad, con un Arch Linux y programando en Neovim, SOLO con abrir el proyecto de Next me ponía la CPU al 100% (adjunto imagen xD).

No contentos con eso, cuando tenía 8 GB de RAM me la consumía toda y me petaba el PC. Me compré otra RAM de 8 GB para tener 16 GB de RAM pero al tener siempre la CPU al 100% era imposible programar nada. Y por favor, no quiero hablar de lo que tardaba en mostrar los cambios cada vez que guardaba un archivo y lo que tardaba en compilar el proyecto cada vez que lo corría en modo development (y sí, lo corría con turbo).

Svelte o “Suerte”

Mientras malgastaba mi tiempo usando Vue y React tuve la oportunidad de probar Svelte y… ¿sabéis qué? No me gustó. ¿Qué cojones era eso de poner $ a las variables? ¿Cómo puede ser que declarando una variable en lo alto de un <script> ya sea reactiva? Demasiada magia que no entendía y una abstracción que me hacía temer perder el control en un desarrollo futuro cuando hubiera que debuggear esa magia. Además, para mí usar $ en un lenguaje de programación, a menos que tenga sentido en ciertas ocasiones como para las variables dentro de strings o el $store, siempre me ha parecido como un recurso pobre al que recurrir cuando estás diseñando un lenguaje o un framework, y Svelte no se contentaba con tener declaraciones $: ..., sino que también tenía variables precedidas de una $ y de $$… No era lo mío.

Cuando probé Sveltekit me pasó más de lo mismo. ¿Qué es eso de ponerle un + a los archivos especiales de Svelte? Además como en esa época aún no había probado ningún metaframework rollo Next no entendía tampoco su utilidad, así que lo ignoré.

Pero al final, como dice esa canción de Fabian Show:

Y pasó pasó pasó, lo que tuvo que pasar

(Escucharos la canción, es un temazo Fabian Show - El Federal)

Buscando una solución para el problema de Next a un amigo se le ocurrió usar Sveltekit. Yo estuve un poco rehacio al principio pero le di un try al tutorial interactivo oficial de Svelte y… Joder. Qué bien está hecho ese tutorial. De verdad que pasas de no saber nada de Svelte a conocer fácilmente el 80% o 90%. Obviamente sin dominar todo lo que te enseñan pero yo es que ni miro la documentación. Cuando tengo alguna duda de cómo implementar algo, como me suena que ya lo hice en el tutorial o que el tutorial me enseñó que ese problema que podría tener ya lo tienen ellos solucionado, simplemente vuelvo a esa parte del tutorial y refresco el código. Fin. Fácil. Rápido. Elegante. Bonito. Útil.

Svelte y Sveltekit es todo lo que podría pedir. Prácticamente todas las soluciones que han tomado en el desarrollo de Svelte han sido buenas y bien ejecutadas. Tal vez sea mi fanatismo el que esté hablando (de hecho seguro que lo es, soy muy fanático de las cosas que me gustan) pero es que no veo ninguna razón para usar otro framework que no sea que haya alguna librería en específico que no exista en Svelte.

Sveltekit funciona con Vite, me tarda 1 segundo en comenzar el proyecto en dev, el refresco tras guardar los cambios en un archivo es instantáneo. La CPU, con el navegador abierto, telegram y Sveltekit no me llega al 15% de consumo y la rapidez con la que desarrollo código es algo impresionante.

Al final me ha pasado con Svelte como me pasó con Tailwind y Prisma, me hice una idea de por qué no me gustaría pero luego lo probé y no hay vuelta atrás. Todo lo que me quejé de las $ lo retiro. Absolutamente todo. De hecho las Declarations de Svelte ($: ...) opino que es de lo mejor que tiene Svelte y algo muy big brain. En general la sensación de usar Sveltekit es la de algo hecho por cerebros gigantes para cerebros pequeños como el mío, y eso es justamente lo que quiero. (Si es que Sveltekit tiene hasta para hacer animaciones y transiciones directamente sin necesidad de instalar ninguna librería externa…).

Bueno, resumiendo, que si no este post no se acaba nunca. Si no has probado Sveltekit, hazlo, y hazlo con el tutorial interactivo. Si no vienes de un background de haber usado Vue, React (o 🤮 Angular 🤮) seguramente no lo aprecies tanto, pero quién sí lo tenga, es como si pasaras de Java a Python, una locura vamos.

Aquí me despido. Hasta la próxima maquinotes.