5 min de lectura
Cómo hacemos nopa, parte 2
En la primera parte prometí abrir el capó. Aquí está: por qué nopa no tiene backend, cómo cabe el trabajo pesado en una pestaña del navegador, dónde vive lo que haces — y cómo comprobar cada palabra de esto tú mismo en un minuto.
No hay adónde subir nada
Casi todos los sitios de herramientas son una página delante de un servidor: tu archivo sube, el servidor hace el trabajo y el resultado vuelve. nopa funciona al revés. El sitio son archivos estáticos —HTML, JavaScript, fuentes— y es el código el que viaja hasta ti, no tu archivo hasta él. Cuando unes dos PDF, la unión ocurre en tu pestaña y el PDF no sale de ella.
Por eso tampoco hay cuenta. Una cuenta existe para guardar algo tuyo en un servidor, y no hay ningún servidor guardando nada: no hay dónde iniciar sesión.
El trabajo pesado, en una pestaña
El navegador se ha vuelto una máquina seria, y cada herramienta usa la parte que encaja con su tarea:
- PDF: pdf-lib construye y reescribe el archivo, PDF.js dibuja las páginas que ves. Comprime un PDF y los dos funcionan en tu dispositivo.
- Fotos y audio: las redes neuronales funcionan en WebAssembly sobre ONNX Runtime. Las herramientas para quitar el fondo y transcribir audio descargan su modelo una vez y lo guardan; tu foto va al modelo, nunca al revés.
- Escaneos: tesseract.js lee el texto de una página escaneada en un hilo aparte. La primera vez descarga un modelo de lectura de 4–5 MB; después ya está ahí.
- Archivos de Word: mammoth lee un .docx y docx lo vuelve a escribir, así que el editor de Word abre el contrato que te enviaron y te lo devuelve como un archivo de Word de verdad.
- Juegos: jsnes ejecuta una NES entera en JavaScript. La página de NES trae dos juegos homebrew cuyos autores lo permiten, y juega tu propio archivo .nes sin subirlo.
El precio: el código tiene que llegar hasta ti
Tiene su contrapartida. Una herramienta de servidor te manda una página ligera y hace lo pesado donde no lo ves; nosotros tenemos que mandarte lo pesado a ti. Así que lo medimos: un script de nuestro repositorio abre cada página en un navegador real y suma el JavaScript que descarga antes de que pulses nada. La primera pasada encontró páginas que cargaban 1,4 MB para nada; la historia completa, con cifras, está en un artículo anterior.
La regla desde entonces: un motor se carga cuando se pulsa su botón. El motor de PDF llega cuando abres un PDF; el modelo de lectura, cuando pides leer un escaneo. Esta semana la regla atrapó otro caso: la pizarra descargaba una biblioteca de PDF de 170 KB cada vez que se abría, por una sola opción del menú.
Dónde vive tu trabajo
Lo que guardas —una pizarra, una lista de tareas, un documento, los archivos que producen las herramientas— va a IndexedDB, la base de datos del propio navegador, en tu dispositivo. Las aplicaciones guardan mientras trabajas: cierras la pestaña y todo sigue donde lo dejaste.
La parte honesta: ese almacenamiento pertenece a este navegador. Borra los datos del sitio y desaparece; coge el móvil y ahí no está. Por eso la copia de seguridad está a un clic —todo el escritorio en un solo archivo, en Ajustes → Datos—, y en esa misma pantalla puedes pedir al navegador que no borre nopa cuando falte espacio en el disco.
Sin conexión, después de la primera visita
Un service worker guarda una copia de la aplicación en tu dispositivo, así que, una vez abierto nopa, las herramientas se abren sin conexión. No todo se guarda de antemano: los modelos de redes neuronales y el de lectura se descargan solo cuando una herramienta los necesita, porque un móvil no debería cargar con cien megas de modelos por si acaso.
Compruébalo tú mismo
Abre las herramientas de desarrollo del navegador, ve a la pestaña Network y usa cualquier herramienta. Verás dos tipos de peticiones: nuestro propio código llegando desde nopa.space y estadísticas de visitas para Yandex Metrica y PostHog —qué página se abrió, qué herramienta se usó—. No verás tu archivo yendo a ninguna parte, porque no va. Un bloqueador de contenido apaga las estadísticas y todas las herramientas funcionan igual.
Una vez nos equivocamos nosotros mismos. El panel de nuestras páginas de producto prometía «ni un solo POST»: se midió en una versión sin estadísticas, y en producción el contador envía sus propios POST. Un lector lo habría pillado en diez segundos; lo pillamos esta semana y reescribimos el panel para que diga exactamente lo que verás.
Lo que este diseño no puede hacer
Un servidor hace cosas que una pestaña no puede, y preferimos decirlo:
- No hay sincronización. Tu móvil y tu portátil guardan cada uno su copia; un archivo de copia la traslada, un enlace en vivo no existe.
- No hay colaboración en tiempo real. Dos personas editando una pizarra necesitan un servidor entre ellas.
- La primera vez, una herramienta de IA espera a que se descargue su modelo.
- Un móvil es más lento que un centro de datos. Casi todo tarda un momento; una hora de audio tarda un rato.
Qué viene
Si algo falla en tu dispositivo o necesitas una herramienta que no tenemos, escribe a hello@nopa.space: lo lee una persona. O empieza por el catálogo; la primera parte, sobre por qué existe nopa, está aquí.