DOM Şablon API’sini Tanıtmanın Tam Zamanı

 (justinfagnani.com)
1 puan yazan GN⁺ 2025-06-28 | 1 yorum | WhatsApp'ta paylaş
  • Web platformu dinamik uygulama çalışma zamanı olarak yerini sağlamlaştırdı, ancak standart DOM’da veri, olaylar, özellikler, XSS savunması ve verimli güncellemeyi birlikte ele alan deklaratif bir şablon API’si yok
  • React, Vue, Angular, Lit, Svelte, SolidJS gibi modern framework’ler, markup ile veriyi birleştiren şablon sistemini temel alır; bu da okunabilirliği, güvenliği, performansı, statik analizi ve sunucu tarafı render etmeyi etkiler
  • Geçmişte E4X, E4H ve yerleşik html şablon literal etiketi DOM oluşturmayı kolaylaştırdı, ancak DOM güncellemeyi çözmedi; artık tagged template literals ve framework deneyimi standardizasyon için bir temel sağlıyor
  • JavaScript tabanlı API, JSX standardizasyonundan veya HTML tabanlı şablonlardan daha dar kapsamlıdır; JSX dönüşümünün derleme hedefi haline gelerek daha sonra HTML şablonlarına ve deklaratif custom element’lere uzanabilir
  • Önerilen yol DOM Parts, template identity, Signals, DOM scheduler gibi alt mekanizmalarla bağlantılıdır ve vanilla geliştiricilere, Web Components kullanıcılarına ve framework uygulayıcılarına ortak bir temel sunabilir

Standart DOM’da eksik olan deklaratif şablon katmanı

  • Web platformu tarihin en başarılı uygulama çalışma zamanıdır; DOM API ise statik belge görüntüleyicisini dinamik ve ifade gücü yüksek bir çalışma zamanına dönüştüren temeldir
  • Photoshop gibi karmaşık uygulamalar bile web uygulaması olarak sunuluyor ve tüm UI Web Components ile oluşturulabiliyor; DOM bu kadar güçlü bir API’dir
  • Ancak mevcut standart DOM API’sinde aşağıdaki işleri tek seferde ele alan kullanışlı bir yol yok
    • Veriden DOM düğümü parçaları oluşturma
    • Olay dinleyicileri ekleme
    • Element özelliklerini ayarlama
    • XSS saldırılarına karşı güvenliği sağlama
    • Bu DOM parçasını yeni verilerle verimli şekilde güncelleme

Framework’lerin zaten kanıtladığı şablon değeri

  • Modern web framework’leri ve render kütüphaneleri, markup ile veriyi deklaratif olarak birleştiren şablonları temel özellik olarak kullanır
    • React, Vue, Angular, Preact, Lit, Svelte, SolidJS, Stencil, Quik, Ember, FAST, Polymer, Marko vb. buna dahildir
  • Deklaratif şablonlar, imperatif DOM API’ye göre yazması ve okuması daha kolaydır
    • İnterpolasyon, olay dinleyicileri ve özellik ayarları şablona yakın durduğu için davranışın yerelliğini korumak daha kolaydır
  • Şablon sistemleri interpolasyon değerlerini otomatik olarak escape edebildiği için XSS savunması açısından avantajlıdır
  • İyi bir şablon sistemi yalnızca değişmesi gereken DOM’u güncelleyerek çoğu elle yazılmış koddan daha hızlı olabilir
  • Birçok şablon sistemi tür denetimi ve otomatik tamamlama gibi statik analiz desteği sunar
  • Deklaratif şablon tanımları tam tarayıcı ortamı dışında da yorumlanabildiğinden verimli sunucu tarafı render mümkündür

