เจาะประเด็น
Dev Tools / Bun
Bun 1.4 เอาจริงเรื่อง WebView: เส้นทางใหม่ของ Browser Automation ที่ไม่ต้องง้อ Playwright
ใครว่าการเขียนสคริปต์ควบคุมเบราว์เซอร์ต้องยุ่งยาก? ไอเดียจากคนทำ shot-scraper กำลังเปลี่ยนเกมนี้ทั้งเกม
ทีมข่าว เอไอไทย.com
⏱ อ่าน 4 นาที
ถ้าคุณคิดว่า "เปิด Chrome ผ่าน API" เป็นเรื่องแพงและเปลืองทรัพยากร ลองดูตัวเลขนี้ก่อน แล้วค่อยว่ากันใหม่
หลังจากรอคอยกันมานาน ในที่สุด Bun 1.4 ก็ปล่อย stable version ออกมาเป็นที่เรียบร้อย นี่คือเวอร์ชันแรกหลังจากการรีไรต์โค้ดจาก Zig ไปเป็น Rust อันโด่งดังเมื่อไม่กี่เดือนก่อน ซึ่งทีมงานเลือกที่จะไม่โปรโมตประเด็นนี้มากนักในโน้ตรีลีส แต่กลับโชว์ของใหม่เพียบและเคลมว่ากดบั๊กไปกว่า 2,900 ตัว แถมยังเพิ่มเทสต์จาก Node.js อีก 1,517 ตัวด้วย
พูดกันตรงๆ ว่าการอัปเดตครั้งนี้มันโคตรจะเยอะ ทั้งเรื่องประสิทธิภาพที่อ้างว่าลดการใช้ CPU ตอน idle ลง 5 เท่า, ลดแรมลงได้ถึง 35%, และบูตเร็วขึ้น 50% บน Linux แต่ที่สะดุดตาที่สุดสำหรับผมไม่ใช่พวกนั้นเลย มันคือ Bun.WebView — ฟีเจอร์ที่เพิ่มความสามารถด้าน browser automation แบบ first-class support เข้าไปในตัว Bun เอง ไม่ต้องง้อไลบรารีภายนอกให้วุ่นวาย
ที่มาของไอเดียนี้มาจาก Simon Willison เจ้าของโปรเจกต์ shot-scraper สุดดัง เขาให้ Claude Code for web สร้างโปรโตไทป์ของ web API ที่ทำหน้าที่โหลดหน้าเว็บแล้วสั่งรัน JavaScript ผ่านมันได้ โดยแรงบันดาลใจหลักมาจากเครื่องมือ shot-scraper javascript CLI ของตัวเอง และที่สำคัญคือเขาอยากรู้ว่าเว็บเซอร์วิสแบบนี้มันต้องใช้แรมเท่าไหร่ถึงจะอยู่ได้จริงในคอนเทนเนอร์
ผลลัพธ์ที่ได้คือเซิร์ฟเวอร์ TypeScript ที่ใช้ Bun.WebView ในการควบคุมเบราว์เซอร์ ซึ่งรองรับทั้ง macOS WebKit และการควบคุม Chromium ในเครื่องผ่าน Chrome DevTools Protocol (CDP) และผลการเทสต์ด้วย cgroups พบว่าการรัน Chrome แบบเต็มรูปแบบกับหน้าเว็บที่ซับซ้อนๆ นั้นต้องการคอนเทนเนอร์ขนาด 192MB ถึง 256MB เท่านั้นเอง
ฟังดูเหมือนตัวเลขไม่มาก แต่ถ้าเทียบกับคอนเทนเนอร์ที่รัน Node.js เปล่าๆ เพื่อทำ API ธรรมดาๆ ที่กินแรมหลักสิบเมกะไบต์ นี่ถือว่าหนักเอาเรื่องอยู่เหมือนกัน แต่นี่คือราคาของการมีเบราว์เซอร์จริงๆ อยู่ในกระบวนการ ซึ่งมันเปิดความเป็นไปได้ใหม่ๆ ที่น่าสนใจมาก โดยเฉพาะการทำ web scraping แบบจัดหนัก, การเทสต์ UI อัตโนมัติ, หรือแม้แต่การสร้างเครื่องมือวิเคราะห์เว็บแบบเรียลไทม์
สิ่งที่ผมชอบคือการที่ Bun ผลักดันเรื่องนี้เข้ามาเป็นส่วนหนึ่งของ core แทนที่จะปล่อยให้เป็นหน้าที่ของ external library เหมือนที่ผ่านมา มันลดความยุ่งยากในการจัดการ dependencies ลงไปได้เยอะ แถมยังการันตีเรื่องความเข้ากันได้กับตัว runtime เอง ซึ่งเป็นจุดที่ Node.js ยังทำได้ไม่ดีเท่า
โหลดหน้าเว็บแล้วรัน JavaScript ได้เลย
หัวใจหลักของโปรโตไทป์นี้คือการเปิดหน้าเว็บแล้วสั่งรันโค้ดผ่าน API ได้ทันที ไม่ต้องไปยุ่งกับ selenium หรือ puppeteer ให้เสียเวลา
เลือกได้ว่าจะใช้ WebKit หรือ Chromium
บน macOS ใช้ WebKit พื้นเมืองได้เลย ส่วน Linux หรือที่อื่นก็สั่งให้มันไปควบคุม Chromium ผ่าน CDP แทน ยืดหยุ่นใช้ได้
แรม 256MB ก็รันได้
ตัวเลขนี้มาจากการเทสต์จริงกับหน้าเว็บซับซ้อนๆ ซึ่งถือว่าน่าประทับใจสำหรับการรันเบราว์เซอร์เต็มรูปแบบในคอนเทนเนอร์
แต่อย่าเพิ่งตื่นเต้นไปมากนัก เพราะนี่เป็นแค่โปรโตไทป์ที่ Simon สร้างขึ้นเพื่อทดสอบแนวคิดเท่านั้น ยังไม่ใช่ production-ready อะไร แต่การที่เขาพิสูจน์ให้เห็นว่า "มันเป็นไปได้" ด้วยทรัพยากรแค่นี้ คือการเปิดประตูบานใหญ่ให้คนอื่นต่อยอดได้อีกเยอะ
ผมมองว่าอนาคตของ browser automation กำลังจะเปลี่ยนไป จากเดิมที่เราต้องตั้งโครงสร้างใหญ่โตเพื่อรัน headless browser แยกต่างหาก ตอนนี้มันเริ่มถูกดึงเข้ามาเป็นส่วนหนึ่งของ runtime หลักแล้ว ซึ่งจะทำให้การพัฒนาเครื่องมือประเภทนี้เข้าถึงง่ายขึ้น และอาจทำให้เกิด use case ใหม่ๆ ที่เราไม่เคยคิดมาก่อนด้วยซ้ำ
Bun กำลังพิสูจน์ให้เห็นว่ามันไม่ใช่แค่ runtime ที่เร็วขึ้น แต่คือแพลตฟอร์มที่คิดใหญ่กว่า และการที่ WebView เข้ามาอยู่ใน core แบบนี้ ผมว่ามันจะปลดล็อกศักยภาพของ developer ในการสร้าง tools ที่ฉลาดขึ้นได้อีกเยอะ — ใครที่ยังเมิน Bun อยู่ ลองเปิดใจดูซักทีเถอะ
ที่มา: Simon Willison's Weblog — อ่านต้นฉบับ
ความคิดเห็น 6
กำลังโหลดความคิดเห็น...