Pensieri sul ribasso

Markdown è una seconda natura per molti di noi. Guardando indietro, ricordo di aver iniziato a digitare in Markdown non molto tempo dopo che John Gruber ha rilasciato il suo primo parser basato su Perl nel 2004 dopo aver collaborato al linguaggio con Aaron Swartz.

La sintassi di Markdown ha uno scopo: essere usata come formato per scrivere per il web.

— John Gruber

Sono passati quasi 20 anni, cavolo! Quella che era iniziata come una sintassi per HTML più facile da scrivere e da leggere è diventata un tesoro per come scrivere e archiviare prosa tecnica per programmatori e persone esperte di tecnologia.

Markdown è un significante per la cultura degli sviluppatori e degli smanettoni. Ma dalla sua introduzione, anche il mondo dei contenuti digitali è cambiato. Mentre Markdown va ancora bene per alcune cose, non credo che dovrebbe più essere il punto di riferimento per i contenuti.

Ci sono due ragioni principali per questo:

1. Markdown non è stato progettato per soddisfare le odierne esigenze di contenuto.
2. Markdown trattiene l'esperienza editoriale.

Naturalmente, questa posizione è influenzata dal lavoro per una piattaforma per contenuti strutturati. In Sanity.io, trascorriamo la maggior parte delle nostre giornate a pensare a come i contenuti come dati sblocchino molto valore e passiamo molto tempo a pensare profondamente alle esperienze degli editor, a come far risparmiare tempo alle persone e a rendere piacevole il lavoro con i contenuti digitali . Quindi, c'è una pelle nel gioco, ma spero di essere in grado di ritrarre che, anche se discuterò contro Markdown come formato di riferimento per i contenuti, ho comunque un profondo apprezzamento per il suo significato, l'applicazione e l'eredità.

Prima del mio attuale lavoro, ho lavorato come consulente tecnologico in un'agenzia in cui dovevamo combattere letteralmente i CMS che bloccavano i contenuti dei nostri clienti incorporandoli in presentazioni e modelli di dati complessi (sì, anche quelli open-source). Ho osservato che le persone lottano con la sintassi di Markdown e sono demotivate nel loro lavoro di editore e creatore di contenuti. Abbiamo speso ore (e denaro del cliente) nella creazione di rendering di tag personalizzati che non sono mai stati utilizzati perché le persone non hanno tempo o motivazione per utilizzare la sintassi. Anche io, quando altamente motivato, ho rinunciato a contribuire alla documentazione open source perché l'implementazione di Markdown basata sui componenti ha introdotto troppi attriti.

Ma vedo anche l'altra faccia della medaglia. Markdown viene fornito con un ecosistema impressionante e dal punto di vista di uno sviluppatore, c'è un'elegante semplicità per i file di testo normale e una sintassi facile da analizzare per le persone che sono abituate a leggere il codice. Una volta ho passato giorni a costruire un impressionante MultiMarkdown -> LaTeX -> real-time-PDF-preview-pipeline in Sublime Text per la mia scrittura accademica. E ha senso che un file README.md possa essere aperto e modificato in un editor di codice e renderizzato bene su GitHub. Non c'è dubbio che Markdown offra comodità agli sviluppatori in alcuni casi d'uso.

Questo è anche il motivo per cui voglio costruire il mio consiglio contro Markdown guardando indietro al motivo per cui è stato introdotto in primo luogo e esaminando alcuni dei principali sviluppi dei contenuti sul web. Per molti di noi, sospetto che Markdown sia qualcosa che diamo per scontato come una "cosa che esiste". Ma tutta la tecnologia ha una storia ed è un prodotto dell'interazione umana. Questo è importante da ricordare quando tu, il lettore, sviluppi una tecnologia che gli altri possono usare.

Sapori E Specifiche

Markdown è stato progettato per rendere più facile per gli autori del web lavorare con gli articoli in un'epoca in cui la pubblicazione sul web richiedeva la scrittura di HTML. Quindi, l'intento era quello di semplificare l'interfaccia con la formattazione del testo in HTML. Non è stata la prima sintassi semplificata sul pianeta, ma è stata quella che ha guadagnato più trazione nel corso degli anni. Oggi, l'uso di Markdown è andato ben oltre il suo intento di progettazione per essere un modo più semplice di leggere e scrivere HTML, per diventare un approccio per contrassegnare il testo normale in molti contesti diversi. Certo, le tecnologie e le idee possono evolvere oltre il loro intento, ma la tensione nell'uso odierno di Markdown può essere ricondotta a questa origine e ai vincoli posti nella sua progettazione.

Per coloro che non hanno familiarità con la sintassi, prendi il seguente contenuto HTML:

 <p>The <a href=”https://daringfireball.net/projects/markdown/syntax#philosophy”>Markdown syntax</a> is designed to be <em>easy-to-read</em> and <em>easy-to.write</em>.</p>