Şablon eksikliğinin yarattığı maliyet

  • Platform, neredeyse tüm web uygulamalarının temel ihtiyacını hâlâ doğrudan karşılamıyor
    • Uluslararasılaştırma API’leri, Temporal, Scheduler, Sanitizer gibi şablonlar da standart platform özelliği olarak ele alınmaya değer
  • Kullanıcılar uygulama indirme süresinden, render ek yükünden ve güvenliği zayıf uygulamalardan etkilenir
    • Şablon kütüphanesi kodu en iyi durumda birkaç kB, en kötü durumda 100 kB’den fazla olabilir
    • Birkaç kB bile ilk etkileşimli render bütçesinde büyük pay tutabilir
  • Geliştiriciler temel işler için bile kütüphanelere, npm’e ve CDN’lere bağımlı olmak zorunda kalır
    • Basit statik dosyaların ve DevTools’un kullanışlılığı azalır
    • Farklı stack’ler arasında taşınabilir temel şablon bilgisi yoktur
    • innerHTML gibi yerel DOM oluşturma API’leri varsayılan olarak güvenli değildir
  • Framework’ler ve şablon kütüphaneleri yazılabilirlik, render hızı, güncelleme hızı, güvenlik ve kod boyutu arasında zor ödünler vermek zorundadır
  • Web platformu Flutter, SwiftUI, Jetpack Compose gibi yerel platformlarla rekabet eder
    • Bu platformlar şablon benzeri sistemleri yerleşik olarak sunar, uygulama kurulumu ve derlenen diller kullanır ve birkaç kB’lik bundle boyutuna daha az duyarlıdır

Neden şimdi yeniden denenebilir?

  • Geçmişte de şablona yakın platform önerileri vardı
    • E4X gerçekten Firefox ve Flash’a dahil edilmişti
    • E4H, Ian Hixie’nin sadeleştirdiği bir fikirdi
    • 2012 civarında yerleşik html şablon literal etiketi prototipi de vardı
  • Geçmiş denemeler DOM oluşturmayı kolaylaştırdı, ancak güncellemeyi çözmedikleri için yeterli çözüm olmaları zordu
  • Bugün framework’ler yeterince kullanım senaryosu oluşturdu ve kullanıcı alanındaki şablon çözümleri zamanla birbirine daha çok benzemeye başladı
  • Framework kullanmayan geliştiricilerde ve Web Components topluluğunda da kullanışlı DOM manipülasyonu ve reaktivite API’si talebi var
  • DOM Parts gibi düşük seviyeli DOM güncelleme primitifleri önerileri ilerliyor
    • Daha yüksek seviyeli deklaratif şablon API’si framework uygulama yükünü azaltabilir ve düşük seviyeli API önerilerini doğrulayıp tamamlayabilir

Sözdizimi ve semantiğin ortak paydası

  • Popüler istemci tarafı şablon sistemlerinin çoğu markup ile binding’leri birleştiren bir yapı paylaşır
    • İfade ayraçları, kontrol akışı ve binding türü göstergeleri biraz farklıdır; ancak ortak noktalar daha fazladır
    • HTML tabanlı Vue, Angular, Svelte ile JavaScript tabanlı React, Lit, Solid arasında da benzerlik vardır
  • JavaScript tabanlı API’lerde şablon genellikle bir ifadedir; bileşim şablon ifadelerinin iç içe geçirilmesi veya referanslarla yapılır, kontrol akışını ise JavaScript üstlenir
  • JavaScript API tabanlı birçok sistem, şablon ifadesinden DOM açıklaması döndürür ve bunu ayrı bir render fonksiyonu çağrısıyla uygular
    • Çoğu aynı render çağrısıyla DOM’u günceller
    • Bazıları ince taneli reaktiviteyle bu yolu kullanmaktan kaçınır
  • E4X ve E4H, JSX gibi JavaScript’e markup ekleyen yeni sözdizimi getirdi; ancak DOM açıklaması değil, DOM parçasının kendisini döndürdü
    • İlk DOM oluşturma için iyiydi, fakat güncelleme hâlâ imperatif kaldı

Bugünün JavaScript’iyle ifade edilebilen API

  • JavaScript’te HTML benzeri gömülü DSL’ler için tagged template literals zaten var
  • Yeni JavaScript sözdizimi eklemeden de DOM API’de şablonlar ifade edilebilir
  • Popüler kütüphaneler bu yaklaşımın iyi çalıştığını gösteriyor
  • Önerinin yeni sözdizimi olmadan ilerleyebilmesi standardizasyonun gerçekçiliği açısından önemlidir

