Bertaruh pada HTML

• Seiring meluasnya AI berbasis model bahasa besar, nilai HTML semantik yang dapat dibaca mesin juga semakin besar, sama pentingnya dengan layar yang dilihat manusia
• Walled garden milik media sosial besar menghambat portabilitas data dan interoperabilitas, sementara upaya terdesentralisasi seperti fediverse, Threads, dan Bluesky pun belum punya dorongan yang cukup kuat untuk menarik pengguna umum
• HTML modern sudah memiliki cukup banyak elemen UI dasar yang dibutuhkan aplikasi web, seperti <details>, <dialog>, dan berbagai <input>
• Dengan memanfaatkan gaya bawaan browser dan reader mode, ketergantungan berlebihan pada CSS·JavaScript dapat dikurangi, dan tag yang tepat meningkatkan keterbacaan mesin serta pengalaman input di perangkat mobile
• Dalam arus di mana RSS masih tetap hidup dan antarmuka ala ChatGPT mulai muncul sebagai cara mengakses data, HTML terstruktur dapat menjadi fondasi yang lebih praktis dibanding antarmuka yang berpusat pada iklan

---

HTML sebagai antarmuka data dasar web

• Kemunculan AI berbasis model bahasa besar kembali mengangkat pentingnya HTML semantik
• Inti internet adalah menyampaikan data yang dibutuhkan manusia untuk berinteraksi dengan dunia, tetapi kebebasan HTML/CSS/JavaScript juga punya sisi lain: membatasi akses ke data
• Media sosial milik perusahaan teknologi besar mengikat pengguna di dalam platform tertutup, alih-alih memakai format data dan API yang terbuka serta mudah diakses
  • Interoperabilitas antarpaltform pada praktiknya menjadi sulit
  • Masalah makin rumit karena perusahaan enggan memudahkan perpindahan data
• Ketidakstabilan media sosial belakangan ini kembali meningkatkan minat pada platform terdesentralisasi seperti fediverse
  • Threads milik Meta dan Bluesky yang dibuat Jack Dorsey mengusung interoperabilitas dengan fediverse yang lebih luas
  • Namun, pengguna umum sering kali tidak memilih media sosial baru hanya karena alasan seperti ini
• Perlu melihat kembali HTML sebagai solusi yang sudah terbukti
  • Dahulu, banyak CSS diperlukan agar konten HTML tidak terlihat buruk di browser
  • Kini, banyak elemen HTML modern telah ditambahkan dan menyediakan sebagian besar elemen UI yang dibutuhkan aplikasi web modern
  • Reader mode dapat meniadakan waktu yang dihabiskan untuk styling, dan ini bisa dipandang positif
• Tag yang tepat menyediakan format yang mudah dibaca mesin
  • Ini menjadi alasan yang lebih kuat untuk mengadopsi HTML modern daripada sekadar menghemat waktu desain
  • RSS terus tetap hidup
  • Ada kemungkinan antarmuka seperti ChatGPT menjadi cara masa depan bagi manusia untuk mengakses data

Elemen HTML yang berguna atau layak dilihat dengan perspektif baru

• Daftar lengkap elemen HTML di MDN layak dilihat
  • Contoh di bawah hanya menggunakan gaya bawaan browser tanpa styling terpisah
  • Tampilannya bisa sangat berbeda tergantung browser, atau bahkan tidak didukung sama sekali
• <abbr>: elemen untuk membungkus singkatan
  • Dapat diberi gaya untuk penekanan
  • Terutama berguna untuk pembacaan mesin
• <datalist>: elemen yang menyediakan daftar kandidat input
  • Dapat membuat UI yang tampak seperti typeahead
  • Tampaknya tidak ada validasi bawaan
  • Di Safari, tag option harus ditutup; jika tidak ditutup, elemen ini tidak akan bekerja
• <details>: elemen disclosure yang dapat dibuka dan ditutup
  • Dapat digunakan sebagai dropdown kecil
  • Styling juga bisa diterapkan secara kuat
• <dialog>: elemen kotak dialog
  • Ini adalah elemen bawaan yang dapat dibuka dan ditutup dengan tombol, form, atribut, dan JavaScript
  • Tidak persis sama dengan modal, tetapi layak dijadikan dasar jika ingin membuat modal
  • Tampaknya dirender di atas elemen berikutnya