Con Markdown puoi esprimere la stessa formattazione di:

 The [Markdown syntax](https://daringfireball.net/projects/markdown/syntax#philosophy) is designed to be _easy-to-read_ and _easy-to-write_.

È come una legge di natura che l'adozione della tecnologia sia accompagnata dalla pressione per evolversi e aggiungere funzionalità ad essa. La crescente popolarità di Markdown ha fatto sì che le persone volessero adattarlo ai loro casi d'uso. Volevano più funzionalità come il supporto per note a piè di pagina e tabelle. L'implementazione originale è arrivata con una posizione supponente, che all'epoca era ragionevole per quello che era l'intento progettuale:

Per qualsiasi markup che non è coperto dalla sintassi di Markdown, usi semplicemente lo stesso HTML. Non è necessario prefarlo o delimitarlo per indicare che stai passando da Markdown a HTML; usi solo i tag.

— John Gruber

In altre parole, se vuoi una tabella, usa <table></table> . Scoprirai che questo è ancora il caso per l'implementazione originale. Uno dei successori spirituali di Markdown, MDX, ha adottato lo stesso principio ma lo ha esteso a JSX, un linguaggio di template basato su JS.

Dal ribasso al ribasso?

Può sembrare che il fascino di Markdown per molti non fosse tanto il suo legame con l'HTML, ma l'ergonomia del testo in chiaro e la semplice sintassi per la formattazione. Alcuni creatori di contenuti volevano utilizzare Markdown per altri casi d'uso rispetto ai semplici articoli sul Web. Implementazioni come MultiMarkdown hanno introdotto agevolazioni per gli scrittori accademici che desideravano utilizzare file di testo normale ma avevano bisogno di più funzionalità. Presto avrai una gamma di app di scrittura che accettano la sintassi Markdown, senza necessariamente trasformarla in HTML o addirittura utilizzare la sintassi markdown come formato di archiviazione.

In molte app troverai editor che ti offrono un set limitato di opzioni di formattazione e alcuni di essi sono più "ispirati" alla sintassi originale. In effetti, uno dei feedback che ho ricevuto su una bozza di questo articolo è stato che ormai "Markdown" dovrebbe essere minuscolo, dal momento che è diventato così comune, e per distinguerlo dall'implementazione originale. Perché anche ciò che riconosciamo come markdown è diventato molto vario.

CommonMark: un tentativo di domare Markdown

Come il gelato, Markdown è disponibile in molti gusti, alcuni più popolari di altri. Quando le persone hanno iniziato a eseguire il fork dell'implementazione originale e ad aggiungervi funzionalità, sono accadute due cose:

1. È diventato più imprevedibile ciò che tu come scrittore potevi e non potevi fare con Markdown.
2. Gli sviluppatori di software dovevano decidere quale implementazione adottare per il loro software. L'implementazione originale conteneva anche alcune incongruenze che aggiungevano attrito per le persone che desideravano utilizzarla a livello di codice.

Ciò ha avviato conversazioni sulla formalizzazione di Markdown in una specifica vera e propria. Qualcosa a cui Gruber ha resistito e fa ancora, cosa interessante, perché ha riconosciuto che le persone volevano usare Markdown per scopi diversi e "Nessuna sintassi renderebbe tutti felici". È una posizione interessante considerando che Markdown si traduce in HTML, che è una specifica che si evolve per soddisfare esigenze diverse.

Anche se l'implementazione originale di Markdown è coperta da una licenza "simile a BSD", si legge anche "Né il nome Markdown né i nomi dei suoi contributori possono essere utilizzati per approvare o promuovere prodotti derivati ​​da questo software senza una specifica autorizzazione scritta. " Possiamo tranquillamente presumere che la maggior parte dei prodotti che utilizzano "Markdown" come parte dei loro materiali di marketing non abbiano acquisito questa autorizzazione scritta.

Il tentativo di maggior successo di portare Markdown in una specifica condivisa è quello che oggi è noto come CommonMark. Era diretto da Jeff Atwood (noto per aver co-fondato Stack Overflow e Discourse) e John McFarlane (un professore di filosofia a Berkely che è dietro Babelmark e pandoc). Inizialmente l'hanno lanciato come "Standard Markdown", ma lo hanno cambiato in "CommonMark" dopo aver ricevuto critiche da Gruber. La cui posizione era coerente, l' intento di Markdown è quello di essere una semplice sintassi di authoring che si traduce in HTML:

@davewiner E questo è ciò che è difettoso con CommonMark. Vogliono rendere le cose più facili per i programmatori come obiettivo principale. Mancano il punto.

— John Gruber (@gruber) 8 settembre 2014

Penso che questo abbia segnato anche il punto in cui Markdown è diventato di pubblico dominio. Anche se CommonMark non è etichettato come "Markdown", (come da licenza) questa specifica è riconosciuta e denominata "markdown". Oggi troverai CommonMark come implementazione alla base di software come Discourse, GitHub, GitLab, Reddit, Qt, Stack Overflow e Swift. Progetti come unified.js sintassi traducendole in alberi di sintassi astratti, inoltre si affidano a CommonMark per il supporto del markdown.

CommonMark ha portato molta unificazione su come viene implementato il markdown e in molti modi ha reso più semplice per i programmatori integrare il supporto del markdown nel software. Ma non ha portato la stessa unificazione nel modo in cui il markdown viene scritto e utilizzato. Prendi GitHub Flavored Markdown (GFM). È basato su CommonMark ma lo estende con più funzionalità (come tabelle, elenchi di attività e barrato). Reddit descrive il suo "Reddit Flavored Markdown" come "una variazione di GFM" e introduce funzionalità come la sintassi per contrassegnare gli spoiler. Penso che possiamo tranquillamente concludere che sia il gruppo dietro CommonMark che Gruber avevano ragione: aiuta sicuramente con le specifiche condivise, ma sì, le persone vogliono usare Markdown per cose specifiche diverse.

Markdown come scorciatoia di formattazione

Gruber ha resistito alla formalizzazione di Markdown in una specifica condivisa perché pensava che lo avrebbe reso meno uno strumento per scrittori e più uno strumento per programmatori. Abbiamo già visto che anche con l'adozione ampia di una specifica, non otteniamo automaticamente una sintassi che prevedibilmente funzioni allo stesso modo in contesti diversi. E anche specifiche come CommonMark, per quanto popolare, hanno un successo limitato. Un esempio ovvio è l'implementazione markdown di Slack (chiamata mrkdown ) che traduce *this* in forte/grassetto e non enfasi/corsivo e non supporta la sintassi [link](https://slack.com) , ma usa <link|https://slack.com> invece.

Scoprirai anche che puoi utilizzare la sintassi simile a Markdown per inizializzare la formattazione in editor di testo RTF in software come Notion, Dropbox Paper, Craft e, in una certa misura, Google Docs (ad es. asterisk + space su una nuova riga si trasformerà in un elenco puntato). Cosa è supportato e cosa viene tradotto in ciò che varia. Quindi, non puoi necessariamente portare con te la tua memoria muscolare in queste applicazioni. Per alcune persone va bene e possono adattarsi. Per altri, questo è un papercut e impedisce loro di utilizzare queste funzionalità. Il che pone la domanda, per chi è stato progettato Markdown e chi sono i suoi utenti oggi?

Chi dovrebbero essere gli utenti di Markdown?

Abbiamo visto che il markdown esiste in una tensione tra diversi casi d'uso, pubblico e nozioni di chi sono i suoi utenti. Quello che è iniziato come un linguaggio di markup per scrittori web esperti di HTML, in particolare, è diventato un tesoro per i tipi di sviluppatori.

Nel 2014, i web writer hanno iniziato ad abbandonare lo spostamento di file tramite parser in Perl e FTP. I sistemi di gestione dei contenuti (CMS) come WordPress, Drupal e Moveable Type (che credo che Gruber utilizzi ancora) sono cresciuti costantemente fino a diventare gli strumenti di riferimento per il web publishing. Offrivano vantaggi come editor di testo ricco che gli scrittori web potevano utilizzare nei loro browser.

Questi editor di testo RTF assumevano ancora HTML e Markdown come sintassi RTF sottostante, ma eliminavano parte del sovraccarico cognitivo aggiungendo pulsanti per inserire questa sintassi nell'editor. E sempre più, gli scrittori non erano e non dovevano essere esperti in HTML. Scommetto che se hai sviluppato web con CMS negli anni 2010, probabilmente avresti dovuto fare i conti con "HTML spazzatura" che proveniva da questi editor quando le persone incollavano direttamente da Word.

Oggi sosterrò che gli utenti principali di Markdown sono sviluppatori e persone interessate al codice. Non è un caso che Slack abbia reso il WYSIWYG la modalità di input predefinita una volta che il loro software è stato utilizzato da più persone al di fuori dei dipartimenti tecnici. E il fatto che questa sia stata una decisione controversa, tanto che hanno dovuto riportarla come opzione, mostra quanto sia profondo l'amore per il markdown nella comunità degli sviluppatori. Non c'è stata molta celebrazione del tentativo di Slack di renderlo più facile e accessibile a tutti. E questo è il nocciolo della questione.

L'ideologia di Markdown

Il fatto che il markdown sia diventato lo stile di scrittura in lingua franca e ciò a cui si rivolge la maggior parte dei framework di siti Web è anche il motivo principale per cui sono stato un po' timido nel pubblicarlo. Se ne parla spesso come di un bene intrinseco e innegabile. Markdown è diventato un segno distintivo di essere favorevole agli sviluppatori. Le persone intelligenti e qualificate hanno perso molte ore collettive per consentire il ribasso in tutti i tipi di contesti. Quindi, sfidare la sua egemonia sicuramente infastidirà alcuni. Ma si spera che possa generare qualche fruttuosa discussione su una cosa che spesso viene data per scontata.

La mia impressione è che la cordialità per gli sviluppatori che le persone si riferiscono a Markdown abbia principalmente a che fare con 3 fattori:

1. La comoda astrazione di un semplice file di testo.
2. Esiste un ecosistema di strumenti.
3. Puoi mantenere i tuoi contenuti vicino al flusso di lavoro di sviluppo.

Non sto dicendo che queste posizioni siano sbagliate, ma suggerirò che vengono con compromessi e alcune ipotesi irragionevoli.

Il semplice modello mentale di un file di testo normale

I database sono cose incredibili. Ma si sono anche guadagnati la reputazione di essere difficili e inaccessibili per gli sviluppatori frontend. Ho conosciuto molti grandi sviluppatori che evitano il codice di back-end e i database, perché rappresentano una complessità su cui non vogliono perdere tempo. Anche con WordPress, che fa molto per impedirti di avere a che fare con il suo database dopo l'installazione, è stato un sovraccarico per iniziare a funzionare.

I file di testo normale, tuttavia, sono più tangibili e sono abbastanza semplici da ragionare (a patto che tu sia abituato alla gestione dei file). Soprattutto rispetto a un sistema che suddividerà il contenuto in più tabelle in un database relazionale con una struttura proprietaria. Per casi d'uso limitati, come post di blog di semplice testo RTF con immagini e collegamenti, markdown farà il lavoro. Puoi copiare il file e inserirlo in una cartella o archiviarlo in git. Il contenuto sembra tuo a causa della tangibilità dei file. Anche se sono ospitati su GitHub, che è un Software as a Service a scopo di lucro di proprietà di Microsoft e quindi coperto dai loro termini di servizio.

Nell'era in cui dovevi effettivamente creare un database locale per avviare il tuo sviluppo locale e occuparti della sincronizzazione con il telecomando, il fascino dei file di testo normale è comprensibile. Ma quell'era è praticamente scomparsa con l'emergere dei backend come servizio. Servizi e strumenti come Fauna, Firestore, Hasura, Prisma, PlanetScale e Sanity's Content Lake investono molto nell'esperienza degli sviluppatori. Anche la gestione dei database tradizionali sullo sviluppo locale è diventata meno problematica rispetto a soli 10 anni fa.

Se ci pensi, possiedi meno i tuoi contenuti se sono ospitati in un database? E l'esperienza degli sviluppatori nella gestione dei database non è diventata significativamente più semplice con l'avvento degli strumenti SaaS? Ed è giusto dire che la tecnologia di database proprietaria incide sulla portabilità dei tuoi contenuti? Oggi puoi avviare quello che è essenzialmente un database Postgres senza competenze di amministratore di sistema, creare tabelle e colonne, inserire il tuo contenuto al suo interno ed esportarlo in qualsiasi momento come dump .sql .

La portabilità dei contenuti ha molto più a che fare con il modo in cui strutturi quel contenuto in primo luogo. Prendi WordPress, è completamente open-source, puoi ospitare il tuo DB. Ha anche un formato di esportazione standardizzato in XML. Ma chiunque abbia provato a uscire da un'installazione matura di WordPress sa quanto poco questo aiuti se stai cercando di allontanarti da WordPress.

Un vasto ecosistema... per gli sviluppatori

Abbiamo già parlato del vasto ecosistema di ribasso. Se guardi ai framework dei siti Web contemporanei, la maggior parte di essi assume il markdown come formato di contenuto principale, alcuni di essi l' unico formato. Ad esempio, Hugo, il generatore di siti statici utilizzato da Smashing Magazine, richiede ancora file markdown per la pubblicazione impaginata. Ciò significa che se Smashing Magazine vuole utilizzare un CMS per archiviare articoli, deve interagire con i file markdown o convertire tutto il contenuto in file markdown. Se guardi nella documentazione per Next.js, Nuxt.js, VuePress, Gatsby.js e così via, il markdown avrà un ruolo di primo piano. È anche la sintassi predefinita per README -files su GitHub, che la usa anche per la formattazione nelle note e nei commenti di Pull Request.

Ci sono alcune menzioni d'onore di iniziative per portare l'ergonomia del markdown alle masse. Netlify CMS e TinaCMS (il discendente spirituale di Forestry) ti forniranno interfacce utente in cui la sintassi del markdown è per lo più astratta per gli editori. Troverai comunemente che gli editor basati su markdown nei CMS ti offrono funzionalità di anteprima per la formattazione. Alcuni editor, come quello di Notion, ti permetteranno di incollare la sintassi markdown e la tradurranno nella loro formattazione nativa. Ma penso che si possa dire con sicurezza che l'energia che è andata a innovare per il ribasso non ha favorito le persone che non sono nella scrittura della sua sintassi. Non è salito sullo stack, per così dire.

Flussi di lavoro dei contenuti o flussi di lavoro degli sviluppatori?

Per uno sviluppatore che crea il proprio blog, l'utilizzo di file markdown riduce parte del sovraccarico di installazione e funzionamento, poiché i framework spesso sono dotati di analisi integrata o comunemente lo offrono come parte del codice di avvio. E non c'è niente in più per iscriversi. Puoi usare git per eseguire il commit di questi file insieme al tuo codice. Se sei a tuo agio con git diffs, avrai anche il controllo di revisione come sei abituato con la programmazione. In altre parole, poiché i file markdown sono in testo normale, possono essere integrati con il flusso di lavoro dello sviluppatore.

Ma oltre a questo, l'esperienza degli sviluppatori diventa presto più complessa. E finisci per compromettere l'esperienza utente del tuo team come creatori di contenuti e la nostra esperienza di sviluppatore è bloccata da un ribasso per risolvere problemi che vanno ben oltre il suo intento di progettazione.

Sì, potrebbe essere interessante se convincere il team dei contenuti a utilizzare git e controllare le modifiche, ma allo stesso tempo, è questo l'uso migliore del loro tempo? Vuoi davvero che i tuoi editor si imbattano in conflitti di unione o come rifondare i rami? Git è già abbastanza difficile per gli sviluppatori che lo usano ogni giorno. E questa configurazione rappresenta davvero il miglior flusso di lavoro per le persone che lavorano principalmente con i contenuti? Non è questo un caso in cui l'esperienza degli sviluppatori ha prevalso sull'esperienza dell'editor e non è il costo, il tempo e lo sforzo che potrebbero essere necessari per creare qualcosa di meglio per gli utenti?

Poiché le aspettative e le esigenze dei contenuti e degli ambienti di editing si sono evolute, non credo che il markdown lo farà per noi. Non vedo come parte dell'ergonomia degli sviluppatori finisca per favorire i non sviluppatori e penso che anche per gli sviluppatori il markdown stia ostacolando la nostra creazione di contenuti e le nostre esigenze. Perché i contenuti sul web sono cambiati in modo significativo dai primi anni 2000.

Dai paragrafi ai blocchi

Markdown ha sempre avuto la possibilità di rinunciare all'HTML se volevi cose più complesse. Funzionava bene quando l'autore era anche il webmaster, o almeno conosceva l'HTML. Ha anche funzionato bene perché i siti Web di solito erano principalmente HTML e CSS. Il modo in cui hai progettato i siti Web è stato principalmente creando layout di pagine intere. Puoi trasformare Markdown nel markup HTML e inserirlo insieme al tuo file style.css . Certo, avevamo CMS e generatori di siti statici anche negli anni 2000, ma funzionavano per lo più allo stesso modo, inserendo il contenuto HTML all'interno dei modelli senza alcun passaggio di "props" tra i componenti.

Ma la maggior parte di noi non crea più HTML come ai vecchi tempi. Il contenuto sul Web si è evoluto dall'essere principalmente articoli con una semplice formattazione di testo RTF a componenti multimediali e specializzati composti spesso con interattività dell'utente (che è un modo elegante per dire "invito alle azioni per l'iscrizione alla newsletter").

Dagli articoli alle app

All'inizio degli anni 2010, il Web 2.0 era al suo apice e le società di Software as a Service hanno iniziato a utilizzare il Web per applicazioni pesanti di dati. HTML, CSS e JavaScript sono stati sempre più utilizzati per guidare interfacce utente interattive. Bootstrap open source di Twitter, il loro framework per la creazione di interfacce utente più coerenti e resilienti. Ciò ha guidato quella che possiamo chiamare la "componentizzazione" del web design. Ha cambiato radicalmente il modo in cui costruiamo per il web.

I vari framework CSS emersi in quest'epoca (ad es. Bootstrap e Foundation) tendevano a utilizzare nomi di classi standardizzati e assumevano strutture HTML specifiche per rendere meno difficile creare interfacce utente resilienti e reattive. Con la filosofia di progettazione web di Atomic Design e le convenzioni sui nomi delle classi come Block-Element-Modifier (BEM) l'impostazione predefinita è stata spostata dal pensare prima al layout della pagina, al vedere le pagine come una raccolta di elementi di design ripetibili e compatibili.

Qualunque contenuto tu abbia all'interno di markdown non è compatibile con questo. A meno che tu non sia andato nella tana del coniglio di interporre i parser di markdown e l'abbia ottimizzato per produrre la sintassi che volevi (ne parleremo più avanti). Non c'è da stupirsi, Markdown è stato progettato per essere semplici articoli di testo RTF di elementi HTML nativi che avresti scelto come target con un foglio di stile.

Questo è ancora un problema per le persone che utilizzano Markdown per guidare i contenuti per i loro siti.

Il Web incorporabile

Ma qualcosa è successo anche ai nostri contenuti. Non solo abbiamo potuto iniziare a trovarlo al di fuori dei tag HTML semantici <article> , ma ha iniziato a contenere più... cose. Molti dei nostri contenuti sono passati dai nostri LiveJournal e blog ai social media: Facebook, Twitter, tumblr, YouTube. Per riportare i frammenti di contenuto nei nostri articoli, dovevamo essere in grado di incorporarli. La convenzione HTML ha iniziato a utilizzare il <iframe> per incanalare il video player da YouTube o persino per inserire un tweet-box tra i tuoi paragrafi di testo. Alcuni sistemi hanno iniziato ad astrarlo in "codici brevi", il più delle volte parentesi contenenti alcune parole chiave per identificare quale blocco di contenuto dovrebbe rappresentare e alcuni attributi chiave-valore. Ad esempio, dev.to ha abilitato la sintassi del liquido del linguaggio dei modelli da inserire nel proprio editor Markdown:

 {% youtube dQw4w9WgXcQ %}

Ovviamente, ciò richiede l'utilizzo di un parser Markdown personalizzato e una logica speciale per assicurarsi che sia stato inserito l'HTML corretto quando la sintassi è stata trasformata in HTML. E i tuoi creatori di contenuti dovranno ricordare questi codici (a meno che non ci fosse una sorta di barra degli strumenti per inserirli automaticamente). E se una parentesi viene eliminata o incasinata, ciò potrebbe interrompere il sito.

Ma che dire di MDX?

Un tentativo di risolvere la necessità di contenuti a blocchi è MDX, presentato con lo slogan "Markdown for the component era". MDX ti consente di utilizzare il linguaggio di modelli JSX, oltre a JavaScript, interlacciato nella sintassi markdown. C'è molta ingegneria impressionante nella comunità attorno a MDX, incluso Unified.js , che è specializzato nell'analisi di varie sintassi in Abstract Syntax Trees (AST), in modo che siano più accessibili per l'uso a livello di codice. Si noti che la standardizzazione del markdown renderebbe più semplice il lavoro delle persone dietro Unified.js e dei suoi utenti, perché ci sono meno casi limite da soddisfare.

MDX offre sicuramente una migliore esperienza agli sviluppatori nell'integrazione dei componenti in Markdown. Ma non offre una migliore esperienza dell'editor, perché aggiunge molto sovraccarico cognitivo alla produzione e all'editing dei contenuti:

 import {Chart} from './snowfall.js' export const year = 2018 # Last year's snowfall In {year}, the snowfall was above average. It was followed by a warm spring which caused flood conditions in many of the nearby rivers. <Chart year={year} color="#fcb32c" />

La quantità di conoscenza presunta solo per questo semplice esempio è sostanziale. Devi conoscere i moduli ES6, le variabili JavaScript, la sintassi dei modelli JSX e come utilizzare prop, codici esadecimali e tipi di dati, e devi avere familiarità con quali componenti puoi usare e come usarli. E devi digitarlo correttamente e in un ambiente che ti dia una sorta di feedback. Non ho dubbi sul fatto che ci saranno strumenti di creazione più accessibili su MDX, sembra di risolvere qualcosa che non deve essere un problema in primo luogo.

A meno che tu non sia estremamente diligente nel modo in cui componi e denomina i tuoi componenti MDX, lega anche il tuo contenuto a una presentazione specifica. Basta prendere l'esempio sopra riportato dalla prima pagina di MDX. Troverai un esadecimale di colore codificato per il grafico. Quando riprogetti il ​​tuo sito, quel colore potrebbe non essere compatibile con il tuo nuovo sistema di progettazione. Ovviamente, non c'è niente che ti impedisca di astrarlo e di usare il prop color=”primary” , ma non c'è niente nello strumento che ti spinga a prendere decisioni sagge come questa.

Incorporare problemi di presentazione specifici nei tuoi contenuti è diventato sempre più una responsabilità e qualcosa che ostacolerà l'adattamento, l'iterazione e il movimento rapido con i tuoi contenuti. Lo blocca in modi molto più sottili rispetto all'avere contenuto in un database. Rischi di finire nello stesso posto in cui esci da un'installazione WordPress matura con plug-in. È ingombrante separare struttura e presentazione.

La domanda di contenuto strutturato

Con siti e percorsi utente più complessi, vediamo anche la necessità di presentare gli stessi contenuti in un sito web. Se gestisci un sito di e-commerce, desideri incorporare le informazioni sul prodotto in più punti al di fuori di una singola pagina del prodotto. Se gestisci un moderno sito di marketing, vuoi essere in grado di condividere la stessa copia su più visualizzazioni personalizzate.

Per farlo in modo efficiente e affidabile dovrai adattare i contenuti strutturati. Ciò significa che i tuoi contenuti devono essere incorporati con i metadati e raggruppati in modo da rendere possibile l'analisi per intento. Se uno sviluppatore vede solo "pagina" con "contenuto", ciò rende molto difficile includere le cose giuste nei posti giusti. Se riescono a ottenere tutte le "descrizioni dei prodotti" con un'API o una query, ciò rende tutto più semplice.

Con markdown, sei limitato a esprimere tassonomie e contenuto strutturato in una sorta di organizzazione di cartelle (rendendo difficile inserire lo stesso contenuto in più tassonomie) oppure devi aumentare la sintassi con qualcos'altro.

Jekyll, uno dei primi Static Site Generator (SSG) creato per i file markdown, ha introdotto "Front Matter" come un modo per aggiungere metadati ai post utilizzando YAML (un semplice formato chiave-valore che utilizza spazi per creare ambito) tra tre trattini in alto del file. Quindi, ora avrai due sintassi da affrontare. YAML ha anche la reputazione di essere malizioso (soprattutto se vieni dalla Norvegia). Tuttavia, altri SSG hanno adottato questa convenzione, così come CMS basati su git che utilizzano markdown come formato del contenuto.

Quando devi aggiungere ulteriore sintassi ai tuoi file semplici per ottenere alcuni dei vantaggi del contenuto strutturato, potresti iniziare a chiederti se ne valga davvero la pena. E per chi è il formato e chi esclude.

Se ci pensi, molto di ciò che facciamo sul web non è solo il consumo di contenuti, lo stiamo creando! Attualmente sto scrivendo questo lungo articolo in un elaboratore di testi avanzato nel mio browser.

C'è un'aspettativa crescente che dovresti anche essere in grado di creare contenuti bloccati nelle moderne applicazioni di contenuto. Le persone hanno iniziato ad abituarsi a deliziose esperienze utente che funzionano e hanno un bell'aspetto e in cui non ci si aspetta che tu debba imparare una sintassi specializzata. Medium ha reso popolare l'idea che potresti avere una creazione di contenuti piacevole e intuitiva sul web. E parlando di "nozione", la popolare app per le note si è concentrata sul contenuto a blocchi e consente agli utenti di mescolare il massimo da un'ampia gamma di tipi diversi. La maggior parte di questi blocchi va oltre il markdown e gli elementi nativi dell'HTML.

È degno di nota il fatto che Notion, descrivendo il processo per rendere accessibili i propri contenuti tramite la loro attesissima API, sottolinea la scelta del formato dei contenuti, che:

I documenti di un editor Markdown spesso analizzeranno e visualizzeranno in modo diverso in un'altra applicazione. L'incoerenza tende a essere gestibile per documenti semplici, ma è un grosso problema per la ricca libreria di blocchi e opzioni di formattazione in linea di Notion, molte delle quali semplicemente non sono supportate in nessuna implementazione Markdown ampiamente utilizzata.

Notion è andato con un formato basato su JSON che consente loro di esprimersi come dati strutturati. La loro argomentazione è che rende più facile e prevedibile l'interazione con gli sviluppatori che desiderano creare la propria presentazione del contenuto a blocchi che esce dalle API di Notion.

Se non il ribasso, allora cosa?

Sospetto che l'importanza di Markdown abbia frenato l'innovazione e il progresso per i contenuti digitali. Quindi, quando sostengo che dovremmo smettere di sceglierlo come modo principale per archiviare i contenuti, è difficile dare una risposta diretta a cosa dovrebbe sostituirlo. Quello che sappiamo, tuttavia, è cosa dovremmo aspettarci dai moderni formati di contenuto e dagli strumenti di authoring.

Investiamo in esperienze di authoring accessibili

L'uso di markdown richiede l'apprendimento della sintassi e spesso più sintassi e tag personalizzati per essere pratici con le aspettative moderne. Oggi, sembra un'aspettativa completamente inutile da riporre sulla maggior parte delle persone. Vorrei che potessimo indirizzare più energia nel rendere accessibili e piacevoli esperienze editoriali che producano moderni formati di contenuto portatili.

Anche se è notoriamente difficile creare ottimi editor di contenuti a blocchi, ci sono un paio di opzioni praticabili che possono essere estese e personalizzate per il tuo caso d'uso (ad esempio Slate.js, Quill.js o Prosemirror). Inoltre, investire nelle comunità attorno a questi strumenti potrebbe anche aiutare il loro sviluppo ulteriormente.

Le persone si aspetteranno sempre più spesso che gli strumenti di creazione siano accessibili, in tempo reale e collaborativi. Perché si dovrebbe premere un pulsante di salvataggio sul Web nel 2021? Perché non dovrebbe essere possibile apportare una modifica a un documento senza rischiare una race condition, perché al tuo collega è capitato di avere il documento aperto in una scheda? Dovremmo aspettarci che gli autori debbano affrontare conflitti di fusione? E non dovremmo rendere facile per i creatori di contenuti lavorare con contenuti strutturati con possibilità visive che abbiano senso?

Per essere un po' polemici: le innovazioni dell'ultimo decennio nei framework JavaScript reattivi e nei componenti dell'interfaccia utente sono perfette per creare fantastici strumenti di authoring. Invece di usarli per trasporre Markdown in HTML e in un albero di sintassi astratto per poi integrarlo in un linguaggio modello JavaScript che restituisce HTML.

Il contenuto del blocco dovrebbe seguire una specifica

Non ho menzionato gli editor WYSIWYG per HTML. Perché sono la cosa sbagliata. I moderni editor di contenuto a blocchi dovrebbero preferibilmente interagire con un formato specifico. I suddetti editori hanno almeno un modello di documento interno ragionevole che può essere trasformato in qualcosa di più portatile. If you look at the content management system landscape, you start to see various JSON-based block content formats emerge. Some of them are still tied to HTML assumptions or overly concerned with character positions. And none of them aren't really offered as a generic specification.

At Sanity.io, we decided early that the block content format should never assume HTML as neither input nor output, and that we could use algorithms to synchronize text strings. More importantly, was it that block content and rich text should be deeply typed and queryable. The result was the open specification Portable Text. Its structure not only makes it flexible enough to accommodate custom data structures as blocks and inline spans; it's also fully queryable with open-source query languages like GROQ.

Portable Text isn't design to be written or be easily readable in its raw form; it's designed to be produced by an user interface, manipulated by code, and to be serialized and rendered where ever it needs to go. For example, you can use it to express content for voice assistants.

 { "style": "normal", "_type": "block", "children": [ { "_type": "span", "marks": ["a-key", "emphasis"], "text": "some text" } ], "markDefs": [ { "_key": "a-key", "_type": "markType", "extraData": "some data" } ] }

An interesting side-effect of turning block content into structured data is exactly that: It becomes data! And data can be queried and processed. That can be highly useful and practical, and it lets you ask your content repository questions that would be otherwise harder and more errorprone in formats like Markdown.

For example, if I for some reason wanted to know what programming languages we've covered in examples on Sanity's blog, that's within reach with a short query. You can imagine how trivial it is to build specialized tools and views on top of this that can be helpful for content editors:

 distinct( *["code" in body[]._type] .body[_type == "code"] .language ) // output [ "text", "javascript", "json", "html", "markdown", "sh", "groq", "jsx", "bash", "css", "typescript", "tsx", "scss" ]

Example: Get a distinct list of all programming languages that you have code blocks of.

Portable Text is also serializable, meaning that you can recursively loop through it, and make an API that exposes its nodes in callback functions mapped to block types, marked-up spans, and so on. We have spent the last years learning a lot about how it works and how it can be improved, and plan to take it to 1.0 in the near future. The next step is to offer an editor experience outside of Sanity Studio. As we have learned from Markdown, the design intent is important.

Of course, whatever the alternative to markdown is, it doesn't need to be Portable Text, but it needs to be portable text. And it needs to share a lot of its characteristics. There have been a couple of other JSON-based block content format popping up the last few years, but a lot of them seem to bring with them a lot of “HTMLism.” The convenience is understandable, since a lot of content still ends up on the web serialized into HTML, but the convenience limits the portability and the potential for reuse.

You can disregard my short pitch for something we made at Sanity, as long as you embrace the idea of structured content and formats that let you move between systems in a fundamental manner. For example, a goal for Portable Text will be improved compatibility with Unified.js, so it's easier to travel between formats.

Embracing The Legacy Of Markdown

Il markdown in tutti i suoi sapori, interpretazioni e fork non andrà via. I suspect that plain text files will always have a place in developers' note apps, blogs, docs, and digital gardens. As a writer who has used markdown for almost two decades, I've become accustomed to “markdown shortcuts” that are available in many rich text editors and am frequently stumped from Google Docs' lack of markdownisms. But I'm not sure if the next generation of content creators and even developers will be as bought in on markdown, and nor should they have to be.

I also think that markdown captured a culture of savvy tinkerers who love text, markup, and automation. I'd love to see that creative energy expand and move into collectively figuring out how we can make better and more accessible block content editors, and building out an ecosystem around specifications that can express block content that's agnostic to HTML. Structured data formats for block content might not have the same plain text ergonomics, but they are highly “tinkerable” and open for a lot of creativity of expression and authoring.

If you are a developer, product owner, or a decision-maker, I really want you to be circumspect of how you want to store and format your content going forward. If you're going for markdown, at least consider the following trade-offs:

Markdown is not great for the developer experience in modern stacks :

• It can be a hassle to parse and validate, even with great tooling.
• Even if you adopt CommonMark, you aren't guaranteed compatibility with tooling or people's expectations.
• It's not great for structured content, YAML frontmatter only takes you so far.

Markdown is not great for editorial experience :

• Most content creators don't want to learn syntax, their time is better spent on other things.
• Most markdown systems are brittle, especially when people get syntax wrong (which they will).
• It's hard to accommodate great collaborative user experiences for block content on top of markdown.

Markdown is not great in block content age , and shouldn't be forced into it. Block content needs to:

• Be untangled from HTMLisms and presentation agnostic.
• Accommodate structured content, so it can be easily used wherever it needs to be used.
• Have stable specification(s), so it's possible to build on.
• Support real-time collaborative systems.

What's common for people like me who challenge the prevalence of markdown, and those who are really into the simple way of expressing text formating is an appreciation of how we transcribe intent into code. That's where I think we can all meet. But I do think it's time to look at the landscape and the emerging content formats that try to encompass modern needs, and ask how we can make sure that we build something that truly caters to editorial experience, and that can speak to developer experience as well.

I want to express my gratitude to Titus Wormer (@wooorm) for his insightful feedback on my first draft of this post, and for the great work he and the Unified.js team have done for the web community.