JSX ile yerel şablon API’sinin ilişkisi

  • Tagged template literals, ES2015’in güçlü bir özelliğidir; ancak kullanıcı alanı component sistemlerinde JSX’e göre sözdizimsel ek yükü daha fazladır
  • JSX popülerdir, ancak yalnızca sözdizimine sahiptir; çalışma zamanı semantiği yoktur
    • Standardize etmek için yalnızca yeni sözdizimi eklemenin ötesinde semantiği tanımlamak gerekir
    • Çevrede tanımlı createElement() çağrısı olarak ele alma yöntemi dışlanır
    • Nesne ağacı oluşturma yöntemi statik ve dinamik parçaları karıştırarak daha verimli güncelleme desenlerini engelleyebilir
  • Records and Tuples önerisi ilerliyor olsaydı JSX’in kutulu Records oluşturması mümkün olabilirdi, ancak bu öneri özellikle record identity ve box kısmında duraklamış durumda
  • JSX benzeri sözdizimi ve semantiğin tam bir DOM şablonuna uygun olup olmadığını doğrulamak için hedef bir şablon sistemi gerekir
    • React’in şablonları DOM elementlerinin özelliklerine ve olaylarına açıkça bind etme veya elementlere yönerge uygulama yoluna sahip değildir
  • Mevcut standart dışı JSX, çalışma zamanı semantiği olmayan saf sözdizimi olduğundan JSX’i tagged template literal’a dönüştüren derleyiciler yapılabilir
    • JSX-to-Lit gibi örnekler zaten var
    • Yerel şablon API’si, geliştiricilerin istedikleri sözdizimini seçebileceği bir derleme hedefi olabilir

Neden önce HTML tabanlı şablon yerine JavaScript API’ye bakılıyor?

  • Birçok web geliştiricisi tam özellikli HTML tabanlı bir şablon sistemi istiyor
    • Web Components kullanıcılarında, framework kullanıcılarında ve vanilla geliştirici topluluklarında talep var
    • <template> elementi, declarative shadow DOM ve Web Components’ın bu işlevi sağlayacağını bekleyen geliştiriciler de vardı
  • HTML tabanlı şablon, JavaScript tabanlı API’den çok daha büyük bir iştir
    • Binding sözdizimi
    • İfade dili
    • Kontrol akışı sözdizimi
    • Şablon güncelleme mekanizması
  • HTML tabanlı şablon tanımlarını yerel olarak yüklemenin bir yolu da yok
    • Web Components v0’daki HTML Imports ortadan kalktı ve HTML Modules henüz yok
    • HTML şablonları JavaScript modülünün içine koymak gerekiyorsa, verilerle aynı lexical scope’ta JavaScript ifadeleri kullanmanın daha iyi olduğu değerlendiriliyor
  • Polymer 3, Polymer 2’nin HTML şablonlarını JavaScript’e taşıdı ve bu doğrudan Lit’e uzandı
    • JavaScript’in script benzeri işleri üstlenmesi daha az kod ve daha iyi deneyim sağladı
  • JavaScript API, HTML tabanlı API’nin alt kümesi ve basamağı olabilir
    • JavaScript API geldikten ve doğrulandıktan sonra HTML API için binding, ifade, kontrol akışı ve modül sistemini tanımlama işi kalır

Reaktivite modeli seçenekleri

  • İlk DOM şablon önerileri güncellemeyi içermiyordu; ancak kullanıcı alanı sistemleri reaktivite modellerini ve uygulama yaklaşımlarını yeterince keşfetti
  • Başlıca reaktivite yaklaşımları üç grupta toplanabilir
    • React’in VDOM ve diffing yaklaşımı
    • Lit’in template identity yaklaşımı
    • Solid ve Svelte, Vue, Angular vb. içinde kullanılan Signals ve ince taneli reaktivite
  • Diffing anlaşılması kolaydır ve her tür veriyle çalışır; ancak diğer yaklaşımlardan daha yavaştır
    • Diffing algoritmalarındaki farklar gözlemlenebilir olabilir
    • Tek bir diffing algoritmasını standardize etmek ve platform mühendislerine ek yükü kabul ettirmek zordur
  • Template identity, DOM mevcut şablonla render edilmişse güncelleyip değilse değiştirme yöntemidir
    • Hızlıdır ve birçok kullanım senaryosunda diffing’e çok benzer sonuçlar üretir
    • Tagged template literals, JSX dönüşümü ve HTML tabanlı şablonlarla iyi uyum sağlar
    • Semantiği basit olduğu için spesifikasyona dökmek kolaydır
  • Signals, yeni reaktif DOM API’lerine ve şablon API’sine dahil edilmeye değer bir modeldir
    • JavaScript Signals önerisi var, ancak henüz platformun yerel özelliği değil ve benimsenmesi garanti değil
    • Signals tabanlı sistemler, tüm veriler signal ile sarıldığında en iyi şekilde çalışır
    • Signal olmayan veriler ve signal üretmeyen platform API’leri de çok olduğundan yeniden render, bu değişiklikleri yansıtmanın kolay bir yoludur
  • Template identity ve Signals birlikte var olabilir
    • Binding’lere yalnızca signal aktaran şablonlar yeniden render olmadan yalnızca signal ile güncellenebilir
    • Signal olmayan verilere referans verebilen şablonların yeniden render edilmesi gerekir
    • Yeniden render genellikle reaktif component özellikleri gibi component veya framework katmanı tarafından otomatik yapılır

