Statik Site Paradoksu

• Kişisel blog veya iletişim sayfası gibi basit sitelerde bile sıradan kullanıcılar WordPress gibi CMS'lerde kalırken, statik HTML sitelerini işletmenin aksine profesyonel mühendisler için daha kolay olduğu tersine dönmüş bir durum var
• Statik bir siteyi doğrudan oluşturmak için alan adı satın alma, barındırma seçimi, DNS ayarları, SSG seçimi ve dağıtım hattı kurulumuna kadar birçok ara adımı kendi başınıza halletmeniz gerekiyor
• Mühendisler GitHub Pages veya Cloudflare Pages ile ücretsiz barındırma ve özel alan adı kullanırken, sıradan kullanıcılar statik bir sitenin yeterli olduğu durumlarda bile daha pahalı ve daha ağır hizmetlere bağımlı kalıyor
• SuperHTML, kullanıcılara tanılama bildiren ilk HTML dil sunucusu olarak tanıtıldı; mevcut tanılama araçları ise genellikle belirli bir front-end framework'üne bağlı olduğundan yalnızca vanilla HTML ile kullanılması zor
• Basit web geliştirmeyi kolaylaştıramazsak web, uzman olmayanlardan uzaklaşır ve sıradan kullanıcılar sosyal ağlar gibi kapalı alanlara itilir

---

Statik sitelerin daha zor hâle gelmesi paradoksu

• İki kişisel web sitesi örneği karşılaştırılıyor
  • Biri PHP ile yazılmış karmaşık bir CMS; web sunucusu, birden fazla worker, Redis önbelleği ve SQL veritabanı gerektiriyor
  • Front-end de Single Page Application olarak yükleniyor, içeriği JSON biçiminde istedikten sonra istemci tarafında yeniden oluşturuyor
  • Diğeri ise statik HTML dosyası ile bir iki CSS dosyasından oluşuyor ve JavaScript içermiyor
• Görünüşte sıradan kullanıcıların basit statik site, profesyonel mühendislerin ise karmaşık yapı kullanacağı düşünülebilir; ancak gerçekte durum neredeyse bunun tersi
• Sıradan bir kullanıcının statik bir siteyi kendi başına işletmesi için birçok aşamayı geçmesi gerekiyor
  • Alan adı satın alma
  • Barındırma platformu bulma
  • DNS ayarları
  • SSG seçme veya kendisi oluşturma
  • Dağıtım hattı kurma
• Buna karşılık yazılım mühendisleri GitHub Pages, Cloudflare Pages vb. aracılığıyla ücretsiz barındırma ve özel alan adı desteğinden yararlanabiliyor
• Sonuç olarak statik bir web sitesinin yeterli olacağı durumların %99'unda bile sıradan kullanıcılar daha fazla ücret ödedikleri ve daha fazla işlem kaynağı kullanan karmaşık çözümlere bağlı kalıyor

Basit web'i kolaylaştıran araçlara duyulan ihtiyaç

• Boston'daki SquiggleConf sunumu, bir HTML dil sunucusu uygulama deneyimini ele aldı ve sonuç web erişilebilirliği sorununa bağlandı
• SuperHTML, kullanıcılara tanılama bildiren ilk HTML dil sunucusu olarak tanıtıldı ve ilgili yazı Hacker News ana sayfasına çıktı
• Linter'lar mevcut ve editör tanılamaları da mümkün, ancak bunlar genellikle belirli bir front-end framework'üne bağlı
  • Bu yüzden kullanıcılar gerçekte karmaşıklığa ihtiyaç duymasalar bile bir framework seçmek zorunda kalıyor
• Web yalnızca yazılım mühendislerine ait değildir; web'i daha karmaşık hâle getirdikçe sıradan kullanıcılar sosyal ağların çitleri içine itiliyor
• Startup'lar veya büyük teknoloji şirketleri, ekonomik teşvikleri örtüşmediği için bu sorunu onlar adına çözmekte zorlanır; basit web'i daha kolay hâle getirmek gerekir

[GN⁺]

Hacker News yorumları