• <i> dan <em>
  • Perlu memahami perbedaan kedua elemen ini
• <iframe>
  • Masuk dalam daftar contoh, tetapi dibahas seperti lelucon
• <input>: elemen input form
  • Input harus menggunakan label dan tipe yang sesuai
  • Di mobile, sistem operasi membuka keyboard yang berbeda sesuai konteks, sehingga penentuan tipe input penting
  • Ada beragam input terkait waktu, sehingga dapat mengurangi kebutuhan akan date picker JavaScript terpisah
  • Contohnya mencakup input color, range, dan datetime-local
• <mark>: elemen penyorot teks
  • Secara default, di Safari ditampilkan sebagai sorotan berwarna kuning
• <meter>: elemen untuk menampilkan nilai pengukuran
  • Di Safari, ditampilkan dalam warna merah·kuning·hijau sesuai parameter yang diatur
  • Nilai optimum dapat diatur
  • Bisa berguna untuk demo visualisasi musik 60fps
• <progress>: elemen penampil progres
  • Ini adalah bilah progres HTML native yang dapat diberi nilai tetap atau status tak tentu
  • Di Safari, tampak biru saat jendela aktif dan abu-abu saat tidak aktif
  • Secara default mengikuti warna aksen sistem, dan dapat diatur dengan properti CSS accent-color

[GN⁺]

Pendapat Hacker News

• Aneh kalau HTML disebut sebagai solusi untuk ketergantungan pada ekosistem tertutup. Layanan-layanan tertutup semacam itu pun sudah memakai HTML, dan juga memakai sebagian elemen semantik yang disebutkan serta atribut semantik ARIA yang lebih canggih
  Klaim bahwa antarmuka seperti ChatGPT adalah masa depan akses data manusia juga bertentangan dengan inti sistem kecerdasan buatan: mereka tidak memerlukan anotasi khusus “yang dapat dibaca mesin” untuk memproses masukan. ChatGPT dan model-model penerusnya dapat menjelajahi situs web biasa seperti manusia, dan bisa menyadari bahwa sekumpulan paragraf adalah “daftar” tanpa markup eksplisit
  Yang dijelaskan penulis pada akhirnya lebih mirip API yang dimediasi oleh elemen semantik HTML. Namun jika ada API, model bahasa besar tidak diperlukan untuk akses data otomatis; skrip Python biasa yang memakai Beautiful Soup sudah cukup, dengan keuntungan bahwa ia berjalan sepenuhnya secara lokal

  • Ini rasanya terlalu menyederhanakan. Ada “HTML”, dan ada pula situs web yang DOM akhirnya baru ditentukan setelah pengguna mencoba membacanya selama 10 detik. Di antara dua kutub itu, ada perbedaan besar dalam seberapa banyak fitur browser yang harus dipakai
    Pada akhirnya, yang membedakan yang baik dan buruk adalah kompleksitas implementasi. Alat apa pun bisa dipakai dengan baik atau buruk, dan pemula bisa membuat kecelakaan besar dengan gergaji bundar dan baterai yang terisi. Seorang ahli pun bisa memilih untuk tidak memakai alat sama sekali dan justru menekan sisi lain, yakni menolak kebutuhan bisnis
    Situs web yang baru-baru ini saya buat adalah yang paling kompatibel di antara semua yang pernah saya buat. Saya tidak lagi memakai websocket, dan tidak bergantung pada cara JavaScript berbicara sedikit demi sedikit dengan server. Sekitar 80% produk tetap bisa dipakai meski JavaScript dimatikan sepenuhnya. Saya tidak mengerti bagaimana pilihan rekayasa seperti ini bisa disebut bukan solusi terhadap ketergantungan pada ekosistem tertutup
  • “ChatGPT dan model-model penerusnya dapat menjelajahi situs web biasa seperti manusia” tampaknya masih lebih merupakan klaim yang belum benar. Namun kalaupun memang bisa, itu menarik
    Model bahasa besar belajar dari teks, kode sumber, dan sebagainya, tetapi tanpa sesuatu yang layak disebut perangkat penalaran, saya ragu mereka benar-benar bisa melihat pohon DOM dan mengetahui apa itu serta apa fungsinya. DOM bukan teks, dan karena merupakan hasil bundling atau komponenisasi, sulit juga menyebutnya kode sumber yang terstruktur dengan baik. Kedengarannya hampir seperti mengatakan “model bahasa besar bisa melihat .exe sembarang dan langsung mengintegrasikannya”
  • Saya membaca maksud tulisan ini sebagai ajakan memakai konten semantik yang dapat dibaca mesin di atas HTTP, alih-alih, atau selain, tumpukan div khusus JavaScript. Dengan begitu agen otomatis seperti gelombang baru model bahasa besar dapat lebih mudah mengekstrak detail penting tanpa harus menyalakan browser headless untuk merender halaman
    Saya juga punya minat serupa, tetapi tujuannya crawling dan mesin pencari baru. Jika setiap halaman harus dijalankan di browser headless sebelum diindeks, hambatan masuk bagi mesin pencari baru menjadi jauh lebih tinggi
  • Poin yang valid. Ironisnya, keunggulan utama markup semantik kini tampaknya telah menjadi abstraksi yang memudahkan pengembang manusia melakukan styling dan kontrol
  • Apakah ChatGPT benar-benar bisa melakukan itu? Apakah praktiknya memang begitu?

