Web Browser Engineering (2021)

 (browser.engineering)
2 puan yazan GN⁺ 2024-10-16 | 1 yorum | WhatsApp'ta paylaş
  • Web Browser Engineering, ağ iletişiminden JavaScript’e kadar uzanan konuları ele alan ve Python’da birkaç bin satır kodla temel ama eksiksiz bir web tarayıcısını bizzat geliştirmenizi sağlayan bir kitap
  • Öğrenme akışı, sayfa yüklemeden belge görüntülemeye, uygulama çalıştırmaya ve modern tarayıcı özelliklerine uzanır; HTTP, HTML, CSS, DOM, güvenlik, rendering pipeline konularını sırayla birbirine bağlar
  • İlk bölümler URL ve HTTP isteği, pencere oluşturma ve canvas çizimi, metin satır kırma ve satır aralığı gibi tarayıcı temellerinin uygulanmasına odaklanır
  • Orta ve ilerleyen bölümler HTML ağacı oluşturma, layout, stil uygulama, form gönderimi, olaylara tepki verme, çerezler ve oturum açma ile XSS ve CSRF konularını da kapsar
  • Son bölümler compositing, event loop, GPU animasyonları, erişilebilirlik ağacı, iframe, invalidation ve düzenleme doğruluğuna uzanarak modern tarayıcı uygulama bileşenlerini geniş kapsamda inceleme olanağı sunar

Uygulayarak öğrenilen tarayıcı mimarisi

  • Web Browser Engineering, web tarayıcılarının nasıl çalıştığını anlamak için temel ama eksiksiz bir tarayıcıyı bizzat geliştirme yaklaşımıyla hazırlanmıştır
  • Uygulama dili Python’dır ve toplam uygulama boyutu birkaç bin satır düzeyindedir
  • Kapsam, ağ iletişiminden JavaScript’e kadar uzanır
  • Basılı kitap Bookshop, B&N, Amazon üzerinden satın alınabilir
  • Çeviri baskıları Korece sürüm olarak Hanbit, Japonca sürüm olarak O’Reilly tarafından yayımlanmıştır
  • Güncellemeler blog, Mastodon, Twitter üzerinden takip edilebilir; ayrıca GitHub’da bir discussion forum da vardır

İçindekiler akışı

İlgili okumalar