• Pazarlama ekiplerini WordPress’i bırakıp statik site kullanmaya ikna etmeye çalıştığım çok acı deneyimim oldu.
  Sonunda mesele düzenleme kolaylığına geliyor. WordPress siteleri barındırmaya, teknik sorumluya, muhasebeciye ya da okuyucuya değil editöre göre optimize edilmiş durumda; siteyi düzenleyen kişiler de uygulama biçimini belirliyor.
  100 ms’nin altında render edilen, tamamen güvenli, barındırma maliyeti 0 olan ama Markdown dosyaları ve biraz Git dağıtımı gerektiren bir site ile yavaş, pahalı, kırılgan ve sürekli bakım gerektiren ama düzenleme deneyimi iyi olan WordPress arasında seçim yaptırırsanız her zaman WordPress’i seçerler.
  Bu insanların neden seçim hakkına sahip olduğunu hep şaşırtıcı buluyorum ama aynı deneyi defalarca yapsam da sonuç hep aynıydı.

  • Bu kulağa epey kullanıcı düşmanı geliyor. Pazarlamacıların “yapması gereken iş” içerik üretip onu hedef kitlenin önüne koymak olduğuna göre, düzenleme deneyiminin güvenlikten veya render hızından önce gelmesi gayet doğal.
    Bir metin düzenleyicisi ve Git öğrenmek yerine WordPress’i seçmeleri neden tuhaf, anlamıyorum. Deney, iyi bir düzenleme deneyimi sunarken arka planda statik site ve Git dağıtımı üreten bir araç ile WordPress’i karşılaştırmak şeklinde olmalı. O zaman güvenlik ve hız gibi ikincil gereksinimler anlam kazanabilir.
  • Cevabı kendin vermişsin. Önerdiğin teknoloji onların gereksinimlerini karşılamamış. Pazarlama sitesi editörlere göre optimize edilmelidir; bu pazarlamacıların değil, geliştiricinin başarısızlığıdır.
  • Asıl nokta bu. Ben de bir mühendis olarak birkaç yıl önce WordPress’ten ayrılıp şimdi Ghost kullanıyorum ama WordPress, yalnızca “online store” diye aratınca WooCommerce dahil hazır e-ticaret platformu gibi çalışan 100 eklentinin çıkmasıyla bir kontrol hissi veriyor.
    Bir blogdan ziyade, uzman olmayan birinin yalnızca tıklayıp sürükleyerek istediği işleve göre kurcalayıp oluşturabildiği özelleştirilebilir bir uygulamaya daha yakın. Hacklenene ya da gerçek bir mühendise ihtiyaç duyan özel bir özellik çıkana kadar kod yazmaya da gerek yok.
    Hugo, Ghost vb. kullanınca iş “bunun için başka bir platform gerekir”e gidiyor; o platform da Shopify, muhasebe sistemi, sosyal ağ/üyelik eklentisi, iş ilanları panosu vb. oluyor. WordPress her şeye dönüştürülebilen bir nesne hâline geldi.
    Biri bir danışmana ne istediğini söylediğinde yanıt “WordPress’te kurarız” oluyordu; herkes WordPress kullandığı için de sorun çıkınca, bir eklentiyi biraz değiştirince ya da e-posta gönderme hook’u ekleyecek birini bulmak kolaydı. PHP danışmanları dönemi WordPress’in hâkimiyetini yarattı.
    Sorun şu ki ücretli çözümler dahil çoğu tam bir çözüm değil. Kullanmaya başlayınca WordPress’in saçma sapan kısıtlar dayattığını çabucak fark ediyorsunuz. Orta büyüklükte bir sorgunun bile 5 saniye sürdüğü ve optimize edilmemiş 50 yardımcı sorgu üreten varlık/metadata sisteminin performans felaketinin dışında bir online mağaza tasarlayamıyorsunuz. Bazı eklentiler WordPress’i baypas edip kendi veritabanı tablolarını bile oluşturuyor.
    WordPress’in mimarisi blog dışındaki şeyler için berbat ama her şeyin aracı olarak kullanılıyor. Diğer CMS’ler bunu yapmadığı için insanlar onları kullanmıyor.
  • İki farklı işlevi birbirine karıştırıyorsun. WordPress’in sunduğu şey, kullanıcıların sevdiği bir içerik yönetim sistemi; bu içeriğin nasıl servis edileceği ise kolayca ayrıştırılabilir.
    İçerik hâlâ üretilmiş statik dosyalar olarak CDN üzerinden dağıtılabilir. Statik site demek Markdown ve Git gerektirir demek değildir.
  • Seçim hakkına sahipler çünkü her gün bunlarla uğraşan kişiler onlar. Amaç içeriği hızlıca yayına almak; içerik de Markdown’a pek uymayan tablolar gibi şeylerden ayrı barındırma gerektiren görsellere kadar çok çeşitli.
    Teknik deneyimi hiç olmayan bir stajyerin bile teknik ayrıntılara takılmadan değişiklikleri yayına alabileceği bir araç zincirini uzun süre aradım ama hâlâ bulamadım.
    En yakını, headless CMS üzerine statik site oluşturucu koymak; açıkçası hepsi pek iyi değil.

