वेब ब्राउज़र इंजीनियरिंग (2021)

• Web Browser Engineering एक किताब है जो networking से लेकर JavaScript तक कवर करती है, और Python की कुछ हज़ार लाइनों में एक बुनियादी लेकिन पूर्ण web browser खुद बनाकर देखने पर केंद्रित है
• सीखने का flow page loading से document display, application execution और modern browser features तक जाता है, और HTTP, HTML, CSS, DOM, security, rendering pipeline को क्रम से जोड़ता है
• शुरुआती हिस्सा URL और HTTP request, window creation और canvas drawing, text wrapping और line spacing जैसे browser basics के implementation पर केंद्रित है
• मध्य और बाद के हिस्से में HTML tree construction, layout, style application, form submission, event response, cookies और login, साथ ही XSS और CSRF शामिल हैं
• अंतिम हिस्सा compositing, event loop, GPU animations, accessibility tree, iframe, invalidation और editing accuracy तक जाता है, जिससे modern browser implementation elements को व्यापक रूप से देखा जा सकता है

---

खुद implement करते हुए browser structure सीखना

• Web Browser Engineering को इस तरह बनाया गया है कि web browser कैसे काम करता है, यह समझने के लिए आप एक बुनियादी लेकिन पूर्ण browser खुद implement करें
• implementation language Python है, और पूरा implementation कुछ हज़ार lines के स्तर का है
• scope networking से JavaScript तक फैला है
• print book Bookshop, B&N, Amazon पर खरीदी जा सकती है
• translated editions Korean edition Hanbit, Japanese edition O’Reilly के रूप में उपलब्ध हैं
• updates blog, Mastodon, Twitter पर देखे जा सकते हैं, और GitHub discussion forum भी है

table of contents का flow

• introduction

  • Preface
  • Browsers and the Web
  • History of the Web

• Part 1: Loading Pages

  • Downloading Web Pages: URL और HTTP request
  • Drawing to the Screen: window creation और canvas drawing
  • Formatting Text: word wrapping और line spacing

• Part 2: Viewing Documents

  • Constructing an HTML Tree: HTML parsing और correction
  • Laying Out Pages: inline और block layout
  • Applying Author Styles: CSS parsing और application
  • Handling Buttons and Links: hyperlinks और browser chrome

• Part 3: Running Applications

  • Sending Information to Servers: form submission और web server
  • Running Interactive Scripts: DOM changes और event response
  • Keeping Data Private: cookies, login, XSS, CSRF

• Part 4: Modern Browsers

  • Adding Visual Effects: blending, clipping, compositing
  • Scheduling Tasks and Threads: event loop और rendering pipeline
  • Animating and Compositing: GPU का उपयोग करके smooth animations
  • Making Content Accessible: keyboard input, zoom in/out, accessibility tree
  • Supporting Embedded Content: images, iframe, scripting
  • Reusing Previous Computation: invalidation, editing, accuracy

• wrap-up and appendices

  • What Wasn’t Covered
  • A Changing Landscape
  • Glossary
  • Bibliography
  • List of courses taught from this book
  • One-page version

[GN⁺]

Hacker News की राय

