MyVisor
Lector Markdown centrado en la experiencia de lectura
"Un lector de Markdown deployado como web app. Permite leer documentos desde una biblioteca pública sin registro, o abrir archivos locales con la File System Access API. Experiencia editorial, privada y sin fricción."
El punto de partida del desafío
Hurgando bajo la superficie: ¿Qué investigué?
Revisé alternativas como Obsidian, Typora, Notion, VitePress, Docusaurus y lectores de EPUB. Observé que la lectura era siempre una función secundaria frente al editor de texto. Casi todas las soluciones almacenaban datos en servidores externos o requerían telemetría. Y el diseño visual de los lectores Markdown era sumamente genérico: fondos blancos planos, tipografías estándar y layouts rígidos. Entendí que el problema no era Markdown, sino la experiencia de lectura. Quería construir algo que tratara al texto con el respeto visual de una publicación editorial.
"Cuando el producto existe para consumir contenido, el diseño deja de ser decoración y pasa a ser funcionalidad pura. Decidí diseñar una solución basada en tres principios innegociables: privacidad absoluta (los archivos nunca salen del navegador), lectura ergonómica prolongada (tipografía, ritmo, contraste y ancho de línea controlados) y simplicidad radical (cero backend, cero cuentas, carga instantánea). La experiencia no necesitaba features. Necesitaba atmósfera y foco."
Comprender este pilar transformó por completo la dirección táctica del proyecto, permitiendo depurar el ruido innecesario y enfocarse en valor estricto.
Análisis de compromisos: opciones sobre la mesa
Construir software a medida requiere evaluar escenarios honestamente. Ninguna arquitectura es perfecta, cada decisión tiene un precio:
Opción A: Plugin de Obsidian
Gran ecosistema, pero el foco de la interfaz está en la edición y tiene telemetría. La lectura seguía sintiéndose como una función secundaria.
Opción B: Custom theme de Typora
Buena experiencia de lectura, pero es de pago y no permite abrir carpetas locales completas para navegación fluida entre documentos.
Opción C: Aplicación web propia con Vanilla JS
Control absoluto del diseño. Privacidad 100% verificable. Experiencia diseñada exclusivamente para lectura. Sin dependencias externas.
La Decisión: El camino elegido
LO QUE FUNCIONÓ DE VERDAD
La biblioteca pública logró exactamente lo que buscaba: subo mis apuntes de programación, entro desde el celular o la compu y los leo sin fricción. La performance es instantánea al no cargar runtime de frameworks ni hidrataciones. La barra de progreso, simple pero efectiva, mejoró la experiencia de lectura prolongada. Y el diseño tipográfico con serif y márgenes amplios logró recrear la sensación física de leer un libro, haciendo que las sesiones largas de lectura fueran placenteras en pantalla.
LIMITACIONES Y COMPROMISOS
La File System Access API solo funciona en navegadores basados en Chromium (Chrome, Edge, Opera, Brave). Para Firefox y Safari agregué un fallback de archivo suelto, pero no pueden abrir carpetas completas. Al ser JS puro sin framework, no hay enrutamiento profundo, persistencia remota ni tipado estático. La ausencia de TypeScript fue una decisión deliberada para mantener el código mínimo, pero sacrifica robustez. El alcance se limitó exclusivamente a lectura: sin edición, sin búsqueda dentro de documentos, sin sincronización. Y la biblioteca pública requiere regenerar el índice manualmente cada vez que agrego o modifico documentos.
DE LA BITÁCORA PERSONAL DE GONZALO: ¿QUÉ HARÍA DIFERENTE HOY?
"Migraría el código a TypeScript para ganar robustez sin sacrificar lo mínimo del output. Optimizaría Highlight.js para que cargue solo los lenguajes que usa cada documento, bajando el peso del bundle. Y sumaría un modo foco que oculte todo el chrome del navegador para sesiones largas de lectura."
Anotación retrospectiva posterior al lanzamiento