DOM şablon API’sini benimsemek için doğru zaman

 (justinfagnani.com)
1 puan yazan GN⁺ 2025-06-28 | 1 yorum | WhatsApp'ta paylaş
  • Web platformunda, geliştiricilerin şu anda gerçekten ihtiyaç duyduğu bildirimsel bir şablon API’si eksik
  • Çoğu modern web framework’ünde şablonlama temel bir teknoloji olsa da, standart DOM API’sinde şablonları güvenli ve verimli biçimde oluşturup güncellemenin bir yolu yok
  • Bu nedenle kullanıcılar, geliştiriciler, framework’ler ve hatta platform düzeyinde rahatsızlıklar ve performans düşüşleri ortaya çıkıyor
  • Şablon API’sini hayata geçirmek için uygun zamandayız; son yıllarda framework deneyimi ve JavaScript özellikleri yeterince biriktiği için uygulama ve standardizasyon artık daha pratik
  • Şablon kimliği, sinyal tabanlı reaktivite gibi çeşitli modeller bir araya getirilerek yeni nesil şablon API’sinin yönü ortaya konuyor

Önerinin özeti

  • Bu yazı, web platformuna bildirimsel bir şablon API’si eklenmesine dair arka planı ve bunun neden gerekli olduğunu açıklıyor
  • DOM API’si güçlü olsa da, standart DOM’da veriye dayalı olarak birden fazla düğümü güvenli ve verimli şekilde oluşturup güncelleyecek bir şablon API’si bulunmuyor
  • React, Vue, Angular gibi başlıca framework’lerin tümünde bildirimsel şablonlama temel bir unsurdur ve geliştirici verimliliği, güvenlik, performans, statik analiz, sunucu tarafı render gibi birçok fayda sağlar
  • Şablon API’sinin yokluğu nedeniyle kullanıcılar, geliştiriciler, framework’ler ve platformun kendisi gereksiz karmaşıklık, güvenlik riskleri, performans kaybı ve giriş engelleriyle karşılaşıyor
  • Yazı, bu API’yi eklemek için zamanın doğru olduğunu savunuyor ve mevcut framework deneyimi ile modern JavaScript özelliklerinden yararlanarak kademeli standardizasyon öneriyor

Şablon ihtiyacı ve mevcut sorun

  • DOM API’si, web platformunun dinamik işlevlerini yönlendiren temel yapı taşıdır
  • Ancak standart DOM’da, veriden güvenli biçimde DOM ağacı tanımlamayı ve bunu verimli şekilde güncellemeyi sağlayan bildirimsel bir şablon yöntemi yok
  • Modern web framework’lerinin tamamı (React, Vue, Angular, Svelte vb.) bildirimsel şablonlama sunuyor
  • Bildirimsel şablonlamanın popüler olmasının nedenleri şunlar:
    • Buyruksal API’lere kıyasla daha iyi kullanılabilirlik ve okunabilirlik sağlaması
    • XSS güvenliğini güçlendirmesi; şablon içindeki verilerin otomatik olarak escape edilmesi
    • Verimli ve hızlı render performansı
    • Statik analiz, tip kontrolü, IntelliSense gibi olanaklarla geliştirici verimliliğini artırması
    • Sunucu tarafı render desteği

Mevcut durumun sorunları

  • Kullanıcılar: Kütüphane indirme ve render gecikmeleri nedeniyle ilk yükleme yavaşlıyor. İstemci tarafı kod boyutunun büyümesi UX’i kötüleştiriyor
  • Geliştiriciler: Şablon kullanmak için ayrı bir kütüphane (npm, CDN vb.) gerekiyor. Bu da giriş bariyeri ve standart dışı yük oluşturuyor
  • Framework’ler: Şablon motorunu kendilerinin uygulaması gerekiyor. Performans, özellikler ve kod boyutu arasında ağır ödünleşmeler var
  • Platform: Yerel uygulamalarla rekabette dezavantajlı. Flutter, SwiftUI gibi çözümler yerleşik şablon sistemleri sunuyor

