3 puntos por GN⁺ 2025-03-16 | 2 comentarios | Compartir por WhatsApp
  • Nash es una nota independiente basada en HTML que se abre y edita en el navegador web sin necesidad de un servicio aparte
  • Las notas guardadas se pueden modificar incluso sin conexión, con el objetivo de tratarlas como archivos de documento en lugar de usar Notion o Word
  • Puede utilizarse para crear contenido en formato de documento HTML, como blogs estáticos, contenido de una sola página o adjuntar fotos de pizza desde una galería
  • Al enviarlo por mensajería, puede verse como vista previa, lo que permite compartir contenido largo como si fuera un archivo
  • Nash está publicado como open source, y se puede modificar y usar libremente una página de nota en blanco

Notas HTML usando solo el navegador

  • Nash es una nota independiente orientada a note as HTML
  • No requiere software ni servicios adicionales; basta con un navegador web, que normalmente ya está instalado
  • Las notas guardadas admiten edición sin conexión
  • Se puede abrir una nota en blanco en nash.html

Contenido que se puede crear y formas de compartirlo

  • Puede usarse para crear blogs estáticos o contenido de una sola página
  • También permite crear contenido adjuntando fotos de una galería
  • Si se envía por mensajería, puede verse como vista previa, por lo que sirve para compartir contenido largo
  • Surgió de la experiencia de hacer POC de ideas simples en un solo HTML, y es un primer intento de crear un archivo de documento que funcione sin servicios ni software adicionales
  • Nash está publicado como open source, por lo que puede modificarse y usarse libremente

2 comentarios

 
xguru 2025-03-16

Nash, una nota que funciona como un único HTML

