svelte-kit-vice/routes/web/marketing.md

Active Ecosystem

Enfoque de contenido

Active es un ecosistema para construir aplicaciones Svelte con una separacion clara entre runtime de aplicacion y runtime de interfaz.

La forma mas honesta de venderlo en la web es esta:

Active no es solo una coleccion de componentes. Es una arquitectura de producto para crear aplicaciones reactivas, semanticas y mantenibles, con un nucleo pequeño, servicios opt-in e interfaces que entienden lo que ocurre.

El ecosistema se divide en dos areas principales:

• ActiveApp: el runtime de aplicacion. Organiza servicios, preferencias, logging, eventos, sesiones, almacenamiento, permisos, cache, HTTP, conexiones y orquestacion.
• ActiveUix: el runtime de interfaz. Define componentes desde contratos estructurales, comportamiento headless, semantica de eventos, accesibilidad, preferencias sensoriales y capa visual.

La venta debe apoyarse en una idea central: Active reduce acoplamiento sin renunciar a una experiencia rica. Cada modulo tiene una responsabilidad concreta, cada servicio se declara de forma explicita y la interfaz deja de ser una suma de divs para convertirse en una superficie semantica.

Mensaje principal

Claim corto

Construye aplicaciones que saben que estan haciendo.

Subclaim

Un ecosistema Svelte para componer servicios de aplicacion e interfaces semanticas con contratos claros, dependencias limitadas y una arquitectura preparada para crecer sin convertirse en una masa de estado, estilos y efectos.

Hero copy

Active Ecosystem

Aplicaciones reactivas, interfaces semanticas y servicios componibles sobre un nucleo pequeño.

Active une dos capas complementarias:

• ActiveApp, para el runtime, los servicios y la orquestacion de la aplicacion.
• ActiveUix, para componentes accesibles, visuales y semanticamente expresivos.

El resultado es una base de producto donde el estado, los eventos, las preferencias, los estilos y los servicios no compiten entre si: colaboran bajo contratos explicitos.

CTAs sugeridos

• Explorar ActiveApp
• Ver ActiveUix
• Revisar arquitectura
• Abrir componentes
• Ver modulos

Propuesta de valor

Active esta pensado para equipos que necesitan algo mas que una libreria visual. El objetivo no es solo pintar componentes bonitos, sino construir una plataforma de aplicacion donde cada parte tenga un lugar:

• los servicios viven en ActiveApp,
• la estructura de los componentes vive en Morfo,
• el comportamiento vive en Soma,
• la semantica de eventos vive en Sema,
• la experiencia visual vive en Eidos,
• las mutaciones DOM transversales pasan por ADom,
• la composicion global ocurre en ActiveUix.

Esta separacion permite evolucionar la aplicacion sin meter autenticacion, cache, permisos, validacion, temas, componentes, sonidos, haptica, foco y eventos en el mismo saco.

Las dos areas del ecosistema

ActiveApp

ActiveApp es la capa de composicion de aplicacion. Su trabajo es crear un runtime estable y predecible, con un core fijo y servicios declarados de forma explicita.

El core de ActiveApp cubre:

• Logger: diagnostico, niveles, transporte y eventos de observabilidad.
• Bus: comunicacion interna tipada entre partes del runtime.
• Timers: planificacion determinista para intervalos, timeouts y tareas reactivas.
• Orca: orquestacion de flujos y presets de aplicacion.
• Prefs: preferencias transversales como direccion, movimiento, sonido y haptica.

Sobre ese core se componen servicios opt-in. Si una aplicacion no declara cache, auth o connections, esos servicios no existen en su superficie publica. La arquitectura evita cargar capacidad por defecto solo porque podria usarse algun dia.

Servicios destacados de ActiveApp

• Langs: internacionalizacion, codigos BCP47, plurales, textos y referencias localizadas.
• Format: numeros, moneda, unidades, fechas y formatos dependientes de locale.
• ADom: escritura DOM controlada para atributos, preferencias, scroll lock y entorno visual.
• Clipboard: capacidad de copia con adaptadores inyectables.
• Sium: validacion de esquemas, issues tipados, introspeccion y compatibilidad con contratos de schema.
• Storage: almacenamiento reactivo, adaptadores, migraciones, TTL, validacion y sincronizacion.
• HTTP: resultados tipados, hooks, retry, timeouts, validacion y fetch compatible con SvelteKit.
• Session: adopcion, refresh, revocacion, rescate de 401 y puente SSR/cookie.
• Connections: realtime, transports, reconexion, heartbeat, channels y request/reply.
• Auth: flujos de autenticacion, CSRF, sesiones, dispositivos y handlers de servidor.
• Perm: autorizacion, politicas, snapshots, cache de permisos y helpers de UI.
• Cache: claves, scopes, politicas, stale/revalidate, tags y adaptadores.

