รีวิวยูสการใช้งานเว็บบราว์เซอร์ Servo ที่สร้างด้วย Rust
(spacebar.news)- เมื่อสัดส่วนการใช้งาน เบราว์เซอร์ที่อิงเทคโนโลยี Chromium (Chromium) เพิ่มสูงขึ้นทั่วโลก ความกังวลเรื่องความหลากหลายของมาตรฐานเว็บและ อนาคตของเว็บเปิด (Open Web) จึงขยายตัวมากขึ้น
- เอนจิ้น Servo ที่พัฒนาด้วย Rust มีจุดเด่นสองด้านคือประสิทธิภาพมัลติเธรดและความปลอดภัยของหน่วยความจำ และถูกมองว่าเป็นทางเลือกใหม่ที่สำคัญในวงการเอนจิ้นเรนเดอร์เว็บ
- เนื่องจากยังอยู่ในระยะเริ่มต้น จึงยังมี บั๊กการเรนเดอร์ ในเว็บไซต์ส่วนใหญ่ แต่บางหน้าที่เป็นเดโมหรือไซต์ที่โครงสร้างง่าย ๆ เช่น Wikipedia สามารถทำงานได้ตามปกติ
- โปรเจกต์ Servo เริ่มต้นมาจากการนำโดย Mozilla ในอดีต แต่ขณะนี้อยู่ภายใต้การจัดการของ Linux Foundation Europe และมีโครงสร้างการตัดสินใจเชิงชุมชนที่เน้นความเป็นอิสระทางเทคโนโลยี
- ในกระแสการผสมกลมการตลาดเอนจิ้นเว็บแบบเดี่ยว การพัฒนา Gecko, Servo และ เอนจิ้นทางเลือก อย่างต่อเนื่องจึงมีความสำคัญต่อการรักษาความหลากหลายของระบบนิเวศเว็บ
การผูกขาดของเอนจิ้นเว็บและความเสี่ยง
- ในช่วงทศวรรษ 1990 ถึงต้นทศวรรษ 2000 มีเอนจิ้นเบราว์เซอร์หลายตัวใช้งานร่วมกัน เช่น Trident ของ Internet Explorer, Presto ของ Opera, Gecko ของ Netscape และ KHTML ของ Konqueror
- เมื่อเวลาผ่านไป KHTML ถูกพัฒนาเป็น WebKit และทั้ง Presto และ Trident (รวมถึง Tasman) ก็กลายมาเป็น Blink (เอนจิ้นของ Chromium)
- เมื่อ เบราว์เซอร์หลักสมัยใหม่ (Chrome, Edge, Opera ฯลฯ) กลายเป็น Chromium/Blink เป็นหลัก เกิดภาวะที่การใช้งานเอนจิ้นเฉพาะเริ่มกลายเป็นมาตรฐานเดียวที่อิงตามการใช้งานจริง
- ความเสี่ยงด้านความปลอดภัย ช่องโหว่ และข้อจำกัดในการขยายระบบยิ่งเด่นชัดขึ้นเมื่อระบบนิเวศเว็บต้องอาศัยเอนจิ้นเพียงตัวเดียว
การเกิดขึ้นของเอนจิ้น Servo
- Servo คือเอนจิ้นเรนเดอร์เว็บที่พัฒนาจากศูนย์ด้วยภาษา Rust
- โดยอาศัยข้อดีของ Rust อย่าง การประมวลผลแบบมัลติเธรด และ ความปลอดภัยหน่วยความจำ โครงการนี้พยายามลดข้อบกพร่องโครงสร้างของเอนจิ้นเดิมที่พัฒนาโดย C/C++ (เช่น บั๊กหน่วยความจำ) อย่างเป็นระบบ
- เป้าหมายหลักของ Servo คือการเป็น เอนจิ้นเรนเดอร์เว็บแบบฝังตัว จึงมีโอกาสถูกใช้แทนที่ไม่เฉพาะในเบราว์เซอร์อิสระ แต่รวมถึง Electron หรือ Android WebView ได้ด้วย
- การกำหนดทิศทางทางเทคนิคภายใต้ Linux Foundation Europe ดำเนินการโดยคณะกรรมการเทคนิค แทนการควบคุมจากบริษัทยักษ์ใหญ่
- เป็นเอนจิ้นเบราว์เซอร์แบบใหม่ตัวแรกในช่วงเวลาเกือบ 10 ปี โดยยังคงเอาบทเรียนจากเอนจิ้นหลักเข้ามาเสริมเพื่อยกระดับความสมบูรณ์แบบ
ประสบการณ์การใช้งานและสถานะปัจจุบันของ Servo
- สามารถทดลองใช้ Servo ได้จาก nightly build ที่เผยแพร่ทางเว็บไซต์ทางการสำหรับ Windows, macOS, Android และ Linux
- ขณะนี้ยังไม่รองรับฟังก์ชันพื้นฐานบางอย่าง เช่น ที่คั่นหน้า (bookmark), ส่วนเสริม, การซิงค์ข้อมูล
- ส่วนใหญ่อันดับผู้ใช้พบว่ามี บั๊กการเรนเดอร์ เกิดขึ้น และการค้นหาของ Google หรือบางเว็บไซต์มีปัญหาตกแต่งเลย์เอาต์ผิดเพี้ยนหรือเกิดการ crash
- หน้าเว็บลักษณะง่าย ๆ อย่าง Wikipedia, CNN Lite ทำงานได้อย่างถูกต้อง
- หน้าดีโมของ Servo ช่วยสาธิตความสามารถด้านกราฟิกได้ และในการทดสอบ Particle Physics บน MacBook Pro ล่าสุด (จำลอง x86) ให้ผลที่ 55~60 FPS
- การทดสอบ Acid3 ได้คะแนน 83/100 ต่ำกว่าค่าโดยเฉลี่ยของเบราว์เซอร์หลักที่อยู่ระดับประมาณ 95
- วางแผนรองรับมาตรฐานเว็บสำคัญอย่าง Shadow DOM, CSS Grid ใน roadmap โดยเน้นปรับปรุงความเข้ากันได้กับเว็บ
ประวัติและจุดเปลี่ยนสำคัญของ Servo
- Servo เริ่มต้นในปี 2012 ที่ Mozilla และในปี 2013 Samsung เข้าร่วมพัฒนาร่วมด้วย
- เป้าหมายเดิมคือการนำมาแทนที่เอนจิ้น Gecko หลังจากเสถียรภาพ แต่สุดท้ายปรับกลยุทธ์สู่แนวทางค่อย ๆ แทนที่องค์ประกอบของ Gecko ด้วยโค้ดของ Servo อย่างค่อยเป็นค่อยไป
- การอัปเดต Firefox 57 (Quantum) แสดงให้เห็นการแทนที่เอนจิ้น CSS (Quantum CSS, Stylo) ด้วยโค้ด Servo ส่งผลให้การทำงานดีขึ้นอย่างเด่นชัดในแง่ประสิทธิภาพและความมีประสิทธิภาพหน่วยความจำ
- หลังการ ลดโครงสร้างองค์กรขนาดใหญ่ของ Mozilla ในปี 2020 ที่รวมถึงการย้ายทีม Servo ออกจากองค์กร ต่อมามีการโอนทีมไปสู่ Linux Foundation, การฟื้นฟูการสนับสนุนด้านงบประมาณ และยังคงพัฒนาแบบชุมชนต่อด้วยการหนุนหลังจากบริษัทโอเพ่นซอร์สอย่าง Igalia
ความเป็นไปได้ในอนาคตของระบบนิเวศเบราว์เซอร์
- เมื่อกระทรวงยุติธรรมสหรัฐฯ ชนะคดีฟ้อง Google เรื่องสถานะการผูกขาด (Chrome, Android) ทำให้เกิดการหารือเรื่องการขาย Chrome และการห้ามทำข้อตกลงการค้นหากับเบราว์เซอร์รายอื่น
- Mozilla มีความเสี่ยงสูงเพราะรายได้จำนวนมากของ Firefox พึ่งพาการจัดวางระบบค้นหาพื้นฐาน (สำคัญต่อการรักษา Gecko) จึงแสดงความไม่เห็นด้วยอย่างชัดเจน
- หาก Mozilla สูญเสียรายได้จาก Google อาจมีแนวโน้มแปลงโหมดไปใช้ WebKit หรือ Chromium/Blink เพื่อลดต้นทุนการพัฒนา Firefox
- หากเกิดกรณีดังกล่าว อาจเห็นได้ทั้งการเกิดเวอร์ชันดัดแปลงและบริหารโดยชุมชนจากโค้ด Gecko หรือการค่อย ๆ เสื่อมถอยของ Gecko
- การคงอยู่ของ Servo และ Gecko รวมถึงเอนจิ้นทางเลือกอื่น กลับมาเป็นประเด็นสำคัญอีกครั้งในการรักษาความสมดุลและความหลากหลายของแพลตฟอร์มเว็บ
บทสรุปและข้อสังเกต
- แม้ยังมีแนวโน้มการรวมศูนย์ของเอนจิ้นเบราว์เซอร์หลัก การมาของ ทางเลือกที่สร้างสรรค์อย่าง Servo ก็มีบทบาทสำคัญในการคงความหลากหลายและสุขภาพโดยรวมของระบบนิเวศเว็บ
- แม้โอกาสจะไม่สามารถเป็นเบราว์เซอร์ใช้งานจริงได้ในระยะสั้น แต่ยังคงมีการทดลองทางเทคนิคและการพัฒนาที่ต่อเนื่องอยู่
- มีความคาดหวังสูงต่อเส้นทางพัฒนาของ Servo ในอนาคตและผลกระทบที่อาจเกิดขึ้นในอุตสาหกรรม
4 ความคิดเห็น
จะให้รับของที่แทบใช้งานไม่ได้มาใช้เนี่ยนะ? ความยโสแบบนั้นมันมาจากไหนกันแน่.
ได้ยินมาว่า Rust เป็นภาษาที่สร้างขึ้นมาเพื่อพัฒนา Servo.. หวังว่า Servo จะไปได้สวยนะ
พอนึกถึงโปรเจกต์ Hurd ขึ้นมาบ่อย ๆ ก็เลยสงสัยว่า... หรือจะเป็นแค่ผมคิดไปเอง?
ความคิดเห็นจาก Hacker News
ในโรดแมปปัจจุบัน ฟีเจอร์ที่ถูกจัดลำดับความสำคัญคือ Shadow DOM และ CSS Grid ตอนนี้ฉันกำลังทำงานเรื่องการรองรับ CSS Grid และคาดว่าอีกไม่นานจะเพิ่มการรองรับ "named grid lines and areas" ซึ่งน่าจะทำให้เลย์เอาต์ของเว็บไซต์จำนวนมากทำงานได้ถูกต้องขึ้น อาจลำเอียงเพราะเป็นโปรเจ็กต์ของฉันเอง แต่ฉันคิดว่าวิธีที่ Servo ใช้ในการทำ CSS Grid นั้นเจ๋งมาก โดยแกนหลักของการทำงานถูกแยกออกไปเป็นไลบรารีภายนอกชื่อ Taffy (ลิงก์ GitHub) และไลบรารีนี้ก็ถูกใช้อย่างกว้างขวางใน ecosystem ของ Rust UI เช่น ใช้ในเว็บเอนจิน Blitz(ลิงก์), โปรแกรมแก้ไขข้อความ Zed(ลิงก์) และเกมเอนจิน Bevy(ลิงก์) สำหรับบทบาทหลากหลายอย่างเช่น Flexbox, Block layout ฯลฯ ฉันหวังว่าแนวทางของ Servo ที่แยกเว็บเอนจินออกเป็นโมดูลอิสระและ public API โดยอาศัยประสบการณ์จากการพัฒนาไลบรารีแบบโมดูลาร์อย่าง Stylo และ html5ever จะช่วยลดอุปสรรคในการเข้าสู่วงการพัฒนาเว็บเอนจิน และเป็นประโยชน์มากกับนักพัฒนาเว็บเอนจินหน้าใหม่ในอนาคต
เพิ่งเคยได้ยินเรื่อง Blitz เป็นครั้งแรก ดูเป็นโปรเจ็กต์ที่น่าสนใจและทะเยอทะยานมาก ให้ความรู้สึกเหมือนเป็นเว็บเอนจินที่ "ซ่อนตัวอยู่" จริง ๆ Servo เป็นที่รู้จักกว้างขวางมาตั้งแต่ช่วงแรก ๆ ที่ Rust เปิดตัว แต่ Blitz ก็น่าประทับใจไม่แพ้กัน
สงสัยว่าการเคยลงมือทำฟีเจอร์ของ browser engine เอง ส่งผลต่อวิธีเขียน HTML หรือ CSS ไหม แล้วก็อยากถามว่ายังต้องค้นหา "css grid cheatsheet" สัปดาห์ละสามครั้งอยู่หรือเปล่า
กังวลว่าแนวทางแยกฟีเจอร์ออกมาเป็นโมดูล อาจกลับกลายเป็นนำไปสู่ฟีเจอร์ล้นเกินหรือความกระจัดกระจายมากขึ้น ถ้าจะสู้กับ Google กลยุทธ์ที่มีจุดโฟกัสชัดเจนน่าจะสำคัญกว่า เลยรู้สึกห่วงจุดนี้
ฉันใช้ taffy จัดเลย์เอาต์ในปฏิทิน e-ink ขนาดเล็กที่ทำด้วย Rust ของตัวเองอยู่ ข่าวแบบนี้ฟังแล้วสนุกมาก
ฉันชอบแนวทางการแยกเว็บเอนจินออกเป็นโมดูล public API ที่ใช้งานแยกอิสระได้มาก ก่อนหน้านี้ตอนดู WebRTC ก็เคยนึกว่า ทำไมการจะสร้าง Skype ก๊อปเกรดกากสักตัวถึงต้องเลือกระหว่าง JavaScript 50 บรรทัด กับฝันร้ายจากการ build Chromium C++ เป็นเวลาหนึ่งสัปดาห์ด้วย ตอนนี้มี WebRTC Rust crate แล้ว อย่างน้อยก็ดีที่ไม่ใช่มีแค่เว็บแอปเท่านั้นที่ได้ประโยชน์จากการลงทุนแบบนี้
Mozilla ทำให้รู้สึกเหมือนกำลังจะเข้า Hall of Fame ของบริษัทประเภท "สร้างเทคโนโลยีแห่งอนาคตขึ้นมา แล้วปล่อยให้คู่แข่งคว้าไปหน้าตาเฉย" แบบเดียวกับ Xerox Mozilla เคยแซง Google ไปก่อนในงานพัฒนาเบราว์เซอร์ด้วย Rust และ Servo แต่สุดท้ายกลับไม่เดินหน้าต่อ เรื่องนี้ฉันไม่เข้าใจจริง ๆ
Mozilla ไม่เหมือน Xerox ถ้าจะมีใครเป็น Xerox ยุคใหม่ คนนั้นน่าจะเป็น Google มากกว่า Google ทุ่มเงินมหาศาลให้ฝ่ายวิจัยและพัฒนาที่ไม่มีแผนธุรกิจชัดเจน ตัวอย่างชัดคือโมเดล transformer — พูดได้ว่า Google เป็นคนสร้างรากฐานของ LLM ก่อนด้วยซ้ำ แต่สุดท้ายก็โดน OpenAI แซงไป ความสำเร็จของ Mozilla นั้นผูกกับเว็บเบราว์เซอร์มาโดยตลอด ไม่ว่าจะ Netscape หรือ Firefox และ Rust เองก็เป็นภาษาที่โดยแก่นแท้ถูกสร้างขึ้นเพื่อเบราว์เซอร์ การที่มันไปมีประโยชน์ในที่อื่นได้ก็เป็นเพียงผลพลอยได้ที่ดีเท่านั้น
ตั้งแต่ปี 2006 Google เป็นแหล่งรายได้หลักของ Mozilla ถ้า Mozilla จะอยู่รอด ก็แค่ต้องทำให้ Google พอใจ เรื่องนี้มีช่องให้เกิดผลประโยชน์ทับซ้อนได้ก็จริง แต่ในมุมของ Mozilla มันก็เป็นดีลที่ค่อนข้างคุ้ม
ฉันคิดว่า Mozilla จบแล้ว พึ่งพา Google มากเกินไป และตอนนี้แม้แต่สิ่งนั้นก็อาจจะหายไป อนาคตน่าจะเป็นของ Servo กับ Ladybird และการที่ Ladybird พัฒนาได้เร็วมากด้วยคนจำนวนน้อยก็น่าประทับใจจริง ๆ
ถ้า Mozilla ยอมทิ้ง Gecko เมื่อไร นั่นแหละคือเวลาที่ควร hard fork และหนีออกจาก Mozilla เสียที และเพื่อความชัดเจน ที่พูดถึงการทิ้ง Gecko นั้นหมายถึงการเปลี่ยนไปใช้ Chromium ไม่ใช่ Servo
รู้สึกว่าการทำให้คนยอมจ่ายเงินให้เบราว์เซอร์เป็นเรื่องยาก ผู้คนยอมจ่าย 10 ยูโรให้เบียร์ได้ง่าย ๆ แต่คนรอบตัวฉันหลายคนกลับพยายามเลี่ยงค่าไลเซนส์ WhatsApp แบบตลอดชีพ 0.99 ยูโร
ฉันยังไม่เข้าใจเลยว่าทำไม Mozilla ถึงยอมทิ้งอนาคตทางเทคนิคของ Firefox แต่พอมอง Mozilla ผ่านกระแสเงินทุน หลายอย่างก็เริ่มเข้าใจขึ้น
การปิดบริการ Pocket ก็เป็นอีกตัวอย่างที่น่าเศร้า ฉันเคยจินตนาการเล่น ๆ ว่าถ้า Mozilla ประกาศในวัน April Fools' ว่าจะยุติ Firefox เพื่อไปโฟกัสกับธุรกิจหลักจะเป็นอย่างไร เป็นมุกขม ๆ ว่าดูเหมือน "การยุติผลิตภัณฑ์ยอดนิยมอย่างสวยงาม" จะเป็น platonic idea ของธุรกิจหลักจริง ๆ
จากการลาออกหลายครั้งและรูปแบบการสื่อสารต่าง ๆ ดูเหมือนว่า Mozilla ในเวลานั้นเป็นบริษัทที่เต็มไปด้วยการเมืองภายในอย่างหนัก Servo เป็นโครงการที่สื่อสารกันคึกคักมาก และ Rust ก็มีบรรยากาศที่ดี เลยคิดว่าอาจเพราะเหตุนี้เองมันถึงไปสะกิดประสาทคนข้างบน Mozilla ทุกวันนี้ก็ยังถูกขับเคลื่อนโดยคนหน้าเดิมเป็นหลัก และฉันคิดว่าความผิดพลาดของผู้บริหารระดับสูงมีส่วนมาก
ฉันยังเชื่ออย่างแรงกล้าว่า Servo ยังสามารถเป็นคู่แข่งที่สู้การผูกขาดของ Chrome/Chromium ได้จริง ๆ ฉันไม่เข้าใจว่าทำไม Mozilla ถึงเลิกสนับสนุนมัน และก็ไม่เข้าใจเหมือนกันว่าทำไม Linux Foundation ถึงแทบไม่สนับสนุนอะไรเลย
ถ้ามองกลยุทธ์ของ Mozilla ในแง่การสร้างความเป็นอิสระจากเงินของ Google ระยะยาว มันก็มีเหตุผลอยู่ รายได้ที่ไม่ใช่จาก Google เพิ่มจาก 80 ล้านดอลลาร์ในปี 2022 เป็น 150 ล้านดอลลาร์ในปี 2023 สินทรัพย์รวมก็เพิ่มปีละ 100 ล้านดอลลาร์จนแตะ 1 พันล้านดอลลาร์ในปี 2023 และสัดส่วนเงินจาก Google ก็ลดลงจาก 90% ในปี 2020 เหลือ 75% ในปี 2023 แม้ยังไม่เป็นอิสระเต็มตัว แต่ก็มีทิศทางอยู่ ตรงข้ามกับที่คนชอบพูดกัน ถ้ามองแค่กระแสเงินทุน ข้อสรุปอาจต่างออกไป หลายคนวิจารณ์ว่าพวกเขาควรสานต่อ Servo แต่ฉันคิดว่าหลัง Quantum แล้ว Servo ไม่ได้มีบทบาทมากนักกับ Firefox
อยากถามว่าเรื่องที่บอกว่ารายได้ส่วนใหญ่ของ Mozilla มาจาก Firefox นั้นจริงหรือเปล่า
ยังมี Ladybird(หน้าเว็บทางการ) ที่อาจมาท้าชนการผูกขาดของ Blink ได้ด้วย ยังไม่แน่ใจว่าอนาคตจะเป็นอย่างไร แต่ก็กำลังจับตาดูด้วยความคาดหวัง
ฉันไม่ค่อยเข้าใจเป้าหมายของ Ladybird ชัด ๆ มีทั้งอดีตวิศวกรและมีการรับเงินบริจาค เห็นได้ชัดว่าไม่ใช่แค่โปรเจ็กต์งานอดิเรกธรรมดา แต่ก็ยังนึกไม่ออกว่าจะไปแข่งกับ Blink, Webkit, Gecko ได้อย่างไรในแง่ฟีเจอร์ ความปลอดภัย และประสิทธิภาพ เพราะมันไม่ใช่ทีมใหญ่โตอยู่แล้ว และถ้าไม่มีการยอมรับในวงกว้าง การทำแค่เอนจินอย่างเดียวก็คงไม่ส่งผลมากนัก ประเด็นนี้ใช้กับ Servo ได้เหมือนกัน แต่ Servo มีเป้าหมายทางเทคนิคที่ฟังขึ้นมากกว่า ส่วน Ladybird ยังไม่ค่อยเห็นข้อมูลชัด ๆ แบบนั้น
ถ้ามองในเชิงเทคนิคอย่างเดียว ฉันยังไม่ค่อยเห็นเสน่ห์ของ Ladybird เท่าไร เพราะพื้นฐานแล้วมันเขียนด้วย C++ เลยดูไม่ต่างจาก Gecko หรือ Blink มากนัก ขณะที่ Servo มีจุดต่างด้านการออกแบบทางเทคนิคที่ชัดเจน ทั้งเรื่องความปลอดภัยและการประมวลผลแบบขนาน จึงดูน่าสนใจกว่า
ฉันหวังให้ Ladybird ประสบความสำเร็จ ตอนนี้สามารถสนับสนุนโดยตรงได้แล้ว เลยคิดว่ามีความหมายดี และต่างจาก Mozilla ตรงที่ฉันมั่นใจว่าเงินบริจาคที่รวบรวมได้จะถูกใช้กับการพัฒนาเบราว์เซอร์ทั้งหมดจริง ๆ
สงสัยว่า Ladybird กำลังพยายามย้ายไปใช้ Swift อยู่หรือเปล่า ถ้าจะพัฒนาเอนจินเบราว์เซอร์ด้วย C++ ฉันก็ไม่ได้ชอบนัก แต่ก็ถือว่าดูเป็นทางเลือกที่สมจริงและโฟกัสผลลัพธ์ ถ้าเป็น Rust ก็จะให้ความรู้สึกมองไปข้างหน้ามากกว่า ซึ่งฉันยอมรับจุดนั้นได้ แต่ถ้าจะทำเอนจินด้วยภาษาอื่นอย่าง Swift มันดูเหมือนการตัดสินใจทางการเมืองภายในบริษัทมากกว่า ฉันยังสงสัยกับการเลือกภาษาแบบจงใจใช้ภาษาที่ ecosystem สนับสนุนยังไม่พร้อมนัก (ทวีตอ้างอิง)
การทดสอบ Dogemania บน M4 Pro MacBook Pro ทำงานได้ลื่นที่ 60 FPS จนถึงภาพ 400 ภาพ แต่ใน Chrome รักษา 60 FPS ได้ถึง 1400 ภาพ และหลังจากนั้นฉันก็ขี้เกียจทดสอบต่อเลยปิดไป
ฉันลองแบบเดียวกันแล้ว และความต่างระหว่าง Firefox กับ Chromium นั้นน่าผิดหวังมาก บน Chromium ยังได้ 100 FPS ต่อเนื่องแม้เกิน 1000 ภาพไปแล้ว แต่บน Firefox พอเกิน 500 ภาพก็ตกต่ำกว่า 60 FPS ทันที อาจไม่ใช่การทดสอบที่ยุติธรรมสมบูรณ์นัก (Chromium ไม่มีส่วนเสริมและเป็นเบราว์เซอร์ที่แทบไม่ได้ใช้) แต่ก็ทำให้รู้สึกหลายอย่างเมื่อเห็นประสิทธิภาพเทียบกันตรง ๆ
ถ้ารูปภาพใน dogemania นิ่งอยู่หลังแอนิเมชัน แบบนั้นไม่ใช่กรณีที่ปรับแต่งประสิทธิภาพได้ง่ายมากหรือ ฉันถึงกับคิดว่าคอมพิวเตอร์ยุคเก่าอย่าง Amiga ก็น่าจะจัดการสิ่งระดับนี้ได้แบบไม่จำกัดเลยด้วยซ้ำ
การเรียก Servo ว่าเป็นเอนจิน "ใหม่" ก็ดูฝืนไปหน่อย
ฉันเข้าใจมาตลอดว่า Rust ถูกสร้างขึ้นเพื่อเว็บเบราว์เซอร์ Servo
สำหรับความเห็นที่ว่า “ถ้ามาตรฐานเหลือ implementation เดียว สุดท้าย implementation นั้นก็จะกลายเป็นมาตรฐานเอง” ฉันไม่ค่อยเข้าใจว่าทำไมมันถึงเป็นปัญหา ถ้า implementation นั้นเป็นโอเพนซอร์ส และสเปกถูกกำหนดโดยคณะกรรมการที่มีหลายฝ่ายร่วมดูแล ฉันก็คิดว่าโอเค สถานการณ์แบบทุกวันนี้ที่ต้องทุ่มทรัพยากรทำหลายเอนจินต่างหากที่ดูสิ้นเปลือง ฉันคิดว่า browser engine ก็ควรมีแบบเดียวเหมือน Linux kernel แล้วปล่อยให้ต่างกันที่ดิสโทรจะมีประสิทธิภาพกว่า
ไม่ว่าเจตนาจะดีแค่ไหน implementation ก็ย่อมมีบั๊กและข้อบกพร่องเล็ก ๆ น้อย ๆ ถ้าไม่มี implementation อิสระตัวที่สอง สุดท้ายบั๊กก็จะกลายเป็นมาตรฐานไปเองเพราะ "ทุกอย่างใช้ได้หมด" เมื่อเว็บเพจเริ่มพึ่งพาบั๊กพวกนั้น ในที่สุดมันก็จะทำงานตามข้อบกพร่องเฉพาะของ implementation ตัวนั้น ไม่ใช่ตามสเปก นี่คือเหตุผลที่ UI รุ่นเก่าใน MS Windows ถูกซ้อนทับกันหลายชั้นและการรักษาความเข้ากันได้กลายเป็นฝันร้าย ถ้ามีหลาย implementation ที่เป็นอิสระต่อกัน มาตรฐานก็จะรักษาและพัฒนาต่อได้จริง อีกทั้งยังทำให้การปรับแต่งประสิทธิภาพง่ายขึ้นด้วย
ในทางทฤษฎีอาจฟังดูดี แต่ในทางปฏิบัติ ฉันคิดว่าไม่ควรมีการผูกขาด เพราะผู้พัฒนาเพียงรายเดียวไม่ได้มีผลประโยชน์ตรงกับผู้ใช้เสมอไป โดยเฉพาะอย่างยิ่งกรณีล่าสุดที่ Blink-based เลิกใช้ manifest v2 ก็เป็นสิ่งที่ผู้ใช้ไม่ชอบกันมาก
ยิ่งมี browser engine หลายตัว ก็ยิ่งลดความเสี่ยงที่ช่องโหว่ความปลอดภัยจะกระจุกอยู่ที่เดียว แม้จะใช้ภาษาแบบ memory-safe แต่ความผิดพลาดเชิงตรรกะก็ยังสร้างความเสียหายได้ ดังนั้นความหลากหลายจึงสำคัญ
คุณพูดถึงกลยุทธ์แบบ “เอนจินเดียวแต่มีหลายดิสโทร” แต่สำหรับคนที่คุ้นกับสภาพแวดล้อมแบบ BSD หรือ ZFS กลับยิ่งรู้สึกได้ชัดถึงความมั่นคงและความสมบูรณ์เมื่อได้ออกจากแนวทางเก่า ๆ
ตอนนี้ความเห็นของ Google หรือเครือข่ายคนฝั่งนั้นก็มีอิทธิพลต่อการกำหนดมาตรฐานมากอยู่แล้ว ถ้าทุกอย่างหมุนตาม Chromium สถานการณ์จะยิ่งแย่ลงไปอีก บางทีอาจต้องเกิดหายนะจริง ๆ ก่อนที่ทุกคนจะยอมรับข้อจำกัดขององค์กรอย่าง W3C หรือ WHATWG
“เว็บไซต์ส่วนใหญ่มีบั๊กด้านการเรนเดอร์เล็กน้อย และบางเว็บก็ใช้งานไม่ได้เลย ผลการค้นหา Google มีองค์ประกอบซ้อนทับกันเยอะ และหน้าแรกของ MacRumors ก็แครชหลังเลื่อนหน้าจอ แต่ Wikipedia, CNN Lite, เว็บไซต์ส่วนตัว และ NPR แบบข้อความกลับทำงานได้สมบูรณ์” — พอเห็นข้อสังเกตแบบนี้แล้ว ฉันแทบไม่เคยเห็นใครบอกว่าฝั่ง Google หรือ MacRumors ควรแก้เว็บให้เข้ากับ Servo เลย กลับมีแต่สรุปว่า Servo ควรทำตัวให้เหมือน Chrome/Chromium ซึ่งน่าเสียดายมาก เพราะถ้าเป็นแบบนั้น (a) สุดท้ายบริษัทโฆษณาก็จะเป็นคนกำหนดมาตรฐาน และ (b) คนทำเว็บก็จะมีแรงจูงใจที่ผิด ฉันคิดว่าการทำให้เว็บเป็นแบบง่าย ๆ อย่าง Wikipedia หรือ CNN Lite กลับสะดวกกว่า ฉันมองว่าเบราว์เซอร์ที่เป็น "มาตรฐาน" ควรมุ่งไปสู่มาตรฐานจริง ไม่ใช่ความนิยม การที่เว็บใช้งานได้ทั้งบนเบราว์เซอร์ยอดนิยมและเบราว์เซอร์ที่ไม่เป็นที่นิยมต่างหากคือมาตรฐานจริง สุดท้ายคำตอบไม่ใช่การแก้ที่เว็บเบราว์เซอร์ แต่คือการแก้ที่เว็บเพจ ฉันยังทดลองกับไลบรารีและเครื่องมือ libwww ต้นฉบับของ w3c อยู่เลย แก้นิดหน่อยมันก็ยังใช้ได้ดีมากสำหรับเว็บเพจแบบข้อความที่ปรับแต่งมาโดยเฉพาะ แม้เวลาจะผ่านไปเกิน 30 ปีแล้ว อินเทอร์เน็ตเป็นสาธารณสมบัติ แต่เบราว์เซอร์และหน้าเว็บทุกวันนี้กลับเอนเอียงไปทางการเพิ่มประสิทธิภาพเพื่อโฆษณาและการเก็บข้อมูลส่วนตัวมากเกินไป ฉันคิดว่าหน้าเว็บและเบราว์เซอร์ที่ทำเพื่อผู้ใช้ www อย่างแท้จริงต่างหากที่ควรมาก่อนจึงจะมีความหมาย ด้านล่างนี้คือสคริปต์ง่าย ๆ สำหรับ build static binary ของ libwww
น่าเศร้ามากที่ได้เห็น Mozilla ค่อย ๆ เปลี่ยนจากบริษัทเบราว์เซอร์ที่แข่งขันอย่างจริงจัง ไปเป็นองค์กรที่ให้อารมณ์แบบนักเคลื่อนไหวมากขึ้น และนั่นก็น่าจะเป็นเหตุผลที่ผลิตภัณฑ์หลักของมันอ่อนแอลงเรื่อย ๆ