Web'in Döngüsel Evrimi: Standartlar Ne Kadar Kalıcı?
1990'ların web'i tablo düzenleri, 216 renklik güvenli palet ve üç beş yazı tipiyle sınırlıydı. Araçlar o günden beri tanınmayacak kadar güçlendi, tartışma ise aynı yerde duruyor: bugünkü kolaylığın faturasını yarın kim ödeyecek? Web'in hikâyesi ilerleme kadar tekrardan da oluşuyor, o yüzden en çok tekrarlanan tavsiyeyi, yani “standartlara sadık kal”ı da sorgulamakta fayda var.
Tablo düzenlerinden standart hareketine
İlk siteler table içinde kurulur, metin iç içe geçmiş font etiketleriyle biçimlendirilirdi. Renk seçimi 216 tonla sınırlıydı, çünkü palet 6x6x6'lık bir ızgaraydı ve dışına çıkmak tarayıcının rastgele dithering yapması anlamına geliyordu. 2000'lerin başında CSS ve standartlar hareketi bu düzeni dağıttı. Sunucu tarafında Perl'in yerini PHP, Java ve .NET aldı, arkasından Blogger, Movable Type ve WordPress geldi.
Ardından AJAX, sayfayı yenilemeden içerik güncellemeyi mümkün kıldı. Prototype, YUI ve jQuery tarayıcı farklarını kapattı. Bu kütüphanelerin çoğu bugün kullanımda değil, ama kapattıkları farkın standarda dönüşmüş hali (querySelector, fetch) duruyor. Web Standards Project gibi grupların işi tam olarak buydu: bugünün hack'ini yarının şartnamesine taşımak.
Bugünün kolaylığı, yarının bakım borcu
Artık birkaç komutla neredeyse her fikri prototipleyebiliyoruz. Sorun prototipte değil, prototipin on yıl yaşaması gerektiğinde başlıyor. Üçüncü taraf bir katmana bağlandığınızda yeni bir tarayıcı özelliğini o katman benimseyene kadar bekliyorsunuz, üstelik katmanın kendi sürüm yükseltmeleri de takvimini size soruyor.
Bir kurumsal siteyi zamanın popüler framework'üyle kurmuştuk; iki yıl sonra build zincirini ayakta tutmaya harcadığımız süre, sitenin içeriğini güncellemeye harcadığımızı geçmişti.
Standart olması kalıcı olduğu anlamına gelmiyor
“Standartlarla başla, çünkü standartlar kalır” cümlesi kulağa sağlam geliyor. Aynı tavsiyeyi verenlerin XHTML'i hatırlatarak espri yapması ise cümlenin kendi içindeki çatlağı gösteriyor: XHTML de bir standarttı. Katı ayrıştırma kuralları yüzünden değil, tam da o kurallar yüzünden öldü. Tek bir kapatılmamış etiket sayfanın tamamını hata ekranına çeviriyordu ve kimse içerik yönetim sistemine bunu göze alacak kadar güvenmiyordu.
Buradan çıkan sonuç, çoğu yazının söylediğinin tersi. 90'lardan kalma acemi işi sayfaların bugün hâlâ açılmasının sebebi o sayfaların standartlara uygun olması değil. HTML5, hatalı işaretlemeden ne yapılacağını adım adım tarifleyerek hata kurtarmayı standartlaştırdı. Yani eski web'i ayakta tutan şey disiplin değil, tarayıcıların o disiplinsizliği kurala bağlamış olması.
Neyin öğrenilmeye değer olduğunu nasıl ayırırsınız
Bir aracın kalıcılığını tahmin etmenin pratik bir yolu var: aracı denklemden çıkarın, geriye ne kaldığına bakın. Sunucudan gelen HTML'i zenginleştiren bir katmanı sildiğinizde elinizde okunabilir bir sayfa kalıyorsa, o katmanı benimseyin. Sildiğinizde geriye boş bir div kalıyorsa, sitenin varlığını tek bir JavaScript paketinin sağlığına bağlamışsınız demektir.
Bu, yeni olan her şeye mesafeli durmak anlamına gelmiyor. Interop gibi ortak çabalar sayesinde yeni CSS ve JavaScript özellikleri eskisine göre çok daha hızlı yaygın destek kazanıyor; bir özelliği öğrenip destek tablosuna baktığınızda çoğu zaman zaten kullanılabilir olduğunu görüyorsunuz. Mesele hız değil, hangi katmana yaslandığınız.
Sonra ne olacağını bilmiyoruz, plan da bunun üzerine kurulur
Performans, erişilebilirlik ve okunabilirlik için optimize edin. Geliştiriciyi rahatlatan her aracın kullanıcıya, sizden sonra gelen geliştiriciye ve standartların yayılmasına ne kadara mal olduğunu ayrı ayrı hesaplayın. Kurumsal bir projede bu hesap genelde yapılmaz, çünkü maliyet ilk üç ayda değil üçüncü yılda görünür.
Web'e ustalaştığınızı düşündüğünüz her seferde bir şey değişecek. Değişimi kucaklamak diye bir zorunluluk yok; değişimin hangi katmanda olduğunu görmek yeterli. Tarayıcının altındaki değişim sizi taşır, paket yöneticinizin içindeki değişim sizi meşgul eder.