Argumento de venta

ActiveApp da una forma clara de montar el backend emocional de la aplicacion: todo eso que no se ve en una captura, pero que decide si el producto escala bien o se rompe por dentro.

No obliga a usar todos los modulos. Permite componer solo los servicios necesarios, con errores tipados, diagnostico comun y dependencias visibles.

ActiveUix

ActiveUix es la capa donde la interfaz se vuelve sistema. No se limita a exportar componentes: define como se estructuran, como se comportan, como emiten significado, como se tematizan y como se integran con preferencias globales de la aplicacion.

ActiveUix organiza la UI en capas:

• Morfo: contrato estructural de cada componente.
• Soma: comportamiento headless, estado, foco, teclado, puntero y accesibilidad.
• Sema: semantica de eventos, intenciones, familias y canales sensoriales.
• Eidos: capa visual, tokens, temas, recetas y CSS.
• ADom: ejecucion controlada de mutaciones transversales en el DOM.
• ActiveUix: composicion de servicios UI y puente con ActiveApp.

Argumento de venta

ActiveUix permite crear componentes que no dependen de una estetica fija ni de una demo aislada. Un componente tiene contrato DOM, semantica, comportamiento, accesibilidad y visualizacion por capas.

Eso permite cambiar el tema sin cambiar el comportamiento, cambiar el comportamiento sin romper la semantica y conectar eventos visuales, sonoros o hapticos sin mezclar efectos dentro del componente.

La arquitectura semantica

Uno de los puntos diferenciales de ActiveUix es que los eventos no son solo callbacks.

Sema define un vocabulario para expresar que ha pasado y como deberia sentirse:

• Familias: contacto, confirmacion, señal, manejo, aparicion, cambio y sostenimiento.
• Intenciones: neutral, afirmacion, cumplimiento, riesgo, amenaza y perdida.
• Canales: visual, sonido y haptica.

Un boton no solo ejecuta onClick. Puede emitir una accion de contacto, una confirmacion, una señal de riesgo o una respuesta de cumplimiento. Esa informacion se puede proyectar a:

• atributos data-event-* temporales,
• animaciones visuales,
• feedback sonoro,
• feedback haptico,
• logs de interaccion,
• pruebas de comportamiento.

Esta capa semantica es clave para vender ActiveUix como algo superior a un kit visual. La interfaz no solo muestra estado: comunica significado.

Morfo: contratos antes que improvisacion

Morfo define la forma publica de los componentes:

• partes del componente,
• atributos data-*,
• estados DOM,
• roles ARIA,
• reglas de foco,
• eventos esperados,
• textos y traducciones,
• variantes estructurales.

La idea comercial:

Cada componente tiene una anatomia documentada. No dependes de mirar el CSS o el HTML generado para entender como integrarlo, testearlo o extenderlo.

Morfo es especialmente importante para una web de marketing porque permite explicar que ActiveUix no vende componentes opacos. Vende componentes con contrato.

Soma: comportamiento sin encierro visual

Soma contiene el comportamiento de los componentes:

• estado,
• contexto,
• navegacion por teclado,
• puntero,
• focus management,
• accesibilidad,
• seleccion,
• apertura/cierre,
• sincronizacion con formularios,
• emision de eventos semanticos.

La venta:

Soma permite que la logica de un componente sea reutilizable y testeable sin atarla a una capa visual concreta.

Esto habilita componentes headless, adaptables a temas, densidades, modos y experiencias distintas.

Eidos: visuales con contrato

Eidos es la capa visual del ecosistema UIX. Gestiona:

• tokens,
• temas,
• modos claro/oscuro,
• densidades,
• roles visuales,
• recetas de componente,
• CSS generado o externo,
• custom properties,
• adaptacion visual desde atributos DOM.

La clave de venta:

Eidos no secuestra la interfaz. La estiliza a partir de contratos.

Un componente puede exponer estados por Morfo y Soma, emitir significado por Sema y dejar que Eidos traduzca todo eso en una experiencia visual consistente.

ActivePrefs: preferencias transversales

Active separa preferencias transversales y preferencias visuales:

• Direccion: ltr o rtl.
• Motion: comportamiento de movimiento y reduccion de animacion.
• Sound: activacion o silencio de feedback sonoro.
• Haptic: activacion o desactivacion de feedback tactil.
• Theme, mode y density: pertenecen a Eidos como preferencias visuales.