• Kalimat pertama tulisan itu adalah “dengan munculnya kecerdasan buatan berbasis model bahasa besar, HTML semantik menjadi lebih penting dari sebelumnya”, tetapi menurut saya kalimat yang jauh lebih bisa dipertahankan justru “dengan munculnya kecerdasan buatan berbasis model bahasa besar, HTML semantik menjadi kurang penting dari sebelumnya”
  Web semantik gagal, dan posisinya digantikan oleh cara Google menggelontorkan uang sangat besar untuk berbagai heuristik yang dipasangi kecerdasan buatan terbaik pada masanya. Semakin baik kecerdasan buatan, semakin tinggi kemampuannya mengekstrak informasi bahkan dari campur aduk yang dibuat sembarangan; dan jika campur aduk seperti itu sudah cukup, upaya yang orang mau keluarkan juga hanya akan sampai di sana. Pada prinsipnya, pada akhirnya baik web semantik maupun tumpukan heuristik akan digantikan oleh kecerdasan buatan
  Penting juga bahwa istilah LLM hanya dipakai di awal lalu setelah itu diganti menjadi istilah umum AI. Model bahasa besar bukanlah seluruh kecerdasan buatan; ia hanya satu cabang yang sedang panas saat ini, dan bukan cabang panas terakhir. Tidak baik membuat proyeksi untuk puluhan tahun ke depan dengan mengasumsikan model bahasa besar sebagai jawaban akhir bagi kecerdasan buatan

  • Apakah maksudnya kecerdasan buatan juga akan menyelesaikan aksesibilitas web yang berbasis HTML semantik dan ARIA? Jika tidak, manusia tetap diperlukan untuk memastikan konten web dapat diakses, dan dalam hal itu HTML semantik tetap penting
  • Saya penasaran seperti apa optimasi mesin pencari setelah model bahasa besar
    Jika tujuannya adalah agar bagian-bagian konten yang relevan cukup terindeks dengan baik dan naik peringkat, bisa dibilang insentif untuk sepenuhnya mengadopsi HTML semantik memang kurang
    Jika tujuannya berubah dari “naik peringkat” menjadi “membuat model bahasa besar mengekstrak nuansa dan tekstur konten semaksimal mungkin”, insentif untuk memakai elemen-elemen tertentu dengan lebih baik bisa meningkat. Situs web yang melakukan itu dapat memiliki pengaruh lebih besar terhadap keluaran model bahasa besar
    Rasanya seperti perbedaan antara berbicara cukup keras agar terdengar, dan berbicara cukup jelas agar dipahami
  • Bukankah schema.org dan Wikidata/Wikipedia masih menopang sebagian besar hasil penelusuran kaya Google?
    Saya mendengar mereka mengumumkan halaman hasil baru yang menyertakan Bard, tetapi entah karena kebiasaan mengabaikan iklan atau karena belum tersedia di wilayah saya, rasanya saya belum melihatnya, jadi saya perlu mencari tahu
  • Kecerdasan buatan terasa seperti sihir. Saya selalu menganggap kemampuan pengenalan pola manusia cukup unik dan sulit direplikasi. Kita memakai kemampuan itu saat menelusuri campur aduk sebuah situs web dan mengekstrak data dengan cara apa pun
    Di kepala saya, saya lebih dekat dengan kubu web semantik, tetapi jika mesin bisa memahami campur aduk itu dengan cukup baik, benar juga pertanyaan: untuk apa repot-repot?
  • Proyek-proyek yang mencoba membuat sumber daya data lalu membuat kecerdasan buatan memakai sumber daya itu melewatkan inti persoalan. Kecerdasan buatan itu sendiri adalah sumber daya data
    Ada juga proyek-proyek yang berargumen bahwa graf pengetahuan atau aset data lain dapat membantu kecerdasan buatan mencari pengetahuan yang “benar”. Secara pribadi, saya pikir lebih baik mengembangkan cara agar kecerdasan buatan dapat membuat aset datanya sendiri. Bobot jaringan saraf juga termasuk salah satu aset semacam itu
    Masalah kebenaran tetap sangat sulit. Bagaimana kita bisa memberi tahu kecerdasan buatan bahwa suatu pengetahuan lebih dapat dipercaya daripada pengetahuan lain? Tentu saja manusia pun menghadapi masalah yang sama

