Önce HTML

• Tarayıcının varsayılan olarak sunduğu yerel özellikleri önce kullanmak, web uygulaması geliştirirken ek dillere ve araç zincirlerine dayanma düzeyini azaltabilir
• React, props, state ve bileşen gibi kalıplarla UI geliştirmenin güvenilirliğini artırdı, ancak geliştirme yaklaşımının merkezini HTML’den JavaScript’e kaydırdı
• Bu arada W3C, WHATWG, IETF ve TC39 web’in temel dillerine binlerce iyileştirme ekledi; büyük tarayıcılar bunları entegre ettikçe React’e ihtiyaç duyulmasının bazı nedenleri zayıfladı
• HTML First, React’ten memnun geliştiricileri ikna etmeye çalışmaktan çok, HTML merkezli yaklaşıma ilgi duyan kişilere düşüncelerini toparlayıp ekip arkadaşlarıyla tartışabilecekleri bir dil sunmayı amaçlayan bir akım
• Bu, web’in temel dilleri ve tarayıcı özellikleriyle hızlı ve erişilebilir yazılım üretmenin mümkün olup olmadığını yeniden değerlendirmeye yönelik, pratiğe dönük bir bakışa daha yakın

---

HTML First’in benimsediği geliştirme yaklaşımı

• HTML First, web yazılımı geliştirirken HTML, CSS, JavaScript ve tarayıcının yerel özelliklerine öncelik verir
• Temel fikir, web platformunun üzerine eklenen soyutlama katmanlarını azaltmaktır
  • Ek diller ve araç zincirleri de azaltılması gereken katmanlara dahildir
• Amaç, tarayıcının zaten sunduğu özellikleri merkeze alan ve yalnızca gerektiğinde bunların üzerine araç ekleyen bir geliştirme yaklaşımıdır

React sonrasında karmaşıklaşan web geliştirme

• React’ten önce arayüzleri HTML ile yazmak ve HTML’in doğal olarak desteklemediği kısımları jQuery gibi araçlarla tamamlamak yaygın bir yaklaşımdı
  • Bunun tipik örnekleri asenkron istek gönderimi ve DOM güncellemeleridir
• React gibi kütüphaneler, geleneksel web geliştirmenin çeşitli sorunlarını çözdü
  • Üst öğeden alt öğeye veriyi açıkça aktaran props ve state kalıpları, belirli türde hataları azalttı
  • UI, stil ve davranışı bileşenlerde bir araya getirerek başkalarının oluşturduğu parçaların kendi kod tabanına kolayca kurulmasını sağladı
• Ancak bu avantajları elde etmek için, ağırlıklı olarak HTML kullanılan bir yaklaşımdan ağırlıklı olarak JavaScript kullanılan bir yaklaşıma geçmek gerekiyordu
  • JavaScript daha karmaşık bir dil olarak ele alındı
  • React’in beraberinde getirdiği birçok kavram ve araç da ayrıca öğrenilmeliydi
• Sektör, karmaşıklık artsa da bu ödünleşimi kabul etti ve bu tür kütüphaneler web uygulaması geliştirmenin temel yöntemi haline geldi
  • React öncesinde yeni geliştiriciler önce HTML ve CSS öğrenip ardından JavaScript’e geçiyordu
  • React sonrasında ise önce JavaScript ve React’in öğrenildiği, ardından geri kalanına geçilen bir akış yaygınlaştı

Web platformundaki iyileştirmelerin doğurduğu yeniden değerlendirme noktası

• W3C, WHATWG, IETF ve TC39, React yaklaşımı yaygınlaşırken web’in yerel dillerine binlerce iyileştirme ekledi
  • Bu iyileştirmeler Chrome, Safari, Firefox ve Edge’e entegre edildi
  • Bunların önemli bir kısmı, insanların React kullanma nedenlerinden bazılarını doğrudan ele alıyor
• Yazılım geliştirme maliyetleri artarken ve tarayıcı iyileştirmeleri geniş ölçekte dağıtıma girerken, eklenen katmanların bugün hâlâ gerekli olup olmadığını sorgulayanların sayısı arttı
• HTML First fikri hâlâ sektörde azınlıkta
• Bu yaklaşım, hâlihazırda HTML merkezli geliştirmeyle ilgilenen kişilerin düşüncelerini sağlamlaştırmasına ve ekip arkadaşlarıyla iletişim kurmak için dil ve kavramlar edinmesine yardımcı olmaya odaklanıyor
• Ana mesaj şu: web’in yerel dillerini ve özelliklerini başlıca araçlar olarak kullanarak da güzel, hızlı, kullanımı kolay ve erişilebilir web yazılımları üretmek mümkündür; ayrıca bu yaklaşım pratiktir ve makuldür