• इस किताब की एक अच्छी बात यह है कि इसमें “जो चीज़ें नहीं की गईं” को अलग से कवर किया गया है
  लेआउट सच में कठिन है, और CSS के बिना सिर्फ tables संभालना भी मुश्किल है। CSS आ जाए तो लेआउट लगभग असंभव हद तक जटिल हो जाता है
  मुझे संदेह है कि कोई ऐसा व्यक्ति है जो पूरे CSS specification और उससे जुड़े behavior को दिमाग में रख सकता हो। आज का CSS+HTML+JavaScript एक dynamic page description language (PDL) जैसा हो गया है, और संभव है कि यह आज के सबसे जटिल software में से एक हो
  साथ ही, video decoding hardware पर offload हो जाती है, इसलिए यह पहले जितनी battery नहीं खाती

  • production-grade CSS layout लागू करने के लिए भारी मात्रा में code चाहिए, और Servo source इसे अच्छी तरह दिखाता है
    उदाहरण के लिए, यह file सिर्फ block/inline context लागू करती है; इसमें थोड़ा Rust boilerplate भी है, लेकिन ज़्यादातर हिस्सा specification के अलग-अलग भागों को संभालने वाली असली logic है। ऐसे files का पूरा एक folder भरा हुआ है: https://github.com/servo/servo/blob/main/components/layout/f...
    फिर भी layout engine लागू करना संभव है। CSS कोई जादू नहीं है; इसके पीछे एक specification है जिसे सावधानी से code में उतारा जा सकता है। जो लोग CSS को arbitrary लगने पर परेशान होते हैं, उन्हें ऐसा code दिखाने से यह समझने में मदद मिलती है कि runtime environment में भी logic मौजूद है
    बेशक, किसी library implementation को देखने की तरह इसे बार-बार click करके देखने की नौबत नहीं आती होगी, लेकिन उस मायने में मुझे यह React जैसी चीज़ों से बहुत अलग नहीं लगता
  • सही है, layout कठिन है, और खासकर दो वजहें बड़ी लगती हैं
    पहला, CSS 2 जैसे layout के सबसे core हिस्से काफी ढीले-ढाले तरीके से design किए गए थे, और अजीब features आपस में अजीब तरह से interact करते हैं। जैसे float और clearance, margin collapsing वगैरह। इस core के कुछ हिस्सों को सभी layout modes में universally इस्तेमाल करने के इरादे से बनाया गया था, लेकिन वे दूसरे modes में ठीक से fit नहीं होते। उदाहरण के लिए, margin और padding का grid elements में उद्देश्य साफ नहीं है
    दूसरा, यह JavaScript API की तरह अच्छी तरह modularized नहीं है। JavaScript API अक्सर स्वतंत्र रूप से implement किए जाते हैं, लेकिन layout modules कई तरीकों से nest हो सकते हैं, इसलिए वे सब एक-दूसरे को प्रभावित करते हैं। grid जैसे नए specifications ज़्यादा strict बनने की कोशिश करते हैं, लेकिन असली 2D screen जैसे shared resource को कई layout modes के बीच बांटना पड़े, यह बुनियादी कठिनाई बनी रहती है
  • layout इतना मुश्किल था कि मैंने Common Lisp और ncurses में बना रहा अपना passion project छोड़ दिया, और वही बन गया जिसे मिटाने की मैंने कसम खाई थी: React developer
    मुझे नहीं लगता कि मैं अकेला हूं जो CSS से सरल, लेकिन पिछले 20 सालों की सीख को शामिल करते हुए simplicity और expressiveness के product को maximize करने वाली layout language चाहता है। सोचता हूं कि क्या ऐसी चीज़ को गंभीरता से design करने वाला कोई project है, या सबने CSS3 को स्वीकार कर लिया है और LLVM backend का इंतज़ार कर रहे हैं, या बस plain text पर लौट गए हैं
  • React Native में Facebook engineers ने मानो हार मानकर कह दिया, “तुम्हें हम सिर्फ flexbox layout देंगे,” और लोगों को यह काफी ठीक लगा। बेशक, कुछ लोग display grid न होने की शिकायत भी करते हैं
    https://github.com/facebook/yoga
  • यह बाबेल की मीनार एक दिन ढह जाएगी
    layout को इतना जटिल होने की ज़रूरत नहीं है। ज़्यादा सरल layout systems वाले दर्जनों GUI frameworks हैं, और लोगों द्वारा इस्तेमाल किए जाने वाले applications के लिए वे काफी हैं

• अच्छा लग रहा है। करीब 15 साल पहले मैंने एक headless browser बनाना शुरू किया था और कुछ साल तक उसे maintain किया
  JavaScript interpreter के लिए SpiderMonkey इस्तेमाल किया, और DOM खुद implement किया। उस समय का latest JavaScript और AJAX वगैरह सब चलाता था, और बाद में custom Flash runtime भी जोड़ा। screen पर draw करने को छोड़कर लगभग सब कुछ करने वाला project था, इसलिए बहुत मज़ेदार था
  मैं यह किताब ज़रूर पढ़ना चाहूंगा

  • screen पर draw करने के लिए आप कौन-सी library इस्तेमाल करने की सोच रहे हैं, यह जानने की उत्सुकता है