• Sebagian besar elemen HTML ini hampir tidak pernah saya dengar, dan itu cukup disayangkan. Karena hal-hal seperti ini bisa sangat membantu mengakhiri ekosistem yang menganggap “semua hal membutuhkan JavaScript”
  Setidaknya JavaScript bisa dikembalikan ke tempat yang lebih dekat dengan tujuan awalnya: sebagai sarana untuk menambahkan sedikit hiasan atau interaksi. Ia tidak perlu menjadi pengganti semua markup sekaligus pengelola seluruh DOM
  Browser yang saya impikan mungkin berbentuk seperti visurf https://sr.ht/~sircmpwn/visurf/, dengan mesin Netsurf di dalamnya diperbarui agar mendukung HTML+CSS modern termasuk elemen-elemen ini. Dengan browser seperti itu, rasanya bisa dibuat web kecil yang hampir tanpa JavaScript. Aksesibilitasnya akan lebih baik karena lebih sedikit merusak screen reader, tema sistem, shortcut keyboard, dan sebagainya; memakai sumber daya jauh lebih sedikit dibanding perangkat JavaScript berat yang sebenarnya bisa diganti; dan tampaknya tetap memungkinkan sebagian besar hal yang diharapkan dari aplikasi web kelas menengah saat ini. Untuk hal seperti WebGL, tinggal buka Firefox, tetapi misalnya klien Matrix mungkin cukup memakai sedikit JavaScript hanya untuk websocket dan enkripsi end-to-end

  • Masalah umum komponen bawaan seperti ini adalah penerapan tema yang sulit. Kalau komponen bergaya Windows 7 tiba-tiba muncul di tengah aplikasi modern, itu sangat mengganggu
    Ekstensibilitasnya juga hampir tidak ada, jadi begitu perlu melakukan sesuatu yang sedikit saja kompleks, akhirnya harus ditinggalkan dan mulai lagi dengan JavaScript. Kalau begitu, lebih baik sejak awal memakai JavaScript; pendekatan itu bekerja dengan baik, memberi kendali penuh, dan berperilaku sama di semua sistem
    Pada akhirnya, komponen tambahan seperti ini menjadi bloat yang harus diimplementasikan semua browser tetapi tidak dipakai siapa pun
  • Saat pertama melihat datalist, saya berpikir, “wah, ini game changer.” Perilakunya sama di tiap browser, tetapi tampilannya sepenuhnya tergantung browser dan tidak bisa distyling dengan CSS
    Kadang hanya teks datanya yang terlihat, kadang teks dan atribut value terlihat bersama. Jadi yang dipilih bukan “Atlanta”, melainkan “234290780 Atlanta”, yaitu ID dan nilai sekaligus
    Dalam perilaku klik pun ID tidak bisa langsung didapat; harus mengambil keseluruhannya lalu mem-parse ID. Rasanya seperti elemen yang dibiarkan terbengkalai
  • Mungkin Anda akan suka ini: http://youmightnotneedjs.com/
  • Saya tidak menentang keseluruhan gagasannya, tetapi elemen-elemen ini sudah ada sejak lama. Agar kritik terhadap HTML bisa dianggap serius, menurut saya hal-hal dasar perlu diketahui
    Tulisan itu menautkan ke MDN, dan MDN termasuk yang paling berguna sebagai referensi singkat. Tentu ada juga spesifikasi HTML WHATWG, dan kalau itu terlalu besar, ada sintaks format SGML DTD untuk snapshot WHATWG HTML 2021·2023 serta sintaks lama lini HTML 5.x
    [1]: https://sgmljs.net/docs/html200129.html
  • https://qutebrowser.org