[GN⁺]

Hacker News yorumları

• Buradaki fikir hoşuma gidiyor ama açıkçası örnekler zayıf kalmış
  “Mümkün olduğunda stil ve davranışı satır içi HTML nitelikleriyle tanımlayın” kısmındaki örnek muhtemelen gerçekten çalışmayacaktır ve daha fazla stil eklemek isterseniz yapı, ClassList.add'e verilen string parametresinin durmadan uzamasına dönüşüyor
  Bana göre button:active { background: green; } çok daha okunabilir; ama yazar bunu “Davranışın Yerelliği (Locality of Behaviour)” yaklaşımı yüzünden daha karmaşık görüyor gibi
  “Bir kütüphaneye ihtiyacınız varsa JavaScript ya da özel sözdizimi merkezli olanlar yerine HTML niteliklerini kullanan bir kütüphane kullanın” sözüne katılıyorum ama önerilen örnekteki “on input put me into #output”, kötü örnek diye verilen kütüphaneden bile daha tuhaf duruyor; üstelik framework olmadan sadece JavaScript ile de rahatça yapılabilir gibi görünüyor
  “HTML'e derlenen gizli katmanlar yerine ‘çıplak’ HTML'i tercih edin” örneği olarak Rails ERB tag helper'larını kullanmamayı söylüyor ama bu helper'lar, doğrudan en minimal template'lerle yazınca dağınıklaşacak pek çok şeyi hallediyor. Örnek, benzersiz DOM ID'leri, Turbo tag'leri ve döngü işleme gibi gerçek hayattaki ayrıntıları atlıyor

  • “Mümkün olduğunda stil ve davranışı satır içi HTML nitelikleriyle tanımlayın” kısmı benim de aklıma takıldı
    Stil tanımı ile davranış ayrı tutulmalı ve anlamlı bir ölçekte ikisinin yalnızca referanslarla birbirine bağlanması mantıklı olan tek yaklaşım
    Teknik olarak tüm SQL veritabanı bağlantılarını ve hardcoded SQL'i tek bir Python uygulamasında upuzun tek bir dosyaya koyabilirsiniz ama bu kötü bir alışkanlıksa, bu ilke de ona benziyor

• Şu kısım kafamı karıştırıyor: “Bir kütüphaneye ihtiyacınız varsa JavaScript ya da özel sözdizimi merkezli olanlar yerine HTML niteliklerini kullanan bir kütüphane kullanın”
  Ama önerilen örnek olarak _hyperscript [0] gösteriliyor. Bu, özel sözdizimi merkezli bir kütüphane ve yaptığı şey yalnızca HTML niteliğinin içine ayrıca öğrenmeniz gereken yeni bir dilin script'ini koymak. Ciddi mi emin değilim
  [0] https://hyperscript.org

  • Bu, sanki hyperscript'i tanıtmak için yazılmış bir ipucu listesi gibi duruyor
    Örnekler de oldukça zayıf. Saf çözüm, yani yalnızca ilk ipucu bile aynı işi gayet iyi yapıyor
  • Katılıyorum. _ niteliğine anlaşılması güç bir DSL ifadesini değer olarak koyan örnek gerçekten çok tuhaf ve kafa karıştırıcı görünüyor
    Bunun yerine açık bir onclick ya da başka bir event niteliğinin içine saf bir JavaScript ifadesi koymak, ne olduğunu hemen anlamayı sağladığı için daha iyi olurdu
  • Yazarın tavsiyesi doğrultusunda Alpine.js daha iyi bir öneri olurmuş. Çünkü HTML niteliklerini ve sezgisel JavaScript kullanıyor
  • hyperscript, HTMX ile ilişkili olduğu için onu öne çıkarmak isteyenler var gibi ama bana göre daha çok eğlenceli bir oyuncak
  • Yazar, önerilen ve önerilmeyen örnekleri yanlışlıkla birbiriyle yer değiştirmiş olabilir

