Cómo construimos un marketplace completo sin frameworks frontend

El punto de partida

Cuando empezamos a construir BKLN Marketplace, teníamos una decisión por delante: ¿React, Vue, o vanilla JS? La respuesta no fue obvia al principio, pero terminó siendo la que más nos enseñó.

El proyecto era ambicioso: una plataforma C2C orientada al mercado de África Central, con moneda XAF, autenticación múltiple, mensajería en tiempo real, sistema de suscripciones y panel de administración. Nada trivial.

Elegimos JavaScript puro. Sin frameworks. Sin bundlers. Sin toolchain.

Por qué vanilla JS

La razón principal no fue filosófica — fue práctica.

El mercado objetivo usa dispositivos modestos con conexiones variables. Cada kilobyte cuenta. Un bundle de React con sus dependencias, hidratación y runtime ya pesa varios cientos de KB antes de escribir una sola línea de lógica de negocio.

Con vanilla JS, el navegador ya trae el runtime. No hay nada que cargar, compilar ni hidratar. La primera interacción ocurre en milisegundos.

La segunda razón: queríamos entender a fondo lo que estaba pasando. Con un framework, cuando algo falla en producción, a veces no sabes si el problema es tuyo o de la librería. Sin framework, el código es completamente tuyo.

Mensajería en tiempo real sin librerías de estado

El mayor desafío técnico fue el chat entre compradores y vendedores. En un stack moderno lo típico es usar un hook de React con un store de Zustand o Redux. Nosotros no teníamos nada de eso.

La solución fue Supabase Realtime Channels: suscripción directa a cambios en la tabla de mensajes con RLS (Row Level Security) garantizando que cada usuario solo recibe sus propios mensajes.

const channel = supabase
  .channel(`chat:${conversationId}`)
  .on('postgres_changes', {
    event: 'INSERT',
    schema: 'public',
    table: 'messages',
    filter: `conversation_id=eq.${conversationId}`
  }, (payload) => {
    appendMessage(payload.new)
  })
  .subscribe()

El cleanup lo hacemos manualmente al salir de la vista. Sin useEffect, sin dependencias. Solo lógica.

Autenticación multi-método en un flujo unificado

Soporte para tres métodos: email/contraseña, OTP por SMS y Google OAuth. El reto era presentar los tres en una sola pantalla sin que pareciera un formulario de gobierno.

La solución fue una interfaz de tabs animados con un solo contenedor que cambia de estado. El error de cada método se muestra inline, no como un alert genérico. Si introduces un email ya registrado, el sistema te sugiere directamente hacer login en vez de darte un error críptico.

El sistema de planes sin pasarelas de pago

Quisimos evitar depender de Stripe o cualquier otra pasarela de pago externa para la activación de planes premium. En mercados emergentes, las tasas de conversión caen drásticamente si obligas a usar tarjeta.

El modelo que construimos: el cliente pide el plan, nosotros generamos un código de activación desde el panel de administración, el cliente paga por el canal que prefiera (transferencia, efectivo, móvil) y nosotros activamos el código.

Un objeto PLAN_LIMITS centralizado controla qué puede hacer cada usuario según su plan activo. Un solo lugar donde tocar cuando cambian las reglas de negocio.

Lo que repetiríamos y lo que cambiaríamos

Repetiríamos: la decisión de vanilla JS para este contexto específico. El rendimiento en dispositivos modestos es notablemente mejor. El código es predecible y fácil de depurar.

Cambiaríamos: la gestión del estado global. Sin un sistema de reactividad, acabas con event emitters caseros y funciones de "re-render" manuales en algunos sitios. No es insostenible, pero escala peor que un sistema reactivo bien pensado.

Para proyectos donde el rendimiento en dispositivos lentos no es crítico, un framework moderno sigue siendo la opción más productiva. El contexto manda.

Conclusión

Construir BKLN Marketplace sin frameworks nos obligó a entender cada pieza que normalmente damos por sentada. La mensajería en tiempo real, la gestión de estado, el routing por hash, la reactividad — todo implementado a mano.

¿Lo recomendamos para todos los proyectos? No. ¿Valió la pena para este? Absolutamente.