Markdown Üzerine Düşünceler

Markdown, çoğumuz için ikinci doğamızdır. Geriye dönüp baktığımda, John Gruber'in Aaron Swartz ile dil üzerinde işbirliği yaptıktan sonra 2004'te ilk Perl tabanlı ayrıştırıcısını piyasaya sürmesinden kısa bir süre sonra Markdown'da yazmaya başladığımı hatırlıyorum.

Markdown'ın sözdizimi tek bir amaç için tasarlanmıştır: Web için yazmak için bir format olarak kullanılmak.

— John Gruber

Bu neredeyse 20 yıl önce - evet! HTML için daha yazar ve okuyucu dostu bir sözdizimi olarak başlayan şey, programcılar ve teknoloji konusunda bilgili insanlar için teknik nesirlerin nasıl yazılacağı ve saklanacağı konusunda bir sevgili haline geldi.

Markdown, geliştirici ve metin tamirci kültürü için bir belirteçtir. Ancak piyasaya sürülmesinden bu yana dijital içerik dünyası da değişti. Markdown bazı şeyler için hala iyi olsa da, artık içerik için gidilmesi gerektiğine inanmıyorum.

Bunun iki ana nedeni vardır:

1. Markdown, günümüzün içerik ihtiyaçlarını karşılamak için tasarlanmamıştır.
2. Markdown, editoryal deneyimi geri tutar.

Tabii ki, bu duruş, yapılandırılmış içerik için bir platform için çalışmaktan etkilenir. Sanity.io'da günlerimizin çoğunu, veri olarak içeriğin nasıl birçok değeri ortaya çıkardığını düşünerek geçiriyoruz ve editör deneyimlerini, insanlara nasıl zaman kazandıracağımızı ve dijital içerikle çalışmayı nasıl keyifli hale getireceğimizi derinlemesine düşünerek çok zaman harcıyoruz. . Yani oyunda dış görünüm var, ancak içerik için gidilecek format olarak Markdown'a karşı çıksam da, bunun önemi, uygulaması ve mirası için hala derin bir takdirim olduğunu betimleyebildiğimi umuyorum.

Şu anki işimden önce, müşterimizin içeriğini sunum ve karmaşık veri modellerine (evet, hatta açık kaynaklı olanlara) yerleştirerek kilitleyen CMS'lerle kelimenin tam anlamıyla savaşmak zorunda olduğumuz bir ajansta teknoloji danışmanı olarak çalışıyordum. İnsanların Markdown sözdizimi ile mücadele ettiğini ve editör ve içerik yaratıcısı olarak işlerinde motivasyonlarının düştüğünü gözlemledim. İnsanların sözdizimini kullanmak için zamanları veya motivasyonları olmadığı için hiç kullanılmayan özel etiket oluşturucular oluşturmak için saatler (ve müşterinin parasını) harcadık. Ben bile yüksek motivasyona sahipken, bileşen tabanlı Markdown uygulaması çok fazla sürtüşmeye neden olduğu için açık kaynaklı belgelere katkıda bulunmaktan vazgeçtim.

Ama madalyonun diğer yüzünü de görüyorum. Markdown, etkileyici bir ekosistemle birlikte gelir ve bir geliştiricinin bakış açısından, kod okumaya alışmış kişiler için düz metin dosyalarına zarif bir sadelik ve ayrıştırması kolay sözdizimi vardır. Bir zamanlar akademik yazım için Sublime Text'de etkileyici bir MultiMarkdown -> LaTeX -> real-time-PDF-preview-pipeline oluşturmak için günler harcadım. Ve bir README.md dosyasının bir kod düzenleyicide açılıp düzenlenebilmesi ve GitHub'da güzel bir şekilde oluşturulabilmesi mantıklıdır. Markdown'ın bazı kullanım durumlarında geliştiricilere kolaylık sağladığına şüphe yok.

Bu nedenle, Markdown'a karşı tavsiyemi, ilk etapta neden tanıtıldığına bakarak ve web'deki bazı önemli içerik gelişmelerini gözden geçirerek oluşturmak istiyorum. Birçoğumuz için Markdown'ın "var olan bir şey" olarak kabul ettiğimiz bir şey olduğundan şüpheleniyorum. Ancak tüm teknolojinin bir tarihi vardır ve insan etkileşiminin bir ürünüdür. Okuyucu olarak, başkalarının kullanması için teknoloji geliştirdiğinizde bunu hatırlamak önemlidir.

Tatlar ve Spesifikasyonlar

Markdown, web yayıncılığının HTML yazmayı gerektirdiği bir çağda web yazarlarının makalelerle çalışmasını kolaylaştırmak için tasarlanmıştır. Bu nedenle amaç, HTML'de metin biçimlendirme ile arayüz oluşturmayı kolaylaştırmaktı. Gezegendeki ilk basitleştirilmiş sözdizimi değildi, ancak yıllar içinde en çok ilgiyi çeken sözdizimiydi. Bugün, Markdown'ın kullanımı, HTML okumanın ve yazmanın daha basit bir yolu olmak, düz metni birçok farklı bağlamda işaretleme yaklaşımı olmak için tasarım amacının çok ötesinde büyüdü. Elbette, teknolojiler ve fikirler amaçlarının ötesinde gelişebilir, ancak bugün Markdown kullanımındaki gerilim, bu kökene ve tasarımına getirilen kısıtlamalara kadar takip edilebilir.