• Niyetini anlıyorum. HTML'in yerleşik özelliklerini kullanmak temiz ve basit
  Ama 10 yıl önce de pratik değildi, bugün de değil. htmx gibi şeylerin React gibi daha ağır çözümlerden özellikle daha iyi olduğunu da düşünmüyorum
  Bu tür yaklaşımları her gördüğümde aynı soruyu soruyorum: açılır menü, çoklu seçim ve tarih seçici nasıl görünüyor? Tarayıcılar tarih seçici sağlıyor mu? Evet. Görünüşü ve davranışı tarayıcılar arasında tutarlı mı? Hayır. Stil vererek eşitlemek mümkün mü? O da hayır
  Çoklu seçim de benzer. Birden çok öğe seçmek için Shift/Ctrl tıklamasını zorunlu kılmak, kullanıcı deneyimi açısından hiç kabul edilebilir değil. Varsayılan öğeler hâlâ böyle çalışıyor ve bunu değiştiremiyorsunuz. Sadece çoklu seçim değil, normal seçim öğeleri de kötü görünüyor ve genel olarak değiştirilmesi zor
  Her yeni framework ile birlikte bu tür üçüncü taraf bileşenlerin çıkmasının bir nedeni var. Yerleşik öğeler tek başına yeterli değil. Tıpkı MDN'in Array sayfasında yerleşik özellikler her yıl artsa da projelerimin %90'ının hâlâ lodash'e bağımlı olması gibi. 10 yıl öncesine göre daha iyi olduğu doğru ama hâlâ yetersiz

  • Sadece tarih seçiciyi düşünerek hızlıca söylemek gerekirse, web siteleri kullanıcılar için tasarlanır
    Kullanıcılar farklı tarayıcılar kullanabilir ama tek bir kullanıcının ziyaret ettiği tüm web sitelerinde aynı tarayıcıyı kullanma olasılığı yüksektir
    Bu yüzden bana göre tarih seçicinin tek bir web sitesinde tüm tarayıcılarda tutarlı olmasındansa, tek bir tarayıcı içinde tüm web sitelerinde tutarlı olması daha önemli. Elbette özel işlevlere ihtiyaç varsa durum değişir
  • “Birden çok öğe seçmek için Shift/Ctrl tıklamasını zorunlu kılmak UX açısından hiç kabul edilebilir değil” derken, çoklu seçimin bu şekilde yapılmaması gerektiği mi kastediliyor? Öyleyse nasıl yapılması gerektiğini merak ediyorum
    Bir listedeki art arda gelen 10 ya da 15 öğeyi seçmek istediğinizde, şu anda Shift+click'ten daha iyi bir arayüz pek bilmiyorum
  • “Görünüşü ve davranışı tarayıcılar arasında tutarlı mı? Hayır” denmesi ilginç; çünkü eskiden native look-and-feel masaüstü uygulamalar için vazgeçilmez sayılırdı
    Tüm web sitelerindeki UI bileşenlerinin kendi aptal stillerini yeniden icat etmesi yerine, asıl site tasarımı hariç tarayıcının native look-and-feel'ini izleseler çok daha iyi olurdu. Tabii bunun için tarayıcıların da bunu iyi göstermek konusunda özenli olması gerekir
  • Tartışmanın geri kalanına bakınca, input öğeleri tarayıcıya göre etkileşim biçimi ciddi şekilde değiştiği için kötü bir şöhrete sahip; diğer HTML öğelerinin çoğunda ise baskın davranış büyük ölçüde tektir

