- Layanan GOV.UK harus bekerja dengan pendekatan HTML lebih dulu agar pengguna tetap bisa menyelesaikan tugas inti meski browser, perangkat, atau kondisi koneksi berbeda; progressive enhancement diwajibkan untuk semua layanan pemerintah
- HTML memiliki toleransi kesalahan: ia mengabaikan markup yang tidak dikenal dan terus melakukan parsing, sehingga navigasi dan fungsi dasar kemungkinan besar tetap berjalan bahkan di browser lama atau pada halaman dengan sebagian kesalahan
- CSS dan JavaScript adalah lapisan yang lebih rapuh: pada CSS, satu set aturan dapat diabaikan jika selector tidak dikenal, sedangkan pada JavaScript, sintaks atau API yang tidak didukung dapat menghentikan eksekusi sisa kode
- JavaScript sebaiknya digunakan untuk meningkatkan HTML dan CSS, bukan menggantikan fungsi inti; autocomplete pun harus ditumpangkan di atas elemen dasar seperti
<select>agar pengguna tetap bisa melanjutkan pekerjaan jika terjadi kegagalan - Framework JavaScript sisi klien dan SPA dapat menimbulkan beban performa, aksesibilitas, dan pemeliharaan, sehingga tidak diperlukan untuk layanan yang berpusat pada GOV.UK Design System dan bukan UI kompleks
Prinsip dasar progressive enhancement
- Layanan berkualitas harus dibuat dengan cara yang tangguh, dan progressive enhancement adalah pendekatan yang membuat situs web dan aplikasi berfungsi mulai dari HTML
- Lapisan seperti CSS dan JavaScript baru ditambahkan setelah perilaku dasar dibuat dengan HTML
- Semua layanan pemerintah harus mengikuti progressive enhancement, dan prinsip ini tetap berlaku sekalipun sebagian layanan atau layanan tingkat atas membutuhkan JavaScript
- Manfaat progressive enhancement adalah sebagai berikut
- Layanan menjadi lebih tangguh dan berkualitas lebih tinggi
- Lebih mungkin berfungsi terlepas dari browser atau perangkat yang digunakan
- Fungsi paling dasar bekerja dan memenuhi kebutuhan inti pengguna
- Mendorong praktik terbaik seperti markup semantik, sehingga aksesibilitas meningkat
- Pengguna dengan keterbatasan perangkat atau koneksi lebih mudah menggunakan layanan
- Saat menggunakan solusi COTS atau menyerahkan layanan kepada pemasok eksternal, pertimbangkan untuk memasukkan progressive enhancement ke dalam persyaratan strategi pembelian
Mulai dari HTML
- Layanan pemerintah harus berfungsi hanya dengan HTML
- Contoh layanan yang harus berfungsi hanya dengan HTML adalah sebagai berikut
- Layanan transaksional seperti formulir yang digunakan pengguna untuk memberikan informasi kepada pemerintah
- Layanan berbentuk smart answers, misalnya Registering a birth abroad
- Situs web berbasis konten seperti foreign travel advice di GOV.UK
- Lapisan HTML secara desain memiliki toleransi kesalahan
- Browser mengabaikan markup yang tidak dipahami dan sebisa mungkin terus melakukan parsing
- Meski ada bug pada HTML atau memakai fitur yang hanya ada di browser modern, browser lama kemungkinan besar tetap dapat memuat layanan
- Pengguna harus bisa menavigasi layanan hanya dengan HTML
- Gunakan markup semantik yang benar, dan susun urutan sumber serta outline dokumen secara logis
Cara menggunakan CSS
- CSS dapat digunakan untuk memberi gaya agar layanan terlihat seperti GOV.UK
- Lapisan CSS relatif memiliki toleransi kesalahan
- Browser mengabaikan deklarasi individual yang tidak dipahaminya
- Jika menggunakan properti yang hanya ada di browser modern, hanya deklarasi tersebut yang mungkin diabaikan
- Namun, jika browser menemukan selector yang tidak dipahaminya, browser dapat mengabaikan seluruh set aturan
- CSS dapat gagal dimuat karena berbagai alasan
- Agar situs tetap terlihat benar meskipun JavaScript tidak dimuat, hindari teknik seperti CSS-in-JS
Cara menggunakan JavaScript
- JavaScript dapat digunakan untuk menambahkan elemen interaktif ke layanan
- Lapisan JavaScript tidak toleran terhadap kesalahan
- Jika browser pengguna menjalankan sintaks yang tidak didukung atau memanggil API yang tidak didukung, akan terjadi error
- Jika terjadi error, sisa JavaScript tidak akan dijalankan
- Jika layanan dirancang tanpa mempertimbangkan kemungkinan ini, pengguna bisa jadi tidak dapat menggunakan layanan
- Cara meningkatkan kemungkinan JavaScript berfungsi dengan benar di berbagai browser adalah sebagai berikut
- Gunakan deteksi fitur untuk API browser
- Sertakan polyfill untuk fitur browser modern
- Transpile JavaScript ke sintaks umum yang dapat dipahami browser target
- Gunakan pengujian otomatis atau linter
- Lakukan pengujian manual berkala, termasuk pada perangkat lama atau berperforma rendah
- Transpile dan polyfill dapat memperbesar ukuran JavaScript secara signifikan
- Pertimbangkan trade-off terkait
- Karena pola penggunaan browser berubah, keputusan perlu ditinjau ulang secara berkala
- Jika memungkinkan, JavaScript harus meningkatkan HTML dan CSS yang menyediakan fungsi inti yang sama
- Autocomplete dapat dibuat dengan meningkatkan elemen
<select>atau elemen dasar serupa - Meski JavaScript gagal, pengguna tetap dapat melakukan tugas yang diperlukan
- Autocomplete dapat dibuat dengan meningkatkan elemen
Alternatif JavaScript dan kanal pelengkap
- Jika layanan dinilai hanya bisa dibuat dengan JavaScript, pertama-tama periksa apakah solusi yang lebih sederhana dengan HTML dan CSS dapat memenuhi kebutuhan pengguna
- Jika ingin menyediakan grafik interaktif dengan JavaScript, pertimbangkan alternatif berikut
- Menampilkan data dalam tabel
- Mengizinkan data diekspor agar dapat dianalisis di aplikasi lain
- Melakukan prarender grafik sebagai gambar
- Jika fungsi inti layanan tidak dapat disediakan tanpa JavaScript, sediakan cara bagi pengguna untuk menggunakan layanan melalui kanal lain
- Telepon
- Kunjungan ke kantor
Framework JavaScript sisi klien
- Jika layanan sebagian besar terdiri dari komponen GOV.UK Design System dan tidak memiliki UI kompleks, framework JavaScript sisi klien tidak diperlukan
- Komponen GOV.UK Design System menyertakan cara untuk membawa JavaScript ke layanan tanpa framework
- Framework JavaScript sisi klien dapat membantu saat membuat UI kompleks, tetapi sekaligus dapat memperkenalkan berbagai masalah
- Masalah yang dapat muncul dari penggunaan framework adalah sebagai berikut
- Menambah ukuran keseluruhan codebase dan memindahkan pemrosesan ke klien, sehingga dapat menimbulkan masalah performa bagi pengguna dengan jaringan lambat atau perangkat berperforma rendah
- Menjadikan layanan bergantung pada kode pihak ketiga yang tidak dikendalikan pengembang, sehingga perubahan besar pada layanan mungkin diperlukan untuk mengikuti perubahan framework
- Jika popularitas framework menurun seiring waktu, orang dengan keterampilan yang diperlukan untuk pemeliharaan bisa menjadi sulit ditemukan
- Jika menggunakan framework JavaScript, syarat berikut harus dipenuhi
- Harus dapat membenarkan dengan bukti manfaat penggunaan JavaScript bagi pengguna
- Harus memahami dan dapat memitigasi dampak negatifnya
- Harus mempertimbangkan apakah manfaatnya lebih besar daripada potensi masalah
- Framework hanya boleh digunakan pada bagian UI yang tidak dapat dibuat hanya dengan HTML dan CSS
- Setiap bagian UI harus dirancang sebagai komponen terpisah
- Dengan memisahkan komponen, jika pemuatan JavaScript gagal, hanya komponen tunggal tersebut yang gagal, sementara bagian halaman lainnya tetap dimuat secara normal
- JavaScript harus digunakan hanya untuk meningkatkan HTML dan CSS, dan pengguna harus tetap dapat menggunakan layanan meskipun JavaScript gagal
Alasan CSS dan JavaScript bisa gagal
- CSS dan JavaScript dapat gagal dimuat atau dijalankan karena berbagai alasan
- Kesalahan jaringan sementara
- Ekstensi browser pihak ketiga seperti pemblokir iklan
- Downtime pemasok pihak ketiga saat menggunakan jaringan pengiriman konten
- Kegagalan lookup DNS
- Bug yang muncul akibat pembaruan browser
- Bug pada JavaScript pihak ketiga yang sengaja dijalankan di halaman yang sama
- Firewall perusahaan yang digunakan organisasi besar seperti bank atau departemen pemerintah yang memblokir, menghapus, atau mengubah konten
- Operator jaringan seluler yang mengubah konten untuk mengurangi waktu muat dan penggunaan bandwidth
- Firewall pribadi atau perangkat lunak antivirus yang mengubah atau memblokir konten
- Pada koneksi yang tidak aman, penyedia internet menyisipkan kode mereka sendiri ke halaman, dan kode tersebut berbenturan dengan kode layanan
- Sebagian pengguna dapat sengaja menonaktifkan fitur browser
- Layanan harus menghormati pilihan pengguna dan tetap dapat digunakan oleh pengguna tersebut
Alasan menghindari single-page application (SPA)
- Layanan tidak boleh dibuat sebagai single-page application (SPA)
- SPA adalah pendekatan ketika pemuatan halaman di dalam layanan ditangani oleh JavaScript, bukan oleh browser
- SPA hampir tidak memberikan manfaat dan dapat merusak aksesibilitas
- Pengguna teknologi bantu mungkin tidak mengetahui bahwa perubahan konteks yang sama terjadi saat berpindah ke halaman baru
- Fokus mungkin tidak ditangani saat berpindah halaman
- Pengguna mungkin tidak dapat menavigasi dengan tombol mundur dan maju browser
- Pengguna mungkin tidak dapat pulih dari error seperti koneksi jaringan terputus
Kriteria pengujian
- Jika sebagian komponen layanan sangat bergantung pada JavaScript atau framework JavaScript, pastikan hal berikut
- Berfungsi di berbagai browser dan perangkat
- Berfungsi bersama teknologi bantu
- Telah melalui pengujian untuk memastikan performa yang baik
- Jika memungkinkan, pastikan komponen tersebut berfungsi dengan baik di dalam layanan melalui pengujian aksesibilitas
1 komentar
Komentar Hacker News
Katanya, “kalau memakai framework JavaScript, harus bisa membenarkan dengan alasan yang jelas manfaat penggunaan JavaScript bagi pengguna” — semuanya santai dulu
Patokan yang bagus adalah, kalau aplikasi bisa berjalan offline-first seperti aplikasi desktop, maka tidak masalah dibuat sebagai single-page application
Contohnya Photopea, Google Docs/Sheets, tldraw, dan dalam kasus seperti ini bisa terasa lebih cepat dan lebih baik daripada aplikasi browser multi-halaman
Dengan begitu, dua kelemahan terbesarnya—perpindahan antarhalaman dan kebutuhan koneksi internet—hilang
Namun kalau aplikasi membutuhkan koneksi internet dan banyak halaman, lebih baik biarkan browser menangani navigasi dengan cara yang tangguh terhadap gangguan
Kalau butuh offline atau sesuatu yang mirip GUI desktop di berbagai sistem operasi, single-page application memang unggul, tetapi kalau cuma ingin membuat website, single-page application belum tentu pilihan terbaik
Single-page application itu sendiri dan kompleksitas untuk membangunnya adalah dua hal yang berbeda
Saya mulai mengenal web saat masih anak-anak di tahun 90-an. Saya bahkan tidak tahu apa itu CSS atau JS, dan JS cuma saya kenal sebagai skrip ajaib yang bikin sesuatu berkedip saat disalin-tempel
Belakangan saya membuat situs dinamis untuk bisnis lokal dengan PHP, dan di situ saya juga belajar sedikit JS dan CSS
Lalu saya berhenti dari pengembangan web karena muak menghabiskan terlalu banyak waktu agar semuanya berjalan di browser terburuk seperti IE6
Setelah hampir 6 tahun menjauh, saya kembali sekitar 2015 karena sadar server web akan berguna untuk pekerjaan yang sedang saya lakukan
Tapi saya kaget melihat dunia seolah melupakan banyak hal yang dulu saya tahu tentang HTML dan CSS
Dulu orang membuat beberapa stylesheet untuk sebuah situs, memastikan situsnya jalan dulu tanpa JS, lalu menambahkan JS sebagai peningkatan tambahan, tetapi pendekatan seperti itu sudah dilupakan
Saya juga melihat developer web melakukan seluruh validasi form hanya di JS dan tidak melakukan apa pun di server, dan anehnya ini masih umum sampai sekarang
Saya tidak begitu melihat pola umum di mana server memvalidasi lalu JS hanya menampilkan hasilnya. Sepertinya semua orang menerapkan dua kali atau sama sekali tidak memvalidasi di server
Setelah melihat itu, saya tidak lagi terkesan dengan apa yang orang lakukan di web. Itu bukan web yang saya kenal, cuma “aplikasi” yang dibuat dengan JS, dan memperjuangkan pendekatan web-first adalah pertarungan yang kalah
Waktu kecil saya mulai dengan HTML 3.2/XHTML dan CSS, lalu beberapa tahun kemudian bekerja dengan Django + jQuery sebelum tertarik ke sisi infrastruktur
Sekitar setahun lalu saya bekerja bersama tim pengembang web dan melihat apa yang mereka lakukan, dan saya sudah tidak mengerti apa-apa lagi
Kompleksitasnya terasa luar biasa, dan sepertinya sebagian besar waktu mereka habis untuk mengelola kompleksitas: mengurangi waktu build, menyelesaikan masalah dependensi, menangani masalah TypeScript yang aneh, dan penanganan error di banyak komponen
Di masa Django+jQuery, fokusnya masih pada hal-hal yang benar-benar bisa dilihat dan digunakan pengguna
Tentu saja klien sama sekali tidak boleh dipercaya, jadi nanti tetap harus divalidasi ulang di server
Mengurangi beban server itu berguna
Nasihat yang bagus, tapi bukankah secara teknis tidak benar kalau dikatakan “pengguna teknologi bantu tidak bisa mengetahui perubahan konteks yang sama saat berpindah ke halaman baru”, “tidak bisa menangani fokus saat perpindahan halaman”, “tidak bisa menavigasi dengan tombol maju/mundur browser”, dan “tidak bisa pulih dari error saat koneksi jaringan terputus”?
Banyak, bahkan mungkin sebagian besar single-page application memang tidak memperhatikannya, tapi hal-hal ini tetap bisa diimplementasikan di single-page application
Begitu masuk ke ranah single-page application, untuk kembali ke tingkat kesetaraan yang sama Anda harus menemukan ulang banyak roda, atau mengganti fitur native dengan pengganti berbasis JS
Coba pikirkan form multi-halaman: berapa banyak single-page application yang menyimpan semuanya di memori lalu hanya mengirim satu permintaan di akhir
Kalau tanpa JS, backend akan menyimpan status tiap langkah agar nanti pengguna bisa kembali ke form atau me-refresh halaman tanpa kehilangan data
Kalau website HTML biasa sudah berjalan baik dengan pengaturan bawaan, kenapa harus memaksakan sampah seperti itu
Jika pengguna tidak mengizinkan riwayat navigasi diutak-atik setelah kejadian, hanya tinggal satu pilihan
Yaitu membuat riwayat browser dengan benar pada saat riwayat itu ditulis
Semoga seluruh internet mengikuti nasihat ini
Yang lama menjadi baru lagi
Bukankah seharusnya kita memprioritaskan solusi sesederhana mungkin daripada yang sedang tren hari ini
Hanya karena sebagian besar industri mabuk JS bukan berarti semua orang begitu
Kenapa Linux tidak ada dalam daftar itu?
https://www.gov.uk/service-manual/technology/designing-for-d...
Jawaban yang lebih serius namun masih dalam konteks yang sama adalah, ada puluhan distro, dan jika memasukkan fork keluarga Mozilla, jumlah browsernya juga bisa sekitar sepuluh
Kita memang bisa memilih satu distro/browser resmi, tetapi basis pengguna dari satu pilihan itu akan menjadi sangat kecil
Bahkan Ubuntu pun tampaknya hanya memiliki sekitar 1% pangsa sistem operasi desktop berdasarkan angka yang bisa dihitung sebagai metrik sekunder
Ini pertanyaan serius, tetapi melihat komentar-komentarnya, sepertinya orang-orang menyukai pendekatan seperti ini
Kalau begitu, kenapa arus umumnya justru bergerak ke arah memakai framework seperti React dan JavaScript, kadang-kadang secara tidak perlu
Ringan, tata letaknya rapi, aksesibilitasnya bagus, dan umumnya memakai JavaScript seminimal mungkin atau tetap berfungsi tanpanya
Sebaliknya, saya tidak suka kebanyakan single-page application. Banyak yang merusak fitur browser yang seharusnya ada, tidak berguna tanpa JavaScript, dan sering memuat berbagai dependensi berat dari banyak situs pihak ketiga
Tetapi apa yang disukai pengguna dan apa yang disukai developer serta bisa mereka buat dengan cepat sering kali sangat berbeda
Begitu sesuatu diterima sebagai standar industri, keputusan untuk mengikuti arus menjadi aman
Lagi pula, tidak ada yang melakukan developer relations untuk HTML/CSS/JS murni
Kalau mencari cara melakukan sesuatu, hampir semua hasilnya terkait framework
Kalau Anda membuat program yang berjalan di komputer sendiri, Anda harus menanggung biaya itu secara langsung, atau setidaknya menjelaskan ke tim keuangan kenapa biaya cloud naik 5%
Tetapi kalau seperti developer frontend Anda menjalankan perangkat lunak di perangkat milik orang lain, biayanya hampir tidak ada
Sinyal negatif baru masuk lewat jalur seperti laporan pengguna, tiket dukungan, atau mungkin postingan Twitter, dan proses itu penuh bias seleksi sehingga besar kemungkinan tidak memberi gambaran utuh
Pada akhirnya ini semua soal insentif
Web sedang menggantikan thick client tradisional, dan klien seperti itu pun mengasumsikan koneksi jaringan yang cukup stabil serta spesifikasi platform tertentu
Sistem pemerintah harus berjalan pada penyebut bersama terendah, meskipun itu jarang
Startup teknologi bisa tetap ada walau awalnya hanya punya satu pelanggan, dan saat skalanya membesar mereka bisa percaya bahwa kebutuhan mereka pada umumnya akan menjadi hal yang lazim
Bahkan saya rasa justru karena mereka developer frontend maka mereka tidak menyukai pendekatan ini. Kalau tidak, hampir tidak akan ada lagi frontend yang perlu dikembangkan
Cara yang ingin saya ikuti juga ke arah ini. Menyajikan HTML bersama data yang sudah diambil lebih dulu dari server, memproses apa yang bisa dikerjakan di klien di sisi klien untuk mengurangi bolak-balik ke server, membuat layout responsif dengan CSS seminimal mungkin, dan memakai JS murni
Kalau perlu, cukup pisahkan menjadi halaman web terpisah
Tetapi tampaknya bagi rekan kerja saya, hanya karena memakai HTML, CSS, dan JS murni, pendekatan ini terdengar aneh dan kuno
Sebenarnya tidak ada yang kurang
Tulisannya juga mengatakan bahwa memakai sisi server saja secara membabi buta bukanlah rekayasa perangkat lunak yang baik
Perlu diperhatikan bahwa yang dikatakan adalah “bisa menimbulkan masalah”, bukan “menimbulkan masalah”
Framework JavaScript sisi klien bisa membantu saat membangun layanan dengan antarmuka pengguna yang kompleks, tetapi juga dapat memperbesar ukuran total codebase dan mendorong pemrosesan ke klien sehingga menimbulkan masalah performa bagi pengguna dengan jaringan lambat atau perangkat berdaya rendah
Itu juga bisa membuat Anda bergantung pada kode pihak ketiga yang tidak dikendalikan developer, dan mungkin memaksa perubahan besar pada layanan untuk menyesuaikan perubahan framework
Jika popularitas framework menurun, bisa jadi sulit menemukan orang untuk memeliharanya
Jika menggunakan framework JavaScript, Anda harus membenarkannya dengan bukti tentang manfaatnya bagi pengguna, memahami dan mengurangi dampak negatifnya, serta menimbang apakah manfaatnya lebih besar daripada potensi masalah
Selain itu, pakailah hanya pada bagian antarmuka pengguna yang tidak bisa dibuat hanya dengan HTML dan CSS, dan rancang setiap bagiannya sebagai komponen terpisah
Jika komponen dipisahkan, kegagalan memuat JavaScript hanya akan membuat komponen itu saja yang gagal, sementara sisa halaman tetap dimuat seperti biasa