1 yorum

 
GN⁺ 2024-10-16
Hacker News yorumları

  • Bu kitapta iyi olan noktalardan biri, “yapılmayan şeyleri” ayrıca ele alması.
    Yerleşim gerçekten zor; CSS olmadan yalnızca tabloları ele almak bile zor. CSS de işin içine girince yerleşim neredeyse imkânsız derecede karmaşıklaşıyor.
    CSS spesifikasyonunun tamamını ve ilgili davranışları kafasında tutabilen biri var mı, merak ediyorum. Günümüzün CSS+HTML+JavaScript’i dinamik sayfa teknolojisi diline (PDL) yakınlaştı ve bugün en karmaşık yazılımlardan biri olması muhtemel.
    Ek olarak, video çözme donanıma aktarıldığı için eskisi kadar pil tüketmiyor.

    • Üretim seviyesinde CSS yerleşimi uygulamak muazzam miktarda kod gerektiriyor; Servo kaynak kodu bunu iyi gösteriyor.
      Örneğin bu dosya yalnızca blok/inline bağlamını uyguluyor; biraz Rust boilerplate’i var ama büyük kısmı spesifikasyonun çeşitli bölümlerini ele alan gerçek mantık. Böyle dosyalarla dolu bir klasör var: https://github.com/servo/servo/blob/main/components/layout/f...
      Yine de bir yerleşim motoru uygulamak mümkün. CSS sihir değil; titizlikle koda aktarılabilecek bir spesifikasyonu var. CSS’in keyfî göründüğünden yakınan insanlara böyle kodları göstermek, çalışma ortamının da bir mantığı olduğunu anlamalarına yardımcı oluyor.
      Elbette bir kütüphane implementasyonuna bakar gibi sık sık tıklayıp inceleyeceğimiz bir şey değil; ama bu açıdan React gibi şeylerden de pek farklı olmadığını düşünüyorum.
    • Doğru, yerleşim zor; özellikle iki nedenin büyük rolü var gibi.
      Birincisi, CSS 2 gibi yerleşimin en temel kısımları oldukça dağınık tasarlanmış ve tuhaf özellikler birbirleriyle tuhaf biçimde etkileşiyor. float ve clearance, margin collapse gibi şeyler. Bu çekirdek parçaların bir kısmı tüm yerleşim modlarında genel olarak kullanılmak üzere tasarlanmıştı, ama diğer modlara pek uymuyor. Örneğin margin ve padding, grid öğelerinde amaç açısından net değil.
      İkincisi, JavaScript API’leri gibi iyi modülerleştirilmiş değil. JavaScript API’leri çoğu zaman bağımsız uygulanır; yerleşim modülleri ise çeşitli şekillerde iç içe geçebildiği için hepsi birbirini etkiliyor. grid gibi daha yeni spesifikasyonlar daha sıkı olmaya çalışıyor, fakat gerçek 2D ekran denen ortak kaynağı birden fazla yerleşim modunun paylaşmak zorunda olması gibi temel bir güçlük var.
    • Yerleşim o kadar zordu ki Common Lisp ve ncurses ile yaptığım tutku projesini bırakıp, ortadan kaldıracağıma yemin ettiğim varlık olan bir React geliştiricisine dönüştüm.
      CSS’ten daha basit, ama son 20 yılın derslerini yansıtıp basitlik ile ifade gücünün çarpımını en üst düzeye çıkaran bir yerleşim dili isteyen tek kişi ben olamam. Böyle bir şeyi ciddi şekilde tasarlayan bir proje var mı, yoksa herkes CSS3’ü kabullenip LLVM backend’ini mi bekliyor ya da sadece düz metne mi dönüyor, merak ediyorum.
    • React Native’de Facebook mühendisleri adeta pes edip “size verdiğimiz tek şey flexbox yerleşimi” demiş oldu; insanlar da bundan oldukça memnun kaldı. Tabii display grid yok diye yakınanlar da var.
      https://github.com/facebook/yoga
    • Bu Babil Kulesi bir gün yıkılacak.
      Yerleşimin bu kadar karmaşık olması gerekmiyor. Daha basit yerleşim sistemlerine sahip onlarca GUI framework’ü var ve insanların kullandığı uygulamalar için bunlar yeterli.

  • Harika görünüyor. Yaklaşık 15 yıl önce bir headless browser yapmaya başlamış ve birkaç yıl boyunca sürdürmüştüm.
    JavaScript yorumlayıcısı olarak SpiderMonkey kullanıp DOM’u kendim uygulamıştım. O dönemin en yeni JavaScript’ini, AJAX’i vb. çalıştırıyordu; daha sonra özel bir Flash runtime da ekledim. Ekrana çizme kısmı hariç neredeyse her şeyi yapan bir projeydi, bu yüzden gerçekten eğlenceliydi.
    Bu kitabı mutlaka okumak istiyorum.

    • Ekrana çizmek için hangi kütüphaneyi kullanmayı düşündüğünü merak ediyorum.

  • Tarayıcı mühendisliğinin artık bir trend hâline gelmesi sevindirici
    Ekosistem fiilen yalnızca Google, Apple ve Mozilla tarafından tanımlanan oldukça zayıf bir durumda. Gelecekte daha fazla bağımsız tarayıcı motorunun olduğu bir gelecek görmek isterim

    • HTML için yeni bir render motoru yazmanın girişilecek bir iş olduğunu sanmıyorum. Asla bitiremezsiniz. HTML artık fiilen Google ve Apple’ın tamamen sahip olduğu bir spesifikasyon ve sıfırdan uygulamak için fazlasıyla karmaşık
      İlginç alan HTML-sonrası UI/belge teknolojileri. Diğer başlıktaki Typst, daha iyi bir LaTeX gibi; Markdown da büyük etki yarattı. “HTML ama daha iyisi”ni yapmak için çok alan var. Mutlaka bir işaretleme formatı olması da gerekmiyor. Typst ve React HTML, kod ile veri arasındaki sınırı bulanıklaştırıyor; Jetpack Compose ise Kotlin’in DSL özellikleriyle UI açıklaması gibi görünen ama aslında kod olan şeyler üretmenin yolunu gösteriyor
      Elbette bunun için o formata yönelik bir ‘tarayıcı’ dağıtmanız ya da mevcut tarayıcılarda göstermenin bir yolunu bulmanız gerekir. Yine de JavaScript/HTML/WASM’e derlemek mümkün. JavaFX gibi taşınabilir bir GUI araç takımı da kullanabilirsiniz ve erişilebilirlik de elde edebilirsiniz. İkisi birden de yapılabilir
      Kendi UI dilinizi tanımlarsanız HTML’in iyi yapamadığı pek çok şeyi deneyebilirsiniz. Bunun en tipik örneği içerik ile stilin ayrılmasıdır. HTML bunu denedi ama hiçbir zaman düzgün başaramadı; XSL:T daha da ciddi denedi ama XML söz dizimi kullanan garip, saf fonksiyonel bir dildi. React, JSON’ı kutulara dönüştürmekte oldukça iyi, fakat alttaki protokol hep sonradan eklenmiş geçici çözümlerden oluştuğu için onun üzerinde faydalı araçlar geliştirmek zor
      Bir başka fikir olarak, temelden XSS’e bağışık bir format da mümkün
    • Daha az bellek kullanan bir tarayıcı olsa iyi olurdu. Bunun dışında, Capital-G Google Chrome ve Capital-M Mozilla Firefox’taki casus yazılımları saymazsak, motor sayısının az olması başlı başına büyük bir sorun değil bence. Sonuçta yinelenmeden birikmiş milyonlarca saatlik emek var
      Yine de HTML’e bir alternatif istiyorum. Ben bir tarayıcı yapsaydım, HTML’e katlanamadığım için onu değiştirmeye odaklanırdım; JavaScript’i de çalışma zamanı ağır olduğu için değiştirmek isterdim
      Örneğin neredeyse hiç JavaScript runtime’ı olmayan ve yalnızca WASM çalıştıran bir tarayıcı epey komik olurdu
    • Tamamen yeni bir platforma ya da protokole ihtiyaç olabilir. Mevcut olanın karmaşıklığı tamamen doygunluğa ulaşmış durumda
    • Servo, Ladybird, Goanna, NetSurf, Sciter, Flow gibi alternatif tarayıcı motorlarına hiç bakıp bakmadığını merak ediyorum

  • Bu kitabın yazarlarından biriyim. Güzel sözler için teşekkürler; sorularınız varsa yanıtlayabilirim

    • Harika bir kitap hazırladığınız için teşekkürler. Bir web geliştiricisi, ya da kitapta ifade edildiği gibi web mühendisi olarak, dayandığım teknik temeli hep daha fazla öğrenmek istemişimdir
      Tarayıcı uygulama dili olarak Python seçmenizin sürecini merak ediyorum. Node üzerinden JavaScript’in daha ilgili bir programlama deneyimi sağlayabileceği de düşünülebilir

  • Yazarın neden Python’u seçtiğini anlattığı yazı: https://browserbook.substack.com/p/why-python
    Görünüşe göre bunun bir kısmı Python’u JavaScript’e derliyor ve artık tarayıcının içinde, yani “kitabın kendi içinde” de çalışıyor
    https://browserbook.substack.com/p/compiling-python-to-js

    • Python ile yazılmış olması, gerçekten bu kitabı okumak istememi sağladı. Rust ya da Go olsaydı muhtemelen geçerdim; C++ ise keyif için bakılan bir proje için fazla yorucu
      Okuduktan sonra geri gelip daha anlamlı şeyler konuşabilmeyi umuyorum

  • Böyle kaynakların üretildiğini görmek gerçekten heyecan verici
    Tarayıcılar gizemli ve çözülemez kara kutular gibi görünüyor; muhtemelen Google da böyle algılanmalarını istiyor olabilir. Ama Ladybird gibi projelerin çabalarına ve sonuçlarına bakınca o duvarın çatladığını görüyorsunuz
    Bir gün bizzat işe koyulup o hendeği yıkmaya katkıda bulunmak istiyorum; bu kitap da harika bir başlangıç noktası gibi görünüyor

    • O hendek, Chrome dışı tarayıcı motorlarının eksikliğinden değil, Chrome dışı motor kullanan insan sayısının çok az olmasından kaynaklanıyor
      Firefox zaten var. Sadece neredeyse kimse kullanmıyor ve kullanıcılar Firefox’ta çalışmayan bir web sitesiyle karşılaşınca Chrome’u açmayı öğrenmiş durumda
      Hendeğin yıkılmasını umarak Ladybird gibi tarayıcı motorlarına katkıda bulunmak eğlenceli olabilir, ama bunun tek başına hendeği yıkmaya katkı sağladığını söylemek zor. Gerçekte neyin yardımcı olacağını bilmek isterdim
    • Kitabın yazarlarından biri olan Chris, Google’da Blink render ekibine liderlik ediyor
    • Kitabın iki yazarından biriyim; diğer yazar Blink Rendering’in başındaki kişi. Chrome ekibinden insanlarla da birçok kez konuştum, ama tarayıcıları gizemli tutmak isteyen biri gibi görünen kimseye rastlamadım
      Aksine Chrome, Firefox, Safari ve Ladybird üzerinde çalışan herkes, tarayıcıları ve nasıl çalıştıklarını konuşmaktan çok heyecan duyuyor gibi. Tarayıcı geliştirme dünyası sanıldığından küçük ve mühendisler de şirketler arasında sıkça geçiş yapıyor; bu yüzden herhangi bir “komployu” sürdürmek zor olurdu
      Yine de eğitim materyallerinin gerçekten eksik olduğu doğru. Bu kitabı bu yüzden yazdık; özellikle layout ve rasterization gibi temel aşamalarda tarayıcı iç yapılarını tartışmak için ortak bir söz dağarcığı da eksik. Chris ve ben bu kitapla böyle bir temel oluşturmak istedik

  • Başlayacak eğlenceli bir proje arıyordum; bu kitabı şimdiden gerçekten keyifle okuyorum. Yazımının özellikle ilgi çekici olması hoşuma gitti
    Chrome’un nasıl çalıştığını anlatan şu çizgi kitap da başlamak için iyi bir kaynak: https://www.google.com/googlebooks/chrome/med_00.html

  • Tarayıcı iç yapısını öğreniyorum ve bu kitap harika
    Milyonlarca satırlık Chrome koduna dalmak zorunda kalmadan, tarayıcının nasıl çalıştığına dair sezgi geliştirmeye yardımcı oluyor

  • HN için promosyon kodu olup olmadığını merak ediyorum
    Eskiden Jython [2] ile birlikte HTMLUnit'i [1] memnuniyetle kullanmıştım; ileride kod üretimi ve doğrulama teknikleriyle tarayıcı kodunun bazı bölümlerinin otomatik üretilebildiği bir gelecek ilgimi çok çekiyor. Playwright/Cypress/Selenium gibi araçlara saygım var ama hiçbiri bana HTMLUnit kadar rahat gelmemişti
    [1] https://htmlunit.sourceforge.io/
    [2] https://www.jython.org/

    • Kitap henüz yayımlanmadığı için promosyon kodu yok, ancak tamamı çevrimiçi olarak ücretsiz erişime açık

  • İyi bir kitap. 9. bölümü iki bölüme ayırmayı öneririm
    JavaScript'i Duktape ile çalıştırma kısmı bir bölüm olarak kalırsa, DOM ve olaylarla etkileşim kısmı daha sonra ayrı bir bölüm olsa iyi olur

    • İki seferde okumak en iyisi olabilir
      İlerledikçe bölümler uzuyor ve daha ileri düzey konular ele alınıyor; kitabı okurken kodu da birlikte takip etmenizi öneririm