• İddiaların çoğuna katılıyorum ama bu yazı biraz çelişkili geliyor. Çünkü Tailwind önerirken aynı anda “build adımından kaçının” diyor.
  Devasa CSS/JS kaynakları dağıtmak kapsayıcılık ilkesine de aykırı. Hızlı internete ya da yeterince güçlü bilgisayara sahip olmayan çok insan var.

  • Artık Tailwind kullanmıyorum ama deneyimime göre Tailwind devasa CSS/JS kaynakları dağıtmaya yol açmadı.
    Hatta Tailwind’in istemci tarafına ne kadar JavaScript çıkardığını hiç bilmiyorum. Son deneyimim 2.x ileydi, o yüzden bir şey değişti mi emin değilim.
    CSS boyutunda da benim deneyimim tersiydi; Tailwind çıktısı genelde elle yazdığım CSS’ten çok daha küçüktü.
    Elbette saf CSS’ye de karşı değilim ama onu da en az o kadar kolay berbat etmek mümkün.
  • Build adımı gerektirmeyen atomik bir CSS kütüphanesi yaptım. İsteyen olursa burada. Tabii spoiler vereyim, kimse istemiyor: https://casscss.github.io/cass/
  • Deno Fresh, build adımından kaçınmak için Twind kullanıyor: https://twind.dev/
    Ama hatırladığım kadarıyla tam Tailwind’in sunduğu tüm özellikleri sunmuyor. Genel olarak Fresh’in fiilen Preact ve Twind üzerine ciddi biçimde kurulu olması ve önce bu kütüphaneleri benimsemek gerektiğini dürüstçe göstermemesi sinir bozucuydu.
  • Tailwind’in build adımı olarak kullanılabilen bağımsız bir CLI’ı var.
    Bu yazının bağlamında önermek biraz tuhaf, buna bir ölçüde katılıyorum; ama build adımı son derece minimal tutulabiliyor ve ortaya çıkan şeyin hâlâ incelenebilir bir CSS olması da güzel.
    Kişisel sitemde Tailwind kullanıyorum, geri kalan her şey tamamen düz HTML. Stil yazarken CLI’ı watch modunda çalıştırmak beni pek rahatsız etmiyor.
  • No-build seçeneği olarak iki şey iyi: Tailwind v3 CDN’i kendin host etmek ya da https://github.com/gnat/css-scope-inline kullanmak.
    İkisi de şaşırtıcı derecede hızlı ve 10.000’den fazlasını parse ediyor.

• Teoride ya da basit örneklerde eğlenceli ama bunun uygulandığı büyük bir projeyi ve pratikte nasıl bir fark yarattığını görmek isterdim.
  Yazının başındaki hedefler harika ama tavsiyenin kendisi beni biraz hayal kırıklığına uğrattı. Çok temel durumlar dışında nasıl işleyeceğini pek göremiyorum; bu hedeflere nasıl ulaşacağını ise hiç göremiyorum.
  Web platformundan mümkün olan en yüksek verimi alma fikrine katılıyorum ve karmaşıklığı olabildiğince azaltmaya da tamamen katılıyorum. Ama bu ilkelerin bunu başaracağına çok şüpheyle yaklaşıyorum; hatta aynı şeyi yapmanın birden fazla yolunu yaratarak karmaşıklığı artırabilir gibi geliyor.
  İyi niyetle söylemek gerekirse, bu listenin tek başına bu ilkelerin gerçekten sınanıp sınanmadığını mı, yoksa beklendiği gibi çalışacağı varsayımına mı dayandığını anlamak mümkün değil.

  • Bunun neden ancak büyük projeler için iyiyse iyi bir pratik sayılması gerektiğini bilmiyorum.
    Bunu samimiyetle soruyorum. İnsanlar bu iddiayı sık sık öne sürüyor ama ben hiç anlayamadım.
    Benim açımdan web’in %95’i küçük ve orta ölçekli projelerden oluşuyor. Teknolojilerin çoğu buna odaklanmalı. Basit projelerde basit çözümler kullanılır, karmaşıklık ise sonra eklenebilir.
  • İşte HTML öncelikli tarzda bir frontend’i zorlamaya çalıştım ama sıradan frontend geliştiricileri işe alınca bunu temelden anlamadılar; her şeyi div ile yaptılar ve VueJS’in tüm mantığı ve içeriği kontrol etmesini istediler.
    Kaybettiğimiz yarı nesnel şeylerden biri erişilebilirlik oldu. Linkleri, üzerine click event listener eklenmiş div’lerle safça yeniden uyguladığımız için sitenin büyük kısmında klavyeyle gezinilemiyor.
    Bu oldukça endişe verici. Düzenleme geldiğinde, attığımız şeyi geri kazanmak için panikle koşturacağız.
    Yine de meşhur “HTML öncelikli” site örnekleri bulmanın zor olduğu konusunda bir ölçüde katılıyorum. Buna inanıyorum ama gerçekten iyi ortaya konmuş örnekler görmedim. Yine de bunun sebebi tamamen eğitim olabilir. HTML güçlenmeye başladığında frontend eğitimi zaten framework merkezli şekilde iyice kemikleşmişti.
  • jQuery’den daha genç frontend geliştiricileri için, bu tavsiyeye göre bir projeye başlamak; neden build adımı gibi şeyler kullandığımızı ve HMR öncesi geliştirmenin ne kadar zor olduğunu öğrenmek için iyi bir fırsat olurdu.
    Yazarın bunu gerçekten ikiden fazla kişinin çalıştığı ve mevcut tarayıcıların %99’unu destekleyen bir projede yapmış gibi görünmediğini düşünüyorum. Ayrıca kendi kodunu da çalıştırmamış gibi duruyor. Ekranım bozuk değilse onlick, div için bir handler değil.
  • Eski dersleri unuttuk. Backend öncelikli yaklaşım, yalnızca gördüğüne inanan ve uzmanlara güvenmeyen insanlara karşı bir savunma mekanizmasıydı.
    Çalışıyor gibi görünen ama gerçekte çalışmayan bir ürün yaparsanız bunu anlamazlar. Sonra da kendinizi fazla söz verip az teslim etmeye zorlanırken bulursunuz.
    Unit testlerin az bilinen avantajlarından biri, yönetimin göremediği kodun birbirine bağlanmadan önce daha fazla kalite güvencesinden geçmesini sağlamasıdır. İlk ekranın görünmesiyle yayın arasındaki o tuhaf aralığı daraltır.
  • Katılıyorum.
    1999’da ilk web sitemi düz HTML, CSS ve düz JS ile yaptım, Geocities’te host ettim.
    O zamandan beri PHP/WordPress/Yii/Laravel, Ruby/Rails/Sinatra/Jekyll, React/Typescript ve ClojureScript ile siteler ve uygulamalar geliştirdim.
    Şu an React, TSX component’leri, CSS-in-TS, Effects ve Context bana rahat bir ev gibi geliyor. Sanki sonunda web/frontend için tam teşekküllü bir programlama dili ortaya çıktı. Fonksiyonel ve reaktif programlama gibi modern ilkeler üzerine kurulu, frontend için açıkça tasarlanmış bir dil.
    Artık gerçekten yazılım geliştirebiliyorum. Ondan önceki HTML, CSS, düz JS ve PHP daha çok hack işine yakındı. Rails full-stack için iyiydi ama frontend’de parlamıyordu.
    Web stack uygulamalar için de hazır olduğunda framework’ü atlarım. Şimdilik siteler için yeterli olabileceğini kabul ediyorum.