Neden şimdi doğru zaman

  • Geçmişteki şablon girişimleri (E4X, E4H, HTML template literal’ları vb.) başarısız oldu; ancak o dönemde DOM güncellemeleri zayıf halkaydı
  • Son yıllarda framework’ler ve topluluk içinde şablon API’si için en iyi uygulamalar yeterince birikti
  • JavaScript tabanlı bir API önermek mümkün. Güncel standart JS’de tagged template literal zaten mevcut
  • Vanilla JS geliştiricileri ve web components topluluğu içinde de kullanışlı DOM manipülasyonuna yönelik talep artmaya devam ediyor
  • DOM Parts gibi düşük seviyeli primitive öneriler de paralel ilerliyor; ancak yüksek seviyeli bildirimsel bir API çok daha büyük fayda ve daha net bir gelişim yönü sunabilir

İyi şablon sözdizimine dair örnekler

  • Ana akım şablon sistemleri (React-JSX, Vue, Svelte, Angular vb.) özünde oldukça benzer bir işaretleme + binding sözdizimine dayanıyor
  • JS API tabanlı şablonlarda genellikle şablon ifadesi bir DOM tanımı döndürüyor, ayrı bir render fonksiyonu da bunu gerçek DOM’a uyguluyor
  • E4X gibi eski girişimler doğrudan DOM’un kendisini döndürdüğü için güncelleme modeli zayıf kalmıştı

JavaScript tabanlı şablon API’si olasılığı

  • Tagged template literal sayesinde, yeni bir JS özelliği eklemeden bir şablon API’si tasarlanabilir
  • JSX-to-Lit gibi çeşitli doğrulayıcı örnekler zaten mevcut

JSX entegrasyonu tartışması

  • JSX’in standardizasyonu, karmaşık anlam tanımları ve çalışma zamanı semantiklerini gerektirir. JSX’in kendisi yalnızca bir sözdizimidir
  • Günümüzdeki standart dışı JSX, saf bir sözdizimi dönüşümü olduğundan, gelecekte standart bir şablon API’si gelirse JSX -> template literal dönüşümü yapan derleyicilerle ilişkilendirilebilir
  • İleride gerçek bir JSX standardizasyonu olursa, şablon API’sine uygun veri türlerini kabul eden bir yapıya geçmek de kolay olur

HTML tabanlı şablon API’siyle ilişkisi

  • Pek çok geliştirici ve topluluk HTML tabanlı bir şablon sistemi talep ediyor
  • Ancak HTML tabanlı sistemlerde binding, ifade dili, kontrol yapıları gibi yeni sözdizimi ve ifade tasarımı gerektiğinden iş çok daha büyük
  • Lit gibi güncel framework’lerin HTML şablonlarından JS API’sine yönelmesinin arkasındaki neden de aynı
  • Bu nedenle önce JS tabanlı bir şablon API’sinin benimsenmesi, ardından zamanla HTML API’sine doğru kademeli genişleme daha olası görünüyor

Reaktivite uygulama deneyiminin olgunlaşması

  • VDOM diffing (React), şablon kimliği (Lit), sinyaller (fine-grained signals, Solid/Svelte/Vue vb.) gibi çeşitli reaktivite modelleri doğrulandı
  • VDOM tabanlı yaklaşım daha yavaşken, şablon kimliği + sinyal modeli birleşimi hızlı, verimli ve açıklayıcılığı yüksek bir yaklaşım sunuyor
  • Sinyal tabanlı modelde tüm verilerin sinyal içine sarılması gerekse de, normal verilerle birlikte kullanılmaları da mümkün

