Framework ve çeşitli kütüphaneler olmadan bir web sitesi kurmak

 (kodingkitty.com)
3 puan yazan GN⁺ 2023-07-05 | 1 yorum | WhatsApp'ta paylaş
  • Koding Kitty, küçük şirket web sitesi için statik HTML merkezli bir yığın kullanarak büyük bir CMS ya da framework olmadan gerekli sayfaları ve blogu işletiyor
  • Seçim kriterleri hız, geliştirme kolaylığı, ucuz hosting ve düşük karmaşıklık idi; WordPress, no-code, framework'ler ve Jamstack ise gereksinimlere kıyasla kurulum ve öğrenme yükü açısından ağır kaldı
  • İçerik, Markdown ya da görsel düzenleyici yerine doğrudan HTML olarak yazılıyor; böylece metin ile HTML/CSS/JS widget'larının karıştığı gönderi yapıları kolayca ele alınıyor
  • Tekrarlanan yapılar ve ortak bloklar Jinja şablonları ile işleniyor; 45 satırlık bir Python betiği değişiklik algılama, HTML render etme ve Tailwind CSS CLI çağrısını birbirine bağlıyor
  • Site statik olduğu için ucuz hosting yeterli oldu; Hetzner webhosting 2 EUR'dan başlıyor ve Hacker News ana sayfası düzeyindeki ani trafik artışını da kaldırdı

Basit bir yığın seçme nedeni

  • Koding Kitty'nin web sitesi teknoloji yığını, son dönemdeki hafif web geliştirme trendlerini izlemekten ziyade gerçek gereksinimlere göre bilinçli olarak basit tutuldu
  • Amaç, geliştirici için sürtünmesi düşük bir yapı oluşturmaktı ve karmaşık framework ile kütüphane kombinasyonları yerine basit bir çözümün müşteri için daha iyi olabileceği düşünüldü
  • Kendine özgü ama aşırıya kaçmayan bir tasarım birçok şekilde yapılabilirdi, ancak mevcut yapı ihtiyaç duyulan kapsam için seçildi

Gereksinimler ve ilk kriterler

  • En baştan bunun statik bir web sitesi olmasına karar verildi
  • Gerekli işlevler ön sayfa, vitrin/showcase ve blog kadardı; bunun ötesinde çok fazla ihtiyaç yoktu
  • Kriterler dört taneydi
    • hızlı web sitesi
    • hızlı geliştirme
    • ucuz hosting
    • minimum karmaşıklık

Değerlendirildi ama elenen seçenekler

  • WordPress ve benzeri CMS'ler

    • WordPress'in internette büyük bir rol oynadığı kabul ediliyor
    • Ancak mütevazı gereksinimler için fazlaydı
    • İçeriği veritabanında saklamaya, eklentilere ya da görsel düzenleyiciye ihtiyaç yoktu

  • No-code araçlar

    • Web kodlayan birinin no-code araç kullanması tuhaf hissettirdi
    • İçeriğe doğrudan sahip olmak ve siteyi istenildiği gibi yönetebilmek istendi
    • Kod yazarak üretmenin, no-code WYSIWYG editörlerden daha hızlı olduğu düşünüldü
    • İlk öğrenme ve sürekli öğrenme gereksinimi de ayrıca yük oluşturuyordu

  • Framework'ler

    • Framework deneyimi vardı, ancak tüm o kurulumu beraberinde getirmek istenmedi
    • Veritabanı, yapılandırma, kütüphaneler, yönetici işlevleri gibi bileşenler fazla çoğalabiliyordu
    • Tamamen özelleştirilebilir olsa da sonuçta WordPress'e benzer bir yapıya dönüşebileceği düşünüldü

  • Jamstack ve statik site oluşturucular

    • Statik site oluşturucular, gereksinimlere iyi uyan bir seçenek gibi görünüyordu
    • Bir dil seçip kod yazdıktan sonra düğme ya da betikle hızlı bir statik site üretmek mümkündü
    • Ancak başlangıç kurulumu ile ilk ve sürekli öğrenme ihtiyacı vardı
    • Blogu Markdown ile yazmanın rahatlığı kabul edilse de genel olarak daha basit bir çözüm seçildi