• Bu yıl vazgeçtim. Artık bundler ve transpiler’lar ile yanlarında gelen her türlü ıvır zıvıra sahip React, Vue, Angular canavarlarıyla savaşmayı sürdürmek imkansız hale geldi
  Node ve npm, daha birkaç saniye önce oluşturulmuş projeye bile “7 ciddi güvenlik açığı ve 8 kritik güvenlik açığı” olduğunu fırlatıyor. Binlerce dosya indirmek gerekiyor ve bunların arasında boolean değer sarmalayıcısı gibi şeyler bile olabiliyor
  Python backend sunucusunun frontend’i de birlikte servis ettiği dönem benim için bitmiş gibi görünüyor

  • Öfkelen! Makinelere karşı öfkelen!
    Aslında ne senin ne de başkasının bu kadar şişkin bir JavaScript frontend’ine gerçekten ihtiyacı var. Sadece reddedebilirsin
    Hafif sayfaları backend’den ya da cache’ten servis edip, gerçekten gerekirse havalı işleri CSS ile halledebilirsin
    Hızlı render sürelerine ve küresel erişilebilirliğe kavuşabilirsin
  • Kaçış düğmesine basın. Web’in iyi yanlarının önemli bir kısmı Phoenix Liveview içinde var. Çılgın React/Node oyuncakları olmadan da çekici ve tepkisel web siteleri yapılabilir
    Ama dürüst olmak gerekirse bu yazıdaki örnekler tuhaf. Hataları ve çeşitli kullanım kolaylıklarını otomatik üreten Phoenix form helper’ları yerine neden doğrudan ham etiketler yazmak gerektiğini bilmiyorum. Mantığını anlıyorum
  • Mümkün. Sadece htmx kullanmayı deneyin