• 2016'da yerel işletmeler için tanıtım siteleri yapan bir ajansta çalışırken, bir müşteri kendi yaptıkları web sitesine rezervasyon sistemi için küçük bir iframe eklememizi istemişti. Gönderdikleri şey tek bir Word belgesiydi; meğer bunu HTML olarak dışa aktarıp ucuz bir paylaşımlı hosting'e yüklüyorlarmış
  Onlar için gayet iyi işliyordu. Çevrimiçi menüyü her zaman güncel tutabiliyorlardı; çünkü basılı menüyü hazırladıkları Word belgesinden aynen dışa aktarmaları yeterliydi. O zamanlar ekip içinde biraz alay etmiştik ama şimdi düşününce üzülüyorum. Restoran işletmek gibi milyon tane daha önemli iş varken bu aslında dâhice bir yöntem
  Statik site yapmak hâlâ daha kolay. Sadece HTML üreten yazma araçları şu anda pek iyi değil ya da iyi olsalar bile siteyi sunmak için sunucuda çalışması gereken bir süreç ekleniyor

  • İşletmelerin sorunları bu şekilde çözmesini seviyorum. Çalışıyorsa çalışıyordur
    Benim işim “bunu daha iyi yapabilirdik” diye alay etmek değil; onların çözümünü iyileştirmek, sunduğum çözümün mevcut yöntem kadar, mümkünse daha iyi çalışmasını sağlamak ve zaten elde ettikleri başarıyı sekteye uğratmamak
    Pek çok geliştirici kabul etmek istemese de, bu tür geçici web çözümleri çoğu zaman deneyimli bir web geliştiricisinin tek başına uygulayacağı birçok stratejiden daha iyi çalışır
    Önemli olan işletmenin ne sunduğu ve müşterileriyle nasıl ilişki kurup etkileşime girdiğidir. Bazen bir Word belgesini HTML olarak dışa aktarmak yeterlidir. Teknolojiyle iyileştirme yapılabilir ama asıl sihir işi yürüten insanlardadır
    Bu tür çözümleri iyileştirmenin yolunu bulmak bazen gerçekten epey zor olabilir. Daha iyi bir web sitesi yapıp gelişmiş bir altyapıya dağıtabilirsiniz ama sonuçta müşteriler bunu daha mı çok beğeniyor? İşletme daha mı iyiye gidiyor? Bu kısmı hiç de önemsiz olmayabilir
  • FrontPage'in ortadan kaybolmasını uzun zamandır eleştiriyorum. Ürettiği HTML korkunçtu diye alay ederdik ama aynı zamanda sıradan işletme sahiplerinin ya da normal insanların, iyi bir parola seçtikleri sürece güvenlik kaygısı olmadan küçük ve ucuz web sitelerini güncelleyebildiği bir programdı
    Word'ün HTML dışa aktarımından daha doğru HTML üreten ve daha fazla seçenek sunan iyi bir alternatifi yıllardır arıyorum
  • Bu yaz CDMX'te gittiğim bir restoranın menüsü, bir Figma belgesinin herkese açık önizleme bağlantısıydı. Bunu fark etmek çok komikti ama aynı zamanda bu kadar iyi çalışmasına sevindim
    Böyle şeyleri seviyorum. Vue template ile yapılan tek HTML dosyalı siteler de çok var; herkese açık Notion belgesi olarak yayımlanmış siteler ya da iCloud'daki satır içi fotoğraf kitaplıkları da. Sadece birbirine bağlamanın ne kadar kolay ve yaygın hâle geldiğini görmek şaşırtıcı; ayrıca sıfırdan kendimiz yapmaya çalışırken işleri ne kadar sık karmaşıklaştırdığımızı da hissettiriyor
    Zamanım olmadığında küçük mikro siteleri ya da tek seferlik siteleri hızla bir araya getirmek için mmm.page gibi şeyleri de seviyorum. Bu araçları keşfetmek eğlenceli
  • Bir müşteri için meta veri yönetimi, kalite kontrolü ve daha bir sürü havalı iş yapan bir “veri uygulaması” yaptım
    Ama bazı sayfalardaki “belgeler”, tarih ve metin içeren tablo gruplarından oluşuyor ve müşteri bunları kendisi yönetiyor. Sonunda vardığımız çözüm de benzer oldu. Word belgesine tablo koyup bize veriyorlar; biz de HTML/CSS olarak dışa aktarıp doğru yere yerleştiriyoruz
    Zarif değil, ölçeklenebilir bir çözüm de değil ama söz konusu kullanım için açık ara en kolay yöntem
  • Rusya'nın Ukrayna'yı işgalinin hemen ardından Almanya'nın insani yardım yanıtı da, resmi kurumlar birkaç gün ila birkaç hafta sonra yetişene kadar böyle yürüdü. Notion, Telegram, WhatsApp ve Google Docs durumu kurtardı
    O zaman da hayranlık vericiydi, şimdi de öyle. Sessizce, bilişimi herkese ulaştırma hayalini gerçekleştirdik

