Últimamente pienso mucho en lenguajes y frameworks, no por capricho sino porque la AI cambió mucho la forma de laburar. Si la AI va a escribir código y yo lo voy a revisar, necesito un stack que al menos cumpla con estas cinco cosas:
- Tipos estáticos para que la AI se pueda chequear sola.
- Ecosistema grande y conocido por la AI.
- Un camino prescriptivo, sin mil opciones.
- Que resuelva la mayor cantidad de piezas dentro del mismo framework.
- Expresividad: más con menos, sin ambigüedades.
TS/Next.js
Tiene tipos, tiene ecosistema y es el idioma nativo de la AI. Pero es un quilombo de opciones. En la capa de datos hay mil formas de hacer lo mismo. Sí, podés elegir entre Server Actions, tRPC, React Query pelado… pero yo no quiero elegir.
Y después está el costo de los tipos: paso más tiempo peleando con errores de TS que resolviendo problemas de negocio. Los tipos no siempre reflejan lo que pasa en runtime. Sí, ayudan a la AI, pero a veces parecen más un castigo para los humanos.
Y después está el costo de los tipos: paso más tiempo peleando con errores de TS que resolviendo problemas de negocio. Los tipos no siempre reflejan lo que pasa en runtime. Sí, ayudan a la AI, pero a veces parecen más un castigo para los humanos.
Ruby/Rails
Rails es lo opuesto: expresivo, opinionated, rápido para shippear. Resuelve mucho de entrada y tiene un solo camino para la mayoría de las cosas. El gran problema: no tiene tipos estáticos por defecto, y eso para mí es un dealbreaker.
Después está Hotwire 🤦♂️. En la búsqueda de no escribir JS terminamos con el backend prescribiendo qué hace el frontend (append, update, delete…). El modelo debería abstraer la vista como en LiveView, o abrazar las directivas como en htmx, donde la acción es explícita en el HTML y no hay que ir a leer el endpoint o el template para entender qué carajo va a pasar.
Después está Hotwire 🤦♂️. En la búsqueda de no escribir JS terminamos con el backend prescribiendo qué hace el frontend (append, update, delete…). El modelo debería abstraer la vista como en LiveView, o abrazar las directivas como en htmx, donde la acción es explícita en el HTML y no hay que ir a leer el endpoint o el template para entender qué carajo va a pasar.
Elixir/Phoenix
Phoenix me resulta mucho más interesante. Tiene un lenguaje expresivo como Elixir, mejora la experiencia con typespecs + Dialyzer y están trabajando en un sistema de tipos estáticos más formal que la comunidad banca (a diferencia de Rails con Sorbet) y sobre todo LiveView.
LiveView simplifica todo: el frontend reacciona al estado de la vista en el server. Punto. No hay mil moving pieces. Es declarativo, claro, y estimo debe ser mejor para la AI porque tiene menos superficie donde confundirse.
Además, Elixir y la BEAM integran cosas que otros ecosistemas delegan en servicios externos (procesos, concurrencia), lo que lo vuelve más completo. Lo único que me da cagazo es el deployment.
LiveView simplifica todo: el frontend reacciona al estado de la vista en el server. Punto. No hay mil moving pieces. Es declarativo, claro, y estimo debe ser mejor para la AI porque tiene menos superficie donde confundirse.
Además, Elixir y la BEAM integran cosas que otros ecosistemas delegan en servicios externos (procesos, concurrencia), lo que lo vuelve más completo. Lo único que me da cagazo es el deployment.
En definitiva
TS/React es viable (y es lo que uso hoy) si le pongo reglas claras: una receta de cocina para datos, validación y cache. Pero si quiero reducir decisiones, revisar menos y que la AI se equivoque menos, Phoenix/LiveView creo que está varios pasos adelante.