• Ana fikir galiba kullanıcının View Source tuşuna basıp ne olup bittiğini anlayabilmesi gerektiği. Web sitesi ise katılıyorum
  Web uygulamasıysa, en azından 50 satırı geçiyorsa, muhtemelen tipli bir dil kullanmak istersiniz. Teknik olarak özel yorumlardaki tip anotasyonları ve TypeScript derleyicisi eklenmiş .js kullanabilirsiniz ama pek keyifli değildi
  Eskiden bu fikre epey güçlü biçimde çekiliyordum ve bugünlerde çoğu sitenin okunamaz tek satırlık HTML yığını olması üzücü. Bağımlılık olmadan tek bir HTML dosyasıyla her şeyi dağıtmakta bir güzellik ve zarafet var. Tek bir ağ isteği yeterli
  Sonunda rahat düzenleme için bir “build system” yaptım ama benim build system’ım cat. Böylece insanın okuyabildiği tek bir dosyada bulunan, kendi kendine yeten taşınabilir bir yazılım oluyor
  Aynı bağlamda, web geliştirmenin en havalı yanı ilk etkileşimli programınızı yalnızca Notepad ve varsayılan tarayıcıyla yapabilmeniz. Sadece HTML dosyasını tarayıcıya sürükleyip bırakmanız yeterli. Büyü gibi
  Ek: Kendi kendine yeten HTML’in beklenmedik bir avantajını keşfettim. Yazılım bit çürümesine karşı bağışık hale geliyor. Eski bir projeyi Web Archive’da açtım ve harici JS dosyaları arşivlenmemişti. Üzücü. Buna karşılık bunda tüm JS HTML’in içinde olduğu için sorunsuz yükleniyor. Zafer
  https://web.archive.org/web/20210508133239id_/https://andai....
  Bu, eski SodaPlay Constructor’a bir saygı duruşu. Editörü yapamadım. Kaynağı görüntülemekte özgürsünüz

  • Bu kısımda şüpheliyim. Artık geliştirici panelinde “perdenin arkasına” bakmanın pek çok yolu var
    DOM görünümü, ağ sekmesi, heap görünümü ve yerleşik JavaScript güzelleştirme özelliği var
    Elbette “kaynağı görüntüle” hâlâ önemli ama HTMX tarafındakilerin söylediği gibi bunun önemi hâlâ mutlak mı, emin değilim
  • “Bağımlılık olmadan tek bir HTML dosyasıyla her şeyi dağıtmakta bir güzellik ve zarafet var. Tek bir ağ isteği yeterli”
    Artık data: URL’leri var, bu da bunu daha kolay hale getirdi. HTTP sunucusuna bile ihtiyaç duymayan file:// URL’lerinin sorunlarından kaçınmak için de kullanışlı
  • Ek: JavaScript’e tip anotasyonları eklemeyi genişletmeye yönelik bir öneri var; böylece TypeScript’in “oldukça büyük bir alt kümesi” doğrudan tarayıcıda çalıştırılabilir hale gelebilir. Güzel!
    https://github.com/tc39/proposal-type-annotations
  • Yazarın tek dosyalı sistemi savunduğunu sanmıyorum. Daha ziyade, söylemek istemiyorum ama

