- Busca ser un lenguaje de documentos que permita al navegador entender la estructura del documento y que el lector la aproveche directamente, superando las limitaciones de los PDF y las páginas web estáticas
- Los documentos de Nota se compilan como programas de JavaScript y se ejecutan en el navegador, por lo que al escribir documentos se pueden usar variables, funciones y estructuras de datos
- Está diseñado pensando en la integración con bibliotecas de JavaScript como KaTeX, Vega-Lite y Penrose, además de facilitar el soporte para requisitos de accesibilidad
- Con el paquete
@nota-lang/notase puede instalar el ejecutablenotay trabajar con documentos mediante flujos de compilación o de edición interactiva - Sigue siendo una tecnología nueva y en evolución, por lo que la arquitectura y la API pueden cambiar, y hay que considerar posibles errores, omisiones e inexactitudes en las herramientas y la documentación
Estructura de documentos que el navegador entiende
- Nota es un lenguaje para escribir documentos como artículos académicos y publicaciones de blog
- Su objetivo es llevar los documentos a un medio propio del siglo XXI
- Dentro de un documento hay mucha estructura que el lector necesita seguir, como definiciones de términos y referencias
- Por ejemplo, la palabra
Notahace referencia a un término definido en el párrafo anterior - Nota permite que el autor exprese esa estructura, y que el navegador la entienda para que el lector pueda aprovecharla
- En la página de ejemplo se puede comprobar su funcionamiento haciendo clic o doble clic en la referencia
Nota
- Por ejemplo, la palabra
- Los documentos de Nota se compilan como programas de JavaScript
- Se pueden ver en cualquier dispositivo con navegador web
- Se pueden usar variables, funciones y estructuras de datos para simplificar la escritura del documento
- Se pueden integrar bibliotecas de JavaScript como KaTeX, Vega-Lite, Penrose
- Facilita el soporte de requisitos de accesibilidad como los lectores de pantalla
Instalación y flujo de edición
- Nota se puede usar instalando el ejecutable
notamediante el paquete@nota-lang/nota- Los requisitos son NodeJS ≥ 16 y npm ≥ 6
- El directorio global de binarios de NodeJS debe estar en el
PATHdel shell
- Un documento individual de Nota se puede compilar con el siguiente flujo
npm install --global @nota-lang/notaecho "@Title: Hello world" > index.notanota build index.notaopen dist/index.html
- Los archivos de Nota se pueden editar de forma interactiva con el comando
nota edit index.nota - La forma de escribir documentos se puede consultar en la Reference
- Para agregar Nota a un sitio web o revisar la arquitectura, se puede consultar la Integration guide
La brecha entre el PDF y la web estática
- Los medios principales de los documentos digitales se dividen entre PDF y páginas web
- El PDF fue diseñado para reflejar documentos físicos, por lo que arrastra limitaciones del papel como la paginación, el ancho fijo y estilos que no cambian
- Las páginas web permiten formato dinámico, como adaptar el tamaño al teléfono, traducir a otros idiomas o cambiar colores para personas con daltonismo
- Las páginas web también permiten interacciones dinámicas, como texto que pide más contexto, diagramas que cambian de perspectiva o anotaciones para más adelante
- Hoy, estas funciones dinámicas siguen estando disponibles sobre todo para desarrolladores web especializados
- Las herramientas de documentos existentes como LaTeX, Pandoc, Markdown y Scribble en su mayoría solo pueden generar páginas web estáticas
- Nota busca reducir esa brecha con un lenguaje de documentos de baja barrera de entrada, alto techo de expansión y una curva de aprendizaje gradual
Estado actual y materiales de referencia
- Nota sigue siendo una tecnología nueva y en evolución
- La arquitectura y la API siguen cambiando
- Las herramientas pueden tener errores y funciones faltantes
- La documentación puede estar incompleta o ser inexacta
- Actualmente buscan usuarios tempranos que quieran participar en convertir a Nota en el lenguaje de documentos del futuro
- Los componentes
@Definitiony@Refpermiten que, si el autor agrega una pequeña cantidad de anotaciones al documento, el entorno de ejecución de Nota muestre en contexto la definición de una referencia como tooltip- Versiones futuras de Nota podrían incluir funciones como encontrar todas las referencias a una definición específica
- La filosofía de diseño se puede ver con más detalle en A New Medium for Communicating Research on Programming Languages
1 comentarios
Opiniones de Hacker News
Soy quien creó Nota, y desde el prototipo inicial de la página web estoy refinando de nuevo el diseño.
Estoy construyendo una base más sólida para cuestiones como cómo mezclar contenido y cómputo(https://arxiv.org/abs/2310.04368) y cómo la sintaxis hace que el trabajo con documentos sea fácil/difícil/imposible(https://github.com/cognitive-engineering-lab/doclang-benchma...).
Sigo creyendo en la gran filosofía, pero creo que Nota será bastante diferente en unos 6 meses. Mientras tanto, considero que el avance más genial en el campo de los lenguajes de documentos es Typst, y recomiendo echarle un vistazo: https://typst.app/
La próxima versión de Nota estará escrita 99% en Rust :-)
Si el rendimiento es realmente el problema, Rust tiene más sentido que JavaScript, pero no sé si será decisivo en la mayoría de los casos de uso.
Aunque he escrito muchos documentos grandes en LaTeX, nunca me gustó; era un monstruo para la academia, no para los negocios. Incluso en Word, las tareas que uno quiere hacer de forma consistente no siempre son fáciles, los estilos se desordenan rápido, y la numeración y las viñetas son propensas a que se cuelen errores.
Cuando hay varias rondas de revisión, el control de cambios se vuelve un gran problema, y al final uno depende de confiar en que la otra parte no sobrescriba el seguimiento. Un producto que por sí solo garantice que todos los cambios se vean correctamente desde el inicio hasta la aprobación final podría ser una killer app que encantaría a empresas y abogados.
Si le espolvoreas blockchain encima, quizá sea más fácil conseguir inversión, pero en realidad parece más un problema básico de criptografía que de blockchain, y no parece necesitar ese nivel de complejidad.
Lo más importante en un lenguaje de documentos es priorizar esas dos cosas. Por ejemplo, un documento TeX empieza con código preparatorio como
\documentclass, varios\usepackage, definiciones de theorem y configuración de fuentes, mientras que un documento R Markdown/Quarto empieza directamente con el significado real del texto, como el título, el autor y el resumen.La diferencia de énfasis se ve claramente.
Esto incluye layouts apretados y cargados de información como un póster académico A0, estilos de documentos según normas nacionales como GOST en el espacio postsoviético, requisitos de estilos bibliográficos que se multiplican explosivamente según cada tradición internacional, hacer que parezca el estilo predeterminado de cierta versión de MS Word, colocar con precisión imágenes o texto encima de figuras para correcciones rápidas en artículos, y ajustar conscientemente ese tipo de cosas.
En el mundo TeX todo eso es técnicamente posible, pero en la práctica requiere una magia negra tan profunda que ni un usuario común con título universitario querría meterse ahí.
Durante los últimos meses lo he usado con gusto para explorar ideas de animación SVG(https://simpatico.io/svg) o concretar nuevas estructuras de datos/algoritmos(https://simpatico.io/stree3).
Todo el servidor y el procesador de Markdown son unas 500 líneas de código Node legible, con muy pocas dependencias y sin dependencias transitivas, y no requiere paso de compilación. Por defecto, el servidor no permite ningún tipo de recurso de terceros ni cookies.
Está en GitHub con licencia MIT, y lo estoy ordenando mientras lo muevo de un repositorio personal a uno de organización. Referencia: https://simpatico.io/lit
Donde no se necesita “dinamismo esencial”, más bien su ausencia es una función, no un bug
En móvil prefiero mucho más leer páginas web que PDF, porque una página web razonable normalmente puede adaptarse a la pantalla del móvil
Se necesita un formato que codifique tanto la información visual como la digital. La capa digital no tiene por qué ser visible por defecto, pero debería ser accesible cuando haga falta
Por supuesto, estas “funciones” se consideraron bugs y se eliminaron en la especificación ISO PDF/A, pensada para preservación a largo plazo: https://en.wikipedia.org/wiki/PDF/A
El punto es que a veces un documento debe ser solo un documento. En papers científicos, LaTeX es algo que escriben personas para personas y, gracias a comandos y paquetes personalizados, permite crear documentos de texto plano tan legibles como el paper generado. También es bueno en términos de accesibilidad
Hay un territorio interesante y poco explorado en los documentos dinámicos, pero hacen falta buenos ejemplos de uso elegante
En resumen, está más cerca de LaTeX, con algunos elementos de Markdown; está escrito en JavaScript, así que mucha gente puede contribuir en un lenguaje que ya conoce, y me gusta que tenga licencia MIT
No sé si tenga un uso inmediato para mí, pero se ve bastante genial. Si escribiera algo que necesitara funciones al estilo LaTeX, pero el lugar de entrega no exigiera LaTeX, creo que probaría Nota
Creo que Knuth es casi una figura semidivina, pero no es como si hubiera bajado del cielo, nos hubiera entregado TeX y dicho “no prueben nada nuevo jamás”
También le faltan demasiados mecanismos contra errores y comodidades que ofrecen los lenguajes modernos. Cuando uso LaTeX, dependo mucho de fragmentos
\input{}para aislar bloques y evitar que todo se rompa por olvidarme de un escapeSigo esperando una reinterpretación moderna, pero siento que estamos atrapados en un óptimo local del que es difícil salir por décadas de inercia y paquetes acumulados alrededor de TeX
Entre cosas parecidas están https://pandoc.org/, https://quarto.org/, https://markdoc.dev/, https://mdxjs.com/, https://typst.app/
El problema de los nuevos intentos en este campo es que entran a un espacio que ya está demasiado saturado. No importa demasiado si las soluciones existentes no son perfectas
Es parecido a llegar a una ciudad histórica europea con mil años de arquitectura acumulada y defender el diseño de un gran edificio nuevo. Los terrenos vacíos son raros, y la gente no derriba estructuras antiguas solo para probar algo nuevo. Tiene que percibir una ventaja abrumadora
En arquitectura, el acero y el concreto reforzado abrieron la dimensión vertical, mejoraron mucho el uso del espacio y, después de eso, la historia cambió
La cuestión clave es si existe alguna dimensión inexplorada capaz de atraer a la gente a otro formato de documentos más que “mejore” ASCII, reStructuredText, wikitext, Markdown, TeX/LaTeX, AsciiDoc, HTML, etc.
La respuesta común es una infraestructura de hipertexto semántico. La visión original aún no se ha hecho realidad. Si suponemos que los ecosistemas cerrados de hoy son una pesadilla pasajera, una web nuevamente descentralizada necesitará una infraestructura de autoría de documentos moderna, fácil de usar y empoderadora
Aun así, puede haber otras dimensiones que eleven la creación y el intercambio de documentos a un nuevo nivel. La belleza de la innovación está en no estar atada a las reglas y la sabiduría existentes
Se necesita un formato de documentos eficiente, y para eso debe ser un formato que no intente hacerlo todo. Es decir, las tablas deberían separar los tipos de documento por archivo, como en los formatos estándar de hojas de cálculo, a diferencia de HTML, que intenta encargarse por sí mismo de tablas, gráficos (SVG), etc.
Separar cada cosa en archivos distintos permite que el usuario elija el programa que quiera para ver o manipular documentos, en vez de verlo todo con un solo navegador; también ayuda a la distribución por red y conviene en entornos con poco almacenamiento o ancho de banda
Así que, desde mi punto de vista, no hay nada nuevo que inventar. Basta con especializar y pulir lo que ya fue inventado
Al seguir el enlace, https://willcrichton.net/nota/ muestra ventajas convincentes en el nicho para el que Nota está pensado, es decir, hacer más comprensibles los artículos académicos sobre lenguajes de programación.
Que pueda renderizarse como PDF de alta calidad es, por supuesto, una necesidad y una pregunta. Por compatibilidad con los sistemas existentes, quizá incluso convenga más renderizarlo como LaTeX.
En esencia, Nota es markup + código (JavaScript), y esa combinación es el terreno al que apunta MDX. Cuando alguien lo mencionó antes, su creador dijo que Nota estaba orientado a la documentación y MDX a los sitios web: https://news.ycombinator.com/item?id=31349579
Si es así, creo que para que Nota despegue alguien tiene que envolverlo en un producto. El resultado se ve bien, pero tocar Node.js para crear documentos es demasiado engorroso y vuelve a sentirse como LaTeX. La mayoría preferirá Notion o un procesador de texto.
Además, Nota no compite directamente con la familia TeX. Nota produce algo para que lo lea un navegador web, mientras que xxxTeX produce algo para que lo lea un lector de PDF. Sé que xxxTeX también puede generar otros formatos de salida, pero la mayoría lo usa para generar PDF.
MDX está listo para usarse con cualquier framework como React/Vue, pero eso significa que, básicamente, no ofrece ninguna postura por defecto.
Nota se siente como algo que podría enchufarse a un generador de sitios estáticos. Claro que para eso habría que hacer que ambos cooperen, pero me parece una expectativa alcanzable para alguien un poco más dedicado que yo.
No entiendo por qué haría falta un lenguaje que compile a JavaScript para crear páginas de texto. AsciiDoc ya cubre ese mismo objetivo.
Editoriales reales como O’Reilly también usan AsciiDoc como formato de entrada para crear libros y sitios web.
He usado AsciiDoc durante los últimos años y me gusta. Solo vuelvo a Markdown en lugares donde AsciiDoc todavía no está soportado. Por ejemplo, GitHub y GitLab soportan renderizado de AsciiDoc.
Lamentablemente PyPI aún no lo soporta, pero me alegra ver que más gente parece estar prestándole atención: https://github.com/pypa/readme_renderer/issues/205
Dicho eso, las herramientas recientes me frustran. Se nota y agradezco el enorme esfuerzo puesto en Asciidoctor, pero no tiene salida HTML5 semántica, la integración con generadores de imágenes es difícil, o al menos más difícil de lo necesario, y es tan pesado que es la única dependencia de Ruby en toda mi máquina.
Dejando de lado el problema de Ruby, estos temas están abiertos en GitHub, así que supongo que se resolverán con más tiempo y recursos.
No sé. Emacs org-mode parece mejor y menos dependiente de JavaScript.
https://docusaurus.io/ también es muy bueno y flexible. Si quieren extender Nota de una forma parecida, recomendaría mirar esos dos.
Justo estaba pensando en la forma más fácil de crear un blog con contenido mayormente estático, pero que permita agregar gráficos interactivos o personalizaciones arbitrarias si uno quiere. Me pregunto si Nota será una buena opción.
También miré otras alternativas como Quarto (https://quarto.org/), y quizá sea posible usar un blog simple de sitio estático como Jekyll y luego editar directamente el HTML de salida cuando haga falta.
Así puedo usar todo HTML, personalizar el proceso de generación, gestionar las dependencias con relativa facilidad y trabajar con formatos relacionados que están estandarizados.
Astro te permite escribir componentes al estilo React y los compila a HTML/CSS puro, salvo en los casos donde realmente se necesita JavaScript. También hice mi sitio personal y mi blog con Astro: https://sjer.red/, y el código fuente está en https://github.com/shepherdjerred/shepherdjerred.com
También hay un tutorial para crear un blog con Astro: https://docs.astro.build/en/tutorial/0-introduction/