¿Qué stack técnico genera un creador de webs con IA?

¿Qué stack técnico genera un creador de webs con IA?

Zugo produce salida web: HTML para la estructura, CSS para el aspecto y JavaScript para el comportamiento, todo ejecutándose en el navegador. Las capacidades externas llegan mediante conectores en lugar de reimplementarse, así que la base de datos es Supabase y los cobros son Stripe. El proyecto entero se exporta a GitHub, y la forma más rápida de confirmarlo es leer el código fuente.

"Qué stack" son en realidad tres preguntas con un solo abrigo: si alguien podrá mantenerlo, si podrás alojarlo donde quieras y si podrás marcharte. Este artículo responde las tres y explica cómo verificar las respuestas en vez de creértelas.

¿Por qué importa tanto la pregunta del stack?

Porque decide quién puede trabajar sobre el resultado. Una base de código con una forma que los desarrolladores reconocen se le puede entregar a cualquiera de ellos. Una en formato propietario solo se le entrega a quien esté dispuesto a aprender ese formato primero, que es un grupo mucho más pequeño y una conversación bastante más incómoda.

También decide dónde puede vivir la cosa. Una salida que el navegador abre directamente se puede servir desde casi cualquier sitio. Una que exige un entorno de ejecución concreto queda atada a los alojamientos que lo ofrezcan, y esa atadura te acompaña durante toda la vida del proyecto.

Y decide cuánto cuesta irse, que es la pregunta que hay debajo de las otras dos. Una plataforma visual donde montas pantallas sobre un lienzo es un compromiso, porque las pantallas no son archivos. Los archivos de texto son portátiles por naturaleza, y esa propiedad no la sustituye ninguna lista de funciones.

¿Qué produce Zugo exactamente?

Un proyecto de navegador que funciona. La página que publicas es marcado, estilos y script que el navegador carga y ejecuta, y por eso una construcción se puede abrir en <slug>.zugo.run de inmediato, sin ningún paso de aprovisionamiento por tu parte.

La capa de diseño es CSS, gobernada por propiedades personalizadas en vez de por un framework de componentes, y la tipografía se carga como una hoja de estilos de fuente web corriente. El comportamiento interactivo es JavaScript dentro de la página: estado, almacenamiento y lo que se le pidiera hacer al pulsar un botón.

Cuando conectas Supabase, la página generada carga el cliente de Supabase como módulo ES en una versión fijada y habla con tu proyecto directamente desde el navegador. Fijar la versión importa más de lo que parece: el código que corre en tu dominio publicado, al lado de los datos de tus visitantes, no debería cambiar por debajo porque un tercero publique una versión nueva.

¿Cómo puedes comprobar el stack por tu cuenta?

Leyéndolo, cosa que lleva un minuto y vale más que cualquier afirmación de este artículo.

La tercera fila conviene hacerla antes de planificar nada relacionado con buscadores. Si tus secciones comparten una dirección con un fragmento detrás del #, un buscador ve una sola página, lo cual está bien para una landing y limita a un sitio de contenidos. Ese asunto se desarrolla en si una web hecha con IA es buena para SEO.

La cuarta fila es la prueba honesta de cualquier promesa de propiedad, incluida la nuestra. Haz la exportación sobre un proyecto de prueba antes de necesitarla, no el día que te vas.

¿Qué facilita este stack?

Cuatro cosas, y son la razón de la elección.

Cualquiera puede leerlo. Marcado, estilos y script son el idioma común de la web. Un desarrollador no necesita aprender una abstracción propietaria antes de poder ayudarte, lo que acorta la primera conversación y baja el presupuesto.

Corre en cualquier sitio. Un proyecto de navegador se puede servir desde el alojamiento de Zugo en <slug>.zugo.run, desplegar en tu propia cuenta de Vercel mediante el conector, o servirse desde donde quieras una vez el repositorio está en GitHub.

No hay nada entre tú y el resultado. Lo que lees en el fuente es lo que ejecuta el navegador. Depurar consiste en mirar la página, no en razonar sobre una tubería de compilación.

La superficie de fallo es pequeña. Que haya menos piezas móviles entre tu descripción y una página renderizada es parte de por qué una construcción simple tarda alrededor de un minuto y una plataforma multipágina tarda varios.

¿Qué te cuesta este stack?

Tres renuncias reales. Un builder que no las nombra no está siendo franco contigo.

No es una base de código en React ni en Next.js. Si tu equipo estandariza sobre un framework, o tu plan de contratación lo da por supuesto, la salida generada no encajará con esa expectativa, y más vale saberlo antes que después. Lo que recibes es portátil y legible, no lo que un equipo acostumbrado a un framework espera abrir.

Un documento tiene techo. Un proyecto montado como un único documento de navegador funciona de maravilla hasta cierto punto y se vuelve incómodo pasado ese punto. Las aplicaciones muy grandes son justo la forma en la que un equipo de desarrollo y una base de código convencional justifican su coste, y Zugo no sustituye a un equipo de desarrollo en un producto complejo.

No hay ecosistema de componentes. No existe un mercado de bloques prefabricados que instalar. Cualquier cosa poco habitual se genera para ti o se levanta con ediciones sucesivas. A veces eso es mejor que buscar un plugin. Cuando ya existe uno maduro, no lo es.

¿Dónde encajan los servicios externos?

Al lado de la página en vez de dentro de ella, y ese matiz cambia cómo hay que hacer la pregunta del stack.

Léelo como un segundo stack situado debajo del primero. La página generada es pequeña precisamente porque las piezas pesadas y sensibles a la seguridad las llevan servicios construidos para ellas. Una app generada nunca guarda un número de tarjeta, porque eso lo hace Stripe, y nunca cifra una contraseña, porque eso lo hace Supabase.

Esa disposición es además la que habría montado un desarrollador competente. La diferencia interesante es que en un builder son tres clics en lugar de tres tardes. El detalle del conector de base de datos está en la guía de Supabase.

¿Qué le preguntarías a cualquier builder sobre su stack?

Cuatro preguntas, en este orden, porque cada una hace que la siguiente tenga sentido.

Si puedo ver el código fuente de una página publicada sin pedir permiso. Si puedo exportarlo a un repositorio que controlo yo. Si esa exportación contiene el proyecto entero o solo una foto de la página visible. Y si puedo ejecutarlo y modificarlo sin el builder de por medio.

Una herramienta que responde que sí a las cuatro convierte la pregunta del stack en algo casi académico, porque sea cual sea la respuesta, puedes ir a mirarla. Una que responde que no a la segunda o a la tercera la convierte en la pregunta más importante que harás, sea cual sea el stack.

Las consecuencias prácticas están en exportar el código y en si un desarrollador puede retomarlo después. Y si prefieres comprobar antes que leer, describe algo pequeño en Zugo, publícalo y mira el código fuente del resultado.