Lo habían publicado en Show GN y también lo subieron a Hacker News; recibió muchos votos. ¡Felicidades!

 
GN⁺ 2025-03-16
Opiniones de Hacker News
  • Una buena parte del trabajo pesado la resuelve un solo atributo HTML simple pero potente, y sorprende que no tantos desarrolladores parezcan conocerlo.
    Es una función que existe desde hace bastante tiempo.

    • Esta sola línea representaba casi el 90% de la implementación inicial de Writely.
      Writely fue la startup que después se convirtió en Google Docs; lo digo como uno de sus fundadores.
      El otro 90% era código de backend que tuvimos que escribir para sincronizar correctamente las ediciones, porque cada navegador tenía distintos bugs raros en su implementación de contenteditable :-)
    • Realmente impresionante. Incluso alrededor de 2016 seguía haciendo muchos sitios personalizados para pymes, y me di cuenta de que la mayoría podía hacerse con algo como WP.
      Pero (1) dar estilo en WP era demasiado tedioso y no quería mantenerlo, (2) no quería depender de funciones de plugins ni de actualizaciones de WP, y (3) quería que personas con distintos permisos pudieran editar distintas partes de la misma página, algo que en la práctica era imposible en la mayoría de los CMS.
      Así que hice un CMS casi desde cero, basado solo en contenteditable y TinyMCE, y puse esa etiqueta en las áreas editables. Por supuesto, antes de guardar, el backend verifica quién puede editar qué.
      Cuando un cliente o empleado inicia sesión, puede editar directamente solo las áreas de la página para las que tiene permisos, y el CMS muestra un borde punteado alrededor de las partes editables. Las fuentes y los colores quedan guardados en la configuración de TinyMCE, así que no hay que revisar ni tocar el HTML. Si quieren, también pueden tocarlo directamente.
      Para el cliente se siente bastante mágico: no tienen que ir a una página de edición separada para ver cómo quedará el cambio; editan en el mismo lugar de la página, guardan y se publica de inmediato.
      La mayoría de esos sitios siguen funcionando 5 a 10 años después, y casi no requieren mantenimiento de mi parte.
    • Hace unas semanas hice una demo en vivo de este concepto. Para ser una función oculta de HTML, es realmente simple y potente.
      https://news.ycombinator.com/item?id=43179649
    • Esto está bueno. Hace tiempo hice un editor de PDF convirtiendo el documento a HTML y luego poniendo contenteditable="true" en el div de nivel superior.
    • Se lee como “oh, aquí hay algo increíble, se llama rueda y existe desde hace bastante tiempo”.
      Creo que ya trabajaba con esto hace 20 años.
      ContentEditable se introdujo por primera vez en IE 5.5 en el año 2000, y para 2007 ya se podía usar en todos los navegadores principales.
  • Me gusta mucho, y al ver el código me gusta aún más que esté hecho con JavaScript puro.
    Hoy se subestima lo mucho que se puede hacer en apps web bastante interactivas sin librerías ni frameworks.
    También me encanta la idea de hacer apps web locales simples como una sola página HTML. Una vez fui con mi hijo a un museo de ciencias, usamos un animador stop-motion sencillo, hice una web app parecida y se la copié a su laptop como un único archivo HTML para que pudiera usarla sin internet.
    Eso sí, como me da flojera escribir JavaScript puro directamente, la hice con React y un bundler, y el resultado queda empaquetado en un solo archivo HTML. Tal vez algún día la suba a Show HN.

    • Así como antes existía “no necesitas jQuery para hacer eso”, ahora hace falta “no necesitas React ni Vue, Svelte ni nada parecido para hacer eso”.
      Con JavaScript puro normal y un nivel decente, casi todo puede hacerse de forma más limpia y más fácil de mantener.
      Después de décadas manteniendo cosas hechas por otros, un diseño tan simple que parece tonto, hecho por alguien inteligente, le gana a las demás combinaciones.
    • Esto es algo que me gusta de Quarto. Permite crear archivos HTML autónomos para compartir con otras personas.
  • Bien hecho.
    Valdría la pena considerar cambiar el comportamiento para que, si la página se abre en el navegador desde el disco local, entre automáticamente en modo edición, y cuando está publicada en el sitio web de alguien y accesible desde la web pública, se muestre como una vista de solo lectura normal. Bastaría con comprobar si la dirección es http/https.
    Por supuesto, debería existir alguna vía alternativa para verla también en modo edición, como un parámetro en la query string o un fragmento de URL mágico.
    Además, debería ser posible definir excepciones para ciertos dominios o prefijos de URL. Si el valor predeterminado fuera keepworking.github.io o <https://keepworking.github.io/nash/>, el modo edición también se activaría en ese sitio y no habría que hacer nada extra para la demo.
    Sería aún mejor si el usuario pudiera modificar esas excepciones. Por ejemplo, así otras personas también podrían obtener el mismo comportamiento sin el truco del punto 1.

    • Me encanta la idea de un sitio web cuyo contenido se puede editar y guardar localmente.
      Personalmente, me parece excelente y ojalá lo dejaran tal como está.
  • Con https://rpdillon.net/redbean-tiddlywiki-saver.html se puede convertir en una app portátil autosuficiente con guardado “real”.

    • Hace tiempo hice algo parecido, y se puede ver en https://original.littr.me.
    • Estaría bueno que pudiera proponer guardar el archivo.
      Eso lo acercaría mucho más a una función para tener marcadores personales cuando uno quiera.
  • Está bueno. Hubo una discusión anterior que mencionaba esta idea y TiddlyWiki.
    https://news.ycombinator.com/item?id=43179649

  • Ojalá los navegadores soportaran mejor las apps web locales.
    Si los archivos locales pudieran acceder fácilmente al almacenamiento persistente, se abrirían muchas oportunidades para apps con GUI rápidas y fáciles. En la práctica, sería lo opuesto a Electron.

    • ¿Cómo puede un archivo acceder a algo? Un archivo es solo datos, así que no puede hacer nada.
  • Genial. Tal vez porque estoy demasiado acostumbrado a escribir la parte de JavaScript de un sitio web fuera del HTML real, la primera vez que lo vi pensé: “wow, qué curioso que se pueda hacer esto solo con HTML”.
    Pero al ver el código fuente, tenía JavaScript dentro de una etiqueta script común y corriente, y eso me hizo recordar de nuevo que también se puede hacer así

    • HTML está subestimado.
      La mayoría de las pantallas que vemos todos los días, incluso los editores de código, son páginas HTML
    • No es algo que necesariamente haya que hacer si quieres separación o control de versiones. Pero sin duda es una forma posible de hacerlo.
      Lo más sorprendente es que la gente use frameworks para meter dentro del HTML cosas que ni siquiera son JavaScript, y además use estructuras donde JavaScript externo se agrega después o tiene que hacer hidratación. Se siente como juntar lo peor de ambos mundos.
      Yo estoy más cerca del extremo opuesto: JavaScript es el centro y, salvo index.html, no tengo archivos con extensión .html. Tampoco meto HTML dentro de JavaScript. Todas las plantillas parciales son .htm y las hidrato antes de agregarlas al DOM
  • Estaría bueno que apareciera una advertencia cuando intentas cerrar la página después de editar sin guardar.
    Valdría la pena considerar agregar un manejador onbeforeunload

    • Esta página web también muestra una advertencia al cerrar, pero en general es una buena sugerencia
  • Me gustan este tipo de herramientas simples. Hace poco hice una “página de inicio”/dashboard personalizado y sencillo: https://github.com/rcarmo/onepage-by-spec

    • Acabo de actualizarlo para que también se pueda “guardar”
  • Muy bueno. Frustra ver cómo ha aumentado tanto el software que esconde detrás de una suscripción funciones que se pueden hacer fácilmente en local y que ya se venían haciendo, imponiendo limitaciones artificiales.
    Estoy creando un editor de Markdown gratuito que funciona solo dentro del navegador y permite editar archivos locales mediante la nueva File System Access API. Esta API solo está disponible en navegadores basados en Chromium.
    https://zareith.github.io/chillmd/