• Şu anda Asheville'de bu sorunu ciddi biçimde yaşıyoruz. Cep telefonu hizmeti zar zor geri geldiğinde bile herkes kopup duran berbat 3G kullanıyordu ve temel hayatta kalma bilgilerini almamız gereken web sitelerinin hiçbiri yüklenmiyordu
  İyi insanlar yalnızca metin içeren bir haber sitesi yaptı; bugün Buncombe county web sitesinde de düşük bant genişlikli bir site çıktığını gördüm ama açınca hâlâ render'ı engelleyen 130KB Bootstrap CSS ve 50KB jQuery olduğunu fark ettim
  İnsanların bunları yapması harika ama vatandaşların buna bir buçuk hafta önce ihtiyacı vardı. Şimdi suyu, gıdayı, içilemeyen suyu vb. nereden bulacağımızı zaten öğrenmiş durumdayız. Bu süreçte teknolojinin bu kadar ağır başarısız olduğunu görmek insanın gözünü karamsar bir şekilde açıyor

  • O kadar felaket düzeyinde değil ama bizim mahallede elektrik kesildiğinde de genelde elimizde sadece çekimi kötü cep telefonu kalıyor. Kablo internet ekipmanlarında yedek güç yok
    Elektrik şirketinin kesinti haritası girişin arkasına saklanmış ve şık kümeleme ile UI özellikleriyle render ediliyor; iyi bir bağlantıda bile zaten yavaş. Bu yüzden durumu kontrol etmek ya da kesintiyi bildirmek bile epey uzun sürüyor
    Elektrik şirketini aramak da mümkün ama menüyü tuş takımı tonlarıyla değil sesli gezinmeyle seçtirmişler; kötü 4G ya da 2G bağlantısında bozulan sesi de iyi tanıyamıyor
  • Bu tür durumlar bana yeniden amatör telsiz lisansı almayı düşündürüyor. Sadece Asheville değil, çok daha geniş Western NC'yi vuran afet gibi durumlarda internet tabanlı sistemlere güvenmek istemiyorum
    Uzun dalga boyları ve düşük güç gerekiyor. Ama erişilebilirliği çok düşük ve bunun geçerli nedenlerle mi böyle olduğundan emin değilim
    Black Mountain'dan Tennessee ve Georgia sınırına kadar bağlantı koptu. Berbat 3G'yi bile yeniden yakalayabilen çok kişi var mı bilmiyorum. Bildiğim şey, orada yaşayan insanlarla iletişimi sürdürmenin zor olduğuydu
  • Yalnızca metin içeren haber sitesinin bağlantısı var mı?
  • Uzun zamandır her tür kötü internet bağlantısını kullandığım için bu duruma alışığım. İnternetin çok büyük bir bölümü hızlı bilgisayarlar, hızlı internet ve harika monitörler varsayılarak tasarlanıyor
    En iyi işlerimden bazılarını, güvenilmez otel Wi‑Fi'ına bağlı 12 inç MacBook'ta yaptım. Bu yüzden sayfa hızına çok önem veriyorum
  • Asheville'den yaklaşık 45 dakika uzaklıktaki Sylva'da yaşıyorum; cep telefonu hizmetiyle telefondan yararlı bilgi almak gerçekten çok kötüydü. Starlink olmasaydı en az bir hafta boyunca birçok şeyden tamamen habersiz kalırdım
    Bu felaketin acısını tek cümleyle özetlemek gerekirse, her türlü iletişim çöküşüydü

