XSLT - Web için yerel, sıfır yapılandırmalı derleme sistemi

 (github.com/pacocoursey)
2 puan yazan GN⁺ 2025-06-28 | 1 yorum | WhatsApp'ta paylaş
  • XSLT, karmaşık bir derleme sistemi olmadan doğrudan kullanılabilen, web için yerleşik bir derleme aracıdır
  • Statik site derleme sistemlerinin çoğunda karmaşıklık, anlaşılabilirlik zorluğu ve framework bağımlılığı sorunları vardır
  • XML ve XSLT kullanılarak tarayıcıda doğrudan HTML üretmek mümkündür; dinamik veri işleme ve işaretleme üretimi kolaylaşır
  • Tüm büyük tarayıcılar XSLT tabanlı dönüşümü desteklediği için ek JavaScript veya ayrı araçlar olmadan kullanılabilir
  • Kusursuz bir çözüm olmasa da, web standartlarına dayalı basit ve esnek bir alternatif olarak yüksek bir kullanım değerine sahiptir

Giriş ve sorun tanımı

  • Çoğu statik web sitesi geliştirme süreci; veriler için dosyalar (.json, .md, .txt), ayrı bir derleme sistemi (Hugo, Next.js, Astro vb.) ve ortaya çıkan HTML yapısından oluşur
  • Derleme sistemleri giderek daha karmaşık hale gelir ve küçük bir blogu bile anlamak ve işletmek zamanla zorlaşır
  • Framework kullanmadan, yalnızca basit HTML, CSS ve standart tanımlar (HTTP, URI, HTML) ile çalışmaya çalışıldığında; header veya footer tekrarları gibi bakım sınırları ortaya çıkar
  • HTML import, web component gibi yöntemler de denendi; ancak ilki desteklenmiyor, ikincisi ise JavaScript motoruna bağımlılık nedeniyle iyi bir alternatif olamadı

Web tarayıcısını derleme sistemi olarak kullanmak

  • Çıkış noktası, web tarayıcısının kendisinin çeşitli veri dönüşümlerini (text/html, text/markdown, application/xml vb.) desteklemesidir
  • Web standartları daha derin incelenerek, gereksiz harici araçlar ve framework'ler olmadan bu sorunu çözmenin yolları araştırıldı

XSLT'nin kullanımı

  • RSS akışını daha şık göstermek isterken XSLT standardı keşfedildi
  • XSLT, hem XML verisini hem de HTML çıktı yapısını ifade eden resmî bir standart teknolojidir
  • Kullanımı basittir
    • Örneğin veriler blog.xml içinde düzenlenir
    • Ardından XSLT stil dosyası şu şekilde bağlanır
      • <?xml-stylesheet type="text/xsl" href="blog.xsl"?>
    • blog.xsl içinde HTML şablonları ve veri eşleme kuralları yazılır
  • Şablonlar, döngüler, değişkenler, harici dosya import etme gibi çoğu derleme sistemi özelliği desteklenir

Çalıştırma yöntemi ve avantajlar

  • Ayrı bir araç olmadan, XML dosyasını yalnızca web tarayıcısında açmak dönüşüm sonucunun hemen render edilmesi için yeterlidir
  • XML biçimi HTML'ye benzediği için insan dostudur ve bakımı kolaydır; JSON yerine kullanıldığında da rahatsız edici değildir
  • Başlıca web tarayıcılarının tamamı XSLT tabanlı dönüşümü yerel olarak destekler, böylece istemci dönüşüm sonucunu doğrudan görebilir
  • JavaScript, ayrı derleme araçları veya bundler gerektirmemesi çok büyük bir avantajdır
  • XSLT nihai ve her şeyi çözen bir araç olmasa da, basit ama genişletilebilir bir web derleme alternatifidir

Sonuç

  • Eski bir teknoloji olan XSLT'nin ve açık standartların değeri yeniden keşfediliyor
  • Web tarayıcısını bir derleme sistemi olarak kullanma yaklaşımı, web geliştirme araç kutusuna eklenmeye değer faydalı bir seçenektir

İlgili okumalar

