Tentang melakukan fork pada Web

• Tujuan spesifikasi alternatif bukanlah seluruh Web, melainkan memprioritaskan spesifikasi HTML yang per 6 Mei 2026 berukuran 18.3MiB setelah diekstrak, dengan sasaran mempertahankan kelebihan Web dan menghindari kekurangannya
• Spesifikasi harus singkat dan sederhana, serta menurunkan beban implementasi—misalnya dengan membatasi tar.gz terkompresi yang memuat seluruh spesifikasi hingga 1.44MiB—agar berbagai browser dan klien bisa bermunculan
• Alih-alih menjadi dokumen yang terus berubah seperti Web specification saat ini, spesifikasi harus memiliki versi semantik seperti 1.2.3, dan versi standar yang telah dipublikasikan tidak boleh diubah sama sekali
• Spesifikasi harus mencakup tata bahasa formal yang tidak ambigu dan mudah di-parse, serta halaman yang tidak mematuhi standar tidak boleh dirender, sehingga biaya pembuatan parser dan alat konten bisa ditekan
• Spesifikasi alternatif tidak bertujuan menyalin Web fitur demi fitur, melainkan menargetkan pertukaran informasi yang berpusat pada teks tertulis; alih-alih scripting, pendekatan yang lebih disukai adalah membuka file atau URL yang distandardisasi di program native, seperti standar Geo link atau tiled web map

---

Tujuan spesifikasi alternatif untuk Web

• Spesifikasi HTML per 6 Mei 2026 berukuran 18.3MiB setelah diekstrak, dan objek tinjauan utama dibatasi pada spesifikasi HTML, bukan seluruh Web
• Tujuannya adalah membuat spesifikasi alternatif yang sebisa mungkin mempertahankan kelebihan Web sambil menghindari kekurangannya
• Ini belum merupakan spesifikasi resmi, melainkan lebih mirip catatan informal yang bisa berubah seiring waktu

Kesederhanaan dan keberagaman implementasi

• Seluruh spesifikasi harus singkat dan sederhana, serta memungkinkan pembuatan berbagai browser dan klien dengan usaha yang rendah
• Karena sangat sulit mempertahankan kesederhanaan selama puluhan tahun, salah satu caranya adalah menerapkan aturan yang membatasi panjang spesifikasi pada tingkat byte
• Dillo menggunakan pendekatan yang sama agar rilisnya muat dalam satu floppy disk, dan spesifikasi alternatif juga dapat menetapkan batas 1.44MiB berdasarkan tar.gz terkompresi yang memuat seluruh spesifikasi

Manajemen versi semantik

• Web specification saat ini adalah halaman yang berubah kira-kira setiap minggu, sehingga klien harus terus mengikuti perubahan agar tetap mematuhi spesifikasi
• Spesifikasi alternatif harus memiliki versi semantik yang jelas seperti 1.2.3
• Diperlukan kriteria kompatibilitas seperti: dokumen 1.2.3 dapat dirender dengan benar di browser yang mendukung 1.2.3, 1.2.0, atau 1.3.0, tetapi tidak di browser yang hanya mendukung 1.1.0 atau 2.0.0
• Target penulisan dokumen haruslah versi standar, bukan status implementasi tiap browser; misalnya, dengan asumsi 90% browser mendukung standar 1.2.0, penulis dapat menargetkan versi tersebut
• Versi standar yang sudah dipublikasikan tidak boleh diubah sama sekali
  • Perbaikan typo ditangani dengan kenaikan versi patch
  • Fitur baru yang kompatibel ke belakang ditangani dengan kenaikan versi minor
  • Perubahan yang merusak kompatibilitas memerlukan kenaikan versi major
• Bahkan jika hanya ada salinan cetak standar 1.2.0, seharusnya tetap memungkinkan membuat browser yang sepenuhnya patuh di lingkungan terisolasi, dan browser itu harus dapat mem-parse dokumen 1.2.X dengan benar secara permanen

Tata bahasa yang ketat

