- Pendekatan HTML-first membuat formulir pendaftaran layanan publik tetap berfungsi tanpa JavaScript, sehingga pengguna tetap bisa menyelesaikan pengajuan di perangkat, browser, dan jaringan yang buruk
- Aplikasi React sebelumnya ditarik turun hanya dalam 3 hari karena keluhan pelanggan; masalahnya mencakup loading spinner, status JavaScript global, persoalan aksesibilitas, dan cara penyimpanan gambar yang menabrak batas
localStorage5MB - Implementasi baru berbasis Astro menjadikan setiap langkah formulir sebagai halaman terpisah, lalu menyimpan data kiriman dan unggahan ke sesi backend di setiap tahap untuk mencegah hilangnya data input
- Validasi formulir ditangani dengan web component yang membungkus validasi HTML bawaan browser, dan saat gagal menggunakan struktur peningkatan progresif yang berlanjut ke validasi bawaan browser lalu validasi API backend
- Setelah peluncuran, jumlah penyelesai formulir menjadi dua kali lipat, dan terungkap bahwa pengguna yang keluar karena kegagalan JavaScript tidak tertangkap oleh paket analitik berbasis JavaScript
Latar belakang masalah dan upaya sebelumnya yang gagal
- Pelanggannya adalah perusahaan utilitas, dan pendaftaran layanan bisa dilakukan lewat formulir ASP lama di situs web atau lewat prosedur manual
- Prosedur manual lebih mahal bagi perusahaan, dan dalam kondisi monopoli yang diatur regulator, jika kepuasan pelanggan turun di bawah 96% bisa muncul denda jutaan pound
- Dua upaya sebelumnya untuk menyelesaikan masalah ini gagal, dan pada upaya terbaru kontraktor dari negara lain membuat aplikasi React
- Aplikasi React itu ditarik turun 3 hari setelah dipublikasikan secara online karena keluhan pelanggan
- Aplikasi tersebut dipenuhi loading spinner dan status JavaScript global yang saling bercampur, serta tidak memenuhi aksesibilitas
- Unggah gambar adalah fungsi inti formulir, tetapi aplikasi itu mencoba menyimpan gambar dan seluruh data formulir di
localStorageyang dibatasi 5MB
Kriteria yang ditetapkan dengan HTML-first
- Situs baru dibangun dengan Astro dan mengadopsi struktur HTML-first
- JavaScript hanya digunakan di dalam web component, dan berperan untuk meningkatkan secara progresif situs web yang tetap berfungsi normal tanpa JavaScript
- Diterapkan prinsip bahwa layanan publik harus bekerja di sebanyak mungkin perangkat
- Diterapkan prinsip bahwa layanan harus tetap bekerja meski koneksi buruk
- Diterapkan prinsip bahwa data formulir yang sudah diisi sekali tidak boleh pernah hilang
- Contoh dari Terence Eden menunjukkan bahwa halaman HTML sederhana GOV.UK tetap bisa menampilkan informasi tunjangan perumahan di browser PlayStation Portable yang lambat dan sering kehabisan memori
- Halaman GOV.UK ditulis sebagai HTML sederhana yang dirancang ringan, dan harus tetap berfungsi bahkan di browser yang sangat buruk
Struktur formulir dan cara menjaga data tetap tersimpan
- Setiap sesi formulir harus memiliki ID unik
- Di semua langkah wizard formulir, data kiriman dan file unggahan harus disimpan di backend
- Formulir harus bisa diselesaikan tanpa JavaScript
- Formulir harus bisa diselesaikan bahkan di browser web lama dan berperforma rendah
- Aksesibilitas harus memenuhi standar WCAG, dan tim menargetkan AA, bukan AAA
- JavaScript dan CSS modern seharusnya digunakan untuk meningkatkan pengalaman
- Dalam struktur akhirnya, setiap langkah wizard formulir menjadi halaman terpisah, dan saat pengguna menekan berikutnya formulir dikirimkan
- Jika API menilai data valid, browser diarahkan ke langkah berikutnya
- Pengiriman formulir dan redirect adalah pola aplikasi web lama yang mengalami kebangkitan modern kecil berkat Remix
- Layanan ini bukan aplikasi yang menampilkan data real-time, melainkan formulir besar, sehingga pendekatan mengirim 20MB JavaScript sebelum render terasa tidak tepat
Validasi formulir dan peningkatan progresif
- Validasi formulir dan perenderan error formulir sering diperlakukan sebagai area yang membuat tim menghabiskan banyak person-month karena library validasi React
- Browser sebenarnya sudah memiliki sistem validasi bawaan, dan itu bisa dimanfaatkan dengan kerja yang lebih sedikit dibanding implementasi tiruan berkualitas rendah yang memerlukan pengelolaan library terpisah
- HTML web component yang diimplementasikan adalah elemen kustom sederhana yang membungkus HTML yang sudah ada
- Web component ini tidak memakai shadow DOM, dan hampir tidak merender HTML di dalam JavaScript
- Komponen tersebut membungkus formulir HTML dan mengambil validasi HTML untuk ditampilkan dalam bentuk modern
- Tooltip popup validasi HTML diblokir, lalu error ditempatkan di dalam elemen
aria-describedbyyang terhubung dengan field - Saat ini penggunaan
aria-errormessagedirekomendasikan - Ketika input menjadi valid saat sedang diisi, validasi dihapus, lalu dievaluasi ulang pada saat
blurdan saat submit - Pengalaman pengguna ini dikirimkan dalam ukuran kurang dari 1KB, dan jika gagal akan kembali ke validasi bawaan browser
- Jika validasi bawaan browser juga gagal, API backend akan menangani validasi
- Masalah validasi diberitahukan pada saat paling awal yang diizinkan browser pengguna, dan meski gagal selalu ada fallback ke pengalaman yang tetap layak
- Setelah itu, versi baru web component ditulis ulang dari nol untuk penggunaan umum, dengan nama validation-enhancer
- Contoh penggunaannya adalah
validation-enhancermembungkus formulir HTML sambil tetap memanfaatkaninput type="email",required, danaria-errormessage
Email
Submit
Hasil peluncuran dan kesimpulan
- Setelah peluncuran, jumlah orang yang menyelesaikan formulir menjadi dua kali lipat
- Para analis tidak tahu dari mana para pengguna ini datang
- Paket analitik berbasis JavaScript tidak bisa melihat pengguna yang keluar karena kegagalan JavaScript
- Pendekatan mempertahankan sesi backend dan tidak pernah kehilangan data pengguna terbukti efektif
- Dalam satu kasus, ada pengguna yang menyelesaikan formulir sebulan setelah mulai mengisinya
- Setelah pekerjaan kontrak selesai, penerusnya menanggapi bahwa struktur yang selalu bekerja tanpa JavaScript justru menambah pekerjaan bagi tim
- Mengecualikan pengguna browser lama, pengguna dengan koneksi jaringan buruk, dan pengguna teknologi bantu tidak bisa diterima untuk layanan publik yang bersifat monopoli
- Arus yang terus mendorong pendekatan kasar dan belum matang yang muncul pada masa ekspansi industri perangkat lunak perlu ditinggalkan
- Jika membuat aplikasi web yang bekerja bahkan di PlayStation Portable dan koneksi 3G, itu akan bekerja untuk semua pengguna, dan mungkin tetap bekerja 30 tahun lagi
2 komentar
Komentar Hacker News
Sebagai pengembang non-web, saya penasaran kenapa pendekatan ini dianggap menambah pekerjaan
Pendekatan yang dijelaskan di tulisan itu terlihat cukup sederhana: buat komponen standar untuk form lalu letakkan tombol submit di bawahnya. Dulu saat membuat situs pribadi saya juga melakukannya seperti itu, dan rasanya tidak terlalu sulit. Mungkin karena saya tidak terlalu paham bidang ini, tetapi membuat frontend yang mewah justru terlihat jauh lebih sulit
Bukan karena mereka bodoh. Kalau ditanya langsung, “Apakah bisa membuat situs tanpa React?”, tentu mereka akan menjawab, “Ya.” Namun saat diminta membuat situs baru, karena faktor kebiasaan dan keinginan untuk segera menyelesaikan pekerjaan, mereka tanpa banyak pikir langsung memulai proyek React baru
Sebagian memang benar-benar tidak tahu cara lain. Mereka tidak tahu cara menyiapkan server HTTP biasa yang mengirim HTML murni, dan tidak punya pengalaman membuat form yang divalidasi dan dikirim tanpa JavaScript. Orang-orang seperti ini bukan tipe yang menulis di HN, dan juga tidak ikut dalam diskusi online tentang alat atau teknologi baru, ataupun alat dan teknologi lama. Mereka biasanya hanya belajar secukupnya untuk mendapat pekerjaan lewat bootcamp atau satu mata kuliah webapp di kampus, lalu setelah itu hanya mempelajari alat tertentu yang diminta perusahaan atau dipilih seseorang di tim
Sebagai orang yang lebih tua, saya butuh waktu untuk menyadari hal ini, tetapi sekarang saya memahaminya. Tergantung jalur kariernya, ada orang yang baru mengenal bagian paling dasar dari HTML, CSS, dan JavaScript murni justru setelah mereka lebih dulu mengenal bagian rumit yang khusus untuk framework dari masing-masing teknologi itu. Karena itu, bagi mereka pendekatan tersebut terasa bukan lebih tidak profesional, melainkan lebih sulit dipahami, lebih canggih, atau seperti pengetahuan sampingan
Kalimat “itu membuat pekerjaan kami jauh lebih banyak” juga belum tentu salah secara sengaja. Kalau seseorang harus bekerja dengan alat yang tidak familiar, meskipun alat itu lebih sederhana, pekerjaan itu memang bisa terasa jauh lebih berat
Aplikasinya cepat dan sederhana, tetapi ada konsekuensinya. Kemampuan untuk langsung mengambil elemen UI kaya dari paket npm menjadi terbatas, dan untuk menghadirkan pengalaman pengguna yang baik kami harus bekerja jauh lebih banyak. Semua butuh waktu lebih lama, dan pada akhirnya pengalaman penggunanya juga lebih buruk. Kami peduli, tetapi kadang memang tidak sempat membereskan semuanya sampai tuntas
Perusahaannya gagal, dan saya tidak merasa React akan menyelamatkannya. Namun saya bisa mengatakan dari pengalaman sendiri bahwa obsesi moral terhadap “kesederhanaan” juga tidak membantu. Selalu ada trade-off
Seseorang bilang ia memberikan solusi yang lebih sederhana dan lebih masuk akal dibanding solusi yang biasanya terpikirkan kebanyakan orang, tetapi orang yang menerima handoff tidak puas
Apakah kita tahu kualitas kode yang diserahkan itu memang tinggi? Apakah orang itu bereaksi karena faktanya “ini bukan React”? Apakah mungkin ada template wajib di perusahaan tentang cara membuat app?
Kita tidak tahu
Sudah lama saya jarang mendengarnya, tetapi proposal HTML Triptych masih menjadi salah satu hal yang saya harap suatu hari masuk ke browser. Cara HTML form berinteraksi dengan endpoint REST adalah pola yang bagus
Validasi bantu untuk pengguna ditangani lewat atribut input, validasi sebenarnya dilakukan di sisi lain dari request, dan alurnya menjadi GET /form => POST /thing => GET /thing/1. Jika fitur triptych diimplementasikan, itu akan menjadi pola yang sangat bagus
[0] https://triptychproject.org/
Saya sama sekali tidak menyukai situs React, tetapi yang tidak saya mengerti adalah apakah situs-situs seperti ini memang sama sekali tidak melakukan lazy loading
Bahkan single-page app besar pun bisa sangat cepat jika komponen hanya dimuat saat diperlukan
Saya sudah melalui Angular1 -> Vue2 -> Svelte2 lalu menetap pada web component murni tanpa shadow DOM, dan rasanya menyenangkan sekaligus cepat untuk dikerjakan
Akhir-akhir ini sebagian besar aplikasi dibuat hanya dengan HTMX + Go + SQLite
Rasanya itu sudah cukup untuk kebanyakan proyek
Salah satu situs saya penuh gambar dan menangani trafik 10TB per bulan. Dalam kasus ini, susunannya seperti ini: 1. Menggunakan S3 karena butuh penyimpanan data yang andal 2. Menaruh Cloudflare di depan dan mengaktifkan Tiered Cache. Dengan begitu POP akan lebih memilih mengambil dari Cloudflare daripada origin. Saya mengatur agar semuanya di-cache selama 1 tahun baik di browser maupun di Cloudflare, serta membuat aturan untuk mengabaikan kebijakan cache origin dan query string, dan hanya memakai objek immutable yang perlu revisi 3. Menaruh BunnyCDN di depannya
Cloudflare saja tidak benar-benar memungkinkan menjalankan situs yang berat di gambar, jadi cara ini sangat menurunkan biaya. Secara kebijakan itu seharusnya tidak dipakai terutama untuk gambar, melainkan untuk HTML, CSS, JavaScript, dan konten situs lainnya
Kalau hanya pakai S3, biayanya akan sangat besar
Namun belakangan ini saya sedang membuat aplikasi mobile. PWA punya batasan. Sistem operasi bisa mengambil kembali penyimpanan IndexedDB, jadi tidak bisa menyediakan penyimpanan data yang andal di dalam aplikasi tanpa pendaftaran pengguna atau campur tangan backend
Pada akhirnya saya terpaksa pindah ke Flutter di Android, tetapi itu membawa penderitaan lain. Kadang pembaruan aplikasi lama tertahan di status “sedang ditinjau”, dan itu membuat frustrasi. Sebagai perbandingan, web app dari aplikasi yang sama bisa diperbarui sangat cepat
Saya penasaran kenapa tidak ada sistem operasi mobile yang membiarkan kita membuat aplikasi dengan JavaScript, HTML, dan CSS sekaligus menyediakan penyimpanan yang stabil tanpa banyak usaha. Kemampuan memperbarui aplikasi PWA dengan cepat itu bagus
Perjalanan waktu adalah bagian yang mudah, setelah itu kita harus entah bagaimana mencegah kejatuhan Palm dan webOS dilupakan sebagai sistem operasi smartphone
Kalau 2009 terlalu jauh, Anda juga bisa bertaruh pada Firefox OS tahun 2012
Di luar bercanda, orang dan perusahaan memang pernah mencobanya. Tetapi karena timing yang buruk dan berbagai kejadian lain, kenyataan itu tidak sempat terwujud di lini waktu kita
Rasanya seperti berada di titik optimal yang pas: tidak ada beban tidak perlu seperti C, tetapi juga menyingkir agar kita bisa fokus pada logika bisnis seperti Java. Berbeda dengan Rust
Ini bukan bahasa yang bagus untuk semua hal. Khususnya, kurangnya kemampuan membuat abstraksi cukup disayangkan. Tetapi untuk aplikasi server dengan banyak logika bisnis, ini luar biasa. Rasanya seperti bahasa yang memang khusus untuk bidang itu, bukan bahasa yang mencoba melakukan segalanya
Saya juga membuat beberapa library untuk mengabstraksikan bagian SQL dan HTMX/web/OAuth. Sekarang aplikasi-aplikasi saya sangat mirip satu sama lain sehingga mudah memindahkan fitur dari satu ke yang lain
https://github.com/cattlecloud/webtools
https://github.com/cattlecloud/litesql
Sebagai sanggahan, ada In Defence of the Single Page Application
https://williamkennedy.ninja/javascript/2022/05/03/in-defenc...
In Defence of the Single Page Application - https://news.ycombinator.com/item?id=31275178 - Mei 2022, 32 komentar
Tulisan ini bagus, dan merupakan contoh yang sangat baik tentang mengambil masalah lalu menyelesaikannya dengan teknologi yang tepat dan kedalaman yang tepat. Sangat membantu kalau kita benar-benar punya pengetahuan domain pelanggan
Namun, saya tidak suka framing seperti “HTML sederhana lebih baik daripada React”. Karena sebagai developer React pun saya bisa membuat argumen yang sama persis
Kita bisa terus membahas tanpa habis banyak hal yang dilewati begitu saja dalam tulisan ini, seperti kompleksitas dan nuansa penyimpanan sesi berbasis server versus penyimpanan berbasis browser, tetapi itu akan jadi terlalu panjang
Hal-hal yang sederhana di HTML juga sederhana di React
Secara harfiah itu adalah kode yang sama. Tidak ada yang menghalangi penggunaan validasi HTML berbasis browser di React. Kode yang jadi rumit di React, misalnya logika validasi yang terlalu kompleks, juga akan rumit di Astro. Astro juga punya caranya sendiri untuk validasi skema dan sebagainya, dan untuk mengintegrasikannya ke situs Astro sering kali perlu juga mengintegrasikan client router dan lain-lain, sehingga di sana pun sangat mudah menjadi terlalu kompleks
Pembandingnya juga mungkin adalah tim outsourcing luar negeri dengan pengetahuan yang tidak lengkap, dan dalam struktur proyek seperti itu ada insentif untuk membuat solusi secepat mungkin, dalam waktu sesedikit mungkin, dengan kompleksitas sebesar mungkin
Poin terakhir itu licik. Bukan berarti vendor outsourcing sengaja melakukannya, tetapi dalam struktur insentif, kompleksitas berlebihan memang menguntungkan mereka, jadi tidak ada insentif langsung bagi mereka untuk mengambil pendekatan yang sederhana
Bagaimanapun, solusi sederhana yang langsung menangani masalah yang dihadapi selalu lebih baik, dan itu berlaku apa pun stack yang dipilih
Ini bukan berarti saya anti pada validasi form Astro, saya hanya ingin menekankan bahwa ada hal yang lebih dari sekadar “validasi browser HTML native”
Tulisan yang bagus, tetapi setiap kali membaca tulisan inspiratif seperti ini aku selalu galau. Gagasannya tentang situs yang sederhana yang sepenuhnya benar, bekerja dengan baik, dimuat cepat, dan tidak bergantung pada browser terbaru itu sangat kusukai
Lalu aku jadi berpikir jangan-jangan ini karena aku tidak cukup pintar untuk memahami React atau teknologi keren yang sedang tren saat itu
Rasanya seperti ada batas pemahaman yang tidak bisa kulewati. Kalau diberi editor sederhana seperti Sublime dan diminta membuat halaman web, itu tetap jadi ruang yang menyenangkan bahkan dengan JavaScript. Tapi kalau diberi VSCode atau Zed, plugin Claude/Copilot/ChatGPT yang menempel di mana-mana, dan tutorial React, kepalaku langsung meleleh
Menjaganya tetap sederhana bukanlah hal buruk, dan sering kali justru perlu cukup pintar untuk tidak membuat sesuatu jadi terlalu rumit
Embrace Extend Extinguish itu nyata, dan orang-orang yang mendukungnya pantas saja digantikan oleh LLM yang bisa berbohong lebih cepat dan memuntahkan kode sampah
Ini mengingatkanku pada hampir 15 tahun lalu. Kami memakai manajemen sesi backend di Grails, lalu menggunakan form HTML yang ditingkatkan dengan CSS responsif dan “sedikit” JS
Yang berbeda dari saat itu adalah teknologi browser belum semaju sekarang. Kami harus memikirkan banyak browser dan menangani IE7, bahkan IE6, jadi sulit dan butuh QA yang luas. BrowserStack baru muncul belakangan
Ada alasan kenapa library JavaScript berkembang. Waktu itu belum ada npm, bahkan bower pun belum ada. Lalu Backbone.js muncul dan aku menyukainya. AngularJS luar biasa, lalu versi Angular berikutnya membawa pemutusan kompatibilitas besar, setelah itu muncul React, Polymer, dan lainnya
Browser native sekarang bisa melakukan banyak hal dan peningkatan fungsionalitas juga mudah. Tapi dulu tidak selalu begitu. Keputusan memakai React saat itu masuk akal karena banyak alasan, dan bisa jadi di sini juga begitu
Lebih dari 10 tahun lalu aku membangun aplikasi seperti ini di GOV.UK untuk Kementerian Kehakiman. Kami membuat library wizard form sendiri agar form panjang bisa divalidasi per langkah dan dipecah ke beberapa halaman. Ruby on Rails tidak mendukung itu secara bawaan
Pada saat itu, prinsip bahwa semua orang harus bisa menggunakan layanan digital apa pun lingkungan yang mereka pakai untuk mengaksesnya sangatlah penting
Untuk setiap ID sesi, kita bisa mencocokkan halaman aplikasi multi-halaman dengan ID sesi tersebut, jadi bila perlu pengguna bahkan bisa memasukkannya sendiri. Tetapi dengan informasi yang cukup seperti alamat IP, tanggal unggah, browser, dan sistem operasi, seharusnya tetap bisa dibedakan. Meski begitu, sesi yang paling akurat harus berada di dalam browser, agar cookie dari satu pengajuan tidak tercampur dengan pemohon lain seperti kerabat yang memakai PlayStation Portable
Aku penasaran mereka memakai teknologi apa untuk aplikasi seluler. Kurasa itu bukan aplikasi seluler penuh, mungkin memakai webview
Ini bukan soal “kami mengubah aplikasi React menjadi form HTML lalu performanya membaik”. Ini soal “kami mengubah halaman web yang buruk menjadi halaman web yang baik lalu performanya membaik”
Menyalahkan teknologi yang dipakai untuk menjalankan pengalaman browser itu bodoh. Dengan React pun kamu bisa membuat pengalaman pengguna yang hebat, dan dengan HTML murni pun kamu bisa membuat situs yang mengerikan
Perbaikannya datang dari perubahan desain, bukan dari teknologinya
Tapi itu benar. Perubahan di sisi pengguna datang dari memperbaiki desain, bukan dari teknologi yang dipakai
Ini sangat mirip dengan bullet point buruk di resume. Seseorang menulis “menulis ulang situs web menjadi HTML-first dan meningkatkan jumlah pengunjung 100%” seolah hasil bisnis itu terjadi karena perubahan kode. Kalau ditanya soal poin itu, akhirnya mereka akan mengakui bahwa mereka mendesain ulang seluruh situs untuk memperbaiki masalah desain atau menambahkan fitur, dan peningkatan pengunjunglah yang didorong oleh hal tersebut
JavaScript: The Good Parts karya Douglas Crockford itu lucunya tipis sekali. React: The Good Parts mungkin akan lebih tipis lagi
Menariknya, tulisan aslinya menjelaskan form bergaya wizard multi-halaman yang hampir tidak pernah kulihat lagi selama kira-kira 10 tahun terakhir. Tapi setiap kali aku melihat yang seperti itu, biasanya itu sistem enterprise yang mengerikan. Terakhir kali aku melihatnya adalah sesuatu seperti produk Oracle untuk pengelolaan pengeluaran
Masalah dari hal-hal seperti itu selalu sama: bagian tengah prosesnya lambat. Setiap tombol harus menunggu beberapa detik. Kalau harus mundur satu atau dua langkah, rasanya dua kali lebih menyebalkan. Single-page app yang dibuat buruk cenderung lambat di awal. Memang butuh waktu untuk memuat, tapi setelah termuat biasanya performanya lumayan
Opini Lobste.rs
Membuat sesuatu yang benar-benar berfungsi untuk manusia tentu memang butuh lebih banyak kerja. Tapi pada akhirnya itulah inti dari seluruh pekerjaan
Yang sebenarnya ingin dikatakan para penerus itu tampaknya lebih dekat ke arti bahwa mereka tidak benar-benar memahami dasar-dasar platform web
Ini bukan berarti itu hal yang diinginkan, hanya mengatakan bahwa begitulah kenyataannya saat ini
Bagian yang mengatakan butuh waktu untuk menjelaskan “submit form dan redirect” kepada rekan kerja terasa pahit. Ini karena semua orang sudah terbiasa dengan aplikasi web berpusat pada klien
Pengembangan web saat ini benar-benar dalam keadaan yang menyedihkan, dan ada banyak hal yang harus diajarkan kembali
Saya rasa tidak perlu tingkat kompatibilitas setinggi itu untuk membenarkan pendekatan seperti ini. Seperti yang dikatakan di tulisan itu, pada dasarnya ini cuma form
Jadi kalau saya, sepertinya saya akan membuatnya seperti itu dalam kasus apa pun
Saya ingin mencoba membuat situs seperti yang dijelaskan di tulisan itu. Batasan berupa unduhan yang sangat kecil yang harus berjalan di hampir semua browser dan tetap memperhatikan aksesibilitas terdengar seperti tantangan yang cukup menyenangkan
Saya jadi penasaran apakah ada perusahaan yang berspesialisasi di bidang seperti ini, dan apakah mereka sedang merekrut. Mungkin saya cuma orang tua yang merindukan cara lama yang lebih sederhana
Fungsinya sudah cukup terisolasi sehingga sangat mudah diekstrak menjadi library yang bisa dipakai ulang, dan masih banyak yang bisa dikerjakan. Ini jadi terasa seperti sesuatu yang ingin dimasukkan sebagai default framework web. Tulisan yang sangat bagus
Agak ironis, di Firefox karena suatu style tertentu isi artikel sama sekali tidak terlihat dan tidak bisa dipilih, jadi saya harus beralih ke mode baca. Judul, tanda kutip merah muda, dan code block terlihat, tapi sisanya tidak
Edit: setelah melihat komentar di bawah, sepertinya ini masalah di lingkungan saya. Saya biarkan demi konteks
Tulisannya sendiri terbaca dengan baik. Baik pengembang maupun pengguna akhir, kita semua sedang membayar biaya dari “kelincahan” React. Saya sudah beberapa kali berpikir andai di kantor bisa memakai stack lain
Saya juga terkesan dengan empati penulis dan cara ia merancangnya menjadi struktur “semua orang menang”. Sikap yang peduli pada akhirnya memberi hasil
Sangat relate. Dulu saya pernah membuat blog yang sangat sarat JavaScript, dan gara-gara fitur berbasis JS itu situasinya hampir sampai memicu pemberontakan
Saya masih belum sempat memindahkannya ke pendekatan HTML-first, tapi dari luar setidaknya saya membuatnya terlihat seperti halaman web HTML-first
Di data analitik saya juga terlihat hasil yang mirip. Bounce rate turun dari 80% ke sekitar 50%, dan pengunjung baru untuk tulisan-tulisan setelahnya hampir menjadi dua kali lipat
Ngeri kalau memikirkan berapa banyak orang yang mungkin akan menghindari domain saya seumur hidup gara-gara implementasi buruk berbasis JS yang saya buat di awal. Untuk webpage atau blog, ini salah satu nasihat terpenting
Cara seperti ini juga membantu autofill form. Dulu ada form yang sepenuhnya dinamis dan tidak punya atribut untuk mengidentifikasi tiap bagian, jadi saya tidak bisa membuat input otomatis
Rasanya sayang karena itu berarti dirancang berlebihan demi terlihat cantik dibanding benar-benar berfungsi, jadi saya senang membaca tulisan ini tentang desain yang mengutamakan pengguna
Jika ditambah streaming SSE dan library morph, fitur dinamis, real-time, dan multiplayer juga bisa dibuat dengan cukup keren