Gelişim yolu ve beklenen etkiler

  • Önerilen bildirimsel JS şablon API’si, vanilla JS, web components ve yeni framework’lerin tümüne doğrudan fayda sağlayabilir
  • Mevcut framework’ler için de derleme hedefi, çalışma zamanı backend’i veya doğrudan desteklenen API olarak kullanılabilir
  • Hem "yeniden render" yaklaşımını hem de sinyal tabanlı reaktiviteyi destekler
  • İleride HTML tabanlı bildirimsel şablonlara ve bildirimsel custom element’lere genişleme için bir temel oluşturur
    • API kapsamı dar ve nettir; mevcut API’lerle (ör. DOM Parts) entegrasyonu da kolaydır
  • Ancak yüzeydeki API ve sözdizimi basit görünse de, alttaki DOM Parts ve scheduler gibi uygulama alanı geniştir; standardizasyon, test ve işbirliği gerektirir

Kapanış

  • Yazar, bu öneriyi GitHub issue üzerinden tartışıyor ve platform mühendisleri başta olmak üzere topluluğun katılımını istiyor

İlgili okumalar

1 yorum

 
GN⁺ 2025-06-28
Hacker News görüşleri

  • "İyi bir şablon sözdiziminin ne olduğunu biliyoruz" denince gülmemin nedeni, gerçekte bu ölçüt üzerinde bile hiçbir zaman düzgün bir uzlaşma sağlanmamış olması. Bana göre şablonlarda simgesel(symbolic) bakış açısından çok görsel(visual) deneyim daha önemli. Eski Dreamweaver gibi araçların bu kadar başarılı olmasının nedeni de buydu. Pek çok tasarımcının öğrenmeye Photoshop gibi araçlarla başlaması da aynı bağlamda değerlendirilebilir. Bu girişimin XSLT’yi yeniden yapmaya çalışma gibi görünmesi biraz hayal kırıklığı yaratıyor. İyi yapılmamış yapıları iyi sonuçlarla birleştirmek, şablonlamanın özündeki problem. Ayrıca, label ve for gibi bağlantılı ama aynı ağaçta yer almayan varlıkları ifade etme sorunu da var. Elimde sihirli bir değnek olsa, her şeyi ille de standart belge düzenine tuhaf biçimde uydurmaya çalışmaktan vazgeçilmesini isterdim. Mutlak konumlandırma(absolute positioning) iyi kullanıldığında birçok UI sorununu verimli biçimde çözebilirken, neden tekrar tekrar bütün matematiksel hesaplamaları da makineye zorla yaptırmaya çalıştığımızı merak ediyorum

    • XSLT’yi yeniden yapmaya çalıştığı fikrine katılıyorum. XML’in kendisini pek sevmezdim ama XSLT gerçekten çok güçlüydü. Tarayıcılarda da hâlâ geniş ölçüde desteklenen bir özellik. XML yapılandırma(Configuration) ya da IPC gibi alanlarda belirgin zayıflıklar taşıyordu, ama güçlü bir işaretleme diline XSLT’nin dönüştürme gücü eklendiğinde ortaya çıkan potansiyel aslında yeterince değerlendirilemedi. XSLT’nin yaygınlaşmamasının nedeni, onun gerçekten deklaratif ve fonksiyonel bir DSL olmasıydı. Birçok kişi DSL’lerden olumlu söz eder ama pratikte bunlar çoğu zaman popüler bir dilin prosedürel anlamlarını ince bir katmanla sarmaktan öteye gitmiyor. İyi tasarlanmış DSL’lerle karmaşık işler basitçe çözülebilir; bence sorun insanların bunları öğrenmek için yeterince çaba göstermemesi

    • Asıl iyi bir şablon sözdiziminin görselliğin merkezde olması gerektiğini söylüyorsun; bu sonuca neden vardığını merak ediyorum. Bana daha çok HTML+CSS’in kendisine, yani üretim biçimine yönelik bir memnuniyetsizlik gibi geliyor. Mutlak konumlandırmadan neden söz ettiğini de merak ediyorum. Elbette doğru yerde yararlı, ama genel yerleşim için kullanıldığında yönetimi zorlaşıyor ve ekran boyutu ya da içerik miktarı değişince kolayca bozuluyor. Gazete düzenleri bile gerçekte metin ve tipografiye dair ince ayrıntılar içerdiğinden, yalnızca mutlak konumlandırmayla çözülemiyor. CSS’i derinlemesine ele alırken, başlangıçta mutlak konumlandırmayla kurulmuş yerleşimleri sonradan flex ya da flow tabanlı yapıya dönüştürmenin sorunları daha hızlı ve kolay çözdüğünü çok gördüm. calc() ve viewport birimleri doğru kullanılırsa bir anlamı olabilir, ama içerik ya da viewport tamamen sabit değilse mutlak konumlandırma genelde uygun değil

    • İnsanların, mutlak konumlandırmayla kolay ve hızlı biçimde yapılabilecek bir şeyi gereksiz yere karmaşık yollarla yapıp sonunda aynı etkiye ulaşmaya çalıştığını söyleyenleri gördüm; ama web’de belge her cihaz boyutunda, yönde ve performans düzeyinde iyi görünmek zorunda. Normal uygulamalarda (Windows uygulamaları gibi) bu kadar kaygı yok, mobil uygulamalarda da yalnızca standartlaşmış ekran boyutları düşünülüyor. Bütün bunların hepsini aynı anda ele almak zorunda olan tek ortam web

    • "İyi şablon sözdizimi" ifadesine alaycı tepki vermenin, ilerleme iddiasındaki birine karşı pek saygılı bir tavır olmadığını düşünüyorum. Ayrıca bugün gerçekten iyi şablon sözdizimleri olduğunu düşünüyorum; bunun en temsilî örneği jsx. React hayranı değilim ama jsx’in web geliştirmede devrim yarattığını ve çoğu js şablon sisteminin "ifade olarak şablon", "iç içe geçerek bileşim" ve kontrol akışını JavaScript’le ele alma yapısında neredeyse aynı noktaya geldiğini düşünüyorum

    • React ve Svelte yalnızca yüzeyde benziyor; gerçekte çalışma biçimleri oldukça farklı. React’in özü, (neredeyse) sıradan JavaScript fonksiyonlarının JSX biçiminde tembel(lazy) markup döndürmesi. Döngüler ya da koşullu render için şablonun kendine ait bir sözdizimi yok; bunların hepsi normal JavaScript’le yapılıyor, asıl fark da burada

  • API ve ABI’nin (uygulama ikili arayüzü) asla nihai olmadığını tekrar tekrar öğreniyorum. Uygulama ihtiyaçları sabit değil; zamanla sürekli değişiyor, dolayısıyla sonsuza kadar kullanılabilecek kusursuz bir API diye bir şey yok. Bu öneri de buna iyi bir örnek. Önce sorunu kullanıcı alanındaki kütüphaneler (React vb.) çözüyor, sonra sıra standarda inmesine geliyor. Polyfill’lerde de aynı desen var. Böyle öneriler başarılı olsa bile sonunda eski teknolojiye dönüşüyorlar ve insanlar bunları aşmak için yeni yollar geliştiriyor. DOM API, ECMA, eski tarayıcılar; hepsi aynı kaderi paylaşıyor. Bu da teknik entropi, genişletilebilirlik ve geri uyumluluğun kendisinin standart bir kullanım senaryosu olarak düşünülüp düşünülemeyeceğini sorgulatıyor

    • Web standartlarına yeni özellik eklemek, sonuçta bakım açısından muazzam bir kod yükü getiriyor; standart uyumlu tarayıcılar geliştirirken de uygulanması gereken kod sürekli artıyor. Servo gibi projeler az da olsa yetişmeye çalışırken bile hep bu genişlemeyi takip etmek zorunda kalıyor. Web platformunun, gizlilik ve sandbox kısıtları içinde, yerel ortamların tüm yeteneklerine sahip olmasını isterim. Geliştirici deneyiminin de iyi olmasını isterim. Ama böyle bir hayali gerçekleştirmek için karmaşıklık artışının bedelini de düşünmek gerekiyor. Şu anda tartışılan yerel şablonlama yaklaşımının geliştirici deneyimini gerçekten belirgin biçimde iyileştirip iyileştirmeyeceğinden emin değilim

    • Geri uyumluluk korunup arayüz değiştirilmiyorsa, bunun işini sürümlemenin yapması gerekmiyor mu diye soruyor

    • Eskidikçe etrafından dolaşma ya da yamalama durumunun tekrarlandığı doğru olabilir, ama bu süreçte temel yeteneklerin bir üst seviyeye taşınması gibi olumlu bir etki de var. Kullanıcı ihtiyaçları sürekli yeni boşluklar ve kullanım örnekleri ortaya çıkarsa bile, kademeli güncellemeler yine de yeterince değerli

    • "API ve ABI hiçbir zaman kalıcı olarak kararlı değildir" iddiasına katılmıyorum. Örneğin getElementById, 25 yıldan uzun süredir kararlı biçimde varlığını sürdürüyor. Değişmez API’nin imkânsız olduğu fikri bana daha çok kişisel bir teslimiyet gibi geliyor; dünyada bunun çok sayıda istisnası var. Talep bitmez, o halde yeni API eklersin. Çalışan API’leri bozmak zorunda değilsin

    • Web’de bir API bir kez yayınlandı mı, biçimine ömür boyu bağımlı kalacak kullanıcılar çıkıyor. Bu yüzden 20 yıl önce alınmış kararların artçı etkileri bugün hâlâ sürüyor. Bunun bir örneği "smooshgate"

  • Reaktif programlama akımından söz ederek, kullanıcı düzeyi sistemlerin bu alanı yeterince denediğini ve artık farklı yaklaşımların güçlü yanlarını bir araya getirip gerçek bir standart sistem oluşturabileceğimizi savunuyor. Ama Ryan Carniato/Solid JS tarafında sinyaller(signals) üzerinden yeni imkânlar hâlâ araştırılıyor; bu yüzden keşfin henüz bitmediğini düşünüyorum. Daha gidecek çok yol var

  • Web’in yerel şablonlara, reaktiviteye ve veri bağlamaya gerçekten ihtiyacı var. Dünyadaki milyarlarca kullanıcının React gibi ağır framework’leri indirmek, ayrıştırmak ve çalıştırmak için harcadığı CPU ve bant genişliği korkunç bir israf

    • LLM’lerin ve kriptografik işlemlerin muazzam kaynak israfıyla kıyaslayınca, bu israf önemsiz bile kalıyor

    • TC39’da signals ile ilgili bir proposal geliyor; bu sayede bir adım daha ileri gidiyoruz

    • Geliştirmede gerçekten gereken şey, çift yönlü veri bağlama ile bir jsx klonu kadar basit olabilir

    • React bir şablon sistemi değil

  • Web standartlarına yüksek seviyeli bir şablon sistemi ekleme tartışmalarını izlerken, aslında önce sağlanması gereken şeyin tarayıcıya gömülü düşük seviyeli API’ler olduğunu düşünüyorum. Herkesin standart bir şablon sisteminde uzlaşması neredeyse imkânsız. Buna karşılık tarayıcı DOM’a diff uygulayan düşük seviyeli bir API sunabilir. Mesela şöyle yerel bir metod olsa iyi olurdu: element.applyDiff(DocumentFragment | string, { method: 'innerHTML' | 'outerHTML' }). Böyle bir diff uygulamasıyla, mevcut elementin focus durumu, input değerleri, audio/video durumu gibi şeyler korunarak yıkıcı olmayan güncellemeler yapılabilir. Idiomorph gibi js kütüphaneleri var, ama yerel çözüm muhtemelen çok daha hızlı olur

    • Makalede DOM parts proposal’ına bağlantı verilmiş. Bu öneri düşük seviyeli API olarak oldukça faydalı. VDOM tabanlı framework’lere çok uygun olmayabilir, ama diğer framework’lerde uygulamayı basitleştirip optimizasyon alanını genişletebilir. Signals proposal da gelirse, framework olmadan bile oldukça kullanışlı olabilir

  • Bu yazının yazarının, ilgili alanda en üst düzey deneyime sahip kişilerden biri olduğu söyleniyor. Lit, Polymer, Google’ın web components çalışmaları ve çeşitli temel DOM spesifikasyonlarına büyük katkı vermiş biri

    • Ama onun öne sürdüğü birçok spesifikasyonun aslında daha fazla sorun yarattığı eleştirisi de var. Tam olgunlaşmamış, yüzeysel çözümler için 20’den fazla web spesifikasyonuna ihtiyaç doğurduğu; kullanıcı alanında zaten yapılabilen şeyleri gereğinden fazla karmaşık biçimde standartlaştırdığı söyleniyor. Ayrıca Safari’nin 15 yıl önce deklaratif yaklaşımın gerekliliğini savunduğu ama bunun görmezden gelindiği de belirtiliyor

  • JSX yaklaşımı yerine, Kotlin’in receiver ve builder kullanarak DSL’yi genelleştirmesine benzer bir sözdizimsel yaklaşım istiyorum. Bu yaklaşım sadece basit HTML şablonlarının ötesinde, farklı bileşen hiyerarşileri, yapılandırma(config) ve çeşitli bağlamlarda çok kullanışlı olabilir. Şablonlama ve veri bağlamanın gerçek anlamı sonuçta bu tür sözdizimsel özelliklerden yararlanan standart fonksiyon kümelerinden ibaret; bu da Jetpack Compose’a benziyor

    • Gerçekten gerekli olan özellikler çok az: döngü(loop), koşullu öznitelikler, koşullu düğümler vb. Aslında yalnızca bu yapılar bile olsa, diller arası kullanım mümkün olabilir

  • Deklaratif şablonlamanın jQuery’den daha iyi olduğundan her zaman emin olamıyorum. Yaklaşık 10 yıldır React kullanıyorum ama SPA’m karmaşıklaştıkça DOM’un imperatif kontrolünü özlüyorum. DOM soyutlaması sızdırıyor(leaky abstraction) ve sonunda basit bir "son yazan kazanır(last-write-wins)" modeli bazen daha net geliyor. Deklaratif şablonlama bu sorunları çözdüğünü iddia etse de, bileşenler arasında mutable durum paylaşmaya başladığınız anda sınırlar çok hızlı ortaya çıkıyor

    • Bu his biraz da React tarafındaki geliştiricilerin DOM API’yi doğrudan çağırmayı günah gibi görmesinden kaynaklanıyor olabilir. ref’leri aktif biçimde kullanmak ya da id ile bileşeni doğrudan bulup değiştirmek de gayet kabul edilebilir. Gerçekten hızlı çalışan ve az yeniden render yapan form kütüphaneleri de zaten böyle çalışıyor

    • React’i sevdiğim söylenemez ama deklaratif DOM’dan çıkıp innerHTML, ref vb. kullanmanın önünde ciddi bir engel olduğunu da düşünmüyorum. İmperatif kontrolle yapılabiliyor olsa da, pratikte deklaratif olarak yapılamayan şey çok az. attachShadow() ya da showModal() bile yaklaşık 10 satırlık eklemeyle kolayca deklaratif biçimde sarılabilir

  • Records ve Tuples proposal ilerlemiş olsaydı, JSX bu yapıları kullanarak yeni bir anlambilime kavuşabilirdi; ama gerçekte bu proposal yalnızca durmuş değil, tamamen geri çekildi (issue’a bakın). Yerine composites proposal geldi

  • Bu tür yüksek seviyeli özellikleri standartlaştırma tartışmalarının durması gerektiğini düşünüyorum. Bunun yerine alt seviye özellikleri genişletip, üst seviye kütüphane implementasyonlarına daha çok değer katan yöne odaklanmak daha iyi olur. Bir standart önerisinin kütüphanelere göre açık bir avantajı yoksa anlamlı değil. Bir şey ancak kütüphane olarak en az 5-10 yıl boyunca geniş ölçekte doğrulandıktan sonra standartlaştırma tartışmasına konu olmalı diye düşünüyorum