Esta separacion evita que el sistema visual se convierta en dueño de toda la experiencia. La app puede decidir preferencias globales, y la UI puede interpretarlas sin acoplarse al resto del runtime.

Dependencias limitadas

Active esta pensado con una filosofia de dependencias contenidas:

• nucleo pequeño,
• servicios opt-in,
• imports separados por capas,
• factories explicitas,
• contratos antes que dependencias directas,
• separacion entre runtime de aplicacion y runtime de interfaz,
• modulos que no aparecen en el tipo publico si no se declaran,
• integraciones por adaptadores cuando una capacidad depende del entorno.

La idea para la web:

Active no intenta ganar por acumulacion. Gana por composicion.

En lugar de arrastrar auth, cache, permisos, realtime, validacion y componentes en un unico paquete mental, cada modulo tiene una entrada clara y una responsabilidad concreta.

Observabilidad y diagnostico

Active usa logging y diagnostico como parte de la arquitectura, no como un añadido posterior.

Puntos a destacar:

• logger compartido,
• eventos diagnosticos tipados,
• catalogos de errores,
• servicios con estado absent, present o failed,
• errores especificos por artefacto,
• integracion con flujos de aplicacion,
• capacidad de registrar fallos de configuracion, validacion o entorno.

Para venderlo:

Cuando una aplicacion crece, no basta con que funcione. Tiene que explicar que esta pasando.

SSR, cliente y servidor

Active diferencia entre motores de cliente, servicios activos y contrapartes de servidor cuando tiene sentido.

Ejemplos:

• autenticacion con handlers de servidor,
• permisos con motor y politicas,
• cache con contratos de scope y revalidacion,
• HTTP compatible con SvelteKit,
• sesion capaz de integrarse con cookies y SSR,
• conexiones realtime con puente de sesion.

Esto permite presentar Active como una base para aplicaciones reales, no solo para demos de componentes.

Modulos del ecosistema

ActiveApp Core

Modulo	Papel	Mensaje para web
Logger	Diagnostico comun	Observabilidad integrada desde el inicio.
Bus	Comunicacion interna	Eventos internos sin acoplar modulos.
Timers	Planificacion	Tareas reactivas y temporales bajo control.
Orca	Orquestacion	Flujos y presets componibles para la app.
Prefs	Preferencias transversales	Direccion, motion, sound y haptic sin mezclar UI y app.

Servicios ActiveApp

Modulo	Papel	Mensaje para web
Langs	Idioma y textos	Internacionalizacion como servicio activo.
Format	Formatos regionales	Numeros, moneda, unidades y fechas coherentes con locale.
ADom	DOM transversal	Mutaciones globales controladas, no efectos dispersos.
Clipboard	Copia	Capacidades del navegador encapsuladas.
Sium	Validacion	Schemas, issues e introspeccion con contratos tipados.
Storage	Persistencia	Almacenamiento reactivo, validado y migrable.
HTTP	Red	Resultados tipados, retry, timeout, hooks y validacion.
Session	Sesion	Refresh, adopcion, revocacion y rescate de sesion.
Connections	Realtime	Canales, reconexion, heartbeat y mensajeria.
Auth	Autenticacion	Flujos de login, CSRF, dispositivos y handlers.
Perm	Permisos	Politicas, autorizacion y helpers de UI.
Cache	Cache	Revalidacion, tags, scopes y adaptadores.

ActiveUix

Capa	Papel	Mensaje para web
Morfo	Anatomia del componente	Contrato DOM, partes, datos, ARIA y estructura.
Soma	Logica headless	Estado, foco, teclado, puntero y accesibilidad.
Sema	Semantica de eventos	Interacciones con familia, intencion y canal.
Eidos	Visual system	Tokens, temas, recetas y CSS por contrato.
ADom	Mutacion DOM	Aplicacion controlada de preferencias y atributos.
ActiveUix	Composicion UI	Runtime de interfaz conectado o standalone.

Diferenciadores

Frente a una libreria de componentes tradicional

Una libreria clasica suele partir del aspecto visual. ActiveUix parte del contrato:

• primero define la anatomia,
• despues el comportamiento,
• despues la semantica,
• despues la expresion visual.

Eso reduce el riesgo de que cada componente invente sus propios atributos, estados, eventos y convenciones.

Frente a un framework de aplicacion cerrado

ActiveApp no fuerza una unica forma de aplicacion. Propone una composicion explicita:

• core estable,
• servicios declarados,
• factories por capacidad,
• lazy loading cuando procede,
• diagnostico compartido,
• tipos que reflejan lo que realmente se ha instalado.