• यह देखकर खुशी है कि browser engineering अब trend बनती दिख रही है
  ecosystem असल में Google, Apple, Mozilla तक ही सीमित है, जो काफी कमजोर स्थिति है। आगे चलकर मैं ऐसा भविष्य देखना चाहूंगा जिसमें और ज्यादा independent browser engines हों

  • HTML के लिए rendering engine नए सिरे से लिखना मुझे करने लायक काम नहीं लगता। आप इसे कभी पूरा नहीं कर पाएंगे। HTML अब असल में पूरी तरह Google और Apple के कब्जे वाला spec है, और शुरुआत से implement करने के लिए बहुत जटिल है
    दिलचस्प क्षेत्र post-HTML UI/document technologies हैं। दूसरी thread में Typst बेहतर LaTeX जैसा है, और Markdown ने भी बड़ा असर डाला है। “HTML, लेकिन बेहतर” बनाने की काफी गुंजाइश है। यह जरूरी नहीं कि markup format ही हो। Typst और React HTML code और data की सीमा को धुंधला करते हैं, और Jetpack Compose दिखाता है कि Kotlin की DSL capabilities से ऐसा कैसे बनाया जा सकता है जो UI description जैसा दिखता है लेकिन असल में code होता है
    बेशक इसके लिए उस format के लिए ‘browser’ distribute करना होगा, या existing browser में उसे दिखाने का तरीका ढूंढना होगा। फिर भी JavaScript/HTML/WASM में compile करना संभव है। JavaFX जैसे portable GUI toolkit का इस्तेमाल भी किया जा सकता है, और accessibility भी मिल सकती है। दोनों भी किए जा सकते हैं
    अगर आप अपनी UI language define करते हैं, तो HTML जिन चीजों में अच्छा नहीं है, उनमें बहुत कुछ आजमा सकते हैं। खास तौर पर content और style का separation। HTML ने कोशिश की, लेकिन आखिर तक ठीक से हासिल नहीं कर पाया, और XSL:T ने और ज्यादा गंभीरता से कोशिश की, लेकिन वह XML syntax इस्तेमाल करने वाली अजीब pure functional language थी। React JSON को boxes में बदलने में काफी अच्छा है, लेकिन underlying protocol हमेशा ad-hoc तरीके से ऊपर-ऊपर जोड़ा गया लगता है, इसलिए उसके ऊपर उपयोगी tools बनाना मुश्किल है
    एक और idea के तौर पर ऐसा format भी हो सकता है जो default रूप से XSS से immune हो
  • अच्छा होगा अगर कोई कम memory इस्तेमाल करने वाला browser हो। इसके अलावा, Capital-G Google Chrome और Capital-M Mozilla Firefox के spyware को छोड़ दें तो, engines की संख्या कम होना अपने-आप में मुझे बड़ी समस्या नहीं लगता। यह बिना duplication के जमा किए गए लाखों घंटों का काम है
    हालांकि मैं HTML का alternative चाहता हूं। अगर मैं browser बनाऊं, तो शायद HTML को सहन न कर पाने की वजह से उसे replace करने पर focus करूं, और JavaScript भी बदलना चाहूंगा क्योंकि runtime भारी है
    उदाहरण के लिए ऐसा browser जिसमें JavaScript runtime लगभग न हो और जो सिर्फ WASM चलाता हो, काफी मजेदार होगा
  • शायद पूरी तरह नया platform या protocol चाहिए। मौजूदा चीज complexity से पूरी तरह saturated हो चुकी है
  • सोच रहा हूं कि क्या आपने Servo, Ladybird, Goanna, NetSurf, Sciter, Flow जैसे alternative browser engines कभी देखे हैं

• मैं इस किताब के authors में से एक हूं। अच्छी बातों के लिए धन्यवाद, और अगर कोई सवाल हो तो जवाब दे सकता हूं

  • इतनी शानदार किताब बनाने के लिए धन्यवाद। एक web developer, या किताब की भाषा में web engineer के रूप में, जिन technical foundations पर मैं निर्भर करता हूं उनके बारे में हमेशा और सीखना चाहता था
    browser implementation language के रूप में Python चुनने की प्रक्रिया के बारे में जानना चाहूंगा। Node के जरिए JavaScript शायद ज्यादा relevant programming experience देता लगता

• लेखक ने Python क्यों चुना, यह समझाने वाला लेख: https://browserbook.substack.com/p/why-python
  इसका कुछ हिस्सा Python को JavaScript में compile करके अब browser के अंदर, यानी “किताब के अंदर ही” चलता हुआ लगता है
  https://browserbook.substack.com/p/compiling-python-to-js

  • Python में लिखे होने की वजह से सच में यह किताब पढ़ने का मन हो गया। अगर Rust या Go में होती तो शायद छोड़ देता, और C++ किसी मजे के लिए देखे जाने वाले project के हिसाब से बहुत पढ़ने में कठिन है
    पढ़ने के बाद लौटकर और अर्थपूर्ण बात कर सकूं, तो अच्छा होगा