KittyStack yapısı

  • Koding Kitty'nin yapısı dört temel gereksinim etrafında şekillendi

  • Hızlı web sitesi

    • Statik web sitesi hızlı çalışır

  • Hızlı geliştirme

    • İçerik, Markdown ya da gelişmiş bir editör yerine HTML olarak yazılıyor
    • Koding Kitty gönderileri metin ile HTML/CSS/JS widget'larını karıştırdığı için HTML'yi doğrudan yazmak uygun bulundu

  • Ucuz hosting

    • Statik site hosting maliyeti sağlayıcıya ve gerekli ek özelliklere göre değişir
    • Statik siteler büyük donanım yapılandırmaları gerektirmediği için en düşük yapılandırma seçilebilir
    • Hetzner webhosting 2 EUR'dan başlıyor
    • Koding Kitty sitesi, Hacker News ana sayfasına çıkma düzeyindeki trafik artışını da kaldırdı

  • Minimum karmaşıklık

    • Bazı sayfa ve gönderilerde tekrarlanan kalıplar bulunuyor
    • Kopyala-yapıştır ile de yapılabilir, ancak zamanla kontrol etmesi zorlaşabilir
    • Döngüler ve header/footer gibi kod bloklarını dahil etme özelliklerine ihtiyaç duyuldu

Jinja ve build akışı

  • Tekrarlanan yapılar ve ortak dosya eklemeleri Jinja şablonlarıyla yapılıyor
  • Jinja; döngüler, navbar ve footer gibi dosya eklemeleri ile diğer şablon özelliklerini sağlıyor
  • Ekip daha önce Jinja tabanlı framework'ler kullandığı için yeni bir sistem öğrenmeleri gerekmedi

Basit araç zinciri

  • Nihai statik sayfalar 45 satırlık bir Python betiği ile üretiliyor
    • Bu sayı yorumlar ve boş satırlar dahil hesaplanmış
  • Build akışı şu şekilde
    • Geliştirici index.src.html dosyasını düzenliyor
    • Watchdog.py, dosya değişikliğini algılıyor
    • Jinja şablonlarını index.html olarak render ediyor
    • Tailwind CSS CLI çağrılarak styles.min.css üretiliyor
  • Geliştirme sırasında Live Server dosyaları servis ediyor ve değişikliklerde yeniden yüklüyor
  • Dağıtım anında dosyalar FTP ile manuel olarak yükleniyor

Daha az karmaşık web geliştirmenin avantajları

  • Web geliştirme, çok şeyden vazgeçmeden de basit tutulabilir
  • Seçenekleri birkaç taneyle sınırlamak, aksine daha özgür hissettirebilir
  • Birçok müşteri için daha hızlı, daha basit ve daha ucuz çözümler faydalı olabilir
  • Aynı sonucun daha az karmaşık bir teknoloji yığınıyla elde edilip edilemeyeceğini tüm web ekosistemine bakarak değerlendirmek gerekir

İlgili okumalar