Sözdizimine aşina olmayanlar için aşağıdaki HTML içeriğini alın:

 <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>

Markdown ile aynı biçimlendirmeyi şu şekilde ifade edebilirsiniz:

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

Teknolojinin benimsenmesinin, gelişme ve ona özellikler ekleme baskısı ile birlikte gelmesi bir doğa kanunu gibidir. Markdown'ın artan popülaritesi, insanların onu kullanım durumlarına uyarlamak istedikleri anlamına geliyordu. Dipnot ve tablo desteği gibi daha fazla özellik istediler. Orijinal uygulama, o zamanlar tasarım amacının ne olduğu için makul olan, inatçı bir duruşla geldi:

Markdown'ın sözdiziminin kapsamına girmeyen herhangi bir işaretleme için, sadece HTML'nin kendisini kullanırsınız. Markdown'dan HTML'ye geçiş yaptığınızı belirtmek için önsöz eklemenize veya sınırlandırmanıza gerek yoktur; sadece etiketleri kullanın.

— John Gruber

Başka bir deyişle, bir tablo istiyorsanız, <table></table> kullanın. Bunun orijinal uygulama için hala geçerli olduğunu göreceksiniz. Markdown'ın manevi haleflerinden biri olan MDX, aynı prensibi benimsedi, ancak onu JS tabanlı bir şablonlama dili olan JSX'e genişletti.

Markdown'dan Markdown'a mı?

Markdown'ın pek çokları için çekiciliği HTML ile bağlantısı değil, düz metnin ergonomisi ve biçimlendirme için basit sözdizimi gibi görünebilir. Bazı içerik oluşturucular, Markdown'ı web'deki basit makaleler dışındaki kullanım durumları için kullanmak istedi. MultiMarkdown gibi uygulamalar, düz metin dosyaları kullanmak isteyen ancak daha fazla özelliğe ihtiyaç duyan akademik yazarlar için kolaylıklar sağladı. Yakında, Markdown sözdizimini mutlaka HTML'ye dönüştürmeden veya hatta bir depolama biçimi olarak markdown sözdizimini kullanmadan kabul eden bir dizi yazma uygulamasına sahip olacaksınız.

Pek çok uygulamada, size sınırlı sayıda biçimlendirme seçeneği sunan düzenleyiciler bulacaksınız ve bunlardan bazıları orijinal sözdiziminden daha çok “ilham almıştır”. Aslında, bu makalenin bir taslağı hakkında aldığım geri bildirimlerden biri, “Markdown”un artık çok yaygın hale geldiği için küçük harfli olması ve orijinal uygulamadan farklı olması gerektiğiydi. Çünkü indirim olarak tanıdığımız şey de çok çeşitli hale geldi.

CommonMark: İşaretlemeyi Uysallaştırma Girişimi

Dondurma gibi, Markdown da bazıları diğerlerinden daha popüler olan birçok lezzetle gelir. İnsanlar orijinal uygulamayı çatallamaya ve ona özellikler eklemeye başladığında iki şey oldu:

1. Bir yazar olarak Markdown ile yapabilecekleriniz ve yapamayacaklarınız daha tahmin edilemez hale geldi.
2. Yazılım geliştiriciler, yazılımları için hangi uygulamanın benimseneceğine karar vermek zorundaydı. Orijinal uygulama ayrıca, onu programlı olarak kullanmak isteyenler için sürtüşme ekleyen bazı tutarsızlıklar içeriyordu.

Bu, Markdown'ın uygun bir spesifikasyona resmileştirilmesi hakkında konuşmaları başlattı. Gruber'in direndiği ve ilginç bir şekilde hala yaptığı bir şey, çünkü insanların Markdown'ı farklı amaçlar için kullanmak istediklerini ve "Hiçbir sözdizimi herkesi mutlu edemez". Markdown'ın farklı ihtiyaçları karşılamak için gelişen bir özellik olan HTML'ye çevrildiğini düşünürsek bu ilginç bir duruş.

Markdown'ın orijinal uygulaması "BSD benzeri" bir lisans kapsamında olsa da, "Markdown adı veya katkıda bulunanların adları, önceden özel yazılı izin alınmadan bu yazılımdan türetilen ürünleri desteklemek veya tanıtmak için kullanılamaz. ” Pazarlama malzemelerinin bir parçası olarak "Markdown" kullanan çoğu ürünün bu yazılı izni almadığını güvenle söyleyebiliriz.

Markdown'ı paylaşılan bir spesifikasyona getirmek için en başarılı girişim, bugün CommonMark olarak bilinen şeydir. Başkanlığını Jeff Atwood (Stack Overflow ve Discourse'ın kurucu ortaklarıyla tanınır) ve John McFarlane (Berkely'de Babelmark ve pandoc'un arkasında olan bir felsefe profesörü) yönetiyordu. Başlangıçta “Standart Markdown” olarak piyasaya sürdüler, ancak Gruber'den eleştiri aldıktan sonra bunu “CommonMark” olarak değiştirdiler. Duruşu tutarlı olan Markdown'ın amacı , HTML'ye çeviren basit bir yazarlık sözdizimi olmaktır:

@davewiner Ve CommonMark ile kusurlu olan budur. Birincil hedef olarak programcılar için işleri kolaylaştırmak istiyorlar. Asıl noktayı kaçırıyorlar.

— John Gruber (@gruber) 8 Eylül 2014

Sanırım bu, Markdown'ın kamusal alana girdiği noktayı da işaret etti. CommonMark, "Markdown" olarak markalı olmasa da (lisanslandırmaya göre) bu belirtim tanınır ve "markdown" olarak anılır. Bugün, Discourse, GitHub, GitLab, Reddit, Qt, Stack Overflow ve Swift gibi yazılımlar için temel uygulama olarak CommonMark'ı bulacaksınız. unified.js gibi projeler, sözdizimlerini Soyut Sözdizimi Ağaçlarına çevirerek köprüler, ayrıca işaretleme desteği için CommonMark'a güvenirler.

CommonMark, markdown'ın nasıl uygulandığı konusunda pek çok birleştirme getirdi ve birçok yönden programcıların markdown desteğini yazılıma entegre etmesini kolaylaştırdı. Ancak, markdown'ın nasıl yazıldığı ve kullanıldığı konusunda aynı birleştirmeyi getirmedi. GitHub Aromalı Markdown'ı (GFM) alın. CommonMark'ı temel alır ancak daha fazla özellikle genişletir (tablolar, görev listeleri ve üstü çizili). Reddit, “Reddit Flavored Markdown”ı “GFM'nin bir varyasyonu” olarak tanımlar ve spoiler işaretlemek için sözdizimi gibi özellikler sunar. Hem CommonMark'ın hem de Gruber'in arkasındaki grubun haklı olduğu sonucuna güvenle varabiliriz: ortak özelliklere kesinlikle yardımcı olur, ancak evet, insanlar Markdown'ı farklı belirli şeyler için kullanmak ister.

Biçimlendirme Kısayolu Olarak İşaretleme

Gruber, Markdown'ı ortak bir spesifikasyona resmileştirmeye direndi çünkü bunun onu yazarlar için daha az bir araç ve daha çok programcılar için bir araç haline getireceğini varsayıyordu. Bir belirtimin geniş çapta benimsenmesine rağmen, farklı bağlamlarda tahmin edilebilir şekilde aynı şekilde çalışan bir sözdizimini otomatik olarak almadığımızı zaten gördük. Ve CommonMark gibi popüler olan özelliklerin de sınırlı başarısı var. Bunun bariz bir örneği, Slack'in *this* 'yu vurgu/italik yerine güçlü/kalın olarak çeviren ve [link](https://slack.com) sözdizimini desteklemeyen, ancak <link|https://slack.com> kullanan Slack'in markdown uygulamasıdır ( mrkdown ). bunun yerine <link|https://slack.com> .

Notion, Dropbox Paper, Craft ve bir dereceye kadar Google Dokümanlar gibi yazılımlardaki zengin metin düzenleyicilerinde biçimlendirmeyi başlatmak için asterisk space sözdizimini kullanabileceğinizi de göreceksiniz (örn. maddeli liste). Neler destekleniyor ve nelere çevriliyor, ne değişiyor. Bu nedenle, bu uygulamalarda mutlaka kas hafızanızı yanınıza alamazsınız. Bazı insanlar için bu iyidir ve uyum sağlayabilirler. Diğerleri için bu bir kağıt kesiğidir ve bu özellikleri kullanmalarını engeller. Hangi soruyu soruyor, Markdown kim için tasarlandı ve bugün kullanıcıları kimler?

Markdown Kullanıcıları Kimler Olabilir?

Farklı kullanım durumları, izleyiciler ve kullanıcılarının kim olduğu kavramları arasındaki bir gerilimde indirimin var olduğunu gördük. Özellikle HTML konusunda yetkin web yazarları için bir biçimlendirme dili olarak başlayan şey, geliştirici türlerinin sevgilisi haline geldi.

2014'te web yazarları, dosyaları Perl ve FTP'deki ayrıştırıcılar aracılığıyla taşımaktan uzaklaşmaya başladı. WordPress, Drupal ve Moveable Type (Gruber'in hala kullandığına inanıyorum) gibi İçerik Yönetim Sistemleri (CMS'ler), web yayıncılığı için go-to-araçlar haline gelmek için istikrarlı bir şekilde büyüdü. Web yazarlarının tarayıcılarında kullanabilecekleri zengin metin editörleri gibi olanaklar sunuyorlardı.

Bu zengin metin düzenleyicileri, HTML ve Markdown'ı altta yatan zengin metin sözdizimi olarak varsaydılar, ancak bu sözdizimini düzenleyiciye eklemek için düğmeler ekleyerek bilişsel yükün bir kısmını ortadan kaldırdılar. Ve giderek, yazarlar HTML konusunda bilgili değildi ve olmak zorunda da değildi. Bahse girerim 2010'larda CMS'lerle web geliştirme yaptıysanız, muhtemelen insanlar doğrudan Word'den yapıştırdıklarında bu editörler aracılığıyla gelen "önemsiz HTML" ile uğraşmak zorunda kaldınız.