• Spesifikasi harus mencakup tata bahasa formal yang tidak ambigu dan mudah di-parse
• Halaman harus diuji terhadap standar untuk menentukan kepatuhannya, dan halaman yang tidak patuh tidak boleh dirender
• Klien secara eksplisit dilarang menerima halaman yang tidak mengikuti spesifikasi
• Ini menghilangkan kebutuhan untuk mengimplementasikan aturan standardisasi yang rumit demi memperbaiki halaman rusak, dan memaksa kesalahan dalam spesifikasi untuk diperbaiki pada versi berikutnya
• Tata bahasa yang ketat kemungkinan akan mendorong peralihan ke bahasa yang lebih mudah ditulis manusia dan lebih permisif, misalnya Markdown, dan ini memang merupakan efek yang diinginkan
• Tujuannya adalah menyederhanakan parser dan menurunkan biaya pembuatan alat untuk memanipulasi konten
• Perubahan versi patch hanya mengubah redaksi, sementara tata bahasanya tetap sama

Kemungkinan penggunaan ulang HTML

• Akan ideal jika bisa dibuat subset HTML yang dapat berjalan di perangkat lunak yang ada dengan usaha minimal
• Namun, hal itu mungkin tidak memungkinkan karena kompleksitas parsing HTML
• Karena membuat tata bahasa formal untuk dokumen XML pun tidaklah sederhana, perlu ditinjau apakah HTML/XML memang format yang cocok untuk parsing sederhana

Ketahanan terhadap penangkapan standar

• Salah satu masalah Web adalah ketika pihak dominan dapat menciptakan mekanisme ekstraksi keuntungan, muncul insentif untuk menangkap standar dan mengubahnya demi kepentingan sendiri
• Dalam Web, akibatnya kompleksitas standar dianggap tumbuh tak terkendali, hambatan masuk bagi browser baru meningkat, dan persaingan berkurang
• Ada beberapa gagasan awal untuk mencegah situasi ini, tetapi perlu kajian yang lebih hati-hati dari sudut pandang teori permainan

Prinsip mengutamakan teks

• Tujuan spesifikasi adalah menangani rincian yang cukup untuk menyampaikan informasi antarmanusia seperti buku cetak atau tulisan
• Teks tertulis harus diprioritaskan sebagai media paling serbaguna untuk mengodekan informasi
• Teks dapat diterjemahkan, dapat dibacakan oleh komputer, dan dapat disimpan dengan kebutuhan ruang penyimpanan yang kecil
• Dokumen harus dibungkus barisnya sesuai ukuran layar, sehingga dokumen yang sama dapat dibaca baik di layar kecil maupun besar

Mengecualikan scripting

• Menambahkan kemampuan scripting adalah sebuah kekeliruan, sehingga hal itu dapat dihindari dalam spesifikasi alternatif
• Ini bukan berarti membatasi penggunaan program interaktif oleh pengguna
• Misalnya, saat ini peta interaktif yang menampilkan lokasi titik minat dimuat di dalam browser dengan JavaScript, tetapi sebagai gantinya bisa disediakan Geo link agar lokasi tersebut dapat dibuka di klien mana pun yang mendukung protokol itu
• Demikian pula, jika ada spesifikasi terbuka, klien mana pun dapat menggunakan tile peta dari server, dan standar tiled web map diajukan sebagai contoh terkait
• Pendekatan membuka file atau URL yang distandardisasi di program native dapat dioptimalkan sesuai perangkat yang digunakan dan menghindari pendekatan seragam dari banyak halaman web interaktif

Bukan tujuan

• Tujuannya bukan mereplikasi Web fitur demi fitur
• Tujuannya adalah membuat spesifikasi yang memungkinkan manusia saling bertukar pengetahuan, catatan, dan informasi lain, sambil menghilangkan kebutuhan untuk menjalankan VM penuh hanya untuk membacanya

[GN⁺]

Opini di Lobste.rs