1 yorum

 
GN⁺ 2023-07-05
Hacker News görüşleri

  • Fotoğraf portföyüm de aynı yaklaşımla oturdu. Geliştirmeden fotoğrafçılığa geçince diğer fotoğrafçılar gibi Squarespace'e bağımlı olmamak avantaj oldu
    Ghost, Statamic, Phoenix/Vapor ile yapılmış sunucu tabanlı seçenekleri ve çeşitli tipik statik site oluşturucuları denedikten sonra, sonunda şablonsuz düz HTML yazıp rsync ile bir Hetzner sunucusuna yükleme yöntemine geçtim
    Gezinme gibi ortak UI'larda şablon olmaması biraz can sıkıcı ama regex ile birkaç dakikadan uzun süren bir değişiklik henüz olmadı; başlarda açgözlü bir regex içeriği silmişti, beni git kurtardı
    Görüntü boyutu ve formatına göre türev üretmek zahmetli, ama Ghost gibi kalıplaşmış düzenlere yaslanmadan yeni düzenler denemeyi sağlıyor. Ayrıca çoğu statik site oluşturucunun kullandığı kütüphane ya da CLI araçlarına kıyasla, web için görsel çıkarırken bir RAW düzenleyici olan Capture One'dan alınan sonuç biraz daha kaliteli görünüyordu
    Yavaş ama bence bir fotoğraf kitabı yapmaya daha yakın. Başta daha fazla el emeği istiyor ama bir kez bitince bitiyor ve önümüzdeki 20 yıl boyunca farklı CMS'ler arasında gidip gelip bozmak gerekmiyor

    • Temel önceki/sonraki gezinme ile tutarlı menü, başlık ve altbilgi server-side include ile halledilebilir
    • Kişisel fotoğraf web sitem Svelte + TailwindCSS, Flickr API ve Netlify kullanıyor
      Esasen birkaç HTML dosyasına şablon gücü eklenmiş bir yapı; Flickr API ile bu siteye özel albümden fotoğrafları çekiyor, Netlify ise sadece git push ile otomatik dağıtım yapıyor
      Hosting dahil toplam maliyet 0 dolar ve Flickr uygulamasıyla telefondan fotoğrafları yönetebiliyorum. Netlify sayesinde gerçek bir sunucu kutusuyla uğraşmak gerekmemesi de güzel
    • Vapor deneyimi nasıldı, merak ettim
      Yakın zamanda kullandığım yöntem de yardımcı olabilir(https://news.ycombinator.com/item?id=36592641). Google Sheet'i veri kaynağı olarak kullanmak kolaydı; bunu bir fotoğraf dosya sistemiyle değiştirmek de muhtemelen aynı olurdu
    • Smugmug'dan çıkıp böyle bir şey denemeyi düşünüyordum; portföyünü ya da kaynak kodunu paylaşabilir misin diye merak ediyorum

  • Bu bana ‘simple’ değil, daha çok sadece basit görünen (simplistic) bir şey gibi geliyor. Hiçbir şey yapmayıp köşeleri keserek nispeten basit bir web sitesi yapılabilir
    Bu sayfada görünen neredeyse tek ciddi özellik olan karanlık mod bile, gecikmeli yüklenen JS ile yapıldığı için her sayfa yüklemesinde kaçınılmaz bir beyaz ekran flaşı oluşturuyor. Doğru yapmak için CSS body class yaklaşımı gerekir; çalışmayan bir çözüm, ister basit ister karmaşık olsun, anlamsızdır
    Ayrıca localStorage ve karanlık mod ayarı için gereken 3 satır JS uğruna https://hyperscript.org/ gibi özel bir ‘hyperscript’ yorumlayıcısının tamamını getirmek, “sadelik nihai olgunluktur” fikrine ters düşüyor. Sadece bunun için önbellekte olmayan 96KB'lık bir kütüphane çağırmak tuhaf; HTML doğrulamasının geçmemesinin nedeni de bu mu diye merak ediyorum
    Son olarak ikili anahtar, sistem/tarayıcı ayarlarını yok saydığı için kötü bir karanlık mod uygulaması. Telefonda işletim sistemi karanlık modda olsa bile kullanıcı elle açana kadar açık mod geliyor; ayrıca saate ya da ortam ışığına göre değişen sistem ayarlarına da saygı göstermiyor. localStorage'ın süresi dolabilir ve cihazlar değişebilir, yani ayarı tekrar tekrar yapmak gerekir; bu yüzden kullanıcılar geliştiricinin “basit” dediği uygulamaya katılmayabilir

    • Amaç mümkün olduğunca basit bir web sitesi ise karanlık modun hiç olmaması gerekir. 90'larda da basit ve okunabilir web siteleri vardı ve karanlık mod modası çıkmadan önce sadece açık mod yeterliydi
      Sistem/tarayıcı ayarları, saate göre geçiş, ortam ışığı gibi şeyleri hesaba katınca, basit web sitesi felsefesiyle çelişen ciddi bir karmaşıklık çıkıyor. En iyisi karanlık modu hiç koymamak; HN de hep açık mod ama gece okumakta büyük bir sorun olmuyor
    • Gecikmeli JS yaklaşımının yanlış olduğuna katılıyorum ama media query yaklaşımı da zorlayıcı
      Genelde prefers-color-scheme ayarına saygı duymak ama aynı zamanda bir geçiş düğmesi sunmak istersiniz; kullanıcı daha önce sitede manuel seçim yaptıysa ona öncelik vermek de istersiniz. Bu durumda yine JS ve localStorage gerekir
      Tercih ettiğim yöntem, satır içi stil olarak body {visibility: hidden; opacity: 0;} koymak. Önceki sayfayı göstermeye devam edip DOMContentLoaded anında prefers-color-scheme ve localStorage'ı kontrol ederek body class'ını doğru şekilde ayarladıktan sonra sayfayı çizdirebilirsiniz
    • Okurken “harika bir analiz” diye düşündüm, sonra yazarı görünce nedenini anladım. OP'ye söylemek gerekirse, bu kişi https://gwern.net'in yazarı; bu site birçok teknik blog ve kişisel site tasarımını ciddi biçimde etkiledi ve çok sayıda özgün, harika fikir içeriyor
      Benim sitem CSS ile açık/koyu temaya saygı duyuyor ve manuel geçiş yok. JS'siz saf HTML/CSS siteyi kişisel hedef olarak görüyorum ve açık/koyu ayarının kullanıcının tercihlerine saygı göstermesi gerektiğini düşünüyorum. Bir geçiş düğmesi gerekiyorsa, bu sitenin içinde değil tarayıcı araç çubuğundaki bir ayar olmalı
      /u/gwern bunu okursa, sitem https://daveon.design/ gwern tasarımından ve Tufte.css'ten etkilendi. Eski yayınlar, elyazmaları ve kişisel zevkler de karıştı ama modern ve temiz bir kişisel web sitesinin nasıl görünebileceği ve neler içerebileceği konusunda bana ilk ilham veren temel örnek gwern'di
    • Mac'te Firefox, Chrome, Safari ile Android'de Firefox ve Chrome'da beyaz ekran flaşı görünmüyor. İlk yükleme, yenileme ve karanlık/açık geçişlerinin hepsi normal çalışıyor gibi görünüyor
    • Doğru bir nokta. Ne yazık ki bozuk ama basit görünen düşünme biçimi de, bozuk ve şişkin yaklaşımlar kadar yaygın

  • Dürüst olmak gerekirse, şu anda SvelteKit + Skeleton, işe yarar bir prototip üretme hızı açısından gerçekten etkileyici
    Svelte’i tam olarak bilmeseniz bile dosya tabanlı yönlendirmeyi anladığınızda geri kalanı ihtiyaç duyana kadar neredeyse tamamen HTML; Tailwind varsayılan olarak geliyor ve temalar da çoğunlukla vanilla’ya yakın
    Son birkaç ayda Astro, Lit, Next.js, Go’nun yerleşik şablonları, pug, Eleventy ve daha fazlasını kullandım; şu ana kadar neredeyse her açıdan en çok bu kombinasyonu beğendim

    • SvelteKit harika ama Skeleton’a katılmak zor. Başta üretken ve güvenli hissettiriyor ama çok sayıda tuzağı var ve hoşunuza gitmeyen bir şey çıktığında özelleştirmek zorlaşıyor
      Skeleton’ın kendi sitesi olan https://www.skeleton.dev/docs/get-started bile buna örnek: Page Down’a basınca kaydırmıyor, gezinme çubuğunun üstüne fareyi getirince kaydırmıyor ve yazdırınca yalnızca ekranda görünen kısmı kırpıyor. Bu sorunu gündeme getirdim ama hâlâ büyük bir öncelik değil; buna rağmen birçok site bu bileşen desenini kullanıyor
      Skeleton, koyu tema renklerini ters çevirince iyi bir açık tema elde edildiğini düşünüyor gibi ama gerçekte öyle değil. DaisyUI daha olgun, daha performanslı, daha yaygın kullanılıyor ve erişilebilirliği ciddiye alıyor. JS olmadan, yalnızca CSS animasyonlarıyla bunu başarabilmesi de etkileyici; zor HTML/CSS kısımlarını çözerken kolay Svelte tarafını size bırakıyor. Svelte’e bağımlılığı da düşük, bu yüzden DaisyUI HTML’ini başka framework’lere taşımak kolay
    • Katılıyorum. Bir framework olsa da, JS kapalıyken bile iyi çalışan statik siteleri kolayca üretiyor; Svelte bilmeden kullanılabiliyor ve gerekirse Svelte de kullanılabiliyor
      Tailwind hemen çalışıyor ve Netlify gibi yerlere dağıtmak da çok kolay. Şu an için en iyi statik site oluşturucu ve bence yazıda anlatılan yaklaşımdan çok daha basit
    • Minimalizmi seven biri olarak Astro ve SvelteKit kullandım; SvelteKit, zaten çok küçük bir bileşen kütüphanesi olan Svelte üstüne eklenmiş çok ince bir katman gibi hissettiriyor
      +page.ts ve uygun ayarlarla statik web sitesi de yapılabiliyor, çok sayfalı uygulamaya da tek sayfalı uygulamaya da gidilebiliyor
    • “Şunu girersen sonunda böyle bir sayfa çıkar” tarzı örnekler pek görünmüyor. Kurup adımları izlemeye başlamadan önce, sadece bakıp anlayabileceğim örnekler olsa güzel olurdu
    • Güzel bir öneri. Başka web framework’leriyle deneyimlerini de daha çok duymak isterdim; Flutter’ı da denedin mi merak ediyorum

  • Aman tanrım, HTML ve CSS ile web sitesi yapmak da ne çılgınlık
    Şakayı bir kenara bırakırsak, şablonlar dışında aynı stack’i kullanıyorum. Web geliştiricisi değilseniz CSS framework’lerine neden ihtiyaç duyulduğunu pek anlamıyorum; kendiniz yapmak çok daha kolay. Site oluşturucu olarak Hugo’yu da denedim ama bana hiç zaman kazandırmadı
    Birkaç ay önce CSS becerilerimi geliştirmek için bazı şirket sitelerini yeniden oluşturdum; yalnızca HTML ve CSS ile hepsinin görünüşünü kopyalayabildim. Ama o şirketlerin gerçek web siteleri JS kapalıyken hiç görünmüyordu bile
    Framework üstüne framework, yeni dil, yeni araç ekleyip duruyoruz ve bunların çoğu sadece karmaşıklığı ve gelecek neslin meşguliyetini artırıyor. Gerçekten bunlara ihtiyaç duyan %5’lik web siteleri ise istisna
    Gerçek bir hizmet satan bir site olması da ilginçti; fiyat aralığının nasıl olduğunu da merak ettim

    • Tasarım yapmak ve onu tutarlı biçimde sürdürmek bana çok zor geliyor. Bu yüzden önceden tanımlı CSS olması iyi oluyor; yoksa sonuç dağınık görünüyor
    • Genel olarak katılıyorum ama Astro’yu epey başarılı şekilde kullandım

  • En minimal ve üretken yaklaşımın doğrudan PHP kullanmak olduğunu düşünüyorum. Dil zaten başlangıçta tam bu iş için tasarlanmıştı
    Basit bir site için composer’a da yönlendirici mantığına da gerek yok; header/footer/navigation dosyalarını ayrı tutup her sayfada include etmek yeterli

    • Kütüphane kullanmadan da yaklaşık 100 satır ile bir yönlendirici ve düzen oluşturabilirsiniz. Yönlendirici sadece dosyanın var olup olmadığını kontrol eder, düzen de header.php, pagename.php, footer.php dosyalarını include eder. Basit siteler için böyle yapıyorum; çok kolay ve hızlı
    • PHP olması da şart değil; herhangi bir sunucu tarafı betik dili iş görür. Önemli olan, siteyi yeniden düzenleyebilmek için veriye ve kod bloklarına ad verip kaydedebilmek ve çağırabilmek
      HTML, CSS veya JS gibi harici HTML ekleyebilseydi bunların çoğu zaten gereksiz olurdu. Keşke bunu serbestçe kullanmaya izin verseydi
    • Sadelik istiyorsanız PHP + HTML’i geçmek zor. Tek amaçlı betiklerden daha büyük şeylerde o kadar da sade kalmak istemem ve genelde ayrı bir şablon kütüphanesi eklerim ama bunu yapabiliyor olmak güzel
    • Fikre katılıyorum ama Eleventy tabanlı etkili, özel bir site oluşturucuyu 5–20 saat içinde kurup Netlify’da ücretsiz yayımlayabilirsiniz
      Bir şey değiştirip git commit/push yaptığınızda değişiklikler 30 saniye içinde dünya geneline yansıyor. Gayet harika ve ayrıca sunucu barındırma da gerektirmiyor
    • Basit framework çok, ama birkaç parça daha ekleyince hızla alışıldık şişkinliğe geri dönüyor

  • “Mümkün olduğunca basit, ama daha da basit değil” sözü aklıma geliyor. Muhtemelen Albert Einstein’ın sözü değildir
    Saf HTML + CSS, CSS’yi her HTML etiketi içine ya da sayfanın içine koyma yaklaşımı başlamak için iyidir. Sayfa sayısı ikiye çıkınca CSS’yi ayrı bir dosyaya taşırsınız
    Ama aynı biçimde birden fazla sayfası olan bir site yapmaya başladığınızda, include içeren bir şablon sistemi ve statik site üreticisi gerekir
    Sayfalar veri tabanlıysa, veriyi alıp sayfa üreten programlanabilir bir site üreticisi gerekir; veri “gerçek zamanlı” ise her görünüm için sayfa oluşturmak gerektiğinden en azından PHP alanına, hatta çalışan sunucusu olan modern web framework’leri alanına geçersiniz
    Yakın zamanda hobiyle ilgili bir pro bono site yaptım. Dans tanıtımı ve etkinlik sitesi; sahibi teknik konulara hakim olmayan bir dans öğretmeni. Eleventy(https://www.11ty.dev/) ile Netlify ücretsiz katmanında statik site ürettim ve öğretmenin yaklaşan etkinlikleri tanımlayabilmesi için Google Sheet’ten veri çeken özel build kodu ekledim
    Yapması on küsur saat sürdü ama artık işletme/yönetim maliyeti olmadan gayet iyi çalışıyor. Tam minimum kurulum ile Rails/Phoenix/Django seviyesi arasında güçlü bir sweet spot olduğunu gördüm

    • OP de sonuçta Jinja şablonları ve Tailwind stillendirmesi olmak üzere iki kütüphane kullanıyor. Saf HTML/CSS ile Django/Phoenix/Rails + Angular/React/Vue arasında makul bir orta alan
    • Genelde bir şey iki kez çıkınca refactor ederim ama DRY ilkesini üçe kadar ertelemenin emek/fayda açısından başa baş noktasına ulaşma ihtimalini artırdığı da söylenir
      Yine de sitedeki sayfa sayısı neredeyse kesin olarak 3’ü aşacağından, bu durum sıradan bir kod bloğunun 3 kezden fazla kullanılma ihtimalinden biraz farklı olabilir
    • Bunu açık kaynak olarak yayımlayıp yayımlamadığını ya da benzer bir proje görüp görmediğini merak ediyorum
      Yapı Google Sheets API’sini istemci tarafında çağırıp veriyi dolduruyor mu, öyleyse bir cache katmanı var mı, yoksa her istemci her seferinde yeni bir kopya mı alıyor, bunu da merak ediyorum

  • Framework ve karmaşıklık tartışması artık gerçekten baydı
    Müşteri çok aşamalı yayınlama iş akışı, uluslararasılaştırma ve mevzuata uygun erişilebilirlik içeren özel bir CMS istiyorsa, müşterinin beklediği sürede bunu yapmak için güçlü araçlara ihtiyacınız olur. Enterprise tarafta bu tür müşteriler çoktur; bu yüzden de bu araçlara talep yüksektir. Sadece B2C yaptıysanız şaşırabilirsiniz ama teknoloji endüstrisi buzdağının su altındaki kısmı budur
    Statik bir blog için karmaşık bir Next.js kurulumu ya da Vite toolchain’i gerekmediği doğru. Ama bu araçları ciddi ciddi tartışan insanlar basit bir blog sitesi yapmaktan söz etmiyor. Tutorial’daki küçültülmüş örnek blog olabilir ama gerçek problem farklıdır
    O yüzden framework nefretinin biraz azalmasını isterim. Web sitelerini basit yapmaya dair iyi bir fikriniz varsa tutorial yayımlarsınız; çekiciyse insanlar uygun yerlerde bu yaklaşımı kullanır. Ama belirsiz bir “acı toolchain’ler ve moda framework’ler” düşmanı yaratıp ona karşı çıkma tavrından kaçınılmasını isterim

    • Bu sohbete katılanların çoğu bu araçların yararlı olduğu sorunlarla hiç doğrudan uğraşmadı. Mühendis olabilirler ama frontend’e dokunmadıkları için temelin ötesini bilmiyor olabilirler; ya da CS öğrencisidir, Jekyll ile kişisel blog yapmıştır ve frontend geliştirmeyi bildiğini sanıyordur
      Ya da kullanıcı sayısı iki haneli olan ve UX gereksinimi bulunmayan iç iş uygulamalarını uzun süre yaptığı için her şeyi bildiğini düşünebilir. Bu tür düşük enformasyonlu yargılar tartışmayı bastırıyor
    • Karmaşık bir şey yaparken framework kullanmazsanız sonunda başka bir framework’ü kendiniz yapmış olursunuz
      Üstelik bu kez kodu devralan kişinin alacağı güncellemeler olmaz ve Stack Overflow’da yardım bulmak da daha zor olur
    • Katılıyorum. Framework’lerin getirdiği karmaşıklığı sevmeyen biri olarak bile bunu söylüyorum
      Neden her işte farklı araçlar kullanılamayacağını düşündüklerini anlamıyorum. Framework gerekmeyen zamanlar var ama deneyimime göre, çok basit ve sık değişmeyecek bir şey yapmıyorsanız bu durum nadirdir
      Ortada ekip ve müşteri varken “basit araçlar” sitesinin nasıl yürüyeceğini gözümde canlandırmak zor; bu bir eleştiri değil, gerçekten bilmiyorum demek

  • Bu yaklaşım bile bana artık fazla karmaşık geliyor
    Yazılar Gemtext, yani Gemini için markdown ile yazılıyor; HTML’ye dönüştüren ve dizin sayfaları üreten bir Python script’i yazdım
    CSS sadece 42 satır olduğu için her sayfanın içine koydum; dosya başına eklenen 42 satırlık maliyetin ikinci bir HTTP isteğinden daha büyük olmayacağını da hesapladım
    Python kütüphaneleri ya da şablonlar olmadan, beklediğimden çok daha basitti. En zor kısım e-posta listesine gönderilecek e-postaları üretmekti. Çeşitli framework’leri ve statik site üreticilerini analiz etmeye aylar, düzgün bir CSS bulmaya haftalar harcadım
    Git kayıtlarına göre, WordPress’ten 18 yıllık geçmişi taşımayı da dahil ederek 2 haftalık hack’lemeyle bitirdim. Saf Python olduğu için yeni öğrenmem gereken bir şey yoktu; hata varsa kolayca düzeltebilir ya da değiştirebilirim. Çünkü benim kodum
    Bilgisayar bilimciler, her şeyi yeniden kullanmaya çalışmak yerine geçici özel çözümleri doğrudan kodlayabileceklerini tamamen unuttu. Öğrenme ve uyarlama süresi, doğrudan yapma süresinden daha uzun
    Kod: https://git.sr.ht/~lioploum/ploum.net
    Site: https://ploum.net

    • E-posta mı? Python script’i mi? Git mi? Müthiş bir Rube Goldberg düzeneği
      Benim sitem 2003’te balsa ağacından yontulup Ethernet kablosuna epoksiyle yapıştırılmış bir 6502 işlemciden servis ediliyor. Değiştirmek istediğimde EPROM’u saç kurutma makinesiyle ısıtıp istediğim bitlerin dönmesini sağlıyorum. Şablon yok, kod yok, şişkinlik yok
    • Harika bir blog. Sadece tasarıma bakmak için açtım ama art arda 4 yazı okudum
      Aşağı kaydırırken teknoloji tarihini yeniden gezmek nostaljik bir his uyandırıyor

  • Yanlış anlamadıysam ortalama bir statik site oluşturucudan çok da farklı görünmüyor. Python tabanlı Jinja şablonlarıyla HTML dosyaları üretmekle, Ruby tabanlı Liquid şablonlarıyla HTML/Markdown dosyaları üreten Jekyll arasındaki fark gibi görünüyor

    • Hazır bir framework kullanmak yerine bunu kendisi yapmış. Ve bu sorun değil. Bir şeyler yapmak eğlenceli çünkü
    • Ben de aynı şeyi düşündüm. Amaç sadelik idiyse, mevcut bir statik site oluşturucu kullanmak yerine özel bir oluşturucuyu sıfırdan yapmak garip bir tercih gibi görünüyor
      include için bir PHP sitesi ya da hazır bir statik site oluşturucu çok daha mantıklı olurdu diye düşünüyorum

  • Anlamıyorum. Statik site oluşturucu istemediği için gidip bir statik site oluşturucu yazmış oluyor