Bugün, Markdown'ın birincil kullanıcılarının geliştiriciler ve kodla ilgilenen insanlar olduğunu tartışacağım. Yazılımları teknik departmanların dışında daha fazla kişi tarafından kullanıldığında, Slack'in WYSIWYG varsayılan giriş modu yapması tesadüf değildir. Ve bunun tartışmalı bir karar olduğu ve bir seçenek olarak geri getirmek zorunda kaldıkları gerçeği, geliştirici topluluğunda markdown sevgisinin ne kadar derin olduğunu gösteriyor. Slack'in bunu herkes için daha kolay ve erişilebilir hale getirmeye çalışması pek kutlanmadı. Ve işin püf noktası da bu.

Markdown'ın İdeolojisi

Markdown'ın lingua franca yazma stili haline gelmesi ve çoğu web sitesi çerçevesinin neye hizmet ettiği gerçeği, bunu yayınlama konusunda biraz ürkek olmamın ana nedenidir. Genellikle doğal ve yadsınamaz bir iyi olarak konuşulur. Markdown, geliştirici dostu olmanın bir özelliği haline geldi. Akıllı ve yetenekli insanlar, her türlü bağlamda fiyat indirimi sağlamak için çok fazla kolektif saat harcadılar. Dolayısıyla hegemonyasına meydan okumak elbette bazılarını rahatsız edecektir. Ama umarım, genellikle hafife alınan bir şey hakkında bazı verimli tartışmalar doğurabilir.

Benim izlenimim, insanların Markdown ile ilişkilendirdiği geliştirici dostluğunun çoğunlukla 3 faktörle ilgisi olduğu yönünde:

1. Düz metin dosyasının rahat soyutlaması.
2. Bir takım ekosistemi var.
3. İçeriğinizi geliştirme iş akışınıza yakın tutabilirsiniz.

Bu tutumların yanlış olduğunu söylemiyorum, ancak bazı mantıksız varsayımlar ve takaslarla geldiklerini önereceğim.

Düz Metin Dosyasının Basit Zihinsel Modeli

Veritabanları harika şeylerdir. Ancak, ön uç geliştiriciler için zor ve erişilemez olma konusunda da kazanılmış bir üne sahipler. Arka uç kodundan ve veritabanlarından çekinen birçok harika geliştirici tanıyorum çünkü bunlar karmaşıklığı temsil ediyor ve zaman harcamak istemiyorlar. Kurulumdan sonra veritabanıyla uğraşmak zorunda kalmamanız için kutunun dışında pek çok şey yapan WordPress ile bile, ayağa kalkmanın ve çalıştırmanın yükü vardı.

Bununla birlikte, düz metin dosyaları daha somuttur ve gerekçelendirilmesi oldukça basittir (dosya yönetimine alıştığınız sürece). Özellikle bazı özel yapılara sahip ilişkisel bir veritabanında içeriğinizi birden çok tabloya bölecek bir sistemle karşılaştırıldığında. Resimler ve bağlantılar içeren basit zengin metin içeren blog gönderileri gibi sınırlı kullanım durumları için, işaretleme işi halledecektir. Dosyayı kopyalayıp bir klasöre yapıştırabilir veya git'te kontrol edebilirsiniz. Dosyaların somutluğu nedeniyle içerik sizinkini hisseder. Microsoft'un sahip olduğu ve dolayısıyla hizmet koşulları kapsamında kar amacı gütmeyen bir Hizmet Olarak Yazılım olan GitHub'da barındırılsalar bile.

Yerel gelişiminizi devam ettirmek ve onu uzaktan kumanda ile senkronize etmek için gerçekten yerel bir veritabanını döndürmek zorunda olduğunuz çağda, düz metin dosyalarının çekiciliği anlaşılabilir. Ancak bu dönem, bir hizmet olarak arka uçların ortaya çıkmasıyla hemen hemen gitti. Fauna, Firestore, Hasura, Prisma, PlanetScale ve Sanity's Content Lake gibi hizmetler ve araçlar, geliştirici deneyimine büyük yatırım yapar. Yerel kalkınma üzerine geleneksel veritabanlarını işletmek bile, sadece 10 yıl öncesine kıyasla daha az güçlük haline geldi.

Düşünürseniz, bir veritabanında barındırılıyorsa içeriğinize daha az mı sahip olursunuz? Ve geliştiricilerin veritabanlarıyla uğraşma deneyimi, SaaS araçlarının ortaya çıkmasıyla önemli ölçüde basitleşmedi mi? Ve tescilli veritabanı teknolojisinin içeriğinizin taşınabilirliğini etkilediğini söylemek doğru olur mu? Bugün, esasen bir Postgres veritabanını sysadmin becerileri olmadan başlatabilir, tablolarınızı ve sütunlarınızı oluşturabilir, içeriğinizi içine koyabilir ve istediğiniz zaman bir .sql dökümü olarak dışa aktarabilirsiniz.