• “Davranışın yerelliği” fazla gevşek tanımlanmış bir kural. Sadece ilgi alanlarının ayrılmasına aykırı olan şeye yeni bir ad vermekten ibaret
  CSS’ye uzaktan ürkütücü etki demek de aşırı dramatik. Ortada iyi ilkeler var ama argüman epey zayıf ve çok daha basit anlatılabilirmiş

  • Çok fazla arayüzü olan bir C# organizasyonundan gelen biri olarak, bunu aşırı soyutlanmış sistemlere karşı doğal bir tepki olarak görüyorum
    “Kırmızı ve zıplayan butonu mavi ve sallanan butonla değiştirmek” için hangi sınıfta yeni bir implementasyon gerektiğini ve hangilerinin yeniden kullanılabileceğini bulmak adına 3 ila 7 arayüz ve sınıfı labirent gibi takip etmek gerekiyorsa, 10 dakikalık değişiklik gibi görünen iş yarım gün boyunca derleyiciye ya da önceki geliştiriciye içten içe söylenmeye dönüşür
    Elbette soyutlama yapılmalı, ama tek bir bileşeni değiştirmek için 6 dosyaya dokunmayı gerektirmeyecek şekilde davranışı tek yerde toplamanın bir yolu da olmalı
    https://htmx.org/essays/locality-of-behaviour/#conflict-with...
  • Tailwind de bir build aşaması ve aynı şekilde bolca “uzaktan ürkütücü etki” içeriyor. Öyle olmasa zaten doğrudan satır içi CSS kullanılırdı
    Tailwind kullandığınızda, üçüncü taraf bir kütüphanenin CSS spesifikasyonunu sizin yerinize soyutlamasına ve bu soyutlanmış yarı-spesifikasyonun build ayarlarına göre korunacağına güvenmiş oluyorsunuz
  • “Davranışın yerelliği” gevşek tanımlanmış bir kural ise, ilgi alanlarının ayrılması değil mi?
    Neyi ayırmak gerekir? Hangi çizgiye göre bölmek gerekir? O çizgi nasıl belirlenir? Hangi ilgi alanlarını başka sınıflara, framework’lere, markup’a vb. çıkarmak ne zaman mantıklıdır? Ne zaman bir arada tutmak daha iyidir?
    Cevap “duruma göre değişir”dir
    Hiçbir şeyi ayırmazsanız spagetti olur; her şeyi her yerde mümkün olduğunca ayırırsanız da spagetti kadar bakımı zor, aşırı soyutlanmış bir koda dönüşür
  • Açıkça belirtilen ana hedef, “web yazılımı kod tabanlarında çalışabilecek insan havuzunu büyük ölçüde genişletmek”. Bu, genel programcılara verilen tavsiyelerden oldukça farklı
    Varsayılanlar iyi çalışıyorsa özelleştirme zorunlu değil. Bu yüzden CSS vb. verimlilik kazanımları sadelik karşısında ikinci plana itiliyor
  • Sorun çok boyutlu
    HTML’yi bir belge/gösterim dili olarak görürseniz stillendirmeyi reddedemezsiniz. CSS sadece stillendirme değil, animasyon da ekler
    Her hâlükârda CSS, aspect-oriented programming olarak da görülebilir
    Burada tarif edilen asıl sorun, diller ve framework’ler arasında çalışan mükemmel araçların eksikliği

• Mümkün olduğunda daha basit framework’lere dayanmak mantıklı. Ama build aşamasını kaldıralım fikri neredeyse tam bir şaka
  Build aşamasını daha verimli hâle getirirsiniz ve gerekirse production’a dahil etmezsiniz
  Ayrıca neden HTML’e özellik eklemeyi önceliklendirmek gerektiğini de anlamıyorum. Burada yapılan şey belge üretip web sitesi olarak host etmek mi? Bunun tercih edileceği başka hangi dünyadan söz ediyoruz? CSS’te gezinmek zor değil; aksine daha iyi CSS pratiklerini teşvik etmeliyiz
  Front-end script’leri stillendirmeyi bulanıklaştırabilir ama gerekmiyorsa bu yaklaşıma bağımlı olmazsınız. JavaScript ile özellik eklemektense stil dokümanına koymak daha kolay olduğundan bu zaten çok temel bir nokta
  Sadece gerekeni kullanın türü bazı tavsiyeler mantıklı ve bariz. Ama geri kalanı ya kafa karıştırıcı ya da açıkça saçma. Tüm HTML sayfasını kopyalayabilmenin neden iyi bir şey sayıldığını da anlamıyorum. Açıkçası umurumda değil ve bazı sayfaların HTML’ini göremeseniz bile HTML öğrenmek için zaten kelimenin tam anlamıyla milyonlarca kaynak var
  Genel olarak insanın kafasını yana eğdiriyor

  • Bunun önemli bir kısmı, web geliştirme sektöründeki karmaşıklık tapınmasına verilen bir tepki

• Bu yazının tamamı bir anti-pattern ve kötü tavsiye. Karmaşık web siteleri yapıp büyüme sancıları yaşamamış biri tarafından yazılmış gibi duruyor
  Başta biz de siteleri böyle yapıyorduk ama yan etkiler, çakışan sınıf adları ve kötü iç gözlemlenebilirlik yüzünden bozulmaya başladı; sonra React gelip kurtardı
  İstenen pattern progressive enhancement olmalı; çıktı temiz ve sıkıştırılmış HTML olmalı ve JavaScript bunu güçlendirmeli. Yani build aşaması gerekir. Bu yazının tavsiyesi bunun tam tersi

  • React ile web sitesi yapmanın da tuzakları var ve React kullanmak çok fazla karmaşıklık getirmek demek
    Back-end’de zaten NodeJS kullanmıyorsanız, gerçekten ihtiyaç duymadıkça ReactJS’ten kaçınmak daha iyi