Nadie se despierta una mañana y decide crear un lenguaje de programación. La decisión te encuentra -- generalmente después de años de frustración acumulada, una convicción creciente de que algo ha fallado fundamentalmente, y un momento específico en el que la absurdidad del statu quo se vuelve imposible de ignorar.
Para nosotros, ese momento llegó a finales de 2025, en un escritorio en Abiyán, Costa de Marfil. Thales estaba intentando estructurar una aplicación web sencilla -- un formulario que guarda datos, una lista que los muestra, una página que los renderiza. El tipo de aplicación que, en 1995, habría requerido un archivo HTML y un script CGI. En 2025, requería 18 pasos, 15 archivos de configuración, 1.847 paquetes de npm y 1,5 gigabytes de espacio en disco.
Algo había ido terriblemente mal con el desarrollo web. Y decidimos solucionarlo de raíz.
La explosión de la complejidad: 1995 vs. 2024
Los números cuentan la historia mejor que cualquier argumento.
En 1995, construir un sitio web se veía así:
1. Crear index.html
2. Escribir <h1>Hello</h1>
3. Subir al servidor
4. Funciona.Tres pasos. Un archivo. Cero dependencias. Un niño de doce años podía hacerlo en una tarde. Muchos lo hicieron -- y esos niños de doce años crecieron para convertirse en los ingenieros que construyeron la web moderna.
En 2024, construir el mismo sitio web se ve así:
1. Instalar Node.js
2. npm init
3. npm install react react-dom
4. npm install -D vite @vitejs/plugin-react
5. npm install -D typescript @types/react @types/react-dom
6. npm install -D tailwindcss postcss autoprefixer
7. npm install -D eslint prettier
8. Crear tsconfig.json
9. Crear vite.config.ts
10. Crear tailwind.config.js
11. Crear postcss.config.js
12. Crear .eslintrc.js
13. Crear .prettierrc
14. Crear src/main.tsx
15. Crear src/App.tsx
16. npm run dev
17. Esperar 30 segundos para la compilación
18. Funciona (quizás).Tres pasos se convirtieron en dieciocho. Segundos se convirtieron en horas. Kilobytes se convirtieron en gigabytes. El número 1.847 -- la cantidad de paquetes npm transitivos instalados por create-react-app -- no es una estadística. Es una acusación.
La trayectoria es condenatoria:
Año Para construir "Hello World" Dependencias Archivos de config
---- ---------------------------- ------------ ------------------
1995 1 archivo (HTML) 0 0
2005 3 archivos (HTML/CSS/JS) 0 0
2010 10 archivos + jQuery 5 1
2015 50 archivos + Gulp 200 5
2020 500 archivos + Webpack 1.000 10
2024 50.000 archivos 2.000 15+Cada fila de esa tabla representa una generación de desarrolladores que tuvo que aprender más, configurar más y comprender más solo para producir el mismo resultado. Las herramientas destinadas a ayudarnos se convirtieron en el problema.
El problema de las 47 herramientas
Para construir una aplicación web de producción en 2024, necesitas -- como mínimo -- las siguientes categorías de herramientas:
Categoría Herramientas necesarias
------------------------- ---------------------
Framework frontend React / Vue / Svelte / Angular
Meta-framework Next.js / Nuxt / SvelteKit
Gestión de estado Redux / Zustand / Pinia
Obtención de datos React Query / SWR / TanStack Query
Framework CSS Tailwind / Styled Components
Framework backend Express / Fastify / NestJS
ORM / Acceso a BD Prisma / TypeORM / Drizzle
Base de datos PostgreSQL / MySQL / MongoDB
Motor de búsqueda Elasticsearch / Algolia / Meilisearch
Capa de caché Redis / Memcached
Gestor de paquetes npm / yarn / pnpm
Empaquetador Webpack / Vite / esbuild
Compilador del lenguaje TypeScript
Linter ESLint
Formateador Prettier
Ejecutor de pruebas Jest / Vitest
Entorno de contenedores DockerDiecisiete categorías. Cada una con múltiples opciones en competencia. Cada una con su propio formato de configuración, su propio esquema de versionado, sus propios cambios incompatibles, su propio ecosistema de plugins que pueden o no ser compatibles entre sí.
El recuento total, cuando se incluyen sub-herramientas, plugins y dependencias transitivas, supera las 47 tecnologías distintas. Lo sabemos porque las contamos.
Así es como se ve la raíz de un proyecto típico antes de escribir una sola línea de código de aplicación:
my-app/
package.json
package-lock.json
tsconfig.json
vite.config.ts
tailwind.config.js
postcss.config.js
.eslintrc.js
.prettierrc
jest.config.js
docker-compose.yml
Dockerfile
.env
.env.local
.env.production
.gitignore
node_modules/ # 1.847 paquetes, 1,5 GBQuince archivos de configuración. Quince oportunidades para conflictos de versión, errores de sintaxis e incompatibilidades sutiles. Quince archivos que existen puramente para hacer que otras herramientas funcionen juntas -- no para servir a ningún usuario, no para resolver ningún problema de negocio, no para crear ningún valor.
El coste humano
Esta complejidad no es meramente un problema estético. Tiene consecuencias concretas y medibles.
Para los principiantes, la curva de aprendizaje ahora se mide en meses, no en días. Un estudiante en Abiyán que quiere aprender desarrollo web no enfrenta un problema de conocimiento -- la información existe. Enfrenta un problema de herramientas. Antes de poder escribir <h1>Hello</h1> en un framework moderno, debe entender Node.js, npm, sintaxis JSX, empaquetadores de módulos y TypeScript. El noventa por ciento de los tutoriales quedan obsoletos en un año porque el ecosistema cambia más rápido de lo que cualquiera puede documentar.
Para los profesionales, la experiencia diaria del desarrollo web se ha convertido en una de configuración, no de creación. Un ingeniero senior en una empresa del Fortune 500 pasa más tiempo actualizando dependencias, resolviendo conflictos de versiones y migrando entre versiones de frameworks que construyendo funcionalidades. La frase "funciona en mi máquina" no ha desaparecido; simplemente ha evolucionado a "funciona con esta combinación exacta de versiones de paquetes."
Para las empresas, los proyectos tardan tres veces más de lo que deberían. La deuda técnica se acumula desde el primer día -- no porque los ingenieros escriban mal código, sino porque la base debajo de ellos es una pila de 47 herramientas con versiones independientes que nunca fueron diseñadas para funcionar juntas. La contratación es una pesadilla porque cada equipo usa una combinación diferente de las mismas categorías, y "experiencia en React" significa algo diferente en cada empresa.
Para los mercados emergentes, la situación es catastrófica. Descargar 1,5 gigabytes de node_modules con una conexión que promedia 2 Mbps toma horas. Cada npm install cuesta dinero real en datos móviles. La electricidad poco fiable significa que un proceso de compilación largo -- que podría tomar 30 segundos en San Francisco -- arriesga perder todo el trabajo cuando se corta la electricidad. La brecha entre "desarrollado" y "en desarrollo" no es cuestión de talento; es cuestión de ancho de banda.
La causa raíz
El problema no es React. React es una excelente biblioteca de UI. El problema no es npm. npm es un gestor de paquetes competente. El problema no es TypeScript, ni Tailwind, ni Prisma, ni ninguna herramienta individual.
El problema es que estamos construyendo con bloques de Lego que no encajan entre sí.
Cada herramienta resuelve su propio problema de forma aislada:
React resuelve la reactividad de UI
Prisma resuelve el acceso a base de datos
Express resuelve el enrutamiento HTTP
Redux resuelve la gestión de estado
Tailwind resuelve el estilizado
Vite resuelve el empaquetado
TypeScript resuelve la seguridad de tiposPero ninguna de ellas resuelve el problema real: construir una aplicación. Aún tienes que conectarlas entre sí. Configurarlas. Mantenerlas compatibles. Actualizarlas cuando se rompen. Reescribir tu código de integración cuando una de ellas lanza una versión mayor con cambios incompatibles.
El ecosistema JavaScript no se propuso crear este desastre. Evolucionó orgánicamente, una decisión razonable a la vez. Cada herramienta fue una mejora genuina sobre lo que había antes. Pero el efecto acumulativo es una máquina de Rube Goldberg -- un aparato asombrosamente complejo que, después de todos sus engranajes, palancas y poleas, produce el mismo resultado que un único archivo HTML producía en 1995.
La pregunta que lo empezó todo
Sentado en Abiyán, mirando otra barra de progreso de npm install, Thales hizo una pregunta:
¿Y si hubiera una sola herramienta que simplemente... construyera aplicaciones?
No un framework. No una biblioteca. No un "JavaScript mejorado" o un "empaquetador basado en Rust" o un "ORM con seguridad de tipos." Esas son mejoras incrementales a una arquitectura fundamentalmente rota. Hacen la máquina de Rube Goldberg ligeramente más eficiente sin cuestionar por qué existe la máquina.
¿Y si, en cambio, tuvieras un lenguaje de programación donde construir una aplicación web fuera tan simple como en 1995 -- pero con todo el poder de 2026?
¿Y si pudieras escribir esto?:
flintodos = []
newTodo = ""
entity Todo {
title: text
done: bool = false
}
<main>
<h1>My Todos</h1>
<input value={newTodo} placeholder="Add todo..."
enter={save Todo { title: newTodo }; newTodo = ""}>
{for todo in todos}
<div>
<input type="checkbox" checked={todo.done}
click={todo.done = !todo.done; save todo}>
<span>{todo.title}</span>
<button click={delete todo}>x</button>
</div>
{/for}
</main>Guardarlo como app.flin. Ejecutar flin dev. Listo.
Sin package.json. Sin tsconfig.json. Sin configuración de empaquetador. Sin configuración de ORM. Sin migración de base de datos. Sin biblioteca de gestión de estado. Sin un proceso de inicialización de diecisiete pasos. Un archivo. Un comando. Una aplicación de tareas completa, funcional y respaldada por una base de datos.
Esa es la pregunta que inició FLIN.
Por qué un lenguaje, no un framework
El primer instinto, al enfrentar la complejidad, es construir un mejor framework. Un framework que agrupe las herramientas correctas, las preconfigure correctamente y oculte las costuras. Esto es lo que Next.js hizo para React, lo que Nuxt hizo para Vue, lo que SvelteKit hizo para Svelte.
Los frameworks ayudan. Pero no resuelven el problema subyacente porque están construidos sobre el stack existente. Next.js aún requiere Node.js, aún usa npm, aún incorpora cientos de paquetes, aún genera un directorio node_modules que pesa más de un gigabyte. La complejidad está oculta, no eliminada.
Un lenguaje es diferente. Un lenguaje define sus propias reglas desde la base. No necesita acomodarse a las decisiones de otras 47 herramientas porque es la única herramienta.
Considera lo que FLIN elimina al ser un lenguaje en lugar de un framework:
Lo que un framework debe acomodar Lo que un lenguaje puede eliminar
----------------------------------- ---------------------------
Runtime de Node.js Sin dependencia de runtime
Gestor de paquetes npm Sin gestor de paquetes
Compilador TypeScript Sistema de tipos integrado
Empaquetador (Webpack/Vite) Sin necesidad de empaquetador
ORM (Prisma/Drizzle) Sistema de entidades integrado
Gestión de estado (Redux) Todas las variables son reactivas
Framework CSS (Tailwind) Estilizado integrado
Ejecutor de pruebas (Jest) Pruebas integradas
Archivos de config (15+) Cero archivos de configuraciónUn framework es un conjunto de opiniones sobre cómo usar herramientas existentes. Un lenguaje es un conjunto de opiniones sobre cómo pensar en los problemas. La diferencia es fundamental.
Por qué fuimos nosotros quienes lo construimos
Dos factores hicieron posible que intentáramos esto.
Primero, el modelo CEO-CTO IA. Construir un lenguaje de programación es tradicionalmente un esfuerzo de varios años y múltiples equipos. El compilador de Rust tiene cientos de contribuidores. TypeScript tiene un equipo dedicado en Microsoft. Nosotros éramos dos: Thales, el CEO de ZeroSuite, tomando decisiones arquitectónicas y de producto, y Claude, el CTO IA, implementándolas a la velocidad del pensamiento.
Este modelo -- un humano con profunda intuición de producto y comprensión del mercado, una IA con paciencia ilimitada para la teoría de compiladores y la programación de sistemas -- es especialmente adecuado para el diseño de lenguajes. Thales podía articular cómo debería sentirse el lenguaje para un desarrollador en Abiyán o Lagos. Claude podía traducir esa sensación en un analizador léxico, un parser, un verificador de tipos y un generador de código.
Segundo, la perspectiva africana. La mayoría de los lenguajes de programación se diseñan en entornos con internet rápido, almacenamiento barato, electricidad fiable y abundante talento de ingeniería. FLIN fue diseñado en Costa de Marfil, donde ninguna de esas suposiciones se sostiene. Esto no es una desventaja; es una restricción de diseño que produce mejor software para todos.
Cuando diseñas para un desarrollador que tiene 2 Mbps y paga por megabyte, produces un lenguaje con cero dependencias y un único binario. Ese lenguaje también resulta ser mejor para un desarrollador en San Francisco que está cansado de esperar 45 segundos a que su servidor de desarrollo Next.js arranque.
Cuando diseñas para un estudiante que nunca ha visto un tsconfig.json, produces un lenguaje donde un archivo es suficiente. Ese lenguaje también resulta ser mejor para un ingeniero senior que ha configurado mil archivos tsconfig.json y preferiría no configurar otro.
Las restricciones generan innovación. Y las restricciones de desarrollar software en África Occidental son exactamente las restricciones que el ecosistema global de desarrollo web necesita que se le impongan.
El nombre
FLIN no es un acrónimo. Es una palabra del fongbe, una lengua hablada en Benín, el país de origen de Thales.
En fongbe, la frase "E flin nu" significa "Recuerda las cosas." El elefante -- sagrado en la cultura beninesa -- es el animal que nunca olvida.
El nombre captura la idea arquitectónica central de FLIN: diseño nativo de memoria. En FLIN, cada entidad rastrea automáticamente su historial. Puedes consultar cualquier registro en cualquier momento del tiempo. El lenguaje mismo recuerda todo, tal como lo hace el elefante.
flin// Save a user
save User { name: "Juste", email: "[email protected]" }
// Later, query the user as they were yesterday
user @ yesterday
// Or two versions ago
user @ -2
// Or on a specific date
user @ "2025-06-15"
// Or see every version that ever existed
user.historyContaremos la historia completa del nombre en el tercer artículo de esta serie. Por ahora, sepa que el nombre no es un ejercicio de marketing. Es una filosofía de diseño codificada en tres sílabas.
Lo que vino después
La pregunta -- "¿Y si hubiera una sola herramienta que simplemente construyera aplicaciones?" -- fue formulada a finales de 2025. El 1 de enero de 2026, empezamos a construir la respuesta.
La primera sesión duró 45 minutos. Creamos la estructura del proyecto Rust, definimos 42 palabras clave, implementamos más de 60 tipos de tokens para el analizador léxico y escribimos 25 pruebas unitarias. El proyecto se llamó flin-official, y compiló en el primer intento.
flin-official/
Cargo.toml
src/
main.rs
lib.rs
lexer/
mod.rs
token.rs # 650+ líneas, 42 palabras clave, 60+ tipos de tokens
parser/mod.rs
typechecker/mod.rs
codegen/mod.rs
vm/mod.rs
database/mod.rs
server/mod.rs
error/mod.rs
examples/
counter.flin
todo.flinDoce archivos. Mil líneas de Rust. El esqueleto de un lenguaje de programación que reemplazaría 47 tecnologías por una sola.
Esta serie documenta cómo lo construimos -- cada decisión arquitectónica, cada fragmento de código, cada lección aprendida con esfuerzo. No como una retrospectiva, sino como un plan. Porque el próximo FLIN podría venir de un desarrollador en Lagos, o Nairobi, o Dakar. Y cuando eso suceda, no deberían tener que empezar desde cero.
Siguiente en la serie: 47 Technologies Replaced by One Language -- ¿Y si pudieras eliminar React, Next.js, Redux, Prisma, Express, Tailwind y 41 herramientas más?