İçeriğin taşınabilirliği, bu içeriği ilk etapta nasıl yapılandırdığınızla çok daha fazla ilgilidir. WordPress'i alın, tamamen açık kaynaklıdır, kendi DB'nizi barındırabilirsiniz. Hatta XML'de standartlaştırılmış bir dışa aktarma biçimine sahiptir. Ancak, olgun bir WordPress kurulumundan çıkmayı deneyen herkes, WordPress'ten uzaklaşmaya çalışıyorsanız bunun ne kadar az yardımcı olduğunu bilir.

Geniş Bir Ekosistem… Geliştiriciler İçin

Geniş indirim ekosistemine zaten değindik. Çağdaş web sitesi çerçevelerine bakarsanız, çoğu markdown'ı birincil içerik formatı olarak kabul eder, bazıları ise tek formattır. Örneğin, Smashing Magazine tarafından kullanılan statik site oluşturucu Hugo, sayfalara ayrılmış yayın için hala işaretleme dosyaları gerektirir. Yani, Smashing Magazine makaleleri depolamak için bir CMS kullanmak isterse, markdown dosyalarıyla etkileşime girmesi veya tüm içeriği markdown dosyalarına dönüştürmesi gerekir. Next.js, Nuxt.js, VuePress, Gatsby.js vb. belgelerine bakarsanız, işaretleme belirgin şekilde görünecektir. Aynı zamanda GitHub'daki README -files için varsayılan sözdizimidir ve onu Çekme İsteği notlarında ve yorumlarında biçimlendirme için de kullanır.

İndirimin ergonomisini kitlelere ulaştırmak için bazı onurlu girişimler var. Netlify CMS ve TinaCMS (Ormancılığın manevi torunu), size, editörler için markdown sözdiziminin çoğunlukla soyutlandığı kullanıcı arayüzleri sağlayacaktır. Genellikle, CMS'lerdeki markdown tabanlı düzenleyicilerin, biçimlendirme için size önizleme işlevi sağladığını göreceksiniz. Notion'ınki gibi bazı editörler, markdown sözdizimini yapıştırmanıza izin verecek ve onu yerel biçimlendirmelerine çevirecekler. Ama bence, indirim için yenilik yapmaya giden enerjinin, söz dizimini yazmayan insanları desteklemediğini söylemek güvenli. Olduğu gibi yığını damlatmadı.

İçerik İş Akışları Veya Geliştirici İş Akışları?

Çerçeveler genellikle yerleşik ayrıştırma ile birlikte geldiğinden veya genellikle başlangıç ​​kodunun bir parçası olarak sunduğundan, kendi blogunu oluşturan bir geliştirici için markdown dosyalarını kullanmak, onu kurma ve çalıştırma ek yükünün bir kısmını azaltır. Ve kaydolmak için ekstra bir şey yok. Bu dosyaları kodunuzla birlikte işlemek için git'i kullanabilirsiniz. Git diffs konusunda rahatsanız, programlamada alıştığınız gibi revizyon kontrolüne bile sahip olacaksınız. Başka bir deyişle, markdown dosyaları düz metin olduğundan, geliştirici iş akışınızla entegre edilebilirler.

Ancak bunun ötesinde, geliştirici deneyimi kısa sürede daha karmaşık hale gelir. Ve sonunda, içerik oluşturucular olarak ekibinizin kullanıcı deneyiminden ödün veriyorsunuz ve kendi geliştirici deneyimimiz, tasarım amacının çok ötesinde sorunları çözmek için indirime takılıp kalıyor.

Evet, içerik ekibinizin git'i kullanmasını ve değişikliklerini kontrol etmesini sağlamanız harika olabilir, ancak aynı zamanda bu onların zamanlarını en iyi şekilde kullanmaları mı? Editörlerinizin birleştirme çakışmalarına karşı mı yoksa dalları nasıl yeniden temellendireceklerini gerçekten istiyor musunuz? Git, onu her gün kullanan geliştiriciler için yeterince zor. Ve bu kurulum, esas olarak içerikle çalışan kişiler için gerçekten en iyi iş akışını temsil ediyor mu? Bu, geliştirici deneyiminin editör deneyimini gölgede bıraktığı bir durum değil mi ve kullanıcılar için daha iyi bir şey yapmak için harcanabilecek maliyet, zaman ve çaba değil mi?

İçerik ve düzenleme ortamlarından beklentiler ve ihtiyaçlar geliştiğinden, markdown'ın bunu bizim için yapacağını düşünmüyorum. Geliştirici ergonomisinin bir kısmının geliştirici olmayanları nasıl desteklediğini anlamıyorum ve geliştiriciler için bile, markdown'ın kendi içerik oluşturmamızı ve ihtiyaçlarımızı geride bıraktığını düşünüyorum. Çünkü web'deki içerik 2000'li yılların başından itibaren önemli ölçüde değişti.

Paragraflardan Bloklara