• Jadi, apakah ini berarti kita butuh aplikasi lagi untuk semuanya? Saya tidak setuju bahwa kemampuan scripting itu sendiri adalah sebuah kesalahan
  Menurut saya bagus bahwa web adalah platform serbaguna yang melampaui batas sistem operasi

  • Saya juga berpikir begitu. Katanya keuntungan membuka file atau URL terstandarisasi dengan program native adalah bisa dioptimalkan untuk perangkat dan menghindari pendekatan halaman web “satu untuk semua”, tetapi saya tidak ingin kembali ke masa ketika pengguna Linux dianggap warga kelas dua
    Masa ketika hanya Windows yang didukung dan kadang-kadang Mac saja yang ditambahkan
  • Ada banyak hal yang bisa dikeluhkan tentang web app, tetapi itu juga hampir satu-satunya cara untuk menghindari pajak Apple dan pajak Google di masa depan saat mendistribusikan aplikasi di platform mobile
    Dan karena situasi pengembangan desktop native juga tidak sederhana, saya sangat paham orang-orang yang memilih web app atau Electron di desktop
  • Kenapa semuanya harus jadi aplikasi? Spesifikasi ini juga tidak melarang menjalankan browser web biasa, dan web yang sekarang pun tidak akan hilang
  • Menurut saya titik yang benar-benar tepat adalah mencari sejauh mana kita bisa melangkah hanya dengan markup yang terstandarisasi
    Masalah web modern adalah terus-menerus menciptakan ulang konsep tanpa henti, dan banyak di antaranya seharusnya berupa markup deklaratif. Seharusnya JavaScript tidak perlu ikut campur dalam jalur penayangan situs web. Scripting seharusnya dipakai untuk pemrograman sisi klien yang spesifik, misalnya memproses dataset yang dikembalikan server, yakni hal-hal yang dulu dikerjakan di server tetapi kini dikerjakan di klien
  • Sebenarnya sekarang memang sudah ada aplikasi untuk semuanya. Hanya saja alih-alih menyebutnya aplikasi, kita menyebutnya URL atau nama domain
    Rasanya industri TI mendorong browser web menjadi mesin virtual de facto setelah jelas bahwa alternatif sandbox seperti Java dan Swing, atau Flash, sangat inferior sampai menyakitkan. Sekarang satu aplikasi tunggal, Google Chrome, berperan sebagai mesin virtual untuk sebagian besar komputasi umum pengguna, dan itu pun dimiliki serta dikembangkan oleh perusahaan monopoli kapitalisme pengawasan. Saya tidak tahu apakah ini benar-benar lebih aman, atau hanya karena zero-day nyata sekarang terlalu mahal sehingga tidak dipublikasikan
    Saya memang menganggap penambahan scripting adalah sebuah kesalahan. Setidaknya itu fitur yang ditambahkan belakangan, dan saya setuju dengan Dillo yang membatasi cakupan pembaca dokumen hiperteks pada membaca dokumen, bukan berusaha membuat penulisan dan penyuntingan dokumen juga bisa dilakukan di dalam pembacanya
    Tujuannya bukan menyalin ulang web berdasarkan fungsi, melainkan membuat spesifikasi yang bisa dibaca untuk bertukar pengetahuan, catatan, dan informasi tanpa menuntut menjalankan mesin virtual ukuran penuh
    Saya ingin melihat aplikasi serbaguna yang diperkecil dan berada dalam sandbox yang lebih baik untuk menangani sebagian besar kebutuhan “interaksi”. Apakah benar-benar perlu seluruh mesin virtual hanya untuk bertukar hiperteks di feed media sosial seperti Reddit? Apakah seluruh mesin virtual juga diperlukan untuk menangani keranjang belanja dan informasi pembayaran?
    Hanya saja kemungkinan besar “serbaguna” pada akhirnya akan menelan “aplikasi”, dan pada titik itu kita akan menemukan kembali web. Meski begitu, kalau ada peluang membangunnya di atas pihak selain Google dan bahasa selain C++, mungkin itu tetap lebih baik. Dillo tampaknya memakai C dan C++, jadi mungkin setidaknya satu dari dua hal itu sudah sedikit lebih baik

• Hal lain yang akan bagus untuk ditingkatkan adalah memakai versi ringkas HTTP, tetapi cookie hanya didukung sebagai session cookie yang dikendalikan klien, melarang resource pihak ketiga, dan mewajibkan semua resource berada di server web yang sama dengan dokumen, serta mewajibkan perenderan format seperti text/markdown melalui konverter internal browser

  • Melarang resource pihak ketiga saja sudah bisa mencegah banyak masalah serius
  • Idealnya saya ingin ini dibuat independen dari cara transportnya. Mungkin awalnya akan dicoba secara lokal dulu agar bisa berjalan dari titik mount filesystem jarak jauh mana pun
    Kali ini saya berpikir kita sebaiknya memperbaiki pola makannya dan melihat apakah cookie bisa dihindari. Ini adalah representasi mesin dari dokumen, dirancang agar bisa dibaca manusia, tetapi bukan untuk langsung ditulis manusia. Sebagai gantinya, lebih baik memakai bahasa frontend seperti Markdown lalu mengompilasikannya menjadi dokumen ketat yang portabel
  • Kalau boleh usul, bila cookie memang diperlukan maka itu harus berlaku hanya untuk domain situs tersebut. Cookie dari example.net tidak boleh dikirim ke sub.example.net, dan cookie dari sub.example.net juga tidak boleh bisa diatur di example.net
    HTTP/2 dan HTTP/3 sebaiknya dibiarkan untuk web aplikasi, dan HTTP/1 dibiarkan untuk web dokumen. Saya tidak tahu bagaimana JavaScript harus dibatasi agar masalah “untuk melihat konten saya Anda perlu browser khusus” bisa dihindari, jadi menurut saya JavaScript sebaiknya tidak ada
    Kalau mewajibkan perenderan text/markdown, pertanyaannya juga versi yang mana. Ada kira-kira setengah lusin varian yang harus didukung