• Saya ingin percaya pada web semantik, dan ingin percaya bahwa browser bisa menyediakan modul dasar yang baik serta style bawaan yang lumayan, tetapi saat ini mau tidak mau harus menerima bahwa kenyataannya belum begitu
  Bahkan untuk memberi label pada input, kita harus mulai dengan bertanya kenapa itu bukan atribut, lalu tidak yakin apakah harus dipakai sebagai wrapper atau sebagai saudara dengan atribut for=. Ini baru puncak gunung es. Untuk tiap tag, kita harus mempelajari seluruh riwayat pengembangannya dan meneliti lagi cara yang benar saat ini
  Kita sebenarnya bisa saja memiliki sesuatu yang bagus, tetapi sepertinya sekarang saatnya menenangkan diri dan melepaskannya

  • Saya tidak tahu alat apa yang Anda pakai, jadi ini bukan ditujukan kepada orang tertentu, tetapi kalau para developer web memakai sebagian saja dari waktu yang mereka habiskan untuk mempelajari React, Tailwind, dan sebagainya untuk mempelajari HTML, kondisi web akan jauh lebih baik
    Memang ada bagian-bagian aneh dan sisi-sisi kasar, tetapi jika semua developer web tahu cara memanfaatkan HTML semantik semaksimal mungkin, kemungkinan JavaScript di browser akan jauh lebih sedikit, bug aksesibilitas berkurang, dan lebih banyak mata akan memperhatikan spesifikasi ketika keanehan-keanehan seperti ini perlu diperbaiki atau diganti
  • Jika label input berupa atribut HTML, form akan jauh kurang fleksibel. Dua elemen visual akan digabung menjadi satu, sehingga pengaturan tampilannya sulit. Misalnya, bayangkan input dengan label rata kanan di sebelah kiri, atau checkbox dengan label di sebelah kanan
    Atribut label kemungkinan berarti konten teks polos, dan itu terasa terlalu membatasi
    HTML, seperti sesuatu yang sudah dipakai selama puluhan tahun, memiliki sejarah kompleks dan banyak lapisan. Meski begitu, belakangan ini tidak banyak berubah, dan berkat MDN cukup mudah mempelajari apa yang bisa dilakukan dengan HTML5 serta mendalaminya bila perlu
  • Dalam kasus saya, hampir selalu saya ingin menaruh tag label setelah tag input. Dengan begitu, lewat pseudo-class CSS, saya bisa memilih dan menata label berdasarkan status input
  • Keharusan mempelajari makna tiap tag adalah bagian mendasar dari sistem tagging semantik mana pun. Jika tidak suka gagasan itu, berarti secara fundamental tidak cocok dengan ide web semantik itu sendiri
    Tentu saja, untuk menggunakan sistem penerbitan apa pun—bahkan sistem apa pun—secara efektif, kita harus mempelajari cara memakai elemen-elemen dasar yang disediakannya. Jadi ini bukan masalah khusus web semantik saja

• Saya sering memakai details untuk debugging template HTML Go
  Jika data dimasukkan saat mode pengembangan dengan {{if .DevMode}}, ketika terlipat elemen itu tidak terlalu merusak halaman sehingga tidak terlalu mencolok, dan saat dibutuhkan bisa dibuka untuk melihat seluruh isinya

  • Kalau memungkinkan, saya cukup sering menyalahgunakan elemen details. Sangat rapi, tapi entah kenapa tidak lebih banyak dipakai
  • Bisa dipakai untuk berbagai hal seperti menu yang bisa dilipat di halaman web
    Di GitHub Markdown juga bisa dipakai, dan ada orang yang menggunakannya untuk contoh atau penjelasan inline