• “Web yalnızca yazılım mühendislerine ait değildir. Web’i ne kadar karmaşık hâle getirirsek, sıradan kullanıcıları sosyal ağlar dediğimiz çitlerin içine o kadar iteriz” sözüne güçlü biçimde katılıyorum.
  Bu alıntının geçtiği yakın tarihli Squiggle Conf konferansıyla ilgili bir podcast de var: https://changelog.com/jsparty/339

• Zamanla insanların “temel web sitesi”nden beklediği özellikler çok yükseldi.
  Bir programcı olarak ben de statik site oluşturucu tuzağına birkaç kez düştüm.
  Bir yan projeye statik site oluşturucuyla başlayıp küçük bir özellik eklemek istediğim anda, keşke basit bir Rails ya da PHP uygulamasıyla başlasaydım diye pişman olup sinirleniyorum.
  Bugünlerde statik siteye ihtiyacım olduğunda doğrudan bir HTML dosyaları klasörüyle başlıyorum. Araçlar üzerine masa başı tartışmalarına girip ertelemeden, fikirden uygulamaya giden yol çok daha az karmaşık ve daha hızlı oluyor.
  HTML ve CSS’i doğrudan yazmaktan oldukça memnunum ama bunu herkese önermem.
  Bir başka güzel yanı da şu: Sonradan Rails’e “kaçmaya” karar versem bile HTML dosyaları klasörünü Rails’in public/ klasörüne kopyalamam yeterli. Yükseltme yolu oldukça kolay.

  • İhtiyacına uygun statik site oluşturucuyu henüz bulamamış olabilirsin.
    Ruby tarafında Jekyll en bilinen seçenek, ama Markdown ya da başka hafif işaretleme dilleriyle blog yazmak gibi belirli bir kullanım için tasarlanmış. Başka amaçlara zorla uydurulabilir ama genel amaçlı bir statik site oluşturucu olarak pek rahat değil.
    Rails’e kolayca kopyala/yapıştır yapılabilecek bir şey istiyorsan Rack tabanlı statik site oluşturucu middleman iyi bir seçenek. En baştan erb/haml ve ActiveSupport ile yazabilirsin.
    HTML ve CSS’i elle yazmanın sadeliğini koruyup yalnızca include, parçalı şablonlar, bağlantı yardımcıları gibi kolaylıklar istiyorsan nanoc kademeli bir statik site oluşturucu olarak fena değil. Sıradan HTML/CSS ile başlayıp yalnızca ihtiyaç duyduğunda özellik eklersin.
  • Örnek olmadan tartışmak zor gerçekten. 10 yıldan da uzun süre önce Pelican kullanmaya başladım ve hâlâ memnunum.
    Bazen davranışı özelleştirmek için kod yazıyorum ama bu birkaç yılda bir oluyor. Basit ve gayet iyi çalışıyor.
    Dinamik sitelerde özlediğim şeyler var, ama basit bir HTML dosyaları klasörünün hangi açıdan Pelican’dan daha iyi olduğunu pek bilmiyorum.
  • Kişisel web sitemde 20 yılı aşkın süredir yazı yayımlıyorum ve akış kabaca temel HTML → Drupal → WordPress → Jekyll üzerinden temel HTML şeklindeydi.
    Web sitesinin özellik şişmesini önlemek için koyduğum temel kural, istediğim kimliği belirlemekti. Yaptıklarımın bir arşivi olarak kalmasını istiyordum; arşivse zaman içinde çok uzun süre dayanmalı. Bu yüzden kopyalaması, aynalaması ve herhangi bir barındırma platformunda çalıştırması kolay statik dosyalar doğru seçenekti.
    Çok dilli siteyi düzgün oturtmak biraz zaman aldı ama en azından bir kez ödenen bir bedeldi.
  • Blog için Hugo kullanıyorum. Çünkü stile değil içeriğe odaklanmayı kolaylaştırıyor. Saf HTML dosyaları yazmayı sevmememin nedeni de bu.
    Stil değişiklikleri HTML dosyalarına hard-code edilmişse bu da sorun olabilir.
    Daha gelişmiş işler için Django yazıyorum. Özellik eklemek benim için çok kolay.
  • Ben de bugünlerde statik siteye ihtiyacım olduğunda HTML dosyaları klasörüyle başlıyorum. İçerik için .md → .html adımı eklemeyi düşündüm ama şu ana kadar gerekmedi.
    Siteyi yerel sunucuyla kolayca görebilmek de güzel. En iyisi file:// ile de görülebilmesi olurdu ama yapıyı tamamen çözemediğim için, dosya tabanlı görüntüleme için ayrı bir kopya oluşturan make local adımıyla işi bitirdim.