• Sintaks yang ketat kemungkinan tidak akan berhasil. Itulah juga alasan XHTML gagal, dan alasan HTML5 menambahkan aturan untuk menangani “kerusakan” yang umum
  Mungkin saja HTML5 bisa dispesifikasikan ulang dengan tata bahasa yang lebih formal seperti yang diinginkan penulis, tetapi menolak halaman secara ketat tampaknya bukan pemanfaatan fork yang baik. Alternatif lainnya adalah menjadi sekadar pengganti gopher/gemini lagi, dan ada alasan kenapa itu tidak populer walau punya basis penggemar fanatik. Kekuatan kompatibilitas mundur terlalu besar

  • Saya tidak setuju bahwa XHTML gagal karena terlalu ketat. Penyebabnya adalah IE tidak mendukung XHTML sampai 2011, terlalu terlambat, sehingga orang-orang tidak benar-benar memakai XHTML dan tidak pernah mendapatkan manfaatnya
    Keketatan bisa sangat bagus, tetapi harus ada dukungan agar itu bekerja

• Gagasan bahwa “menambahkan kemampuan script adalah sebuah kesalahan” memang sudah lama jadi meme di kalangan tipe programmer muram yang tidak membiarkan adanya kesenangan, tetapi menurut saya itu lebih dekat ke kurangnya imajinasi
  Multimedia interaktif yang diterapkan dengan hati-hati bisa sangat meningkatkan komunikasi dan penjelasan. Lihat saja misalnya diagram interaktif di tutorial Hex-Grid Red Blob Games atau penjelasan fantastis Bartosz Ciechanowski tentang mekanisme jam tangan. Berkat media interaktif di web, komputer langka yang penting secara historis seperti Canon Cat pun bisa dicoba hanya beberapa detik setelah mengklik tautan, tanpa prosedur mimpi buruk mengompilasi dan menjalankan emulator native. Pengiriman formulir dan image map hanyalah bayangan sangat samar dari multimedia, dan secara inheren memindahkan beban dukungan interaksi ke model yang berpusat pada server dan berpotensi boros bandwidth
  Masalahnya bukan perilaku scripting itu sendiri, melainkan hal-hal yang saat ini diizinkan untuk dilakukan script di browser. Sama seperti HTTP dan HTML bisa dipangkas menjadi sistem yang lebih kecil, lebih sederhana, dan lebih menghormati otonomi pengguna, sebagian besar sisi positif JavaScript web juga bisa dipertahankan sambil sangat mengurangi luas permukaan API dan potensi penyalahgunaannya. Misalnya, bisa dibayangkan web dengan sebuah kotak interaktif seperti Flash di dalam halaman, dengan interaksinya disediakan melalui skrip Lua yang bisa diakses dan diperiksa pengguna serta kemampuan grafis dan input seperti Love2D, sementara tindakan invasif terhadap privasi seperti menghubungi server jarak jauh atau mengakses webcam ditempatkan di balik sandbox yang kuat dan persetujuan eksplisit pengguna sebelumnya
  Aplikasi web yang menghormati pengguna seperti itu sebenarnya masih bisa dibuat hari ini, tetapi fondasinya bergelombang dan tidak konsisten, dengan kekurangan jelas pada fitur berguna serta ancaman yang tidak perlu terhadap keselamatan dan privasi pengguna di mana-mana
  Dari sudut pandang aksesibilitas, saya bisa membayangkan penanganan ketat atas input UI deklaratif seperti tombol, field, checkbox, dan slider, lalu merender gambar dan markup seperti halaman statis di dalam <iframe>, tetapi dengan form sisi klien yang bekerja tanpa bolak-balik ke server jarak jauh. Berbagai kalkulator, alat, dan visualisasi interaktif bisa masuk ke model seperti ini, dengan latensi dan keamanan pengguna yang lebih baik daripada model yang digerakkan backend