• ऐसी सामग्री बनती देखना सचमुच रोमांचक है
  browsers रहस्यमय और समझ से परे black boxes जैसे लगते हैं, और संभव है Google भी चाहता हो कि उन्हें ऐसा ही माना जाए। लेकिन Ladybird जैसे projects की कोशिशों और नतीजों को देखें तो वह दीवार दरक रही है
  किसी दिन खुद कूदकर उस moat को तोड़ने में योगदान देना चाहता हूं, और यह किताब एक शानदार starting point लगती है

  • वह moat non-Chrome browser engines की कमी से नहीं बना, बल्कि इसलिए बना है कि Chrome के अलावा engines इस्तेमाल करने वाले लोग बहुत कम हैं
    Firefox पहले से मौजूद है। बस लगभग कोई उसे इस्तेमाल नहीं करता, और जब users को Firefox में न चलने वाली websites मिलती हैं तो उन्होंने बस Chrome खोलना सीख लिया है
    moat टूटे, इस उम्मीद में Ladybird जैसे browser engine में contribute करना मजेदार होगा, लेकिन सिर्फ उससे moat तोड़ने में योगदान हो रहा है, ऐसा कहना मुश्किल है। जानना चाहूंगा कि असल में क्या मदद करेगा
  • किताब के authors में से एक Chris, Google में Blink rendering team को lead करते हैं
  • मैं किताब के दो authors में से एक हूं, और दूसरे Blink Rendering के head हैं। Chrome team के लोगों से भी कई बार बात की है, लेकिन वे कभी browser को रहस्यमय बनाए रखने की कोशिश करने वाले लोग नहीं लगे
    बल्कि Chrome, Firefox, Safari, Ladybird पर काम करने वाले लोग सभी browser और उनके काम करने के तरीके पर बात करने को लेकर बहुत उत्साहित दिखते हैं। browser development की दुनिया उम्मीद से छोटी है, और engineers भी companies के बीच अक्सर आते-जाते रहते हैं, इसलिए कोई “conspiracy” बनाए रखना मुश्किल लगता है
    हालांकि यह सही है कि educational material सच में कम है। इसलिए हमने यह किताब लिखी, और खासकर layout और rasterization जैसे core stages के browser internals पर चर्चा करने के लिए common vocabulary भी कम है। Chris और मैं इस किताब से ऐसी नींव बनाना चाहते थे

• शुरू करने के लिए कोई मजेदार project ढूंढ रहा था, और मैं पहले से ही यह किताब सचमुच मजे से पढ़ रहा हूं। writing खास तौर पर दिलचस्प ढंग से लिखी गई है, यह अच्छा लगा
  Chrome कैसे काम करता है, यह समझाने वाली यह comic book भी शुरुआत के लिए अच्छा resource है: https://www.google.com/googlebooks/chrome/med_00.html

• मैं browser internals सीख रहा हूं, और यह किताब शानदार है
  लाखों lines वाले Chrome code में घुसे बिना browser कैसे काम करता है, इसकी intuition बनाने में मदद मिलती है

• सोच रहा हूँ कि HN के लिए कोई प्रोमोशन कोड है या नहीं
  पहले Jython [2] के साथ HTMLUnit [1] का संतोषजनक इस्तेमाल किया था, और आगे ऐसे भविष्य में काफी दिलचस्पी है जहाँ code generation और verification techniques से browser code के कुछ हिस्से अपने-आप generate किए जा सकें। Playwright/Cypress/Selenium जैसे tools का सम्मान करता हूँ, लेकिन वे कभी HTMLUnit जितने सहज नहीं लगे
  [1] https://htmlunit.sourceforge.io/
  [2] https://www.jython.org/

  • किताब अभी प्रकाशित नहीं हुई है, इसलिए कोई प्रोमोशन कोड नहीं है, लेकिन पूरी किताब online मुफ्त में उपलब्ध है

• अच्छी किताब है। अध्याय 9 को दो अध्यायों में बाँटने की सलाह दूँगा
  Duktape से JavaScript चलाना वाले हिस्से को एक अध्याय रखें, और DOM तथा events के साथ interaction वाले हिस्से को बाद में अलग अध्याय में रखना बेहतर होगा

  • शायद इसे दो बार में पढ़ना सबसे अच्छा हो
    आगे बढ़ने पर अध्याय लंबे होते जाते हैं और ज्यादा advanced topics कवर करते हैं, और किताब पढ़ते समय code को भी साथ-साथ follow करने की सलाह है