Llevaba dos años pensando en este blog
Decir que lo "pensaba" no es del todo exacto; era más bien una obsesión. Ya estaba ahí cuando aún no sabía escribir ni frontend ni backend, ni tampoco código embebido. Por entonces todavía andaba trasteando con electrónica y, de casualidad, di con los vídeos de @ushio en y con su web, y pensé que aquello era genial y que yo también quería uno. Después pasé casi medio año aprendiendo C desde cero, y algo de JS y CSS, y monté un blog estático con Hexo desplegado en Github Pages. Por fin tenía mi propio rinconcito.
Más adelante descubrí el sitio personal de @Innei. Tenía un diseño muy cuidado y estaba repleto de funciones; me bastó con verlo una vez para quererlo, e incluso apoyé económicamente el proyecto. Aunque al final no llegué a usarlo, no me arrepiento de haber gastado ese dinero, porque así pude acceder al código fuente de React. Fue como cuando vi C por primera vez: al fin y al cabo, no es más que código, ¿qué puede tener de extraordinario? Algún día escribiré uno yo mismo.
Eso fue en 2024, y luego llegaron el 24, el 25 y el 26, hasta hoy
Desde entonces, no ha habido forma de parar.
Fuera de control
Al principio solo quería añadir un conmutador de claro/oscuro al tema de Hexo Nlvi de @colmugx. Apañé uno con el JS de Dark Reader: feo, no me convencía. Después aprendí @media en CSS, luego el cambio por JS en la SPA, luego la .dark class de TailwindCSS, luego next-theme en SSR, y al final me una Cookie más un script inline de Head Sync para acabar con el parpadeo del FOUC. Cuatro o cinco enfoques en total.
Pero aquello no era más que la punta del iceberg. Tras descubrir React, pasé de la Edad de Piedra de Hexo y JavaScript puro al enrutador de páginas de Next.js 13; luego me desvié hacia Vue, estudié el enrutamiento de aplicaciones de página única, entendí el mecanismo de respaldo de index.html y volví a crear el proyecto incontables veces. Compré un servidor y trasteé con Docker, Nginx y un sistema de almacenamiento conectado a la red; como 1Panel me parecía feo, programé a mano el panel Canopy, investigué matrices de almacenamiento y escribí RFS. Al configurar certificados SSL, acme.sh fallaba tanto en el entorno chino que acabé escribiendo en Rust un proxy inverso: Vane & Lazyacme. Al principio no eran más que ochocientas líneas de código basura escritas en tres horas una noche, pero unos amigos del chat me animaron a continuar y terminé dedicándole cuatro meses, metiéndole HTTP/3, copia cero, un modelo por capas y un motor de flujos. Después también está Seam, un framework full-stack y otro pozo sin fondo, pero de eso ya hablaré otro día.
Sobreingeniería
Entonces llegó la era de la IA y mi ansiedad volvió a duplicarse.
Lo más irónico es que todo esto tendría que haberse hecho después del blog, documentándolo sobre la marcha. En cambio, al blog , las ideas se fueron acumulando y no había ni un solo sitio donde anotarlas. Por un lado, mi conciencia no dejaba de acusarme: dijiste que ibas a terminar Vane, así que no puedes parar. Por otro, una impotencia que crecía cuanto más me alejaba. Siempre he recordado lo que tenía que hacer; simplemente no era capaz de hacerlo. Pensándolo bien, hace muchísimo que no me siento a escribir nada. Ahora, mirando atrás, todo apunta a lo mismo: sobreingeniería.
En aquel momento, tampoco es que no me diera cuenta de que me estaba desviando. ¿Vane? Al fin y al cabo, algún día tendría que desplegar el blog, así que necesitaría un proxy inverso. ¿Seam? Tarde o temprano tendría que desarrollar tanto el frontend como el backend, así que mejor crear primero mi framework ideal. Cada paso tenía su justificación; todo iba a «servirme más adelante». Pero el problema era que ese «más adelante» nunca llegaría, porque jamás había empezado...
Fracaso
En realidad, crear un blog no requiere ni un proxy inverso ni un framework propio. Sin embargo, por aquel entonces los traté como requisitos previos y los convertí en una justificación que parecía razonable, aunque me impedía avanzar indefinidamente. Pero nunca fueron requisitos. Solo había uno de verdad: sentarme y escribir el primer artículo.
En realidad, no es que nunca hubiera trabajado en el blog. Todo lo contrario: lo intenté tres veces.
Mi primer intento fue todavía en la época del Page Router de Next.js 13. Por entonces apenas entendía qué era una aplicación de página única y no tenía claro ninguno de los conceptos como SSR, SSG o ISR. Pero como otros decían que el SSR era bueno, yo también quería usarlo. Sin embargo, conforme avanzaba, descubrí que en realidad no entendía qué problemas intentaban resolver esas arquitecturas y ya no pude seguir. Después me pasé a una aplicación de página única pura con Vue 2. ¿Por qué elegí Vue? Me da vergüenza admitirlo, pero el nombre me sonaba bien y, como de todos modos era algo nuevo para mí, pensé en probarlo. Tampoco duré mucho con eso. En el tercer intento volví a React y empecé con JSX sencillo. Aprendí TypeScript, llegué a dominar TSX, entendí la diferencia entre CJS y ESM, me enamoré de la programación reactiva y empecé a usar bibliotecas como Lucide, Framer Motion y Radix UI, que más adelante se volverían indispensables para mí; esta vez, por fin empezaba a parecer algo serio. Pero volví a fracasar, porque en el fondo solo estaba imitando a los demás: usaba cualquier cosa que ellos usaran. Parecía convincente, pero en realidad no entendía en absoluto por qué había que hacerlo así. Con el impulso adicional de las alucinaciones de la IA, podía conseguir que muchas cosas funcionaran como un producto mínimo viable, pero al ampliarlas todo estaba lleno de trampas.
Más adelante también aprendí sobre los loaders de React (Remix) Router, el App Router de Next.js 15 y los RSC, pero para entonces mi día a día ya era tan ajetreado que apenas tenía tiempo para programar y, por tanto, tampoco tuve ocasión de fracasar por cuarta vez. Ahora que lo pienso, desarrollé mi sitio web desde Next.js 13 hasta Next.js 15; apenas había terminado la migración y aún no lo había publicado cuando salió Next.js 16 beta 1.
Déjalo ir
Decir que «lo había dejado atrás» no es del todo exacto; simplemente estaba cansado.
El ritmo de la era de la IA es demasiado rápido. Los modelos se iteran uno tras otro, las técnicas nuevas brotan oleada tras oleada, y yo estaba cada vez más ansioso, como si detenerme bastara para que me adelantaran. En lo más loco escribía código dieciséis horas al día y podía quemar $1.9k USD de Token en un solo día (por febrero, creo); estaba casi destrozado. Pero lo que detuvo todo esto no fue ninguna revelación, sino simple cansancio. Bajo un ritmo cada vez más apretado, cayó la última gota y, al contrario, me sentí en paz, solté, ; y así, también está bastante bien.
Empecé a soltar. Renuncié a aquello con lo que antes me obsesionaba, aprendí a detenerme cuando ya era suficiente y a dejar para mañana los asuntos de mañana. ¿Vane no está terminado? Lo dejo por ahora. ¿A Seam aún le falta mucho? Ya volveré más adelante. ¿El blog no es perfecto? Primero lo publico. Empecé a hacer Vibe Coding por completo: si no hay problemas, no lo toco; si surge alguno, ya me ocuparé entonces.
Lo extraño es que, después de soltar, la calidad no empeoró. Creo que se debe a que aquellos días de programación no fueron en vano. Ya usaba IA en la época de GPT-2, pero entonces seguía escribiendo con honradez cada línea de código y entendiendo cada concepto. Aquella etapa me dio la base. Lo que vino después fue menos Vibe Coding que Context Coding: el criterio necesario seguía ahí, y soltar no me llevó a ningún error de principiante ni a ningún accidente.
Todos aquellos experimentos anteriores son los que ahora me permiten soltar las riendas.
Punto de partida
La solución final resultó ser sorprendentemente sencilla: todo en Cloudflare. R2 para el almacenamiento de objetos, D1 como base de datos en el borde, KV para la caché y Worker para el renderizado del lado del servidor; todo con una arquitectura sin servidor y sin servidores.
¿Es irónica esta respuesta? Muchísimo. Porque antes de llegar a este destino «sencillo», di un rodeo enorme. En su día planeé alojarlo todo por mi cuenta, así que tenía que administrar un servidor, pelearme con Docker y gestionar contenedores. Por eso escribí Canopy como panel de administración, Lazycert para gestionar certificados, Vane como proxy inverso y Twig para instrumentar la supervisión de recursos. Un montón de proyectos solo para servir a un servidor de porquería.
Con el almacenamiento pasó lo mismo. El almacenamiento de objetos me parecía caro y quería usar el disco duro de mi propio servidor, así que escribí RFS, un VFS que eliminaba duplicados de forma atómica y reunía los datos en un único archivo. Incluso resucité el concepto de registro de las décadas de 1980 y 1990, y al final monté todo mediante FUSE. ¿El resultado? Dediqué aún más tiempo a reinventar una rueda peor, mientras el servidor estuvo un año funcionando en vacío. Fue un negocio ruinoso de principio a fin.
Después de dar un gran rodeo, al final volví a la computación sin servidor. El concepto de Vercel es bueno, pero no me gusta Next.js; además, Vercel depende de demasiada magia, y su diseño de software intermediario, precompilado para ejecutarse en el borde de la red, termina fragmentando el sistema e incluso ha dado lugar a varias CVE. Para eso, más vale ejecutarlo todo junto en el servidor de origen. Cloudflare Workers, en cambio, es excelente y lleva las cosas a otro extremo: compila en WASM los artefactos de menos de 10 MB, lo que permite ejecutar lógica de negocio real en el borde. Eso es exactamente lo que quiero. No tiene más inconveniente que el coste, aunque, pensándolo bien, tampoco es realmente un inconveniente, porque el tiempo ahorrado es dinero.
Menos es más
Había oído esta frase innumerables veces, pero tardé dos años en comprender de verdad su significado.
Volver a la esencia de la ingeniería: «Make it function, make it correct, then make it exceptional». Por fin encontré el buen camino y conseguí que funcionara. ¿Es rudimentario el blog actual? Lo es. ¿Está incompleto? Desde luego. Pero es mejor que nada. Si todavía no has publicado nada y sigues creando eso que «quizá necesites», siempre en busca de una perfección invisible, al final no tendrás nada que mostrar. Esto no es una concesión, sino una decisión de ingeniería. En cualquier caso, he aprendido a dejarlo estar. Así que lo dejé estar. Al dejar de obsesionarme con un solo detalle, acabé saliendo por la puerta. Hacía mucho que no había fotos al aire libre en mi móvil, así que tomé una al vuelo junto al camino; hacía muchísimo que no salía (
Al mirar atrás y recordar los rodeos que di, ¿me arrepiento? No. Hay cosas que quizá nunca llegues a comprender si no las pruebas por tu cuenta. Además, en la era de la inteligencia artificial ya es prácticamente imposible seguir el mismo camino de antes que recorrí yo; demasiados flujos de trabajo han cambiado. Y luego está este proyecto, Taki, programado íntegramente con inteligencia artificial. Pero eso no significa que no pueda mantenerse a largo plazo ni que carezca de un toque humano. En realidad, no importa si intervino o no la inteligencia artificial. Al fin y al cabo, lo que me gusta no es escribir código en sí, sino crear algo...