• Bacaan dan demo interaktifnya bagus
  Setelah beberapa tahun mengutak-atik Flutter, aku kembali sampai pada kesimpulan yang sama. Kita harus bertaruh pada HTML
  Kombinasi Astro / Tailwind / Daisy UI / Alpine.js cocok untuk membuat situs HTML yang banyak memakai rendering sisi server sederhana dan menaburkan sedikit reaktivitas di sisi klien
  Hasil akhirnya adalah file HTML yang sederhana dan baik-baik saja, terlihat bagus dan bekerja baik di browser web desktop maupun WebView mobile yang dibungkus. Aplikasiku pada dasarnya statis, jadi bisa di-cache di CDN, berjalan offline, dan view source membuat debugging jadi mudah

  • Setelah mencoba berbagai framework dan platform yang gemerlap, akhirnya aku juga beralih ke situs statis yang memakai Alpine.js dan Tailwind. Sejauh ini itu jelas keputusan terbaik yang pernah kuambil
    Hal terbaiknya adalah aku bisa yakin developer baru, entah orang React, Angular, PHP, atau Python, akan memahaminya setelah melihat file build 100 baris selama kira-kira 3 menit. Sungguh bagus karena sangat sederhana
  • Menurutku ekspor web dengan Flutter hampir seperti mimpi buruk. Terakhir kali aku cek, rendering terjadi di canvas, dan sama sekali tidak ada markup
  • Bisa bantu aku memahami kegunaan Daisy UI? Kelihatannya seperti memakai kelas+stylesheet gaya lama lewat satu langkah tambahan bernama Tailwind
  • Benar, Astro dan arsitektur island benar-benar menyenangkan untuk dikerjakan

• Menurutku masalah semantic web adalah, semudah apa pun dibuat, developer tetap menolak menggunakannya dengan benar. Ekstensi browser-ku memakai tag main, jadi aku cukup memperhatikan tag ini, dan dokumentasi MDN sangat jelas soal apa yang harus dilakukan serta dokumennya sendiri menunjukkan contoh penggunaan yang baik. Namun sangat sedikit situs yang menggunakannya dengan benar
  Bahkan situs profesional yang mewah pun sering membungkus seluruh konten halaman, termasuk navigasi dan footer, di dalam tag main. Tag ini seharusnya hanya dipakai untuk konten utama halaman
  Kalau elemen sesederhana ini saja tidak bisa dipakai dengan benar, aku tidak terlalu berharap pada elemen lainnya

  • Ini satu golongan dengan developer yang salah memakai verba HTTP
    Hal-hal seperti ini tidak boleh pura-pura menjadi kontrak
  • Developer yang memakai tag p untuk paragraf secara harfiah semuanya memakainya dengan benar. Itu berbeda dari hal seperti class="card"
    Aku tidak mengerti kenapa begitu banyak orang yang sangat paham teknologi meratapi ketidakbergunaan semantic web atau kegagalannya seperti ini. Kedengarannya seperti berkata, “Semoga mobil berhasil, perjalanan jarak jauh akan jadi mudah”
  • Solusi pertama yang terlintas adalah validasi yang lebih ketat. Misalnya browser menolak merender jika strukturnya tidak benar
    Tapi masa seperti itu pernah ada. Hal-hal sebelum HTML4 pada umumnya begitu, dan itu lebih buruk
    Jadi mungkin lebih baik kalau developer tools memberi peringatan atau error saat ada penggunaan yang salah
  • Tidak ada insentif sama sekali untuk menggunakannya dengan benar. Aku sendiri berusaha melakukannya dengan benar, tetapi selain waktu yang kuhabiskan untuk memutuskan setiap elemen seharusnya apa, tidak ada bedanya sama sekali