• Jika “mengutamakan teks”, maka CSS juga harus ditinggalkan. CSS pada umumnya ada untuk perusahaan, bukan untuk pengguna. Gaya harus dikendalikan browser, bukan halaman
  Jika pengguna memilih membaca payload mentah suatu halaman, maka sebagian besar isinya seharusnya sama dengan informasi yang ditampilkan browser untuk dibaca. Konten yang dapat dibaca saat ini hanyalah puncak gunung es
  Soal “tanpa scripting”, saya menduga bahwa jika gaya dan halaman yang gemuk dihapus, kebutuhan akan scripting yang memengaruhi cara penayangan juga bisa banyak berkurang. Scripting yang tidak memengaruhi cara penayangan pada umumnya justru dipakai bertentangan dengan kepentingan pengguna

  • Itulah sebenarnya inti awal dari CSS cascade. Ada subset CSS yang masuk akal untuk dipakai dalam tata letak buku dan makalah, dan itu dirancang agar bisa digabungkan dengan style pengguna
    Namun CSS dan pemformatan menjadi terlalu kompleks, dan style pengguna sekarang harus dimulai dari reset CSS penuh atau sangat spesifik per situs
  • Jika Anda ingin menampilkan timestamp sesuai zona waktu pembaca, saat ini tidak ada cara melakukannya tanpa scripting sisi klien
    Saya menemui masalah ini saat membuat alat pribadi tanpa JS di klien, dan menyadari bahwa saya harus menaruh “pengaturan zona waktu saya” di server atau menambahkan skrip bantu kecil
    Jika style dikendalikan browser, tampaknya masalah seperti “halaman saya terbaca dengan baik di browser X dan Y tetapi tidak di Z” bisa jadi lebih buruk daripada sekarang
  • Saya akan tetap hidup bahagia di dunia yang penuh CSS, warna dan latar belakang mencolok, font yang bagus, serta layout flexbox dan grid
    Menurut saya itu lebih baik daripada hanya melihat dokumen hambar yang menghapus suara penulis menjadi teks hitam di atas latar putih. CSS adalah cara penulis berekspresi di web, dan saya benar-benar tidak ingin itu dihilangkan. Memang rumit, tetapi justru itu hal yang baik karena memungkinkan lebih banyak orang melakukan hal-hal menarik di situs web mereka sendiri
  • Setuju. Kita perlu riset lebih jauh sebelum melarang style penulis yang opsional
    Saya juga punya intuisi serupa bahwa jika style dan halaman gemuk dihilangkan, kebutuhan script untuk mengubah tampilan akan berkurang. Jika ada sintaks sederhana, mungkin “dokumen” bisa di-embed ke dalam program native interaktif, bukan sebaliknya