La app no tiene que cargar con modulos que no usa.

Frente a una capa visual sin runtime

Un sistema de tokens por si solo no resuelve:

• sesion,
• permisos,
• cache,
• validacion,
• logging,
• conexiones,
• preferencias,
• semantica de eventos,
• comportamiento headless.

Active ofrece una historia completa: aplicacion mas interfaz.

Mensajes por audiencia

Para producto

Active permite construir experiencias coherentes sin rediseñar la arquitectura cada vez que aparece un nuevo requisito. El producto puede crecer en modulos: autenticacion, permisos, cache, internacionalizacion, realtime o feedback sensorial sin mezclar responsabilidades.

Para frontend

ActiveUix da componentes con anatomia, comportamiento, semantica y visuales separados. Eso ayuda a testear, tematizar, adaptar y mantener interfaces complejas sin convertir cada componente en una pieza aislada.

Para arquitectura

ActiveApp centraliza servicios y observabilidad bajo contratos explicitos. Las dependencias son visibles, los servicios son opt-in y el tipo publico de la app refleja lo que se ha compuesto.

Para diseño

Eidos permite que el sistema visual lea estados y contratos, no implementaciones internas. Los temas, densidades y modos se aplican sobre una estructura comun.

Para accesibilidad

Soma y Morfo colocan foco, teclado, roles, atributos y estados en el centro del componente. La accesibilidad no es una revision final: forma parte de la arquitectura.

Copy reutilizable para la web

Bloque 1: dos areas, un ecosistema

Active se divide en dos areas que trabajan juntas:

ActiveApp organiza los servicios de aplicacion. ActiveUix organiza la experiencia de interfaz.

Una se ocupa de la infraestructura viva del producto. La otra se ocupa de que cada componente tenga estructura, comportamiento, semantica y visuales coherentes.

Bloque 2: servicios opt-in

No todos los proyectos necesitan las mismas capacidades. Active permite declarar solo los servicios que la aplicacion necesita: auth, cache, permisos, HTTP, storage, session, realtime, format o langs.

Si un servicio no se declara, no contamina la superficie publica de la app.

Bloque 3: interfaz semantica

ActiveUix entiende que una interaccion no es solo un click. Puede ser contacto, confirmacion, riesgo, perdida, exito o cambio sostenido.

Esa semantica puede alimentar visuales, sonido, haptica, diagnostico y pruebas.

Bloque 4: visuales sin acoplamiento

Eidos convierte contratos en experiencia visual. Los componentes no tienen que esconder su estado ni atarse a un tema concreto. Exponen datos, roles y eventos; la capa visual los interpreta.

Bloque 5: arquitectura que se puede explicar

Active esta organizado para que cada parte pueda explicarse:

• que responsabilidad tiene,
• de quien depende,
• que expone,
• que eventos emite,
• que errores produce,
• como se integra con el resto.

Esa claridad es parte del producto.

Posibles titulares

• Build applications that know what they are doing.
• A small core for serious applications.
• Semantic UI for reactive products.
• Application services and interface semantics, composed.
• Less accidental coupling. More intentional runtime.
• Interfaces with structure, behavior, meaning and visual coherence.
• ActiveApp for the runtime. ActiveUix for the experience.

Posibles subtitulos

• Compose application services and semantic interfaces without turning your frontend into a knot.
• A Svelte ecosystem for product-grade applications, explicit services and accessible components.
• Runtime, services, events, preferences and visual systems under clear contracts.
• Build with a small core, opt-in modules and UI components that expose meaning, not just markup.

Secciones recomendadas para landing

1. Hero

Presentar Active como ecosistema de aplicacion e interfaz.

Contenido clave:

• ActiveApp + ActiveUix.
• Core pequeño.
• Servicios opt-in.
• UI semantica.
• Contratos explicitos.

2. Two areas

Comparar las dos areas sin enfrentarlas:

• ActiveApp: servicios y runtime.
• ActiveUix: componentes y experiencia.

3. Why it matters

Explicar el problema:

• apps con demasiadas dependencias ocultas,
• componentes que mezclan logica, estilos y efectos,
• eventos sin semantica,
• temas que no entienden estado,
• servicios duplicados por pantalla.

4. ActiveApp modules

Mostrar los servicios como tarjetas:

• Langs,
• Logger,
• Timers,
• Format,
• ADom,
• Clipboard,
• Sium,
• Storage,
• HTTP,
• Session,
• Connections,
• Auth,
• Perm,
• Cache.

5. ActiveUix layers

Mostrar la cadena:

Morfo declara. Soma comporta. Sema significa. Eidos expresa. ADom aplica. ActiveUix compone.

6. Semantic events

Explicar Sema con ejemplos de intencion y canal:

• una accion afirmativa puede tener visual feedback,
• una accion de riesgo puede emitir una señal distinta,
• una interaccion sostenida puede activar estados temporales,
• sound/haptic pueden respetar preferencias globales.

7. Limited dependencies

Presentar la filosofia:

• usar poco por defecto,
• declarar lo necesario,
• aislar capacidades,
• evitar paquetes monoliticos,
• adaptar entorno por factories.

8. Designed for Svelte

Explicar que Active abraza Svelte 5 y su modelo reactivo, pero sin meter todo en componentes visuales. La app mantiene servicios activos fuera del arbol visual cuando corresponde.

9. For real products

Cerrar con el mensaje de producto:

Active esta pensado para aplicaciones que necesitan crecer con sesion, permisos, cache, validacion, internacionalizacion, realtime, preferencias y componentes complejos sin perder claridad.

Frases guia

Usar:

• "contratos explicitos"
• "servicios opt-in"
• "runtime de aplicacion"
• "runtime de interfaz"
• "interacciones semanticas"
• "dependencias contenidas"
• "composicion por capacidades"
• "visual layer sobre contratos"
• "headless behavior"
• "diagnostico integrado"
• "preferencias transversales"

Evitar:

• "framework total"
• "todo incluido"
• "sin dependencias" si no es literalmente cierto
• "magico"
• "automatico" cuando depende de configuracion
• "solo componentes"
• "design system" como unica definicion

Pitch corto

Active es un ecosistema Svelte dividido en dos areas: ActiveApp y ActiveUix.

ActiveApp compone el runtime de aplicacion con un core pequeño y servicios opt-in como langs, logger, timers, format, storage, HTTP, session, auth, permisos, cache y conexiones.

ActiveUix compone la experiencia de interfaz con Morfo, Soma, Sema y Eidos: contratos DOM, comportamiento headless, eventos semanticos y visuales basados en tokens.

La propuesta es construir productos con menos acoplamiento accidental, mas observabilidad y una UI que no solo renderiza estado, sino que expresa significado.

Pitch medio

Active es una base de arquitectura para aplicaciones Svelte que separa dos responsabilidades que a menudo se mezclan: el runtime de aplicacion y el runtime de interfaz.

Con ActiveApp, la aplicacion declara los servicios que necesita y obtiene un nucleo consistente para logging, eventos, timers, preferencias y orquestacion. A partir de ahi puede componer modulos como internacionalizacion, formatos, storage, HTTP, sesion, auth, permisos, cache o realtime sin convertir la app en un bloque monolitico.

Con ActiveUix, los componentes se construyen por capas: Morfo define su contrato, Soma su comportamiento, Sema el significado de sus eventos y Eidos su expresion visual. Esta separacion hace que la interfaz sea mas accesible, testeable, adaptable y coherente.

Active no vende acumulacion de features. Vende composicion, semantica y claridad.

Pitch largo

Active es un ecosistema para crear aplicaciones Svelte con una arquitectura preparada para producto. Su nucleo se divide en dos areas: ActiveApp y ActiveUix.

ActiveApp se encarga de la vida interna de la aplicacion: servicios, preferencias, diagnostico, orquestacion, almacenamiento, red, sesion, permisos, cache, auth y conexiones. Su enfoque es declarativo y opt-in: la aplicacion compone las capacidades que necesita, y cada servicio mantiene una responsabilidad clara.

ActiveUix se encarga de la experiencia de interfaz. En lugar de tratar los componentes como piezas visuales aisladas, los divide en capas. Morfo define la anatomia y el contrato DOM. Soma implementa el comportamiento headless, la accesibilidad y el control de estado. Sema transforma las interacciones en eventos con significado. Eidos convierte tokens, temas y atributos en experiencia visual.

Esta estructura permite construir aplicaciones con interfaces mas expresivas, menos dependencias ocultas y una separacion real entre estado, comportamiento, semantica y estilo.

Active es especialmente util cuando una aplicacion necesita crecer: mas idiomas, mas permisos, mas sesion, mas cache, mas componentes, mas preferencias, mas integraciones. El ecosistema ayuda a que ese crecimiento ocurra por composicion, no por acumulacion accidental.

Claim final

ActiveApp organiza la aplicacion. ActiveUix da significado a la interfaz.

Juntos forman un ecosistema para construir productos Svelte con servicios explicitos, componentes semanticos, visuales coherentes y una arquitectura que se puede mantener.