• Menarik bahwa banyak komentar di sini melihat tulisan ini sebagai tulisan anti-JavaScript. Bagiku justru ini terlihat seperti alat-alat yang akan sangat berguna bila dipakai bersama framework berbasis TypeScript yang kita gunakan di frontend aplikasi enterprise modern. Karena ini alat native HTML, jadi tidak menuntut banyak macam hal
  Misalnya, tag meter sepertinya akan menggantikan semua modul loading yang kami pakai di React begitu aku masuk kerja hari ini. Karena itu jauh lebih baik daripada yang kami pakai sekarang
  Mungkin aku salah memahami orang-orang atau salah membaca tulisannya, tetapi bahkan ketika hampir seluruh frontend berupa TypeScript seperti pada aplikasi besar masa kini, ini tetap sangat menarik

  • Harapanku adalah hal-hal seperti ini menggantikan gumpalan besar kode JavaScript. Aku tahu web tanpa JavaScript sayangnya cuma fantasi, tetapi setidaknya kita bisa menyingkirkan gumpalan besar dan menciptakan pengalaman pengguna yang lebih standar, yang bisa dipandu dan dibentuk oleh sistem
    Ada aplikasi-aplikasi baru yang bisa dibuat dengan JavaScript jauh lebih sedikit dibanding sebelumnya. Pada aplikasi TypeScript enterprise yang sudah ada, ini mungkin bisa menjadi upgrade di tempat, tetapi harapannya adalah dalam pengembangan aplikasi baru kita bisa menghindari framework enterprise semacam itu sendiri. Boleh bermimpi, kan?

• Saya tidak ingin sepenuhnya merendahkan pengembangan web, tetapi memang benar-benar mengerikan. Saya sudah melakukannya selama bertahun-tahun, dari HTML mentah sampai bahasa skrip dan framework, dan waktu yang dibutuhkan untuk melakukan hal-hal sepele terasa seperti pemborosan otak yang luar biasa
  Saat pergi berlibur, saya hanya ingin mencari tempat makan dan minum atau tempat untuk mampir sehari, tetapi sebagian besar situsnya berantakan, usang, atau tidak diperbarui. Masih banyak situs yang dibuat sekali lalu dilupakan. Sepertinya karena anggarannya ketat sehingga tidak mampu memperbarui, atau karena memperbaruinya secara teknis terlalu sulit
  Kompleksitas situs membuat orang lumpuh. Sesuatu yang cukup berupa beberapa halaman teks dan gambar sederhana malah direkayasa berlebihan tanpa perlu dan membakar siklus CPU dalam jumlah besar. Besar kemungkinan juga dibuat dengan mengutak-atik CMS siap pakai yang butuh pembaruan keamanan
  Baru-baru ini saya melihat situs bioskop, dan bahkan sekadar menelusuri beberapa film yang diputar minggu itu saja hampir mustahil. Saya merasa akan lebih mudah dibaca jika dimasukkan ke spreadsheet, dan ketika benar-benar mengunduh JSON dari API-nya, itu memang lebih mudah dibaca
  Kebanyakan hanyalah kemasan melelahkan seperti memoles babi dengan lipstik. Salah satu alasan Facebook berhasil adalah onboarding yang mudah, dan alasan lain adalah mudahnya berbagi foto. WhatsApp dan Instagram juga sama. Publikasi harus mudah. FTP sederhana pun sebenarnya mudah, tetapi bagi orang biasa ada semacam keterputusan aneh dalam alur penggunaannya. Orang menginginkan drag-and-drop, unggah, tinggalkan dan lupakan, serta penyuntingan yang mudah. Orang yang ingin mengonsumsi data pada akhirnya hanya menginginkan intinya. Yaitu datanya

  • Saya tidak berpikir orang yang ingin mengonsumsi data hanya menginginkan data inti. Pembaca HN rata-rata mungkin begitu, tetapi orang rata-rata tidak
    Yang diinginkan orang adalah halaman web yang ditata dengan baik dan bisa digunakan. Masalahnya adalah tidak cukup banyak desainer pengalaman pengguna yang efektif dan berbakat, dan para pemangku kepentingan perusahaan juga kurang memiliki selera UX yang layak
    Karena itu, menyediakan data inti saja akhirnya menjadi situasi yang lebih baik bagi pengguna rata-rata dibanding UX buruk yang mampu dibuat perusahaan rata-rata. Meski bukan yang disukai, itu tetap lebih baik
    {UX buruk} << {data mentah} < {UX baik}
    Jalan pintas yang ditemukan WordPress adalah membuat gaya dan tema profesional lalu membiarkan pengguna membelinya dan menerapkannya. Namun itu tetap tidak bisa mengatasi selera buruk para pemangku kepentingan
    Saya pikir Facebook berhasil karena memaksakan UX yang profesional dan terstandardisasi. {data orang-orang} + {UX profesional dan terstandardisasi} = {kemenangan}. Anda boleh saja tidak menyukai UX awal Facebook, tetapi sulit mengatakan itu pekerjaan tingkat amatir. Persepsi umum terhadap MySpace atau Geocities dan sejenisnya justru sebaliknya
  • Bagian yang menyebut WhatsApp tepat mengenai sasaran. Di negara Afrika tempat saya berada, WhatsApp begitu populer sampai operator seluler bahkan menjual paket data WhatsApp
    Kalau ingin mencari sesuatu seperti kawat kasa, saya mulai dengan bertanya di grup WhatsApp tempat saya bergabung, grup keluarga, lingkungan, atau teman SMA. Biasanya saya mendapat beberapa nomor, lalu menghubungi penyedia layanan lewat WhatsApp untuk mendapatkan informasi terbaru
    Para penyedia layanan itu tidak mampu mengelola situs web yang mutakhir. WhatsApp juga punya fitur untuk menaruh katalog di profil, dan itu untuk akun bisnis gratis
  • Karena itu, untuk sebagian besar usaha kecil, saya merekomendasikan Wix. Apakah semua situsnya terlihat mirip? Ya, dan itu tidak selalu buruk. Karena mudah digunakan dan diperbarui, pelanggan menghargai bahwa mereka bisa mendapatkan informasi terbaru yang mereka butuhkan
    Yang ingin saya lihat adalah sesuatu seperti “Wix Widgets”. Widget terhubung data dengan kustomisasi sebatas menghubungkan pemanggilan layanan REST dan memetakan titik data ke tampilan widget. Ini akan cukup membantu menangani kebutuhan situs web internal yang sekarang ada di semua perusahaan
    Untuk 90–95% halaman web, yang benar-benar dibutuhkan adalah solusi sederhana
  • Lucu juga ketika kita mendengar bahwa platform web adalah sistem GUI lintas platform yang paling baik dan konsisten, tetapi membangun sesuatu di atas sistem itu justru mengerikan
    Saya jadi bertanya-tanya apakah mungkin inilah hakikat GUI. Semua instruksi harus diberikan satu per satu, memakan banyak siklus, dan jika tidak begitu, strukturnya tidak akan berjalan lintas platform
  • Sebagian masalah ini ada pada tag dan elemen di dalam file HTML yang terus bertambah. Ia sudah menjadi markup halaman, bukan markup dokumen, dan sulit membedakan di mana yang satu berakhir dan yang lain dimulai. Memang W3C sempat mencoba dengan menambahkan elemen article dan section
    Tentu saja, kode HTML mentah sejak awal mungkin memang tidak dibuat untuk dibaca oleh siapa pun selain developer, jadi ada sisi itu juga