• Web geliştiricilerin kişisel web sitelerinde karmaşıklığı artıran bir etken var: özgeçmiş odaklı geliştirme.
  Kişisel yan projelerini özgeçmiş odaklı geliştirme için kullanan profesyoneller var; bunun işverenin projelerini bozma olasılığını azalttığını düşünüyorlar.
  Örneğin bu sabah da yakında yayımlanacak bağımsız bir web sitesi vardı; çoğunlukla özgeçmiş gerekçeleriyle popüler ve modern bir web framework’ü kullanıyordu, ama artık web sitesini güncelleyemez hâle geldi.
  Bir NPM paketinde kritik bir güvenlik sorunu vardı; güncellemeye çalışınca NPM otomatik çözülemeyen karşılıklı bağımlılık çakışmalarına takıldı. İronik biçimde bu yüzden prodüksiyon sitesine güvenlik güncellemesi gönderilemedi.
  O site elle yazılmış 5 HTML dosyası, biraz inline JS ve 2 küçük Perl CGI betiğiyle yapılabilirdi. O zaman 25 yıl sonra bile kusursuz çalışıyor olurdu.
  Bunun yerine yalnızca NodeJS kısmında bile 129 NPM paketi, sık sık gereken güvenlik güncellemeleri, şablon parçaları ve TS ayarları, handler’lardan oluşan anlaşılmaz bir kaynak dosya ağacı var.
  Ama profesyonellerin işi saçma derecede karmaşık yapmama lüksü yok. Örneğin özgeçmişte Perl olması işe alınabilirlik açısından ölümcül darbedir. Yaş ayrımcılığı yüzünden özgeçmişi çöpe atmayanlar bile özgeçmiş odaklı geliştirme yapmadığın için seni aptal sayacaktır.

  • İnsanlar karmaşıklığın kırılganlığını fark etmeye başladıkça akışın değiştiğini düşünüyorum.
  • Web ile dağıtık sistemler arasında gidip gelerek çalışıyorum; neyse ki içeriği XML ve JSON dosyalarından okuyan sıkıcı bir PHP sitesi iş değiştirmeme hiç engel olmadı.
  • Bunu gerçekten denedin mi? Ayrıca faydası olmadığını düşünüyorsan bugüne kadar yaptığın her şeyi özgeçmişine koyman gerekmiyor.
  • Elle yazılmış 5 HTML dosyası, biraz inline JS ve 2 Perl CGI ile 25 yıl kusursuz çalışabilir; ama pratiklik açısından bunun ortasında bir yerde de olunabilir.
    Benim durumumda özgeçmiş ya da tekliflerle hiç ilgilenmiyorum, ama yine de JS/Python şablonlarından HTML üretmekten daha ergonomik bir şey istiyorum. Bu yüzden sitelerim TypeScript, Mithril, Express ve birkaç yardımcı kütüphanenin birleşimi.
    Kaç paket olduğunu bilmiyorum ve umursamıyorum. Esas olarak içeri aldığım şeylerin olgun olması ve birkaç dakikada bir yeni özellik-güvenlik açığı doğurmaması yeterli.
    Stack’i söylemedin ama React ve onun “sürekli gelişen ama asla bitmeyen” ekosistemi olma ihtimali yüksek görünüyor. İstenmeyen bir tavsiye verecek olursam yanlış ikileme inanmamak iyi olur. Saf HTML ile en kötü çamur deryası arasında geniş bir alan var; React dünyasındaki durum React’e özgü, dışarısını temsil etmiyor.