• Seperti kata orang lain, menurut saya Gemini adalah contoh yang baik untuk dijadikan acuan. Sekali lagi, Gemini terasa seperti performance art, tetapi benar-benar banyak yang bisa dipelajari
  Satu fitur menarik di Gemini yang kurang dikenal adalah halaman yang bisa dilanggani. Di dalam halaman, tautan yang teksnya dimulai dengan YYYY-MM-DD membentuk feed implisit. Ini sangat terbatas dan tampak bodoh, tetapi menurut saya justru salah satu fitur Gemini yang paling mengesankan. Spec here
  Dalam HTML tradisional, menulis blog dengan tangan itu mungkin dilakukan. Membosankan, tetapi sepenuhnya bisa. Namun untuk memelihara feed RSS/ATOM, hampir pasti Anda memerlukan alat pembuat feed
  Untuk HTML “berorientasi konten” generasi berikutnya, akan bagus jika fitur serupa dimasukkan. Mungkin h-feed di microformats adalah cara yang tepat, tetapi saya sangat menyukai kesederhanaan halaman yang bisa dilanggani di Gemini. Dan feed yang ada di mana-mana itu hal yang baik
  Bahwa Gemini berbasis baris dan mudah diparse adalah keunggulan besar, tetapi saya merasa itu terlalu terbatas dan bisa berdampak buruk dari sisi aksesibilitas. Meski begitu, HTML-lite yang tampak seperti Gemini sepertinya akan baik-baik saja
  Keuntungan lain yang bisa didapat dari forking web adalah merapikan hal-hal tambahan yang ditempelkan ke HTML. <meta name="viewport" content="width=device-width, initial-scale=1.0"/> cukup mengganggu. Kalau dibuat versi baru berdasarkan apa yang kita tahu sekarang, kemungkinan hasilnya bisa cukup bagus
  Untuk bagian lain saya kurang yakin. Secara prinsip saya sepenuhnya mendukung tanpa JS. Hanya saja salah satu kegunaan terbaik web adalah akses universal ke layanan penting seperti pemerintah dan bank. Saya belum sepenuhnya yakin apakah semuanya benar-benar bisa dilakukan tanpa JS sambil tetap menjaga usability yang baik, meskipun mungkin saja bisa
  Saya juga ingin menekankan bagian dari komentar lain yang mengatakan “spesifikasi ini tidak melarang menjalankan browser web biasa, dan web yang sekarang pun tidak akan hilang”
  Akan bagus jika kita bisa menjalankan “browser web konten” dan “browser aplikasi” secara terpisah. Untuk banyak tujuan, tidak banyak alternatif yang sebagus web sebagai platform aplikasi, dan web sudah berkembang jauh, serta tampaknya para pengembang jauh lebih menyukainya daripada yang lain
  Di dunia seperti itu, Google Maps tidak akan berjalan di browser web konten saya dan akan terbuka di browser aplikasi. Jika saya menjalankan GMail di browser aplikasi, maka tautan di dalam email akan dibuka di browser web konten
  Browser web konten idealnya harus jauh lebih mudah diimplementasikan, dan itu akan mendorong kompetisi serta inovasi. Namun sayangnya saya tidak melihat jalur yang jelas untuk mewujudkannya. Saya akan jauh lebih bahagia bila bisa melakukan semua penelusuran konten dengan browser konten semacam itu. Permukaan serangannya akan jauh lebih kecil, jadi saya akan merasa lebih tenang dari sisi keamanan. Tetapi sekarang tampaknya tidak ada lagi yang peduli

  • Hampir semua use case JS yang sah di halaman web muncul karena browser kekurangan fitur penting. Selama puluhan tahun kita sudah belajar hal ini, dan berkat script browser tidak perlu repot menambahkan fitur-fitur itu
    Jadi tinggal tambahkan saja sebagai fitur browser

• Kedengarannya agak mirip Gemini, tetapi fork ini tampaknya akan mengizinkan lebih banyak hal
  Menurut saya situs web bisa ditulis dengan varian Markdown atau sesuatu yang mirip. Dokumennya harus mudah dibaca bahkan dalam bentuk mentah. Semacam Gemtext dengan sedikit tambahan seperti media inline
  Dan sebaiknya sedikit kemampuan styling juga diizinkan. Web dulu adalah tempat yang hebat untuk mengekspresikan kreativitas, dan sekarang pun masih begitu. Jika kita mempertahankan sekumpulan style yang sederhana dan konsisten, orang-orang kreatif bisa membuat situs yang lebih unik

• Akan bagus juga bila elemen dasar HTMX ikut ditangani

  • Secara pribadi, saya rasa cukup jika fitur primitif Triptych dibangun langsung. Itu memberi cukup banyak hal untuk dibangun di sisi server tanpa membuat klien jadi terlalu rumit

• Saya rasa ide ini akan bekerja lebih baik kalau ada motivasi yang jelas. “Mari kita buat lebih sederhana” terlalu abstrak. Karena setiap orang punya gagasan berbeda tentang kesederhanaan, perlu ada tujuan yang lebih eksplisit tentang mengapa web harus lebih sederhana dan kebutuhan konkret apa yang ingin dipenuhi
  Misalnya, proyek Gemini berfokus membangun komunitas yang mengutamakan bentuk komunikasi tertentu. Karena cocok dengan tujuan komunitas itu, web disederhanakan dengan membatasinya pada format komunikasi tersebut, dan kalau saya ingat bahkan gambar pun secara teknis tidak didukung
  Sebaliknya, alat seperti Sciter atau Blitz bertujuan mempermudah penyematan renderer mirip browser ke aplikasi lain. Mereka menyederhanakan dengan menghapus perilaku aneh yang tidak perlu atau menjadikan parsing HTML serta eksekusi JS sebagai opsi. Dengan begitu, implementasi yang perlu dibuat berkurang dan yang perlu di-embed pengguna juga berkurang
  Keduanya sama-sama menargetkan kesederhanaan, tetapi karena tujuan dasarnya sangat berbeda, hasil akhirnya juga sangat berbeda. Jadi, apa sebenarnya tujuan dasar di sini?