Standardizasyon tartışması ve kalan işler

  • Yerel deklaratif JavaScript şablon API’si tartışması WICG webcomponents#1069 üzerinde başladı
  • Bu API, DOM oluşturma API’sinin mantıksal bir sonraki adımı olabilir
    • Vanilla web geliştiricileri için yazması kolay ve güvenli bir DOM oluşturma primitifi olur
    • Lit, FAST, HyperElement gibi mevcut Web Components kütüphaneleri için doğrudan faydalıdır
    • Ham Web Components API kullanıcıları için faydalıdır ve daha eksiksiz bir reaktif component tanımlama API’sine geçiş basamağı olur
    • Yeni framework’ler bu API üzerine kurulabilir
    • Mevcut framework’ler bunu derleme hedefi, çalışma zamanı backend’i veya doğrudan destek hedefi olarak kullanabilir
    • Hem yeniden render teknikleri hem de Signals için faydalıdır
    • Deklaratif HTML şablonlarına ve deklaratif custom element’lere giden basamak olur
    • Üzerinde uzlaşılacak ve spesifikasyona dökülecek API yüzeyi görece küçüktür
    • Şablon semantiğini tanımlamaya yardımcı olur
  • Bu çalışma DOM Parts önerisinin tamamlanmasıyla bağlantılıdır
    • DOM Parts’ı tanımlamaya ve kullanışlılığını kanıtlamaya da katkı sağlar
  • Yüzey API’si ve sözdizimi büyük değildir, ancak davranış alanı ve alttaki DOM Parts API’si büyüktür
  • İnce taneli reaktivite için bir tür DOM scheduler da gereklidir
  • Kararlaştırılacak, üzerinde uzlaşılacak, spesifikasyona dökülecek ve test edilecek çok şey olduğundan işbirliği gerekir
  • İlgilenen geliştiriciler webcomponents#1069 üzerinde yorum bırakabilir veya Bluesky üzerinden iletişime geçebilir

İlgili okumalar

