{"id":36835,"date":"2026-10-23T14:08:07","date_gmt":"2026-10-23T12:08:07","guid":{"rendered":"https:\/\/www.codemotion.com\/magazine\/?p=36835"},"modified":"2026-10-23T14:08:09","modified_gmt":"2026-10-23T12:08:09","slug":"la-ia-se-lleva-genial-con-html-pero-react-ya-es-otra-historia","status":"publish","type":"post","link":"https:\/\/www.codemotion.com\/magazine\/es\/inteligencia-artificial\/la-ia-se-lleva-genial-con-html-pero-react-ya-es-otra-historia\/","title":{"rendered":"Por qu\u00e9 la IA odia los frameworks web modernos (y se lleva de maravilla con los est\u00e1ndares web)"},"content":{"rendered":"\n
En los \u00faltimos dos a\u00f1os, los asistentes de IA para programar se han colado en la vida de pr\u00e1cticamente todos nosotros. Incluso de quienes juraban que no los iban a usar nunca (hola, s\u00ed, yo tambi\u00e9n era de esos y he acabado convirti\u00e9ndome).<\/p>\n\n\n\n
Con HTML, CSS, JavaScript del de toda la vida y funciones puras funcionan de maravilla. Pero les das un componente de React con cinco hooks que se hablan entre s\u00ed, o un computed()<\/code> de Vue conectado a un estado que se modifica tres archivos m\u00e1s all\u00e1, y de repente el asistente parece que se ha tomado dos copas de m\u00e1s.<\/p>\n\n\n\n
Y no, no es una impresi\u00f3n sacada de una charla despu\u00e9s de un meetup. Hay una raz\u00f3n bastante concreta detr\u00e1s, y es la misma por la que estos frameworks tambi\u00e9n nos complican la vida a los humanos. La diferencia es que, con la experiencia, nosotros desarrollamos una especie de callo mental que nos ayuda a esquivar ciertas trampas. Los modelos no tienen ese callo, as\u00ed que caen en ellas con todo el entusiasmo del mundo.<\/p>\n\n\n\n
El problema no es la sintaxis, es la magia<\/h2>\n\n\n\n
Los modelos de lenguaje generan c\u00f3digo prediciendo qu\u00e9 texto viene despu\u00e9s a partir de lo que tienen delante. Se les da bien cuando pueden deducir c\u00f3mo funciona algo mirando el propio c\u00f3digo: una funci\u00f3n pura se explica pr\u00e1cticamente sola. Miras lo que entra, lo que sale y listo. No hay misterio.<\/p>\n\n\n\n
El problema llega cuando el comportamiento depende de algo que no aparece por ninguna parte en el archivo que est\u00e1n leyendo en ese momento.<\/p>\n\n\n\n
En los \u00faltimos a\u00f1os, los frameworks web reactivos han ido todos en la misma direcci\u00f3n: m\u00e1s magia autom\u00e1tica y menos c\u00f3digo que escribir a mano. Todo comod\u00edsimo mientras funciona.<\/p>\n\n\n\n
Para un desarrollador con experiencia, esto puede ser una maravilla: escribes tres l\u00edneas y el grafo de actualizaciones se monta \u00e9l solito. Pero para un modelo que tiene que generar c\u00f3digo correcto sin poder ejecutar mentalmente ese grafo invisible, la cosa cambia.<\/p>\n\n\n\n
Es como participar en una carrera de obst\u00e1culos a oscuras. Y sin que nadie te haya explicado d\u00f3nde est\u00e1n los obst\u00e1culos.<\/p>\n\n\n\n<\/figure>\n\n\n\n
Un ejemplo pr\u00e1ctico. En Vue 3, desestructurar un objeto reactivo puede cargarse la reactividad en silencio:<\/p>\n\n\n
const<\/span> state = reactive({ count<\/span>: 0<\/span> })\n\n\/\/ Deja de actualizarse. Sin errores, sin avisos. Silencio absoluto.<\/span>\nconst<\/span> { count } = state\n\n\/\/ Esto, en cambio, funciona perfectamente.<\/span>\nconst<\/span> count = computed(()<\/span> =><\/span> state.count)<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
Quien lleva un tiempo trabajando con Vue ya se lo sabe y lo evita casi por instinto. Pero un modelo que genera c\u00f3digo bas\u00e1ndose en patrones habituales de JavaScript, donde desestructurar un objeto es inofensivo en el 99 % de los casos, tiene muchas papeletas para caer en la trampa.<\/p>\n\n\n\n
Y la misma pel\u00edcula se repite, con distintos protagonistas, en los arrays de dependencias de useEffect<\/code> en React: te olvidas de una dependencia y aparece un bug silencioso; a\u00f1ades una de m\u00e1s y puedes acabar en un bucle infinito. O con el seguimiento autom\u00e1tico de dependencias de computed()<\/code>.<\/p>\n\n\n\n
Ampliando la familia: Solid y Angular<\/h2>\n\n\n\n
A quien insiste en que \u00abbueno, los signals de Solid son solo un get\/set, tampoco es para tanto\u00bb le dir\u00eda que s\u00ed, siempre que est\u00e9s mirando un signal por separado.<\/p>\n\n\n\n
El problema empieza cuando los combinas.<\/p>\n\n\n\n
Un memo<\/code> o un effect<\/code> en Solid registra en tiempo de ejecuci\u00f3n qu\u00e9 signals ha le\u00eddo durante su ejecuci\u00f3n, sin que tengas que declarar esas dependencias en ning\u00fan sitio. Es el mismo principio que el seguimiento autom\u00e1tico de Vue, solo que aplicado de otra manera.<\/p>\n\n\n\n
Y cuando un signal activa otro, que a su vez dispara un efecto que modifica el primer signal, el grafo de propagaci\u00f3n no aparece escrito en ninguna parte del c\u00f3digo. Hay que reconstruirlo siguiendo las lecturas y escrituras que se producen en tiempo de ejecuci\u00f3n.<\/p>\n\n\n\n
Para un modelo, es el mismo tipo de acertijo que en Vue, pero con otro disfraz.<\/p>\n\n\n\n
Angular, por completar la fiesta, consigue sufrir dos problemas a la vez.<\/p>\n\n\n\n
Por un lado, tambi\u00e9n ha adoptado los signals al estilo de Solid, con el mismo seguimiento impl\u00edcito de dependencias. Por otro, sigue siendo Angular: decoradores, inyecci\u00f3n de dependencias, m\u00f3dulos y una cantidad de c\u00f3digo repetitivo que llamar \u00abgenerosa\u00bb ser\u00eda quedarse corto.<\/p>\n\n\n\n
Aqu\u00ed alguien dir\u00e1: \u00abPero si ahora las ventanas de contexto tienen cientos de miles de tokens, \u00bfqu\u00e9 m\u00e1s da que Angular sea verboso? \u00a1Si ya hay espacio de sobra!\u00bb.<\/p>\n\n\n\n
Y s\u00ed, pero ese no es el problema.<\/p>\n\n\n\n
La cuesti\u00f3n ya no es que se acabe la memoria, sino la relaci\u00f3n entre la informaci\u00f3n \u00fatil y el ruido. Doscientas l\u00edneas de c\u00f3digo repetitivo para decir \u00abeste componente recibe una entrada y expone una salida\u00bb son doscientas l\u00edneas en las que el modelo tiene que repartir su atenci\u00f3n. Y, mientras tanto, la l\u00f3gica de negocio que de verdad importa queda diluida entre decoradores, providers y configuraciones que se repiten una y otra vez.<\/p>\n\n\n\n
Es el mismo fen\u00f3meno que se conoce como lost in the middle<\/em>: cuanto m\u00e1s ruido rodea al detalle importante, m\u00e1s probabilidades hay de que ese detalle reciba menos atenci\u00f3n. No porque falte espacio, sino porque hay poca informaci\u00f3n \u00fatil por l\u00ednea.<\/p>\n\n\n\n
\u00bfEl resultado? M\u00e1s posibilidades de perder el hilo entre un decorador y otro, sobre todo cuando toca enfrentarse a archivos interminables.<\/p>\n\n\n\n
Por qu\u00e9 los est\u00e1ndares web salen mejor parados<\/h2>\n\n\n\n
Los asistentes de IA generan mejor c\u00f3digo con HTML, CSS y JavaScript sin demasiadas capas por exactamente el mismo motivo por el que sufren con los frameworks m\u00e1s \u00abm\u00e1gicos\u00bb: cuanto menos tengan que deducir para saber qu\u00e9 va a pasar, mejor.<\/p>\n\n\n\n
Una funci\u00f3n que recibe un estado y devuelve uno nuevo es un libro abierto. Un manejador de eventos que hace exactamente lo que dice que hace, tambi\u00e9n.<\/p>\n\n\n\n
\u00bfUn sistema que rastrea dependencias escuchando qu\u00e9 variables se leen durante la ejecuci\u00f3n? Eso ya es otra historia.<\/p>\n\n\n\n<\/figure>\n\n\n\n
Esto no es un ataque a los frameworks web, que quede claro. React, Vue, Svelte, Solid y Angular siguen siendo herramientas muy potentes, utilizadas con \u00e9xito a gran escala. Y nadie est\u00e1 proponiendo que volvamos a crear webs con document.write<\/code>, tampoco nos vengamos arriba con la nostalgia.<\/p>\n\n\n\n
Es m\u00e1s bien una reflexi\u00f3n sobre un equilibrio que hasta ahora hemos valorado casi siempre desde el punto de vista humano: cu\u00e1nto c\u00f3digo tengo que escribir, lo c\u00f3modo que resulta y lo r\u00e1pido que puedo trabajar. Pero hoy toca mirarlo tambi\u00e9n desde otra perspectiva: la de quienes cada vez m\u00e1s a menudo programamos en pareja con un modelo de IA o, directamente, le dejamos escribir el c\u00f3digo por nosotros.<\/p>\n\n\n\n
Qu\u00e9 significa todo esto en la pr\u00e1ctica<\/h2>\n\n\n\n
Estas son algunas de las reglas que sigo cuando trabajo con un asistente de IA.<\/p>\n\n\n\n
Cuanto m\u00e1s oculta un framework qui\u00e9n tiene que actualizarse cuando algo cambia, m\u00e1s atenci\u00f3n hay que prestar al c\u00f3digo que genera la IA. Los hooks de React, los composables de Vue y las computaciones de Solid son el terreno perfecto para que se cuelen bugs sutiles. No porque la IA tenga malas intenciones, sino porque desconoce parte del contexto impl\u00edcito.<\/p>\n\n\n\n
El c\u00f3digo expl\u00edcito tambi\u00e9n es m\u00e1s f\u00e1cil de comprobar para un modelo, no solo para una persona.<\/p>\n\n\n\n
Una buena prueba es pedirle a la IA que explique por qu\u00e9 un fragmento de c\u00f3digo hace lo que hace. Si para explicarlo tiene que adivinar comportamientos que no aparecen en el archivo que tienes delante, ah\u00ed hay un punto delicado.<\/p>\n\n\n\n
Y no solo para la IA: tambi\u00e9n para ese compa\u00f1ero que abrir\u00e1 el archivo dentro de seis meses sin acordarse de nada de lo que ten\u00edais en la cabeza cuando lo escribisteis.<\/p>\n\n\n\n
Algunos proyectos est\u00e1n apostando claramente por arquitecturas m\u00e1s expl\u00edcitas: estados como datos sencillos, renderizado mediante funciones puras y nada de proxies ni compiladores de por medio. El objetivo es que el c\u00f3digo sea f\u00e1cil de leer tanto para las personas como para las m\u00e1quinas.<\/p>\n\n\n\n
Inglorious Web, el framework de c\u00f3digo abierto en el que trabajo, es uno de estos intentos, aunque ni mucho menos el \u00fanico. La misma filosof\u00eda lleva tiempo detr\u00e1s de librer\u00edas minimalistas como Alpine.js y de enfoques que ponen HTML en el centro, como htmx.<\/p>\n\n\n\n
Que este camino acabe convirti\u00e9ndose en la norma o se quede en un nicho para quienes no quieren renunciar a lo sencillo est\u00e1 por ver. Pero s\u00ed es una se\u00f1al de hacia d\u00f3nde se est\u00e1 moviendo parte del debate sobre arquitectura frontend.<\/p>\n\n\n\n
Una pregunta abierta (y cero cruzadas)<\/h2>\n\n\n\n
No estoy diciendo que tengamos que volver todos al JavaScript vanilla escrito a mano como en 2010, con jQuery para rematar la jugada nost\u00e1lgica. Los frameworks con su buena dosis de magia ofrecen ventajas reales para la productividad humana que los est\u00e1ndares web, por s\u00ed solos, no pueden igualar f\u00e1cilmente. Y para muchos equipos, el trato sigue compensando.<\/p>\n\n\n\n
Pero quiz\u00e1 ha llegado el momento de hacernos una pregunta: cuando elegimos una arquitectura, \u00bfdeber\u00eda empezar a pesar tanto que el c\u00f3digo sea legible y predecible para un modelo como que resulte c\u00f3modo para un desarrollador con experiencia?<\/p>\n\n\n\n
Porque en 2026 el c\u00f3digo ya no lo escribe siempre una \u00fanica persona que se conoce de memoria todas las trampas del framework. Cada vez m\u00e1s, nace del trabajo conjunto de una persona y un modelo de IA.<\/p>\n\n\n\n
Y que el c\u00f3digo sea f\u00e1cil de entender para ambos deja de ser una man\u00eda estil\u00edstica para convertirse en una caracter\u00edstica de la propia arquitectura.<\/p>\n\n\n\n
La magia est\u00e1 muy bien, pero que luego no nos toque hacer de detectives.<\/p>\n","protected":false},"excerpt":{"rendered":"
![\"\"](\"https:\/\/www.codemotion.com\/magazine\/wp-content\/uploads\/2026\/10\/Designer-1-1024x512.png\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/www.codemotion.com\/magazine\/wp-content\/uploads\/2026\/10\/Designer-2-1024x409.png\")
<\/figure>\n\n\n\n