1 yorum

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

  • Çalıştığım şirketlerden biri XML şablonlarında XSLT'yi çok yoğun kullanıyordu ve muhtemelen hâlâ da kullanıyordur. Açıkçası bu iyi bir tercih değildi; mümkün olsa başka bir şeye geçmek isterlerdi

    1. XSLT'nin modern standartları var ama hâlâ ağırlıkla 1.0 sürümü kullanılıyor; bu sürüm yeni standartlara kıyasla daha kısıtlı ve garip yönleri çok
    2. XSLT şablonlarındaki performans sorunlarını çözmek aşırı derecede zor. XSLT, Turing-tam işlevsel tarzda bir dil olduğu için performans görünmez kalıyor. Çoğu belgede sorun yok ama 100 satırlık bir girdi gelince bir anda patlıyor. Tabloyu işleyen kod O(N^2) performansa sahip olabiliyor ve optimize etmek neredeyse imkânsız. Örneğin her satır için O(N)'lik bir XPath çalışıyor olabilir. Hatırladığım kadarıyla o şablonun tek bir belgeyi işlemesi 7 dakikadan uzun sürüyordu.
      JS'nin de sorunları var ama en azından böyle algoritmik karmaşıklıkları düzeltmenin imkânsız olduğu bir durumda değilsin

    • XSLT/XPath 1.0'dan sonra epey gelişti. key(indeks) gibi çeşitli özellikler geldi ve işlem hızları ciddi biçimde arttı. Saxon gibi kaliteli bir XSLT uygulaması kullanırsan performans sorunları da çok daha az olur. XML'i başka bir şeye dönüştürürken mantıksal yapıyı kurmak için XSLT kadar kullanışlı çok az şey olduğunu düşünüyorum

    • XSLT'yi öğrenmek oldukça zor. Biraz rüya gibi bir Prolog'u andırıyor ve gerçekten ustalaşırsan sudoku çözerkenki o tatmini veriyor. Ama çoğu durumda bu kadar karmaşık şablonlara ihtiyaç olmuyor, o yüzden standart bir seçenek hâline gelmesi zor. Bir de XML zaten herkesin sevdiği bir format değil

    • XSLT 1.0'ın hâlâ çok kullanıldığı kısmını pek anlayamıyorum. 2013'te bile 1.0 artık neredeyse eski püskü sayılıyordu ve XSLT 2 kullanabilen Saxon ücretsizdi, performansı da çok iyiydi. Büyük ya da küçük belgeleri dönüştürürken hiç performans sorunu yaşamadım

    • XSLT'nin ortaya çıktığı dönemde çok uzun içerikli XML'leri işlemek zaten olağandı. Böyle tekrar döngüleri iç içe geçince patlaması da gayet beklenen bir istisna değil

    • Acaba ticari Saxon sürümünü mü kullanıyorsunuz diye merak ediyorum. Fiyatı da aşırı değil; yeni standart desteği, performans ve çeşitli özellikleri nedeniyle IMHO gerçekten parasını hak ediyor. Eskiden kullandığımda oldukça akıllı optimizasyonları olduğunu hatırlıyorum

  • 90'lar-2000'lerde tarayıcılar birbirinden çok farklıydı; bu yüzden davranışı eşitlemek için JS kullanılmaya başlandı
    Aslında istediğimiz şey şık CSS stilleriydi ama o zamanlar bunu düzgün kullanamıyorduk
    Zaman geçtikçe tek bir tarayıcı baskın hâle geldi ve diğerleri de ona daha çok benzemeye başladı (Highlander kuralı, ama Firefox da hâlâ epey iyi direniyor)
    Zaten framework'ler norm hâline gelmişti; sonuçta hepsinde aynı UI'yi tutturmanın yolu olarak yerleşti. Sonra paradigma JSON verisi render etmeye kaydı
    Bugün sunucuda geleneksel web sayfaları üretmek hem hızlı hem de daha az bellek tüketiyor
    Bunu söylememin sebebi, yakın zamanda legacy bir sistemden geçiş yaparken sayfa bazlı HTTP istekleriyle çalışan bir siteyi yeniden deneyimlemem oldu (2000'lerin standardı). Her işlemde sayfanın yenilenmesi gerekiyordu ama buna rağmen React kullanan sistemden çok daha hızlıydı
    Sebepleri de şunlar

    1. İnternet çok hızlandı
    2. Telefonlarda bolca bellek var ama JS framework'leri bunu boşa harcıyor
    3. Backend dün de bugün de CRUD, CRUD, CRUD (+sayfalama, +transaction)

    • AJAX ve DOM güncellemeleri sadece daha hızlı olmak için ortaya çıkmadı. Web'in paradigmasından, yani 'website/web document' anlayışından çıkmak içindi. Tam sayfa yeniden yükleme, belge merkezli paradigmada anlamlı bir yöntem. HN gibi basit örneklerde bu yapı çok iyi çalışıyor. Birçok site, JS framework'leri olmadan da bu modelle yeterince iyi işleyebilir.
      Ama "herkes tam sayfa yeniden yüklemeye geri dönebilir" demek gerçekçi değil. Gerçekte, karmaşık etkileşimler isteyen 'web uygulamaları' için tüm sayfanın yeniden yüklenmesi çok kötü bir UX.
      Özetle,
      'web siteleri', 'web belgeleri', 'basit formlar' gibi şeylerde tam sayfa yeniden yükleme çoğu zaman yeterli olabilirken
      'web uygulamaları' gibi karmaşık veri ekranları/işlemleri gereken durumlarda yeterli değil

    • Benim hatırladığım zaman çizelgesi biraz farklı. JS, tarayıcı davranışını birleştirmekten çok en baştan etkileşimli öğeler için kullanılıyordu (DHTML, AJAX vb.). Asıl layout işi ise tarayıcı bazlı hilelere ve user-agent tespitine dayanıyordu. CSS güçlendikçe bile tutarlılık sorunları kolay çözülmedi. CSS garden, semantik işaretleme, her şeyi tabloyla yapma gibi şeyler o dönemin ruhuydu ve ilk ACID testini geçmek bile inanılmaz uzun sürdü. Framework'lerin UI tutarlılığına ne kadar etki ettiği konusunda şüpheliyim — jQuery'den sonra görsel tutarlılığın asıl belirleyicisi CSS'nin kendisiydi.
      Tabii bu benim kişisel hafızam da olabilir

    • Modern teknoloji yığınlarında sunucu tarafında render edilen geleneksel web sayfalarının hızlı ve hafif olduğuna katılıyorum
      Benim .NET/Kestrel/SQLite yığınımda SSR yanıtının 4ms'yi geçmesi zor. Çoğu zaman yüzlerce mikrosaniye seviyesinde oluyor. Her sayfada birden fazla sorgu ve karmaşık join'lerle görünüme uygun veri şekillendirmesi yapıyorum
      100.000 satırlık tablo üretmek gibi uç durumlarda bile, HTML string'ini birleştirmeden önce veriyi iyi işlersem performans ciddi artıyor. LINQ performansı da çok iyi ama satır başına koleksiyon oluşturursan veri büyüdükçe aşırı verimsizleşiyor
      Benim deneyimime göre HTML template engine ile veritabanını mümkün olduğunca birbirine yakın tutmak performans optimizasyonu için en iyisi. Sonuçta DOM sadece bir byte stream. Karmaşık AST/parser kurmaya gerek yok; StringBuilder ile SQL sorgularını birleştirmek çoğu zaman yeterli.
      Bu basit yaklaşıma gelen tek itiraz genelde hep "geliştiriciye HTML escape konusunda güvenemem" diyen güvenlikçi tartışmasıydı

    • "Modern teknolojiyle sunucuda eski tarz klasik web sayfaları gayet yeterli" sözü, ağ gecikmesi yüksekse bambaşka bir hikâyeye dönüşebilir
      bağlantı

  • 2000'lerde kurumsal XML öyle şişti ki teknoloji çağın gerisinde kalmış gibi görünmeye başladı ve sonunda herkes JSON'un 'temizliğine' kapıldı. Oysa XSLT, XPath gibi teknolojiler zaten oldukça olgundu ve bugün hâlâ uğraştığımız birçok sorunu çözüyordu
    Ben de zamanında XSLT include'ları fazlasıyla kötüye kullandım; PHP stream wrapper ile <xsl:include href="mycorp://invoice/1234"> gibi şeyler yapıyordum
    Dürüst olmak gerekirse bugün biraz demode gelebilir ama tarayıcıda yerel XSLT çalıştırmak hâlâ bana güvensiz hissettiriyor. Eskiden tam bir uyumluluk mayın tarlasıydı çünkü

    • XML'in "temel" özelliklerini JSON'da hâlâ özlüyorum. Mesela gerçekten standartlaşmış bir spesifikasyon, şema tanımları gibi konularda XML çok daha ilerideydi; JSON'un bunu yakalaması neredeyse 10 yıl aldı
      XML'i son düzgün kullandığım yer EXI adlı bir taşıma teknolojisiydi. XML belgelerini sıkıştırılmış ikili akışa dönüştürüyordu; yapı ↔ ASCII dönüşümü ↔ sıkıştırma/iletim ↔ geri dönüşüm tabii ki zahmetliydi. Bugün protobuf ve gRPC önde ama XML yaşamaya devam etseydi belki her şeyin uyumlu olduğu standart tabanlı bir dünya olurdu (en azından benim ideal hayalimde). Gerçekte protobuf/gRPC ile JSON API'leri arasında büyük bir duvar oluştu ama belki de bu daha iyidir

    • XML'in gayet iyi bir format olduğunu düşünüyorum. Uzun ve ayrıntılı ama YAML ile kıyaslayınca kesinlik ve ifade gücü bakımından çok daha üstün
      XPath'e alışmak zor ama denedikçe sonunda istediğin şeyi yapabildiğini görüyorsun
      XSLT'nin ise tamamen akıl dışı bir fikir olduğunu düşünüyorum. Ortadan kaldırılmalı

    • Rimworld adlı oyun tüm ayar verilerini XML'de tutuyor ve XPath ile modlanmasına izin veriyor. Bu ikili gerçekten çok güçlü. Yerel veri özelleştirmesi için bundan iyisi zor. Ama çoğu oyun XML "eski moda" damgası yediği için buna yanaşmıyor gibi
      Rimworld XPath modlama resmî dokümantasyonu

    • 2000'lerin başında kurumsal XML'in şişmesi meselesi gerçekten doğru. XML aslında SGML'in web'de kullanılabilecek şekilde sadeleştirilmiş hâliydi; amacı işaretleme taşımak ve sözcük dağarcığını genişletmekti. Sonunda hayatta kalanlar SVG ve MathML oldu. Web patlamasıyla birlikte W3C/MS SOAP, WS-* spesifikasyonları gibi şeyleri yağdırdı. Bir dönem, altında Scheme kemiği taşıyan XSLT gibi diller bile zorla XML'e uydurulmaya çalışıldı; tam anlamıyla çılgın bir dönemdi. JavaScript'in adının Java'ya benzetilmesi bile aynı dönemin işi

    • XPath'te namespace yüzünden usanılacak kadar uzun sorgular yazmak zorunda kalmak can sıkıcı

  • Hâlâ feed'imi XSLT ile stillendirerek kullanıyorum.
    RSS feed örneği
    XSLT örneği

    • Bunu görünce blog denen şeyin aslında sadece bir RSS feed olması gerekmez miydi diye düşündürüyor

    • XML'in aslında bunu yapabildiğini hep unutuyorum. Bir şekilde sezgisel olarak biraz garip geliyor

    • Gerçekten çok şık yapılmış. Keşke başkaları da bu tür örnekleri daha yaratıcı biçimde kullansa

  • İlk işimde (19 yaşımdayken) Google Search Appliance özelleştirmesi yapmıştım. Milyonlarca liralık sarı Dell sunuculara CentOS kurup Google tarzı Python, CIFS belge tam metin araması gibi şeyleri devreye aldığımız bir projeydi.
    2011 civarında XHTML modaydı ve Google Search Appliance'ta backend XML verisi XSLT ile XHTML'e dönüştürülüyordu. Örnek şablonları patlata patlata şirket intraneti için ucube bir UI yaptım; Coldfusion, StackOverflow, W3Schools ve başka hazır şeyleri kes-yapıştırla içine tıkıştırdım
    Bu deneyimi CV'mden hızla çıkardım. Sonrasında DoD yüklenicileri beni sürekli "XML uzmanı" diye belge sistemlerini modernize etme projelerine çağırmaya başladı, çok yorucuydu
    Bir dahaki sefere JSX ile JSON'dan TypeScript interface'lerine dizi döndürürken iç çekersen beni hatırla. En azından onu XSLT ile yapmıyorsun

  • Ben gerçekten sadelik yanlısıyım. Mağara adamı readmesi gibi kolay belgeleri severim. Bazen klavyeye mağara adamı gibi vuruyormuşum gibi de hissediyorum. Web işi yapmıyorum ve XSLT'yi de pek bilmiyorum. Bazen XML'le bir şeyler hack'leyip kullanıcıya göstermek istiyorum. Dosya formatı çok fazla, başımı ağrıtıyor. Yine de güzel görünen şeyleri seviyorum. Bunu ben de kullanabilirim
    Spesifikasyonu okuduğun ve aracı yaptığın için teşekkürler

  • İnsanlar XML'in uzun ve karmaşık göründüğünü söylüyor ama gerçekten kullandığında mükemmel bir format
    DTD ile doğrulayıp XSLT ile çıktı üretip insanın okuyabileceği hâle getirebiliyorsun
    Benim için XML, metin formatlarının C++'ı gibi. Olgun, "batteries included", güçlü ve her dile bağlanabiliyor
    Eski ve olgun dillerde olduğu gibi, insanların XML'e de tuhaf bir içerikmiş gibi sövmeyi trend hâline getirmesi üzücü. Kullanım alanına uymuyorsa kullanmazsın ama bu kadar nefret etmeye de gerek yok

    • DTD yerine neden XSD kullanmadığını merak ediyorum

  • "XSLT tarayıcıda doğrudan çalışıyor" kısmı beni şaşırttı. XSLT'yi en son 20 yıl önce kullanmıştım ve o zaman büyük kurumsal Java karmaşası yüzünden XSLT'nin kendine özgü estetiği tamamen kayboluyordu.
    Ama XSLT tarayıcıda yerleşik çalışıyorsa, host framework olmadan gerçek statik şablonculuğun kutsal kâsesi burnumuzun dibinde miydi?

    • Tarayıcılar yalnızca XSLT 1.0 destekliyor. Bunun bile ileride kalkabileceği söyleniyor. Keşke tarayıcılar 3.0'a kadar desteklese; statik web sayfası üretimi için inanılmaz kullanışlı olurdu

    • Her zaman o 'büyük kurumsal Java' kulesini kullanmak zorunda değildin. Biz sadece tomcat ve birkaç apache kütüphanesiyle kullandık ve oldukça iyi çalıştı. CMS'ten XML ile üretilen HTML'e kişiselleştirmeyi XML etiketleri olarak gömüyorduk; sunucu tarafı caching proxy sayesinde dönüşüm de hızlıydı ve yüksek trafiği kaldırabiliyorduk. Kilit nokta, XSLT çıktı akışını anında istemciye göndermek ve her şeyi bellekte tamponlamamaktı.
      Bugün wasm sayesinde tarayıcıda her şeyi çalıştırabiliyorsun ama ilk dönem JS berbattı ve tasarımcılar Photoshop PSD dosyasını düzgün teslim etse bile şanslı sayılırdın. Google Maps ve Gmail döneminde ağır JavaScript UI'lar yapmak ve hem Netscape'i hem Internet Explorer'ı desteklemek gerçek cehennemdi

    • XHTML çılgınlığının başlamasının altında da aslında bu "statik şablonculuğun kutsal kâsesi" vardı. Ama işin aslını bilenler sanki bir argo gibi üstü kapalı konuşuyordu; kimse bunu açık açık dile getirmiyordu

    • 2008'de tarayıcı içi XSLT kullanan bir sitede çalıştım; hatta 2000'lerin başında bile destek zaten vardı

    • Chrome'da libxslt, Firefox'ta ise Transformiix adlı 1.0 motoru gömülü geliyor. Chrome yalnızca exsl:node-set destekliyor, Firefox ise çeşitli EXSLT uzantılarını destekliyor (ama hepsini değil)
      Basitçe XSLT işlemcisi bilgisi ve kullanılabilir uzantıları gösteren küçük bir araç da yayımladım.
      GitHub - xslt-detect-ext
      Tarayıcıda bilgi görmek için out/detect.xslt dosyasını sürükleyip bırakabiliyorsun (Chrome, Firefox). Safari'nin eski Windows sürümünde çalışmıyor

  • 90'larda lisede "web tasarımcısı" diye anıldığım dönemde DSSSL lehçeli bir pipeline ile haber akışlarından siteyi otomatik üretiyordum. Bugün bile XSLT dönüşümlerini seviyorum. bananas XI reader gibi araçlarla gerçek metin dönüşümü ve şablon işleri de yapıyorum
    Ama bu tür araçları gerçekten seven insan sayısı hep çok azdı; benden sonra biri gelince de benim benimsediğim teknoloji genelde hızla ortadan kalkıyordu
    bananas XI reader

  • 2000'lerin başında XML ve XSLT çılgınlığının ne kadar ileri gittiğini göstermek için şunu söyleyeyim: Çalıştığım şirket XML'i gerçek zaman hızında parse edip XSLT'yi doğrudan çip üzerinde çalıştıran bir ASIC bile yaptı. O dönemde geleceğin internetinin tamamen XML/XSLT ile işleyeceğine inanılıyordu.
    Nitekim bu şirket daha sonra Intel tarafından satın alındı ve teknoloji SSE hızlandırıcı tarafına gitti

    • XML yorumlayıp XSLT'yi de doğrudan işleyebilen bu tip ASIC'ler yaygınlaşsaydı bugün web siteleri inanılmaz hızlı olurdu diye düşünüyorum

    • IBM hâlâ benzer yetenekleri yerleşik sunan donanımlar satıyor (DataPower Gateway)