• Saya sangat antusias mendengar bahwa modal HTML murni sudah ada, tetapi kecewa ketika tahu tidak ada cara untuk memicunya tanpa JavaScript. Dengan HTML murni, modal hanya bisa ditutup, tidak bisa dibuka
  https://github.com/whatwg/html/issues/3567
  Elemen dialog adalah tambahan yang bagus dan saya senang sedang diimplementasikan, tetapi sebagian fitur intinya bergantung pada JavaScript. Untuk membuka dialog, atribut open harus disetel dengan JavaScript
  Akan bagus jika elemen button atau a punya cara untuk membuka kotak dialog. Preseden untuk interaksi halaman yang tertanam di HTML sudah ada. Misalnya, tautan bisa menggulir halaman, dan elemen details bisa menyembunyikan elemen di balik interaksi, jadi rasanya wajar jika elemen halaman lain juga bisa membuka dialog

  • Saya kurang yakin jika tujuan mulia “hanya HTML” berarti kemampuan scripting harus diperluas ke HTML. Kalau begitu, menurut saya lebih baik langsung pakai JavaScript saja
  • Modal bisa dibuat hanya dengan HTML dan CSS, tanpa JavaScript
    Misalnya, coba klik ? di kanan atas di sini: https://aavi.xyz/proj/colors/
  • Memang akan bagus jika tertanam langsung di HTML, tetapi setidaknya JavaScript yang dibutuhkan tidak rumit dan bisa juga dimasukkan ke atribut onclick
  • Bisa dibuat tampil atau tersembunyi berdasarkan hash saat ini. Tentu saja, cara itu memang membutuhkan CSS