Rekayasa Web Browser (2021)

 (browser.engineering)
2 poin oleh GN⁺ 2024-10-16 | 1 komentar | Bagikan ke WhatsApp
  • Web Browser Engineering membahas dari networking hingga JavaScript, dan mengajak pembaca membuat sendiri web browser yang sederhana namun lengkap dengan ribuan baris Python
  • Alur pembelajaran bergerak dari pemuatan halaman ke penampilan dokumen, eksekusi aplikasi, hingga fitur browser modern, sambil menghubungkan HTTP, HTML, CSS, DOM, keamanan, dan rendering pipeline secara berurutan
  • Bagian awal berfokus pada implementasi dasar browser seperti URL dan permintaan HTTP, pembuatan jendela dan menggambar di kanvas, serta pembungkusan teks dan jarak antarbaris
  • Bagian tengah hingga akhir mencakup penyusunan pohon HTML, layout, penerapan style, pengiriman formulir, respons terhadap event, cookie dan login, hingga XSS dan CSRF
  • Bagian akhir berlanjut ke compositing, event loop, animasi GPU, accessibility tree, iframe, invalidation, dan ketepatan penyuntingan sehingga pembaca dapat meninjau elemen implementasi browser modern secara luas

Belajar struktur browser dengan mengimplementasikannya langsung

  • Web Browser Engineering disusun dengan pendekatan mengimplementasikan sendiri browser yang sederhana namun lengkap untuk memahami bagaimana web browser bekerja
  • Bahasa implementasinya adalah Python, dan skala keseluruhan implementasinya berada di kisaran ribuan baris
  • Cakupannya membentang dari networking hingga JavaScript
  • Buku fisik dapat dibeli di Bookshop, B&N, Amazon
  • Edisi terjemahan tersedia dalam edisi bahasa Korea di Hanbit dan edisi bahasa Jepang di O’Reilly
  • Pembaruan dapat dilihat di blog, Mastodon, Twitter, dan juga ada GitHub discussion forum

Alur daftar isi

Bacaan terkait