• WordPress’ün killer app’i yorumlardır. Statik site üreticileri neredeyse tanım gereği yorumlara izin vermez, ama WordPress bloglarında bu neredeyse her zaman yerleşik olarak bulunur.
  Hugo gibi bir şey blog alanında gerçekten tutmak istiyorsa, yorumlu ve güzel görünen bir tema yapması yeterli. Bunu ölçekli biçimde çözmek gerekir. Örneğin blog başına shard edilmiş SQLite kullanarak üçüncü taraflar bunu çok ucuza barındırabilir. O zaman küçük bir altın yumurtlayan tavuk olur.

  • Blog çağında bu doğruydu, ama artık çok daha az geçerli olduğunu düşünüyorum.
    Yazılara dair yorumlar ve tartışmalar Reddit, HN, Facebook gibi üçüncü taraf topluluklarda. Substack yazısının altındaki yorum listesini tarayanlarla, aynı yazı hakkındaki HN yorumlarından bir iki sayfa okuyanlar arasında hangisi daha fazladır?
    Teknik bir yazıysa, HN tartışmasının belirli bir yazının yorum zincirinden daha kaliteli olacağı neredeyse kesin gibi. Çünkü HN zaten tüm blogların %99,9’undan daha geniş bir okur kitlesini çekmiş durumda.
    Bir blog yazısına doğrudan yorum yapmanın başlıca avantajı, yazarın onu görme olasılığının çok daha yüksek olması. HN’in ön sayfasında kısa süreliğine yer almak geçici bir durum.
  • Hacker News ve “gerçek programcılar”, CMS’in temel kavramlarını sürekli hafife alıyor. Bunu seksi olmayan bir teknoloji olarak gördükleri için, etrafındaki tüm sorunları çoktan çözülmüş sıkıcı problemler sayıyorlar; bu yüzden gerçek sorunların ne olduğunu pek bilmiyorlar.
    WordPress ekosistemi bunun tam tersi. CMS ve web sitesi işleten insanların kendi küçük pazar nişlerinde neye ihtiyaç duyduğunu derinden anlayan milyarlarca dolarlık işletmelerden oluşuyor; bu pazarın ölçeği de yaklaşık 500 milyon web sitesi.
    Bu yazıyı yazan kişi zeki olabilir, ama CMS’in pratik kullanım alanları konusunda kesinlikle zeki değil. “Statik HTML siteleri daha iyi ama kötü şirketler yüzünden popüler değiller” dünya görüşünün çoğunlukla yanlış olduğunu, para karşılığı bir iki web sitesi yapınca anlarsınız.
    Statik HTML site üreticilerinin müşterinin istediği her şeyi yapma olasılığı çok düşük. WordPress bu pazarın ne kadar geniş ve çeşitli olduğunu uzun zaman önce fark etti ve bu yüzden eklenti desteği uyguladı.
    Yorumların, statik site üreticisi yerine CMS’e yakın bir şeyi web’de kullanmanın özgün kullanım alanlarından biri olduğuna %100 katılıyorum. Ama bunun dışında milyon tane kullanım alanı daha var.
    Yalnızca statik HTML belgeleriyle çok uzağa gidemezsiniz. Minimal geliştirici blogunun dışına çıktığınızda gerçek kullanıcıların ve müşterilerin istediklerini yapmak için epey program mantığı gerekir. Bu yüzden ihtiyaca uygun CMS’i kullanır, çok trafik kaldırmasını istiyorsanız agresif biçimde cache’lersiniz. Bu da işin bir parçası.
    Kendini çok önemli gören geliştiricilerin, cache’in nasıl çalıştığını biraz öğrenip uygulamak yerine neden tekerleği yeniden icat etmeye çalıştığını hiç anlayamıyorum. Bu da fazla sıkıcı bir “çözülmüş problem” olduğu için mi?
  • WordPress’ün killer app’i yorumlar değil, eklenti ekosistemidir. Hugo’da bütün hafta sonu ayar yapacağınız bir işi WordPress’te annenizin bile iki tıklamayla açabileceği bir eklenti vardır.
    Ben de Hugo kullanıyorum, ama mühendislik açısından kapladığı alan gereksiz büyük olsa bile kullanıcı deneyimi WordPress’te çok daha dostça.
  • Bir başka “etkileşim” unsuru da iletişim formudur.
    Her işletme sitesi yorum istemez, ama muhtemelen iletişim formu ister. E-posta adresini açıkça yayınlamak da bir alternatif, ama giriş hattını yönetmek daha iyidir.
    Statik bir sitede, gönderimleri işleyecek güvenilir bir servis bulup siteye doğru şekilde bağlamanız gerekir. Bu bir hareketli parça daha demektir; ayrı ödenecek bir fatura olabilir ve sektör konsolide oldukça uğraşmanız gereken bir unsur daha ekler.
  • Disqus bir süre bunu çözdü, ama yıllar boyunca insanları uzaklaştıracak şeyler yaptı: https://en.wikipedia.org/wiki/Disqus#Criticism,_privacy,_and...
    https://hn.algolia.com/?q=%22disqus%22
    Facebook da birçok sitenin kullandığı bir yorum sistemi sunuyordu, ama çeşitli skandallar yüzünden güven ve erişim kaybetti.