Daha karmaşık şeyler istiyorsanız, Markdown her zaman HTML'yi devre dışı bırakma seçeneğine sahipti. Bu, yazar aynı zamanda web yöneticisi olduğunda veya en azından HTML'yi bildiğinde işe yaradı. Web siteleri genellikle HTML ve CSS olduğu için de işe yaradı. Web sitelerini tasarlama şekliniz çoğunlukla tam sayfa düzenleri oluşturmaktı. Markdown'ı HTML işaretlemesine dönüştürebilir ve bunu style.css dosyanızın yanına koyabilirsiniz. Tabii ki, 2000'lerde CMS'lerimiz ve statik site oluşturucularımız vardı, ancak çoğunlukla aynı şekilde çalıştılar, HTML içeriğini şablonların içine, bileşenler arasında herhangi bir "sahne" geçirmeden ekleyerek.

Ancak çoğumuz artık eski günlerdeki gibi HTML yazmıyoruz. Web'deki içerik, çoğunlukla basit zengin metin biçimlendirmesine sahip makalelerden, oluşturulmuş multimedyaya ve genellikle kullanıcı etkileşimli özel bileşenlere ("haber bültenine kaydolma harekete geçirici mesaj" demenin süslü bir yolu) dönüşmüştür.

Makalelerden Uygulamalara

2010'ların başında, Web 2.0 en parlak dönemindeydi ve Hizmet Olarak Yazılım şirketleri web'i veri ağırlıklı uygulamalar için kullanmaya başladı. Etkileşimli kullanıcı arayüzlerini yönlendirmek için HTML, CSS ve JavaScript giderek daha fazla kullanılıyordu. Twitter açık kaynaklı Bootstrap, daha tutarlı ve esnek kullanıcı arayüzleri oluşturmaya yönelik çerçeveleri. Bu, web tasarımının “bileşenleşmesi” olarak adlandırabileceğimiz şeyi getirdi. Web için oluşturma şeklimizi temelden değiştirdi.

Bu çağda ortaya çıkan çeşitli CSS çerçeveleri (örneğin Bootstrap ve Foundation), esnek ve duyarlı kullanıcı arabirimleri oluşturmayı daha az zor hale getirmek için standartlaştırılmış sınıf adları ve varsayılan belirli HTML yapıları kullanma eğilimindeydi. Atomik Tasarımın web tasarım felsefesi ve Blok-Element-Değiştirici (BEM) gibi sınıf adı kuralları ile varsayılan, sayfa düzenini düşünmekten, sayfaları tekrarlanabilir ve uyumlu tasarım öğelerinin bir koleksiyonu olarak görmeye kaydırıldı.

Markdown içinde sahip olduğunuz içerik ne olursa olsun bununla uyumlu değil. İşaretleme ayrıştırıcılarını araya sokmanın tavşan deliğinden aşağı inmedikçe ve istediğiniz sözdizimini çıkarmak için ince ayar yapmadıysanız (bundan sonra daha fazlası). Markdown'ın bir stil sayfasıyla hedefleyeceğiniz yerel HTML öğelerinden oluşan basit, zengin metin makaleleri olarak tasarlanmasına şaşmamalı.

Bu, siteleri için içerik yönlendirmek için Markdown kullanan kişiler için hala bir sorundur.

Gömülü Web

Ancak içeriğimize de bir şey oldu. Onu yalnızca anlamsal <article> HTML etiketlerinin dışında bulmaya başlamakla kalmadık, aynı zamanda daha fazla şey içermeye başladı. İçeriğimizin çoğu LiveJournals ve bloglarımızdan çıkıp sosyal medyaya taşındı: Facebook, Twitter, tumblr, YouTube. İçerik parçalarını makalelerimize geri almak için onları gömebilmemiz gerekiyordu. HTML kuralı, video oynatıcıyı YouTube'dan kanalize etmek veya hatta metin paragraflarınız arasına bir tweet kutusu eklemek için <iframe> etiketini kullanmaya başladı. Bazı sistemler bunu "kısa kodlar" olarak soyutlamaya başladı, çoğu zaman hangi içerik bloğunu temsil etmesi gerektiğini ve bazı anahtar/değer niteliklerini belirlemek için bazı anahtar kelimeleri içeren parantezler. Örneğin, geliştirici, şablonlama dili sıvısından sözdiziminin Markdown düzenleyicisine eklenmesini etkinleştirmiş:

 {% youtube dQw4w9WgXcQ %}

Elbette bu, özelleştirilmiş bir Markdown ayrıştırıcısı kullanmanızı ve sözdizimi HTML'ye dönüştürüldüğünde doğru HTML'nin eklendiğinden emin olmak için özel bir mantığa sahip olmanızı gerektirir. Ve içerik oluşturucularınızın bu kodları hatırlaması gerekecek (bunları otomatik olarak eklemek için bir tür araç çubuğu yoksa). Ve bir parantez silinir veya bozulursa, bu siteyi bozabilir.

Peki ya MDX?