1 komentar

 
GN⁺ 2024-10-16
Opini Hacker News

  • Salah satu hal bagus dari buku ini adalah bagian yang secara terpisah membahas “hal-hal yang tidak dilakukan”
    Layout itu benar-benar sulit, dan bahkan hanya menangani tabel tanpa CSS pun sulit. Kalau CSS ikut masuk, layout menjadi sangat kompleks sampai hampir mustahil
    Saya ragu ada orang yang bisa menyimpan seluruh spesifikasi CSS dan perilaku terkaitnya di kepala. CSS+HTML+JavaScript saat ini sudah mendekati bahasa teknologi halaman dinamis (PDL), dan kemungkinan merupakan salah satu perangkat lunak paling kompleks saat ini
    Sebagai tambahan, decoding video kini di-offload ke hardware, jadi tidak menguras baterai sebanyak dulu

    • Untuk mengimplementasikan layout CSS tingkat produksi, dibutuhkan kode dalam jumlah sangat besar, dan source Servo memperlihatkan hal itu dengan baik
      Misalnya file ini hanya mengimplementasikan konteks block/inline; memang ada sedikit boilerplate Rust, tetapi sebagian besar adalah logika nyata yang menangani berbagai bagian spesifikasi. Ada satu folder penuh berisi file seperti ini: https://github.com/servo/servo/blob/main/components/layout/f...
      Meski begitu, mengimplementasikan layout engine itu mungkin. CSS bukan sihir; ada spesifikasi yang bisa dipindahkan ke kode dengan teliti. Menunjukkan kode seperti ini kepada orang yang frustrasi karena CSS tampak arbitrer bisa membantu mereka memahami bahwa lingkungan eksekusinya pun punya logika
      Tentu saja, kita tidak akan sering mengklik dan melihat-lihat seperti saat menelusuri implementasi library, tetapi dalam hal itu saya rasa tidak jauh berbeda dari sesuatu seperti React
    • Benar, layout itu sulit, dan tampaknya terutama karena dua alasan
      Pertama, bagian paling inti dari layout seperti CSS 2 dirancang cukup berantakan, dan fitur-fitur aneh saling berinteraksi dengan cara yang aneh. Contohnya float, clearance, dan margin collapsing. Sebagian inti ini dimaksudkan untuk dipakai secara universal di semua mode layout, tetapi tidak cocok untuk mode lain. Misalnya margin dan padding tidak punya tujuan yang jelas pada elemen grid
      Kedua, ia tidak termodularisasi dengan baik seperti JavaScript API. JavaScript API sering diimplementasikan secara independen, tetapi modul layout bisa bertumpuk dengan banyak cara, sehingga semuanya saling memengaruhi. Spesifikasi yang lebih baru seperti grid berusaha menjadi lebih ketat, tetapi ada tantangan mendasar bahwa beberapa mode layout harus berbagi sumber daya yang sama, yaitu layar 2D nyata
    • Layout terlalu sulit, sampai saya menghentikan proyek passion yang sedang saya buat dengan Common Lisp dan ncurses, lalu menjadi sosok yang dulu saya sumpahi untuk saya musnahkan: developer React
      Rasanya tidak mungkin hanya saya yang menginginkan bahasa layout yang lebih sederhana daripada CSS, tetapi tetap mencerminkan pelajaran dari 20 tahun terakhir dan memaksimalkan hasil kali kesederhanaan dan daya ekspresi. Saya penasaran apakah ada proyek yang serius merancang hal seperti ini, atau semua orang sudah menerima CSS3 lalu menunggu backend LLVM, atau sekadar kembali ke teks biasa
    • Di React Native, para engineer Facebook pada dasarnya menyerah dan berkata, “yang kami berikan kepada kalian hanya layout flexbox,” dan orang-orang cukup menerimanya. Tentu saja ada juga yang menggerutu karena tidak ada display grid
      https://github.com/facebook/yoga
    • Menara Babel ini suatu hari akan runtuh
      Layout tidak perlu serumit ini. Ada puluhan framework GUI dengan sistem layout yang lebih sederhana, dan itu sudah cukup untuk aplikasi yang dipakai orang

  • Kelihatannya keren. Sekitar 15 tahun lalu saya mulai membuat headless browser dan memeliharanya selama beberapa tahun
    Saya memakai SpiderMonkey sebagai interpreter JavaScript, dan mengimplementasikan DOM sendiri. Ia menjalankan JavaScript modern saat itu, AJAX, dan sebagainya, lalu kemudian saya juga menambahkan runtime Flash kustom. Proyek itu melakukan hampir semuanya kecuali menggambar ke layar, jadi sangat menyenangkan
    Saya benar-benar ingin membaca buku ini

    • Penasaran library apa yang rencananya akan dipakai untuk menggambar ke layar

  • Senang melihat engineering browser kini tampaknya menjadi tren
    Ekosistemnya sebenarnya cukup miskin, karena praktis hanya didefinisikan oleh Google, Apple, dan Mozilla. Ke depannya saya ingin melihat masa depan dengan lebih banyak engine browser independen

    • Menurut saya menulis ulang engine rendering untuk HTML bukan sesuatu yang layak dicoba. Tidak akan pernah selesai. HTML kini praktis merupakan spesifikasi yang sepenuhnya dimiliki Google dan Apple, dan terlalu kompleks untuk diimplementasikan dari nol
      Area yang menarik adalah teknologi UI/dokumen pasca-HTML. Typst di thread lain mirip LaTeX yang lebih baik, dan Markdown juga memberi dampak besar. Masih banyak ruang untuk membuat “HTML, tetapi lebih baik”. Tidak harus berupa format markup juga. Typst dan React HTML mengaburkan batas antara kode dan data, sementara Jetpack Compose menunjukkan cara membuat sesuatu yang terlihat seperti deskripsi UI berkat fitur DSL Kotlin, tetapi sebenarnya adalah kode
      Tentu untuk itu kita harus mendistribusikan ‘browser’ untuk format tersebut, atau mencari cara menampilkannya di browser yang ada. Meski begitu, mengompilasinya ke JavaScript/HTML/WASM tetap mungkin. Bisa juga memakai toolkit GUI portabel seperti JavaFX, dan tetap mendapatkan aksesibilitas. Keduanya pun bisa dilakukan
      Jika mendefinisikan bahasa UI sendiri, kita bisa mencoba banyak hal yang tidak dikerjakan HTML dengan baik. Contoh utamanya adalah pemisahan konten dan gaya. HTML pernah mencobanya tetapi tidak pernah benar-benar berhasil, dan XSL:T mencoba lebih keras, tetapi merupakan bahasa fungsional murni yang aneh dengan sintaks XML. React cukup baik dalam mengubah JSON menjadi kotak-kotak, tetapi protokol dasarnya selalu terasa seperti tambalan sementara, sehingga sulit membuat alat yang berguna di atasnya
      Ide lain yang mungkin adalah format yang secara bawaan kebal terhadap XSS
    • Akan bagus jika ada browser yang memakai lebih sedikit memori. Selain itu, jika mengesampingkan spyware dari Capital-G Google Chrome dan Capital-M Mozilla Firefox, saya tidak melihat jumlah engine yang sedikit sebagai masalah besar. Itu adalah jutaan jam kerja yang terakumulasi tanpa duplikasi
      Namun saya memang menginginkan alternatif untuk HTML. Kalau saya membuat browser, sepertinya saya akan fokus mengganti HTML karena tidak tahan dengannya, dan juga ingin mengganti JavaScript karena runtime-nya berat
      Misalnya, browser yang hampir tidak punya runtime JavaScript dan hanya menjalankan WASM akan cukup lucu
    • Mungkin kita bahkan membutuhkan platform atau protokol yang sama sekali baru. Yang sekarang sudah sepenuhnya jenuh oleh kompleksitas
    • Penasaran apakah ada yang pernah melihat engine browser alternatif seperti Servo, Ladybird, Goanna, NetSurf, Sciter, atau Flow

  • Saya salah satu penulis buku ini. Terima kasih atas kata-kata baiknya, dan saya bisa menjawab jika ada pertanyaan

    • Terima kasih sudah membuat buku yang luar biasa. Sebagai pengembang web, atau seperti istilah dalam buku ini, web engineer, saya selalu ingin mempelajari lebih banyak fondasi teknis yang saya andalkan
      Saya penasaran bagaimana proses memilih Python sebagai bahasa implementasi browser. JavaScript lewat Node sepertinya bisa memberikan pengalaman pemrograman yang lebih relevan

  • Tulisan yang menjelaskan mengapa penulis memilih Python: https://browserbook.substack.com/p/why-python
    Sebagian tampaknya dikompilasi dari Python ke JavaScript sehingga kini bisa berjalan di dalam browser, yaitu “di dalam buku itu sendiri”
    https://browserbook.substack.com/p/compiling-python-to-js

    • Fakta bahwa buku ini ditulis dengan Python justru membuat saya ingin membacanya. Kalau Rust atau Go mungkin saya akan melewatkannya, dan C++ terlalu sulit dibaca untuk proyek yang dilihat sekadar demi kesenangan
      Semoga setelah membacanya saya bisa kembali dan membicarakan hal yang lebih bermakna

  • Saya benar-benar antusias melihat materi seperti ini dibuat
    Browser terlihat seperti kotak hitam yang misterius dan tak bisa diuraikan, dan kemungkinan besar Google pun ingin ia dipersepsikan seperti itu. Namun melihat upaya dan hasil proyek seperti Ladybird, dinding itu mulai retak
    Suatu hari saya ingin ikut terjun langsung dan berkontribusi untuk memecahkan parit pertahanan itu, dan buku ini tampak seperti titik awal yang bagus

    • Parit pertahanan itu bukan muncul karena kurangnya engine browser non-Chrome, melainkan karena terlalu sedikit orang yang memakai engine selain Chrome
      Firefox sudah ada. Hanya saja hampir tidak ada yang memakainya, dan ketika pengguna menemui situs web yang tidak berjalan di Firefox, mereka sudah belajar untuk sekadar membuka Chrome
      Berkontribusi pada engine browser seperti Ladybird sambil berharap parit itu runtuh mungkin menyenangkan, tetapi sulit mengatakan bahwa itu saja benar-benar berkontribusi untuk meruntuhkan parit tersebut. Saya ingin tahu apa yang benar-benar akan membantu
    • Chris, salah satu penulis buku ini, adalah orang yang memimpin tim rendering Blink di Google
    • Saya salah satu dari dua penulis buku ini, dan penulis satunya adalah kepala Blink Rendering. Saya juga sudah beberapa kali berbicara dengan orang-orang dari tim Chrome, tetapi tidak pernah merasa mereka seperti orang yang ingin menjaga browser tetap misterius
      Justru orang-orang yang bekerja di Chrome, Firefox, Safari, dan Ladybird semuanya tampak sangat bersemangat membicarakan browser dan cara kerjanya. Dunia pengembangan browser lebih kecil daripada yang dibayangkan, dan para engineernya juga sering berpindah antark perusahaan, jadi rasanya sulit mempertahankan semacam “konspirasi”
      Namun memang benar bahwa materi edukasi kurang. Karena itulah kami menulis buku ini, dan khususnya juga kurang kosakata bersama untuk membahas bagian dalam browser pada tahap-tahap inti seperti layout dan rasterisasi. Chris dan saya ingin membangun fondasi semacam itu lewat buku ini

  • Saya sedang mencari proyek menarik untuk mulai dikerjakan, dan saya sudah sangat menikmati membaca buku ini. Tulisannya terutama disusun dengan menarik, jadi saya suka
    Komik yang menjelaskan cara kerja Chrome ini juga bahan yang bagus untuk memulai: https://www.google.com/googlebooks/chrome/med_00.html

  • Saya sedang mempelajari struktur internal browser, dan buku ini luar biasa
    Buku ini membantu membangun intuisi tentang cara kerja browser tanpa harus menggali kode Chrome yang berjumlah jutaan baris

  • Penasaran apakah ada kode promo untuk HN
    Dulu saya pernah memakai HTMLUnit [1] bersama Jython [2] dengan memuaskan, dan ke depannya saya sangat tertarik pada masa depan ketika sebagian kode browser bisa dibuat otomatis dengan teknik pembuatan kode dan verifikasi. Saya menghargai alat seperti Playwright/Cypress/Selenium, tetapi belum pernah merasa senyaman memakai HTMLUnit
    [1] https://htmlunit.sourceforge.io/
    [2] https://www.jython.org/

    • Bukunya belum terbit, jadi belum ada kode promo, tetapi seluruh isinya tersedia gratis secara online

  • Buku yang bagus. Saya sarankan membagi Bab 9 menjadi dua bab
    Bagian tentang menjalankan JavaScript dengan Duktape dijadikan satu bab, lalu bagian yang berinteraksi dengan DOM dan event dijadikan bab terpisah setelahnya

    • Mungkin paling baik dibaca dalam dua tahap
      Semakin ke belakang, bab-babnya makin panjang dan membahas topik yang lebih lanjut; sambil membaca buku ini, disarankan juga mengikuti kodenya