• Ben de o paradoksa uyuyorum. Kişisel web sitemi framework veya veritabanı olmadan modern PHP ile yeniden yazdım.
  Çoğunlukla statik bir site, ama header’ı PHP ile ekliyorum ve blog yazısı listeleri gibi listeleri işliyorum. Tamamen statik olmaması biraz daha kullanışlıydı. Yazıyı yazıp commit ve push edince hemen çevrimiçi oluyor. Çoğu statik site üreticisi bana fazla karmaşık geldi.
  Tek sayfalık kod kabaca title = "Blog Article Title";, $this->shortTitle = "Title";, $this->date = mktime(0,0,0,1,27,2024);, if ($this->mode == PageMode::Meta) return; ardından ham HTML içerik gelecek şekilde.
  Router site header ve footer’ını otomatik ekliyor; bir klasöre _layout.php dosyası eklediğinizde alt sayfalara bir düzen katmanı daha ekleyebiliyorsunuz. Blog listeleme sayfası, klasördeki tekil yazı dosyalarını tarayıp indeks oluşturuyor.
  Burada $this->mode == PageMode::Meta kullanılıyor. Her dosyanın kodunu çalıştırıp metadata’yı alıyor ve geri kalanı render etmeden önce çıkıyor. İçerik çoğalırsa ölçeklenebilirliği iyi olmayabilir, ama sorun olursa ayarlayacağım.
  “Framework”ümün tüm PHP kodu yalnızca dört dosyadan oluşuyor: init.php, functions.php, Layout.php, Page.php.
  Geliştirici olmanın avantajı, ayar veya veri yerine kod yazabilmek. İçeriği daha verimli yazmak için de kod kullanabilirsiniz.
  Sonuç hâlâ epey tamamlanmamış, ama burada: https://www.codaris.com/

  • Benim web sitelerimden biri de az önce aynı şekilde başladı. %90’ı HTML; header ve birkaç global parça için yalnızca PHP ile include() kullanıyor.

• Web sitesi sahibi açısından kullanıcı deneyimini düşünürsek bu pek de bir paradoks değil. WordPress, ek yükü çok daha fazla olsa bile işleri inanılmaz derecede kolaylaştırıyor
  Bunu ancak çeşitli ayarlarla uğraşmaya zaman ayırmakla bir takas olarak düşündüğünüzde paradoks gibi görünüyor. Çoğu insan için alternatif, birine para verip web sitesini yaptırmak
  Hugo için bir WYSIWYG editörü yapıp alan adı kaydından siteyi yayımlamaya kadar her şeyi birkaç tıklamayla bitirirseniz büyük para kazanabilirsiniz

  • Netlify, Squarespace, GitHub Pages gibi şirketlerin yaptığı şey bu değil mi? Netlify’da park edilmiş bir alan adını taşıyıp bir şablon seçtiğinizde, kurulumun çoğunu hallediyorlar; site birkaç dakika içinde yayına giriyor, alan adı işlemleri ise yaklaşık 24 saat sürüyor
    Ne demek istediğini anlıyorum. Bu şirketler söylediğine yakın işler yapsa da, aradaki küçük adımları halledebilen biri için büyük bir avantaj olur
  • Az önce Micro.blog’u[1] tarif etmiş olmadın mı?
    [1] https://micro.blog

• “SuperHTML’i yayımladığımda, kullanıcılara tanılama bildiren HTML için ilk dil sunucusu olduğunu fark ettim. Bir blog yazısı yazdım ve Hacker News’in ana sayfasına çıktı; kimse düzeltmediğine göre doğrudur” kısmı, muhtemelen Microsoft LSP’yi çıkarmadan önce de çoğu IDE’nin bunu yıllardır yapıyor olmasından kaynaklanıyordur

  • Popüler editörler arasında saf HTML için tanılama sunmanın bir yolu olanların çok az olduğunu düşünüyorum. Bildiğim tek istisna WebStorm
    Vim, Neovim, Helix, Zed, VSCode; hepsi tanılama desteği olmayan aynı temel uygulamayı paylaşıyordu
    Helix, bir sonraki sürümden itibaren SuperHTML’i varsayılan olarak etkinleştirmeyi planlıyor: https://github.com/helix-editor/helix/pull/11609