1 yorum

 
GN⁺ 2025-06-28
Hacker News yorumları

  • “Şablonlar için iyi sözdiziminin ne olduğunu biliyoruz” demek gülümsetecek kadar iddialı. Bence hâlâ hiç bilmiyoruz. İyi bir şablon neredeyse kesinlikle sembolik bir sözdiziminden çok görsel bir araca daha yakın; eski Dreamweaver gibi araçların başarılı olmasının ve tasarımcıların Photoshop gibi araçlarla öğrenmesinin nedeni de bu
    Ayrıca XSLT’yi yeniden yaratma girişimi gibi görünmesi üzücü. Birileri eninde sonunda tek başına well-formed olmayan parçaları şablonlaştırmak ve birleştirildiğinde well-formed olan bir şey yapmak isteyecek. Sayfa içinde birbirine bağlı olup aynı ağaçta bulunmayan varlıklar için de aynı durum geçerli. Düz markup’taki label ve for bunun kolay bir örneği
    Mümkünse, tüm şablonları markup’ın standart belge yerleşimi denen Rube Goldberg düzeneğine zorla uydurma çabalarının azalmasını isterim. Mutlak konumlandırmayı dikkatli kullanınca oldukça iyi yapılabilen bir şeyi yeniden üretmek için insanlar akıl almaz derecede karmaşık yollara sapıyor. Uydurmak için hesaplama gerekebilir, ama makineyi aynı veri için bu hesabı sürekli tekrarlamaya neden zorlamamız gerektiğini anlamıyorum

    • XML’i hiç sevmiş değilim, ama XSLT bence o ekosistemi kurtarabilecek killer feature’dı ve hâlâ da öyle. Tarayıcılarda hâlâ geniş ölçüde destekleniyor
      XML’in yapılandırma, süreçler arası iletişim gibi uygunsuz yerlerde popülerleşip; XSLT gibi harika bir dönüştürme yeteneğine sahip bir markup dili olarak parlayabileceği yerlerde sönük kalması üzücü
      XSLT’nin tökezlediği noktanın gerçek bir DSL olması, üstelik bildirimsel, saf ve fonksiyonel bir DSL olması olduğunu düşünüyorum. İnsanlar DSL’leri sözde çok över, ama pratikte çoğu zaman popüler bir host dilin yordamlı semantiğini soyutlayamayan basit sözdizimi oyunlarından ibaret kalırlar. Zor işleri önemsiz hâle getiren iyi tasarlanmış bir DSL ile karşılaştıklarında ise insanlar öğrenmeye yanaşmaz
    • Bu sonuca nasıl vardığını anlamıyorum. Söylediklerin şablon üretme biçiminden çok HTML+CSS genelinden duyulan memnuniyetsizlik gibi görünüyor
      Ayrıca mutlak konumlandırmanın neden gündeme geldiği de belirsiz. HN’de bu tür şeyleri tekrar tekrar görüyorum; elbette mutlak konumlandırmanın kullanılacağı yerler var ve çoğu durumda gerekli
      Ama sayfa ya da uygulama yerleşimi için kullanıldığında, deneyimlerime göre içerik veya ekran boyutu biraz değişse bile çoğu zaman dağılan bir kâbusa dönüşüyordu. Basılı gazete yerleşimleri bile tipografiyle iç içe olduğundan böyle yapılamaz
      CSS ile çok uğraştığım dönemlerde, biri mutlak konumlandırmayla “neredeyse bitmiş” bir yerleşim bırakıp işi devraldığımda düzeltmesi inanılmaz zaman alırdı; flex ya da normal akış gibi yöntemlerle yeniden yapmak her zaman daha hızlıydı. Çünkü mutlak konumlandırmayı ana yerleşim aracı olarak kullanınca sorun pratikte düzeltilemez bir seviyeye geliyordu
      calc() ve viewport birimleriyle anlamlı teknikler olabilir, ama deneyimlerime göre tamamen statik içerik ve viewport boyutu söz konusu değilse mutlak konumlandırma yerleşim için uygun değil
    • Web’de belgelerin her cihaz boyutunda, oranında, yöneliminde ve özelliğinde iyi görünmesi beklentisi var. Sıradan uygulamalarda, örneğin Windows uygulamalarında böyle bir beklenti yok; mobil uygulamalarda ise standartlaştırılmış birkaç boyut var. Yalnızca web’de ikisi birden var
    • React ile Svelte arasında yalnızca yüzeysel bir benzerlik olduğunu düşünüyorum. İkisi de büyük ölçüde HTML’e dayalı sözdizimi kullanıyor, ama çalışma biçimleri çok farklı
      React, genel olarak normal JavaScript fonksiyonlarının JSX biçiminde ertelenmiş markup ifadeleri döndürmesiyle çalışan tek büyük framework. React’te şablon düzeyinde döngü ya da koşullu render kavramı yok; bunlar normal JavaScript ile hallediliyor
    • Web platformunun ilerlemesini savunan birinin karşısında alay etmek pek iyi bir tutum değil. Bu ilerleme herkesin yararına
      Ayrıca artık iyi şablon sözdiziminin ne olduğunu bildiğimizi düşünüyorum. Temelde JSX. React’i pek sevmeyen biri olarak bile bunu söyleyebilirim. JSX tüm web’i sardı ve farklı framework’lere uyacak şekilde çeşitlendi; JavaScript şablon sistemlerinin şablonları ifade olarak ele alma, iç içe geçirerek birleştirme ve belirli bir şablon sözdizimi yerine kontrol akışını JavaScript’in kendisiyle yönetme gibi ortak özelliklerde yakınsadığını inkâr etmek zor

  • Tekrar tekrar öğrenilen temel ders şu: API/ABI nihai durum değildir. Uygulama ihtiyaçları tek bir kararlı API ile sonsuza dek karşılanmaz; gelecekteki tüm sorunları da uygulama seviyesi sorunları diye kenara itemeyiz.
    Bu öneri, platformdaki ortak bir sorunun React gibi üst katmanlarda çözülüp, sonunda sorun olarak kabul edildiğinde aşağıya inme sürecini iyi gösteriyor. Polyfill’ler de aynı örnek.
    Böyle bir öneri başarılı olduğunda bir süre dikkat çeker ama yararlı ömrünün büyük kısmında insanların etrafından dolaşmaya çalıştığı eski bir şeye dönüşür. DOM API, ECMA sürümleri, eski tarayıcılar, sistemin parçası olduğu için dokunulamayan tüm yararlı teknolojiler böyle oldu.
    Entropi, genişleme ve geriye dönük uyumluluğu başlıca kullanım senaryoları olarak düşünemez miyiz?

    • Web standartlarındaki her özellik, özenle bakımı yapılması gereken ek koddur; standartlara uyumlu bir tarayıcı yapmak isteyen herkesin de uygulaması gereken ek koddur. https://servo.org/ gibi projelerin zamanla yetişme şansı bulmasını isterim; sürekli büyüyen bir kapsamın peşinden koşmalarını değil.
      Web platformunun yerel platformların sahip olabileceği tüm yeteneklere sahip olmasını istiyorum. Elbette gizlilik ve sandbox kısıtları korunmalı. Web geliştiricilerinin geliştirme deneyiminin de harika olmasını istiyorum.
      Ama bunun, artan karmaşıklığın sonuçlarıyla dengelenmesi gerekiyor. Bu durumda yerel şablonların geliştirme deneyimini gerçekten iyileştirdiğinden emin değilim. Kazancın maliyeti aştığı görülmüyor.
    • getElementById sanırım yaklaşık 25 yıldır kararlı. “Kararlı API diye bir şey yoktur” sözü, uzun ömürlü arayüzler tasarlama becerisi ya da isteği olmayan insanların söylediği bir şey. Evrenin yasası değil, daha çok kişisel bir kabulleniş. Karşı örnekler fazlasıyla var.
      Uygulama ihtiyaçları, diğer ihtiyaçlar gibi sınırsızdır. Bu ihtiyaçlar çalışan API’leri kırarak değil, yeni API’ler ekleyerek karşılanır.
    • Web’de API/ABI gerçekten nihai durumdur. Bir kez web’e açıldığında, birileri sonsuza dek tam o biçimine bağımlı olur.
      Bu yüzden 20 yıl önceki kararlar nedeniyle hâlâ smooshgate gibi olaylara takılan API’ler var: https://developer.chrome.com/blog/smooshgate
    • Bu süreçte temel özellikler bir basamak daha yukarı çıkar. Kullanıcı alanındaki ihtiyaçlar her zaman yeni boşluklar, kullanım senaryoları ve kör noktalar bulacak diye aşamalı güncellemeler değersiz olmaz.
    • Zaten bu yüzden sürümleme yapıp eski sürümlerle geriye dönük uyumluluğu koruyor, “eski” arayüzleri değiştirmiyoruz, değil mi?

  • Web’in gerçekten yerel şablonlara, reaktiviteye ve veri bağlamaya ihtiyacı var. Milyarlarca kullanıcının React gibi şeyleri indirip ayrıştırıp çalıştırması için ne kadar CPU ve bant genişliği harcandığını hayal bile edemiyorum.

    • Artık LLM’ler ve kripto paralar var, bu yüzden böyle bir israf çok küçük görünüyor.
    • TC39 Signals önerisiyle bunun bir kısmında ilerleme var.
    • Çift yönlü veri bağlama ve JSX’in bir kopyası gibi bir şey aslında çoğu kişi için yeterli olur.
    • React’e şablon demek zor değil mi?

  • Signals kısmı çok şey anlatıyor ve fikrin harika olsa da pratikte zor olduğunu iyi gösteriyor.
    Yazarın Signals’ı neden sevdiğini anlıyorum. Yeterince büyük her projede yarım yamalak yapılmış bir DAG hesaplama ağacı vardır; dilin bunlardan birini standartlaştırması mantıklı.
    Ama bu tür soyutlamaların bilişsel maliyeti ve uygulama maliyeti yüksek.
    Çoğu mühendislikte olduğu gibi sorun bir ödünleşim. React modeli global durumu güncelleyip her şeyi yeniden render ettiği için yavaş ama zihnen kolay. Signals modeli hızlı ama çok fazla emek istiyor.
    Çoğu uygulamanın delicesine hızlı olması gerekmiyor ve insanlar daha basit olan React’i seçecek.
    Ama Signals’ın şablonlarla pek ilgisi yok, değil mi? O zaman neden seçilmeli? Şablonlar ve Signals ayrı ayrı var olamaz mı?
    Şablonları düşünmeye başladığınızda, DOM’a şablon düğümlerini nereye yerleştireceğinizi ve değiştiklerinde nasıl güncelleneceğini anlatmanın bir yoluna ihtiyaç duyarsınız. Bu tür önerilerin başarısız olduğu nokta tam da burası.
    API burada bir tarafı seçmek zorunda. Teknik olarak ikisine de izin vermek mümkün olabilir ama korkunç olur. Geliştiriciler bunun hangisi olması gerektiği konusunda asla uzlaşamaz.
    UI’daki büyük sorun her zaman nasıl tanımlandığı değil, nasıl güncellendiği oldu. Microsoft MVC, MVP, MVVM gibi birçok model tanımlamaya çalıştı ve başarısız oldu; hepsi acı vericiydi. Sonra imgui “UI’da hiç durum olmasa?” dedi; bu oldukça iyi ama CPU için yükü büyük.
    Belki de web uygulamalarının başarısının en büyük nedenlerinden biri, DOM’un veriyi görünüme bağlama biçimini dayatmamasıydı. Bu yüzden framework cehenneminden çıkmakta zorlanıyor olabiliriz.

    • Artık Signals’a, proxy’lere ya da başka reaktif ilkel öğelere dayanmadan ince taneli fark hesaplamasını iyi yapan birkaç framework var. Temelde yukarıdan aşağı inen React modeli ama çok daha hızlı; hooks ya da manuel ve savurgan bağımlılık dizileri gibi garip kavramlar da yok.
      Kişisel olarak sevdiğim ivi-js: https://github.com/localvoid/ivi
      Sadece benchmark kazanma düşüncesiyle sonunda varılabilecek en hızlı, en çirkin, imperative ve bakımı imkânsız vanilla JavaScript’ten yalnızca %8 daha yavaş.
      https://krausest.github.io/js-framework-benchmark/2025/table...
    • Microsoft çeşitli dönemlerde bu modelleri kullanmış olsa da, doğrudan tanımladığı tek şey MVVM’dir. MVC Xerox PARC’tan, MVP ise Taligent’ten çıktı.
    • Bir geliştirici olarak, geliştiricinin kafasını biraz daha zorlayacak olsa bile donanım, bant genişliği ve dünya için daha kolay olan tarafı seve seve seçerim.
      Çoğu uygulamanın delicesine hızlı olması gerekmediği sözünden ziyade, uygulamaların hafif olması gerektiğinin daha fazla kabul edilmesini isterim.
      İnsanların React’i daha basit olduğu için seçtiği sözüne katılıyorum; ama React’i sevmememin nedeni de tam olarak bu.

  • JSX’i benimsemek yerine, Kotlin’in receiver ve builder ile DSL’ler için genelleştirilmiş bir sözdizimi sunmasına ve bu sözdiziminin bileşen hiyerarşilerini ifade etmeye de iyi uymasına daha yakın olmasını isterdim.
    Bu, yalnızca HTML şablonları için değil, yapılandırmaları ve çeşitli yapı türlerini ifade etmek için de geniş ölçüde yararlı olurdu.
    Şablonların ve veri bağlamanın gerçek semantiği ise Jetpack Compose’ta görüldüğü gibi, bu tür sözdizimi özelliklerini kullanan standart bir işlev kümesi olarak bırakılabilir.

    • Çok fazla şeye de gerek yok. Döngüler, özellikler için koşullu ifadeler ve düğümler için koşullu ifadeler yeterli. Aslında bu kadarı diller arası ortak özellikler olarak bile mümkün.

  • Bu yazının, bu alanda en deneyimli kişilerden biri tarafından yazılmış olması da önemli. Lit / Polymer’ın başlıca yazarlarından biri; Google’da Web Components üzerinde çalışmış ve web platformunun parçası hâline gelen temel DOM spesifikasyonlarına katkıda bulunmuş biri.

    • Aksine, yarı pişmiş spesifikasyonları pervasızca dayatıp çözdüğünden çok daha fazla sorun yaratan kişilerden biri olduğunu düşünüyorum. Kullanıcı alanının zaten yaptığı şeyleri zar zor taklit etmeye çalışan ve 20’den fazla yeni web spesifikasyonu gerektiren bir “çözümü” zorladı; %100 aynı fikirde olmayanları ise görmezden geldi ya da gaslighting yaptı.
      Safari, 15 yıl önce bile burada deklaratif bir yaklaşım olması gerektiğini savunuyordu.

  • Deklaratif şablonların aslında jQuery’den bile daha kötü hissettirdiğini düşünen başka biri var mı merak ediyorum. React’i neredeyse 10 yıldır kullanıyorum ama SPA’lar karmaşıklaştıkça DOM’u imperatif olarak doğrudan kontrol etmek istiyorum.
    Bunun nedeni, DOM’un sızdıran bir soyutlama olması ve bir noktada son yazanın kazandığı bir modelin daha iyi hissettirmesi.
    Deklaratif şablonların bunu ele almaya çalıştığını biliyorum; ancak bileşenler arasında değiştirilebilir durum paylaşmaya başladığınızda bu yaklaşım çok hızlı dağılıyor.

    • React tarafındaki insanlar, DOM API’sini doğrudan çağırmayı büyük bir günah gibi görme eğiliminde. Bazen bir ref almak ve hatta söylemeye cüret edeyim, bileşeni id ile bulup doğrudan işlemek gayet sorun değil. Gerçekte “hızlı” olan ve daha az yeniden render eden kütüphaneler, örneğin form kütüphaneleri, bunu yapıyor.
    • React’i sevmiyorum ama bu hisse katılmıyorum. Öncelikle zaten deklaratif DOM’dan çıkıp innerHTML ve ref ile istediğinizi yapabilirsiniz.
      İkincisi, DOM’u imperatif olarak kontrol ederek deklaratif yaklaşıma göre daha az zahmetle ne yapılabildiğini bilmiyorum. Aklıma yalnızca attachShadow(), showModal() gibi belirli metotlar geliyor; onlar da 10 satırlık bir bileşene sarılarak deklaratif hâle getirilebilir.
    • Tamamen katılıyorum. React gibi bir şeyin ayrı HTML ve jQuery kullanmaktan zerre kadar daha iyi olduğuna beni ikna eden tek bir örnek bile henüz görmedim.

  • Bildiğim kadarıyla Ryan Carniato ve Solid JS, Signals ile nelerin mümkün olduğunu hâlâ keşfediyor. Bu alandaki kullanıcı tarafı keşfinin tamamen bittiğini düşünmüyorum; ek inovasyon mümkün olabilir.

    • Web geliştirme balonunun dışında da artımlı hesaplama problem alanında ilginç pek çok araştırma var; hatta kendi kendini ayarlayan hesaplama, yani Signals, o kadar da ilginç bir eksen değil.

  • Yönü beğeniyorum, ama ondan önce tarayıcılara birkaç daha düşük seviyeli API’nin girmesi gerektiğini düşünüyorum.
    Herkesin standart bir şablon sistemi üzerinde anlaşması neredeyse imkânsız olacak. Bunun yerine tarayıcının yapabileceği şey, DOM’a farkları performanslı biçimde native olarak uygulayan düşük seviyeli bir API sunmak.
    Tarayıcıda bunun native olarak bulunması gerçekten harika olurdu.
    element.applyDiff(DocumentFragment | string, { method: 'innerHTML' | 'outerHTML' })
    Bu yaklaşım, öğe odağını, giriş değerlerini, ses/video oynatıcı durumunu koruyarak ve öznitelikleri değiştirerek farkları daha az müdahaleci biçimde uygulayabilir. Idiomorph gibi JavaScript kütüphaneleri bunu yapıyor, ancak native bir çözüm büyük olasılıkla çok daha hızlı olur.

    • Yazıda, yararlı bir düşük seviyeli API olabilecek DOM part önerisine bağlantı var. VDOM tabanlı framework’lere pek uymayabilir, ancak diğer framework’lerde çalışma biçimini basitleştirebilir ve optimizasyon alanını artırabilir.
      Framework kullanmayan projeler için de yararlı olur; Signals önerisi de benimsenirse özellikle daha kullanışlı hâle gelir.

  • Records and Tuples önerisi yalnızca duraklamış değil, geri çekildi. https://github.com/tc39/proposal-record-tuple/issues/394
    Onun yerini https://github.com/tc39/proposal-composites aldı.