Show HN: Nash: notas independientes en un solo archivo HTML
(keepworking.github.io)- 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
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!
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.
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 :-)
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.
https://news.ycombinator.com/item?id=43179649
contenteditable="true"en el div de nivel superior.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.
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.
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.
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”.
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.
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
scriptcomún y corriente, y eso me hizo recordar de nuevo que también se puede hacer asíLa mayoría de las pantallas que vemos todos los días, incluso los editores de código, son páginas HTML
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.htmy las hidrato antes de agregarlas al DOMEstarí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
onbeforeunloadMe 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
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/