En programación una mala decisión se parece a un directorio node_modules porque nunca deja de crecer. A veces hay que dar un paso atrás y reconocer que se han estado resolviendo problemas que no necesitaban existir. ¿Has dudado alguna vez al elegir una pila popular para un proyecto importante porque la complejidad crece y la experiencia de desarrollador empeora? La industria pide a gritos herramientas de nueva generación, tal como React lo fue en su momento. Yo desarrollé un framework full stack para aplicaciones web dinámicas en el ecosistema Go pensado para entregar aplicaciones completas sin depender de NPM, con estado reactivo, componentes, control de ciclo de vida, SSR por defecto y una arquitectura sin API HTTP pública.
En esencia mi filosofía es descomponer el concepto moderno de framework front end en primitivas ortogonales y composables que se puedan usar por separado o combinar en abstracciones a medida. El DOM es HTML dinámico: el control vence a la abstracción. Algunas bibliotecas vuelven a ejecutar una función de render virtual para calcular diffs, otras manipulan strings directamente. Mi objetivo fue ofrecer ambas posibilidades sin imponer una sola manera de trabajar.
Presento Door, un contenedor dinámico en el árbol DOM que se puede actualizar, reemplazar o eliminar en tiempo de ejecución y con tipado seguro. Métodos clave: Update para cambiar contenido similar a innerHTML, Replace para sustituir por completo como outerHTML, Clear para vaciar contenido, Remove para eliminar el contenedor y Reload para re-renderizar cuando al renderizar se consultan datos que pueden cambiar. Internamente las Doors forman un árbol con ciclos de vida locales y contexto que soporta hooks de desmontaje. Door es una herramienta simple para manipular el DOM y a la vez la base para abstracciones superiores.
Estado reactivo y comunicación. En las UIs modernas el estado cumple dos roles: argumento de render y disparador de re-render. En componentes complejos ese estado acaba usado como primitiva de comunicación y aparecen cadenas de efectos secundarios. Para evitar que la herramienta empuje a ese abuso introduzco Beam: una primitiva de comunicación y controlador de render opcional. Beam es un flujo de valores que puede leerse, suscribirse, vigilarse o derivarse. Se puede combinar Beam con Door para que valores derivados disparen renders solo en los nodos que los necesitan, evitando diff innecesarios en el DOM.
Modelo de rutas como estado. La ruta es datos cambiantes y por tanto estado. Con Path Model cada ruta de página es una estructura anotada que sirve para hacer match, decodificar y codificar URIs de forma tipada. Se pueden declarar variantes de ruta, capturar parámetros con tipado, usar splat para el resto de la ruta y admitir casi cualquier tipo para parámetros de query gracias a un form decoder robusto. El modelo de rutas se expone mediante Beam al render de la página, de modo que se derivan piezas concretas del modelo y se renderiza en función de ellas. También se pueden generar enlaces y navegar mutando el SourceBeam correspondiente. Requiere algo más de código, pero ofrece seguridad tipada, determinismo y libertad para modelar rutas complejas.
Toolkit y eventos. Prefiero un sistema coherente a un conjunto de atajos. El binding de eventos es sencillo: al renderizar se añade un atributo especial al elemento que crea un endpoint protegido y define control de flujo, reglas de concurrencia, acciones previas y manejo de errores. La API de indicaciones permite comunicar procesamiento mediante combinaciones de indicadores y selectores: indicar temporalmente, añadir o quitar clases, ajustar atributos, cambiar contenido o seleccionar elementos por selector global o ancestor. Las indicaciones se limpian automáticamente cuando los cambios de estado y UI se aplican.
Concurrencia matizada. Las interfaces reciben acciones superpuestas: reenvío rápido de formularios, dobles clics, acciones conflictivas, especialmente cuando se procesan remotamente. El framework garantiza procesamiento secuencial a nivel de hook y permite ignorar invocaciones si la función devuelve true. Para control preciso existe la API de Scopes en el cliente: Debounce para agrupar ráfagas, Blocking para cancelar nuevos eventos mientras uno procesa, Serial para encolar y procesar en orden, Priority para cancelar acciones de menor prioridad y Frame para crear límites entre lotes. Los valores de Scope pueden compartirse entre manejadores y combinarse en pipelines para coordinar comportamientos complejos sin artefactos en la UI.
Integración con JavaScript. No hay nada malo en usar JS para tareas puntuales. El framework permite declarar hooks personalizados y activarlos desde JS como si fuera una API privada, registrar manejadores JS invocables desde Go y pasar datos de Go a JavaScript con facilidad. Esto facilita usar JS cuando es la herramienta correcta sin romper la coherencia del sistema.
Extras del sistema. El framework incorpora alojamiento de archivos privado y público, automatización de cabeceras CSP, generación de import map, bundling y build de JS/TS, opciones de routing, control de ciclo de sesión e instancia y ajustes de rendimiento y gestión de recursos. Está pensado para proyectos reales como productos SaaS, paneles administrativos, portales de cliente y aplicaciones a medida donde la seguridad y la velocidad importan.
Respuestas a inquietudes comunes. Procesar eventos en el servidor añade latencia pero con pings inferiores a 100 ms la experiencia se siente casi instantánea; por encima de 200 ms la percepción se nota pero sigue siendo aceptable. Para la mejor experiencia conviene tener servidores cerca del cliente y aprovechar servicios cloud. Algunas transiciones se resuelven combinando la API de indicaciones con CSS; si hay demanda se pueden ampliar capacidades de animación. Ciertos APIs son verbosos a propósito para dar control; siempre puedes crear wrappers reutilizables. Hay soporte LSP, resaltado y plugins IDE para plantillas, y mi prioridad es mejorar la documentación y herramientas específicas del framework.
Licencia y modelo económico. El framework es un producto comercial pero gratuito para desarrollo y uso en producción no comercial. Está licenciado bajo BUSL-1.1 de modo que cada versión se convierte en código abierto cuatro años después del lanzamiento. La intención es garantizar sostenibilidad, soporte y mejora continua sin sacrificar accesibilidad para proyectos de investigación y aprendizaje.
En resumen, el proyecto llamado doors propone una forma elemental, controlada y tipada de construir aplicaciones web dinámicas con Go sin depender de NPM, centrada en contenedores dinámicos, estado reactivo y rutas tipadas. Si buscas desarrollar aplicaciones a medida o software a medida con equipos expertos, en Q2BSTUDIO somos especialistas en desarrollo de software, aplicaciones a medida, inteligencia artificial y ciberseguridad y podemos acompañarte desde la idea hasta la puesta en marcha. Conoce nuestros servicios de desarrollo de aplicaciones a medida en desarrollo de aplicaciones y software multiplataforma y nuestras soluciones de inteligencia artificial para empresas en inteligencia artificial y agentes IA. También ofrecemos servicios cloud aws y azure, servicios inteligencia de negocio y Power BI, ciberseguridad y pentesting, automatización de procesos y consultoría para integrar IA en tus productos.
Me interesa tu opinión para mejorar la experiencia de desarrollador y la documentación. Prueba el framework, consulta el tutorial y el repositorio de GitHub y abre issues con dudas o sugerencias. Si trabajas en un proyecto empresarial y necesitas una solución segura, rápida y sin dependencias innecesarias, contacta con Q2BSTUDIO para llevarlo a producción con la mejor tecnología y experiencia en inteligencia artificial, ciberseguridad y servicios cloud.
.jpg)
.jpg)