- GOV.UK hizmetleri, tarayıcı, cihaz veya bağlantı durumu ne olursa olsun kullanıcıların temel görevleri tamamlayabilmesi için önce HTML yaklaşımıyla çalışmalı; tüm kamu hizmetlerinde aşamalı geliştirme gerekli olmalıdır
- HTML, bilinmeyen işaretlemeyi yok sayıp ayrıştırmaya devam eden hata toleranslı bir yapıya sahiptir; bu yüzden eski tarayıcılarda veya kısmi hatalar içeren sayfalarda temel gezinme ve işlevlerin korunma olasılığı yüksektir
- CSS ve JavaScript daha kırılgan katmanlardır: CSS, bilinmeyen seçicilerde tüm kural kümesini yok sayabilir; JavaScript ise desteklenmeyen söz dizimi veya API hataları nedeniyle kalan kodun çalışmasını durdurabilir
- JavaScript, temel işlevlerin yerini almak yerine HTML ve CSS’yi geliştirmek için kullanılmalıdır; otomatik tamamlama da
<select>gibi temel öğelerin üzerine eklenmeli, başarısız olduğunda kullanıcının işine devam edebilmesi sağlanmalıdır - İstemci tarafı JavaScript framework’leri ve SPA’lar performans, erişilebilirlik ve bakım yükü yaratabilir; bu yüzden karmaşık bir UI gerektirmeyen, GOV.UK Design System merkezli hizmetlerde gerekli değildir
Aşamalı geliştirmenin temel ilkeleri
- Kaliteli hizmetler sağlam bir yaklaşımla geliştirilmelidir; aşamalı geliştirme, web siteleri ve uygulamaların HTML’den başlayarak çalışmasını sağlayan bir yaklaşımdır
- Temel işleyiş HTML ile kurulduktan sonra ancak CSS ve JavaScript gibi katmanlar eklenir
- Tüm kamu hizmetleri aşamalı geliştirmeyi izlemelidir; hizmetin bazı bölümleri veya üst hizmet JavaScript gerektirse bile bu ilke korunur
- Aşamalı geliştirmenin sağladığı faydalar şunlardır
- Hizmet daha sağlam ve daha yüksek kaliteli olur
- Tarayıcıdan veya cihazdan bağımsız çalışma olasılığı artar
- En temel işlevler çalışır ve kullanıcının ana ihtiyacını karşılar
- anlamsal işaretleme gibi iyi uygulamaları teşvik ederek erişilebilirliği iyileştirir
- Cihaz veya bağlantı kısıtları olan kullanıcıların hizmeti kullanmasını kolaylaştırır
- COTS çözümleri kullanırken veya hizmet dış tedarikçilere verilirken, satın alma stratejisi gereksinimlerine aşamalı geliştirmeyi dahil etme seçeneği değerlendirilmelidir
HTML ile başlamak
- Kamu hizmetleri yalnızca HTML ile de çalışmalıdır
- Yalnızca HTML ile çalışması gereken hizmet örnekleri şunlardır
- Kullanıcının devlete bilgi verdiği form türü işlem hizmetleri
- smart answers türü hizmetler; örneğin Registering a birth abroad
- GOV.UK’taki foreign travel advice gibi içerik odaklı web siteleri
- HTML katmanı tasarım gereği hata toleranslıdır
- Tarayıcılar anlamadıkları işaretlemeyi yok sayar ve mümkün olduğunca ayrıştırmaya devam eder
- HTML’de hata olsa ya da yalnızca modern tarayıcılarda bulunan özellikler kullanılsa bile eski tarayıcıların hizmeti yükleme olasılığı yüksektir
- Kullanıcılar yalnızca HTML ile de hizmet içinde gezinebilmelidir
- Doğru anlamsal işaretleme kullanılmalı; kaynak sırası ve belge ana hatları mantıklı şekilde kurgulanmalıdır
CSS kullanım biçimi
- CSS, hizmetin GOV.UK gibi görünmesini sağlamak için kullanılabilir
- CSS katmanı görece hata toleranslıdır
- Tarayıcılar anlamadıkları tekil bildirimleri yok sayar
- Yalnızca modern tarayıcılarda bulunan özellikler kullanılırsa sadece ilgili bildirim yok sayılabilir
- Ancak tarayıcı anlamadığı bir seçiciyle karşılaştığında tüm kural kümesini yok sayabilir
- CSS çeşitli nedenlerle yüklenmeyebilir
- JavaScript yüklenmese bile sitenin doğru görünmesini sağlamak için CSS-in-JS gibi tekniklerden kaçınılmalıdır
JavaScript kullanım biçimi
- JavaScript, hizmete etkileşimli öğeler eklemek için kullanılabilir
- JavaScript katmanı hata toleranslı değildir
- Kullanıcının tarayıcısının desteklemediği söz dizimi kullanılırsa veya bir API çağrılırsa hata oluşur
- Hata oluştuğunda kalan JavaScript çalışmaz
- Hizmet bu olasılık dikkate alınmadan tasarlanırsa kullanıcılar hizmeti kullanamayabilir
- JavaScript’in farklı tarayıcılarda düzgün çalışma olasılığını artırmanın yolları şunlardır
- Tarayıcı API’leri için özellik algılama kullanmak
- Modern tarayıcı özellikleri için polyfill eklemek
- JavaScript’i hedef tarayıcıların anlayabileceği ortak söz dizimine transpile etmek
- Otomasyon testleri veya linter kullanmak
- Eski veya düşük performanslı cihazları da içeren düzenli manuel testler yapmak
- Transpile işlemi ve polyfill’ler JavaScript boyutunu ciddi biçimde artırabilir
- İlgili ödünleşimler dikkate alınmalıdır
- Tarayıcı kullanım eğilimleri değiştiği için kararlar düzenli olarak yeniden gözden geçirilmelidir
- Mümkün olduğunda JavaScript, aynı temel işlevi sunan HTML ve CSS’yi geliştirmelidir
- Otomatik tamamlama,
<select>öğesi ya da benzer temel öğeleri geliştirecek şekilde tasarlanabilir - JavaScript başarısız olsa bile kullanıcı gerekli işi yapmaya devam edebilir
- Otomatik tamamlama,
JavaScript alternatifleri ve tamamlayıcı kanallar
- Bir hizmetin yalnızca JavaScript ile yapılabileceği düşünülüyorsa, önce HTML ve CSS ile hazırlanmış daha basit bir çözümün kullanıcı ihtiyacını karşılayıp karşılamayacağı değerlendirilmelidir
- Etkileşimli grafiklerin JavaScript ile sunulması planlanıyorsa şu alternatifler düşünülebilir
- Veriyi tablo olarak göstermek
- Verinin başka uygulamalarda analiz edilebilmesi için dışa aktarmaya izin vermek
- Grafikleri önceden görsel olarak render etmek
- Hizmetin temel işlevi JavaScript olmadan sunulamıyorsa, kullanıcıların hizmete başka kanallardan erişebilmesi sağlanmalıdır
- Telefon
- Ofis ziyareti
İstemci tarafı JavaScript framework’leri
- Hizmet büyük ölçüde GOV.UK Design System bileşenlerinden oluşuyor ve karmaşık bir UI içermiyorsa istemci tarafı JavaScript framework’ü gerekli değildir
- GOV.UK Design System bileşenleri, framework kullanmadan hizmete JavaScript eklemenin yolunu içerir
- İstemci tarafı JavaScript framework’leri, karmaşık UI’ler oluştururken faydalı olabilir; ancak aynı zamanda çeşitli sorunlar da getirebilir
- Framework kullanımının doğurabileceği sorunlar şunlardır
- Toplam kod tabanı boyutunu artırıp işlem yükünü istemciye taşıyarak yavaş ağlar veya düşük performanslı cihazlar kullanan kişiler için performans sorunları yaratabilir
- Geliştiricinin kontrol etmediği üçüncü taraf koda bağımlılık oluşturur; framework değişikliklerine uyum için hizmette büyük değişiklikler gerekebilir
- Zamanla framework’ün popülerliği azalırsa, bakımı yapacak gerekli yetkinliğe sahip kişileri bulmak zorlaşabilir
- Bir JavaScript framework’ü kullanılacaksa şu koşullar sağlanmalıdır
- JavaScript kullanımının kullanıcıya ne fayda sağladığı kanıtla gerekçelendirilebilmelidir
- Olumsuz etkiler bilinmeli ve azaltılabilmelidir
- Faydaların potansiyel sorunlardan daha ağır basıp basmadığı değerlendirilmelidir
- Framework yalnızca HTML ve CSS ile oluşturulamayan UI bölümlerinde kullanılmalıdır
- UI’nin her bölümü ayrı bir bileşen olarak tasarlanmalıdır
- Bileşenlerin ayrılması, JavaScript yüklemesi başarısız olduğunda yalnızca ilgili bileşenin etkilenmesini ve sayfanın geri kalanının normal yüklenmesini sağlar
- JavaScript yalnızca HTML ve CSS’yi geliştirmek için kullanılmalı; başarısız olsa bile kullanıcı hizmetten yararlanabilmelidir
CSS ve JavaScript’in başarısız olabilme nedenleri
- CSS ve JavaScript çeşitli nedenlerle yüklenmeyebilir veya çalıştırılamayabilir
- Geçici ağ hataları
- Reklam engelleyici gibi üçüncü taraf tarayıcı eklentileri
- İçerik dağıtım ağı kullanıldığında üçüncü taraf tedarikçi kesintileri
- DNS çözümleme hataları
- Tarayıcı güncellemeleriyle oluşan hatalar
- Aynı sayfada kasıtlı olarak çalışan üçüncü taraf JavaScript’teki hatalar
- Bankalar veya kamu kurumları gibi büyük kuruluşlarda kullanılan kurumsal güvenlik duvarlarının içeriği engellemesi, kaldırması veya değiştirmesi
- Mobil ağ operatörlerinin yükleme süresini ve bant genişliği kullanımını azaltmak için içeriği değiştirmesi
- Kişisel güvenlik duvarı veya antivirüs yazılımlarının içeriği değiştirmesi ya da engellemesi
- Güvenli olmayan bağlantılarda internet servis sağlayıcısının sayfaya kendi kodunu eklemesi ve bu kodun hizmet koduyla çakışması
- Bazı kullanıcılar tarayıcı özelliklerini bilinçli olarak devre dışı bırakabilir
- Hizmet, kullanıcının bu tercihine saygı duymalı ve bu kullanıcıların da kullanmaya devam edebilmesini sağlamalıdır
Neden tek sayfa uygulamalarından (SPA) kaçınılmalı
- Hizmet tek sayfa uygulaması (SPA) olarak oluşturulmamalıdır
- SPA, hizmet içindeki sayfa yüklemelerinin tarayıcı yerine JavaScript tarafından yönetildiği bir yaklaşımdır
- SPA’lar çok az fayda sağlar ve erişilebilirliği olumsuz etkileyebilir
- Yardımcı teknolojileri kullanan kişiler, yeni bir sayfaya geçildiğinde aynı bağlam değişikliğinin yaşandığını fark etmeyebilir
- Sayfa geçişlerinde odak yönetimi yapılamayabilir
- Kullanıcılar tarayıcının geri ve ileri düğmeleriyle gezinemeyebilir
- Ağ bağlantısının kesilmesi gibi hatalardan kullanıcılar toparlanamayabilir
Test ölçütleri
- Hizmetin bazı bileşenleri JavaScript’e veya JavaScript framework’lerine büyük ölçüde bağımlıysa şu noktalar doğrulanmalıdır
- Farklı tarayıcı ve cihazlarda çalıştığı
- yardımcı teknolojilerle birlikte çalıştığı
- iyi performansı garanti eden testlerden geçtiği
- Mümkünse, ilgili bileşenlerin hizmet içinde düzgün çalıştığı erişilebilirlik testleriyle doğrulanmalıdır
1 yorum
Hacker News yorumları
“JavaScript framework’ü kullanıyorsanız, JavaScript kullanımının kullanıcıya ne fayda sağladığını gerekçeyle meşrulaştırabilmelisiniz” demiş; herkes biraz sakin olsun
İyi bir ölçüt şu: Uygulama bir masaüstü uygulaması gibi offline-first çalışabiliyorsa, onu tek sayfa uygulaması olarak yapmak sorun değildir
Photopea, Google Docs/Sheets, tldraw buna örnek; bu durumlarda çok sayfalı bir tarayıcı uygulamasından daha seri ve daha iyi olabilir
Böyle yapınca en büyük dezavantajlar olan sayfalar arası geçiş ve internet bağlantısı gereksinimi ortadan kalkar
Ama uygulama internet bağlantısı ve birden fazla sayfa gerektiriyorsa, gezinmeyi arızalara dayanıklı biçimde tarayıcının yönetmesine bırakmak daha iyidir
Offline ya da birden çok işletim sisteminde masaüstü GUI benzeri bir şeye ihtiyacınız varsa tek sayfa uygulaması avantajlıdır; sadece bir web sitesi yapmak istiyorsanız tek sayfa uygulaması en iyi seçenek olmayabilir
Tek sayfa uygulamasının kendisi ile onu yapmak için gereken karmaşıklık ayrı şeyler
90’larda çocukken web’e başladım. CSS’in ya da JS’in ne olduğunu bile bilmiyordum; JS’i de bir şeyleri yanıp söndürten sihirli script’leri kopyalayıp yapıştırmaktan ibaret sanıyordum
Sonraları yerel işletmeler için dinamik siteleri PHP ile yaptım; o dönemde JS ve CSS’i de biraz öğrendim
Sonra IE6 gibi berbat tarayıcılarda çalışsın diye çok fazla zaman harcamaktan bıkıp web geliştirmeyi bıraktım
Neredeyse 6 yıl uzak kaldıktan sonra, yaptığım işte bir web sunucusunun faydalı olacağını fark ettiğim için 2015 civarında geri döndüm
Ama dünyanın HTML ve CSS hakkında eskiden bildiğim birçok şeyi unutmuş olduğunu görünce şok oldum
Eskiden siteler için birden fazla stylesheet oluşturur, önce JS olmadan çalışır hale getirir, sonra JS’i üzerine eklenen bir iyileştirme olarak katardık; o yaklaşım unutulmuştu
Web geliştiricilerin form doğrulamayı tamamen JS’te yapıp sunucuda hiçbir şey yapmadığını da gördüm; şaşırtıcı biçimde bu hâlâ yaygın
Sunucunun doğrulayıp JS’in sadece sonucu gösterdiği yaygın kalıbı pek görmüyorum. Herkes ya iki kez uyguluyor ya da sunucu doğrulamasını hiç yapmıyor gibi
Bunları görünce insanların web’de yaptığı işler artık bana etkileyici gelmedi. Bildiğim web değil, JS ile yapılmış “uygulamalar”dı sadece; web öncelikli yaklaşımı savunmak kaybedilen bir savaştı
Çocukken HTML 3.2/XHTML ve CSS ile başladım; birkaç yıl sonra Django + jQuery işi yaptım, sonra altyapı tarafına ilgi duydum
Yaklaşık bir yıl önce bir web geliştirme ekibiyle çalışırken yaptıkları işlere baktım; artık hiçbir şey anlamıyordum
Karmaşıklık bunaltıcıydı ve zamanlarının çoğunu build süresini azaltmaya, bağımlılık sorunlarını çözmeye, tuhaf TypeScript problemleriyle uğraşmaya, birden çok component’in hata yönetimi gibi karmaşıklık yönetimi işlerine harcıyor gibiydiler
Django+jQuery döneminde hâlâ kullanıcının görüp kullanabildiği şeye odak vardı
Elbette istemciye asla güvenilemez; bu yüzden daha sonra sunucuda tekrar doğrulamak gerekir
Sunucu yükünü azaltmak faydalıdır
İyi bir tavsiye ama “yardımcı teknoloji kullanıcıları yeni bir sayfaya geçtiğinde aynı bağlam değişimini anlayamaz”, “sayfa geçişinde odağı yönetemez”, “tarayıcının geri/ileri düğmeleriyle gezinemaz”, “ağ bağlantısı kesilirse hatadan toparlanamaz” gibi ifadeler teknik olarak tam doğru değil, değil mi?
Birçok, belki de çoğu tek sayfa uygulaması bunları önemsemiyor sadece; tek sayfa uygulaması içinde de bunlar uygulanabilir
Tek sayfa uygulaması alanına girdiğiniz anda aynı seviyeye dönmek için birçok tekerleği yeniden icat eder ya da yerel özellikleri JS muadilleriyle değiştirirsiniz
Çok sayfalı formları düşünün: Kaç tek sayfa uygulaması her şeyi bellekte tutup en sonunda tek bir istek gönderiyor?
JS olmasaydı backend her adımın durumunu kaydederdi; böylece daha sonra forma dönünce ya da sayfayı yenileyince kaybolmazdı
Varsayılan ayarlarla gayet iyi çalışan temel bir HTML web sitesi varken neden böyle çöpü dayatalım?
Kullanıcı gezinme geçmişine sonradan müdahale edilmesine izin vermiyorsa geriye tek seçenek kalır
Geçmişin yazıldığı anda tarayıcı geçmişini düzgün oluşturmak
Keşke tüm internet bu tavsiyeye uysa
Eski olan yeniden yeni oluyor
Bugün moda olandan önce mümkün olan en basit çözümü tercih etmemiz gerekmez mi?
Sektörün geri kalanı JS sarhoşuydu diye herkes öyle değildi
Bu listede neden Linux yok?
https://www.gov.uk/service-manual/technology/designing-for-d...
Daha ciddi ama aynı doğrultudaki cevap ise şu: Dağıtım sayısı onlarca ve bunların içindeki Mozilla türevi fork’ları da katarsanız tarayıcı sayısı da neredeyse onu buluyor
Resmî bir dağıtım/tarayıcı seçilebilir elbette, ama böyle seçilen tek bir seçeneğin kullanıcı tabanı son derece küçük olur
Ubuntu bile, dolaylı metriklerle çıkarılabilen rakamlara göre masaüstü işletim sistemi payında yaklaşık %1 civarında görünüyor
Ciddi bir soru: Yorumlara bakınca insanlar bu yaklaşımı seviyor gibi görünüyor
O halde genel eğilim neden React gibi framework’leri ve JavaScript’i, bazen gereksiz yere, kullanma yönünde ilerliyor?
Hafif, temiz bir yerleşime sahip, erişilebilirliği iyi ve çoğunlukla JavaScript’i minimumda kullanıyor ya da hiç olmasa da çalışıyor
Buna karşılık çoğu tek sayfa uygulamadan hoşlanmıyorum. Beklenen birçok tarayıcı işlevini bozuyorlar, JavaScript olmadan işe yaramaz hâle geliyorlar ve çoğu zaman çeşitli üçüncü taraf sitelerden bir sürü ağır bağımlılık yüklüyorlar
Ama kullanıcıların sevdiği şeyler ile geliştiricilerin sevdiği ve hızlıca geliştirebildiği şeyler çoğu zaman oldukça farklıdır
Bir şey sektör standardı olarak kabul gördüğünde akışı takip eden karar güvenli olur
Üstelik HTML/CSS/saf JS için kimse developer relations faaliyeti yürütmüyor
Bir şeyin nasıl yapılacağını aradığınızda çıkanların neredeyse tamamı framework’lerle ilgili oluyor
Kendi bilgisayarınızda çalışan bir program yaparsanız bu maliyeti doğrudan siz ödersiniz; en azından bulut maliyetinin neden %5 arttığını finans ekibine açıklamanız gerekir
Ama frontend geliştiricileri gibi yazılımı başkalarının cihazlarında çalıştırırsanız maliyet neredeyse yoktur
Olumsuz sinyaller kullanıcı bildirimleri, destek talepleri, belki Twitter gönderileri gibi kanallardan gelmek zorunda kalır; bu süreçte de çok fazla seçim yanlılığı olduğu için büyük resmi görememe olasılığı yüksektir
Sonuçta mesele tamamen teşvikler meselesi
Web, geleneksel kalın istemcilerin yerini alıyor; o istemciler de oldukça kararlı bir ağ bağlantısı ve platform özellikleri varsayıyordu
Kamu sistemleri, yaygın olmasa bile en düşük ortak paydada çalışmak zorunda
Teknoloji startup’ları ise başlangıçta tek bir müşterileri olsa bile var olabilir ve ölçeklendikçe kendi gereksinimlerinin genel olarak yaygınlaşacağına inanabilir
Aslında frontend geliştiricisi oldukları için bu yaklaşımı sevmediklerini düşünüyorum. Aksi hâlde geliştirilecek pek frontend kalmazdı
Benim izlemeye çalıştığım yöntem de bu. Sunucudan önceden alınmış verilerle birlikte HTML sunmak, istemcide yapılabilecekleri istemcide işleyerek sunucuya gidiş gelişleri azaltmak, minimum CSS ile duyarlı yerleşimler oluşturmak ve saf JS kullanmak
Gerekirse ayrı web sayfalarına bölmek yeterli
Ama yalnızca HTML, CSS ve saf JS kullandığım için meslektaşlarıma herhâlde garip ve eski moda geliyor
Özellikle eksik olan bir şey yok
Yazıda da körü körüne yalnızca sunucu tarafı kullanmanın iyi yazılım mühendisliği olmadığı söyleniyor
“Sorun yaratabilir” dendiğine, “sorun yaratır” denmediğine dikkat etmek gerekiyor
İstemci tarafı JavaScript framework’leri, karmaşık kullanıcı arayüzleri olan servisler geliştirirken yardımcı olabilir; ancak kod tabanının toplam boyutunu artırabilir ve işlemeyi istemciye kaydırarak yavaş ağlara ya da düşük performanslı cihazlara sahip kullanıcılar için performans sorunları yaratabilir
Geliştiricinin kontrol etmediği üçüncü taraf koda bağımlı hâle getirebilir ve framework değişimlerine uyum sağlamak için serviste büyük değişiklikler yapılmasını gerektirebilir
Framework’ün popülerliği düşerse bakımını yapacak kişileri bulmak da zorlaşabilir
JavaScript framework’ü kullanıyorsanız, bunun kullanıcıya ne fayda sağladığını kanıta dayalı olarak gerekçelendirmeli, olumsuz etkileri anlayıp azaltmalı ve faydanın olası sorunlardan büyük olup olmadığını değerlendirmelisiniz
Ayrıca yalnızca HTML ve CSS ile yapılamayan kullanıcı arayüzü bölümlerinde kullanmalı ve her bölümü ayrı bir bileşen olarak tasarlamalısınız
Bileşenleri ayırırsanız JavaScript yüklemesi başarısız olsa bile yalnızca ilgili bileşen başarısız olur, sayfanın geri kalanı ise normal şekilde yüklenir