Blok içerik ihtiyacını çözme girişimi, "Bileşen dönemi için Markdown" sloganıyla sunulan MDX'tir. MDX, JSX şablonlama dilini ve JavaScript'i, markdown sözdiziminde geçmeli olarak kullanmanıza izin verir. Toplulukta, çeşitli sözdizimlerini Soyut Sözdizimi Ağaçlarına (AST'ler) ayrıştırma konusunda uzmanlaşmış Unified.js dahil olmak üzere, MDX çevresinde çok sayıda etkileyici mühendislik vardır, böylece programlı olarak kullanılmak üzere daha erişilebilir olurlar. İndirimin standartlaştırılmasının Unified.js arkasındaki kişiler ve kullanıcıları için işi daha basit hale getireceğini unutmayın, çünkü daha az uç vakaya hitap edecek.

MDX, bileşenleri Markdown'a entegre etme konusunda kesinlikle daha iyi geliştirici deneyimi getiriyor. Ancak daha iyi bir editör deneyimi getirmez, çünkü içerik üretimine ve düzenlemeye çok fazla bilişsel yük ekler:

 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" />

Sadece bu basit örnek için varsayılan bilgi miktarı önemlidir. ES6 modülleri, JavaScript değişkenleri, JSX şablonlama sözdizimi ve props, hex kodları ve veri türlerinin nasıl kullanılacağı hakkında bilgi sahibi olmanız ve hangi bileşenleri ve bunları nasıl kullanacağınızı bilmeniz gerekir. Ve doğru ve size bir nevi geri bildirim sağlayan bir ortamda yazmanız gerekiyor. MDX'in üzerinde daha erişilebilir yazma araçları olacağından hiç şüphem yok, ilk başta sorun olması gerekmeyen bir şeyi çözmek gibi geliyor.

MDX bileşenlerinizi nasıl oluşturduğunuz ve adlandırdığınız konusunda son derece titiz değilseniz, içeriğinizi belirli bir sunuma da bağlar. Sadece MDX ön sayfasından getirilen yukarıdaki örneği alın. Grafik için sabit kodlu bir renk altıgeni bulacaksınız. Sitenizi yeniden tasarladığınızda, bu renk yeni tasarım sisteminizle uyumlu olmayabilir. Tabii ki, sizi bunu soyutlamaktan ve prop color=”primary” kullanmaktan alıkoyan hiçbir şey yok, ancak araçta sizi böyle akıllıca kararlar almaya iten hiçbir şey de yok.

İçeriğinize belirli sunum endişelerini gömmek, giderek artan bir sorumluluk haline geldi ve içeriğinize uyum sağlamanın, yinelemenin ve hızlı bir şekilde hareket etmenin önüne geçecek bir şey haline geldi. Bir veritabanında içerik bulundurmaktan çok daha incelikli yollarla onu kilitler. Eklentileri olan olgun bir WordPress kurulumundan çıkmakla aynı yerde kalma riskiniz vardır. Yapı ve sunumu karıştırmak zahmetlidir.

Yapılandırılmış İçerik Talebi

Daha karmaşık siteler ve kullanıcı yolculukları ile aynı içeriği bir web sitesinde sunma ihtiyacını da görüyoruz. Bir e-ticaret sitesi işletiyorsanız, ürün bilgilerini tek bir ürün sayfasının dışında birçok yere gömmek istersiniz. Modern bir pazarlama sitesi işletiyorsanız, aynı kopyayı birden çok kişiselleştirilmiş görünümde paylaşabilmek istersiniz.

Bunu verimli ve güvenilir bir şekilde yapmak için yapılandırılmış içeriği uyarlamanız gerekecektir. Bu, içeriğinizin meta verilerle gömülmesi ve amaç için ayrıştırmayı mümkün kılacak şekilde yığınlanması gerektiği anlamına gelir. Bir geliştirici yalnızca "içerik" içeren "sayfa" görürse, bu, doğru şeyleri doğru yerlere eklemeyi çok zorlaştırır. Bir API veya sorgu ile tüm "ürün açıklamalarına" ulaşabilirlerse, bu her şeyi kolaylaştırır.

Markdown ile, sınıflandırmaları ve yapılandırılmış içeriği ya bir tür klasör organizasyonuyla (aynı içeriği birden çok taksonomiye koymayı zorlaştırır) ifade etmekle sınırlıdır ya da sözdizimini başka bir şeyle artırmanız gerekir.

Markdown dosyaları için oluşturulmuş eski bir Statik Site Üreticisi (SSG) olan Jekyll, üstteki üç çizgi arasında YAML (kapsam oluşturmak için boşluk kullanan basit bir anahtar/değer biçimi) kullanarak gönderilere meta veri eklemenin bir yolu olarak “Ön Madde”yi tanıttı. dosyanın. Yani, şimdi başa çıkmanız gereken iki sözdiziminiz olacak. YAML aynı zamanda yaramaz olmakla da ünlüdür (özellikle Norveçliyseniz). Bununla birlikte, diğer SSG'ler, içerik formatı olarak markdown kullanan git tabanlı CMS'lerin yanı sıra bu kuralı benimsemiştir.

Yapılandırılmış içeriğin sağladığı avantajlardan bazılarını elde etmek için düz dosyalarınıza ek sözdizimi eklemeniz gerektiğinde, buna gerçekten değip değmediğini merak etmeye başlayabilirsiniz. Ve formatın kimler için olduğu ve kimlerin hariç tutulduğu.

Düşünürseniz, web'de yaptığımız çoğu şey yalnızca içerik tüketmekle kalmıyor, onu biz oluşturuyoruz! Şu anda bu uzun makaleyi tarayıcımdaki gelişmiş bir kelime işlemcide yazıyorum.

Modern içerik uygulamalarında da blok içerik yazabilmeniz gerektiğine dair artan bir beklenti var. İnsanlar, çalışan ve güzel görünen ve özel sözdizimi öğrenmeniz gerekmeyen keyifli kullanıcı deneyimlerine alışmaya başladılar. Medium, web'de keyifli ve sezgisel içerik oluşturabileceğiniz fikrini popüler hale getirdi. Ve "kavram"dan bahsetmişken, popüler not uygulaması tamamen blok içeriğine girdi ve kullanıcıların çok çeşitli farklı türlerden maksimumu karıştırmasına izin veriyor. Bu blokların çoğu, işaretlemenin ve HTML'nin yerel öğelerinin ötesine geçer.

Dikkate değerdir ki, içeriklerini merakla beklenen API'leri aracılığıyla erişilebilir hale getirme sürecini açıklayan Notion, içerik biçimini seçerken şuna dikkat çeker:

Bir Markdown düzenleyicisinden gelen belgeler, genellikle başka bir uygulamada farklı şekilde ayrıştırılır ve işlenir. Tutarsızlık, basit belgeler için yönetilebilir olma eğilimindedir, ancak çoğu, yaygın olarak kullanılan herhangi bir Markdown uygulamasında desteklenmeyen, Notion'un zengin blok kitaplığı ve satır içi biçimlendirme seçenekleri için büyük bir sorundur.

Notion, yapılandırılmış veriler olarak ifade etmelerine izin veren JSON tabanlı bir formatla gitti. Argümanları, Notion'ın API'lerinden çıkan blok içeriğinin kendi sunumlarını oluşturmak isteyen geliştiriciler için etkileşimi daha kolay ve daha öngörülebilir hale getirmesidir.

Markdown Değilse, O Zaman Ne?

Markdown'ın öne çıkmasının dijital içerik için yeniliği ve ilerlemeyi engellediğinden şüpheleniyorum. Bu nedenle, içeriği depolamanın birincil yolu olarak seçmeyi bırakmamız gerektiğini savunduğumda, onun yerine neyin geçeceğine dair net bir cevap vermek zor. Ancak bildiğimiz şey, modern içerik formatlarından ve yazma araçlarından ne beklememiz gerektiğidir.

Erişilebilir Yazma Deneyimlerine Yatırım Yapalım

Markdown'ı kullanmak, sözdizimini ve modern beklentilerle pratik olması için genellikle birden çok sözdizimini ve ısmarlama etiketi öğrenmenizi gerektirir. Bugün bu, çoğu insana yüklenmek için tamamen gereksiz bir beklenti gibi geliyor. Keşke daha fazla enerjiyi, modern taşınabilir içerik formatları üreten erişilebilir ve keyifli editoryal deneyimler yapmaya yönlendirebilseydik.

Harika blok içerik editörleri oluşturmak herkesin bildiği gibi zor olsa da, kullanım durumunuza göre genişletilip özelleştirilebilecek birkaç uygun seçenek var (örneğin Slate.js, Quill.js veya Prosemirror). Ayrıca, bu araçların etrafındaki topluluklara yatırım yapmak da onların gelişimine daha fazla yardımcı olabilir.

Giderek artan bir şekilde, insanlar yazma araçlarının erişilebilir, gerçek zamanlı ve işbirliğine dayalı olmasını bekleyecek. Neden 2021'de web'de bir kaydet düğmesine basmak zorunda kalalım? Meslektaşınız belgeyi bir sekmede açmış olduğu için, bir belgede bir yarış durumu riske atmadan değişiklik yapmak neden mümkün olmasın? Yazarların birleştirme çatışmalarıyla uğraşmak zorunda kalmasını beklemeli miyiz? Ve içerik oluşturucuların mantıklı görsel olanaklara sahip yapılandırılmış içerikle çalışmasını kolaylaştırmamalı mıyız?

Biraz tartışmalı olmak gerekirse: son on yılın reaktif JavaScript çerçeveleri ve UI bileşenlerindeki yenilikleri, harika yazma araçları oluşturmak için mükemmeldir. Bunları Markdown'ı HTML'ye dönüştürmek ve daha sonra HTML çıktısı veren bir JavaScript şablon diline entegre etmek için soyut bir sözdizimi ağacına dönüştürmek için kullanmak yerine.

Blok İçeriği Bir Belirtimi İzlemeli

HTML için WYSIWYG editörlerinden bahsetmedim. Çünkü yanlış olan onlar. Modern blok içerik düzenleyicileri, tercihen belirli bir formatla birlikte çalışmalıdır. Yukarıda bahsedilen editörler, en azından daha taşınabilir bir şeye dönüştürülebilecek mantıklı bir dahili belge modeline sahiptir. 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

Tüm lezzetlerinde, yorumlarında ve çatallarında indirim gitmeyecek. 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.