เงินรางวัล 20,000 ดอลลาร์ของ Prettier ถูก Biome รับไป

 (prettier.io)
3 คะแนน โดย GN⁺ 2023-11-28 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Prettier ตัวจัดรูปแบบโค้ด JavaScript ต้องการกระตุ้นให้เกิด การแข่งขันด้านประสิทธิภาพ ผ่านการทำ implementation ที่เข้ากันได้บนพื้นฐาน Rust หลังจาก logic การจัดรูปแบบเข้าใกล้ระดับเสถียรแล้ว
  • เมื่อวันที่ 9 พฤศจิกายน Prettier ตั้งเงินรางวัล 10,000 ดอลลาร์ โดยมีเงื่อนไขว่าต้องผ่าน 95% ของ test suite และเมื่อรวมเงินสมทบจาก Guillermo Rauch ซีอีโอของ Vercel และ napi.rs ยอดรวมจึงเป็น 22,500 ดอลลาร์
  • Biome ใช้เวลาประมาณ 3 สัปดาห์ โดยมีหลายคนช่วยกันยกระดับความเข้ากันได้จนได้รับเงินรางวัล และในกระบวนการนี้ ขอบเขตความเข้ากันได้จริงกับ Prettier ก็ขยายขึ้นอย่างรวดเร็ว
  • ระหว่างการทำให้ผ่านการทดสอบ ยังเผยให้เห็น บั๊กและการตัดสินใจที่น่าสงสัย ของ Prettier ทำให้ฝั่ง Prettier มีหลักฐานเฉพาะเจาะจงสำหรับนำไปปรับปรุง
  • Prettier ใช้เงินบริจาคจ่ายให้ maintainer 2 คน คนละ 1,500 ดอลลาร์ต่อเดือนมาโดยตลอด แต่ปัจจุบันงบประมาณเหลือ runway 8 เดือน เท่านั้น จึงต้องการเงินบริจาคเพิ่มเติม

Biome ได้รับเงินรางวัลของ Prettier

  • Prettier เป็นตัวจัดรูปแบบโค้ด JavaScript ที่ได้รับการใช้งานอย่างกว้างขวาง เพราะจัดการรูปแบบการเขียนโค้ดที่หลากหลายมากของผู้คนได้อย่างละเอียดรอบคอบ
  • logic การจัดรูปแบบอยู่ในสถานะที่แข็งแรงแล้ว และคาดว่าจะถึงระดับที่น่าพอใจเมื่อรวมงานเกี่ยวกับ ternaries เข้าไป
  • โจทย์ถัดไปคือ การปรับปรุงประสิทธิภาพ
    • เดิมที Prettier ไม่ใช่เครื่องมือที่เร็ว แต่ก็เร็วพอสำหรับ use case ส่วนใหญ่
    • เพื่อไม่ให้หยุดอยู่กับสภาพปัจจุบัน จึงใช้การแข่งขันแบบเป็นมิตรเพื่อกระตุ้นให้เกิดการปรับปรุง

  • เงื่อนไขเงินรางวัลและการเข้าร่วม

    • วันที่ 9 พฤศจิกายน มีการเสนอ $10k bounty สำหรับโปรเจกต์ที่เขียนด้วย Rust ซึ่งสามารถผ่าน 95% ของ test suite ของ Prettier
    • Guillermo Rauch ซีอีโอของ Vercel สมทบเงินเท่ากัน ทำให้ยอดรวมเป็น 20,000 ดอลลาร์
    • napi.rs เพิ่มให้อีก 2,500 ดอลลาร์
    • ฝั่ง Algora สร้าง landing page สำหรับเงินรางวัลนี้

  • ผลสำเร็จของ Biome

    • โปรเจกต์ Biome ได้รับเงินรางวัล
    • ในช่วงประมาณ 3 สัปดาห์ มีคนราว 12 คนรวมตัวกันเพื่อปรับปรุงความเข้ากันได้
    • รายละเอียดเพิ่มเติมอยู่ใน full report ของ Biome
    • ระหว่างการทำให้ผ่านการทดสอบ ยังพบ bugs and questionable decisions ของ Prettier จำนวนมาก ทำให้ Prettier สามารถนำไปปรับปรุงได้

แรงกดดันที่เกิดจากการแข่งขันด้านประสิทธิภาพ

  • เหตุผลที่ทีม Prettier ตั้งเงินให้โปรเจกต์อื่นคือเพื่อสร้าง การแข่งขันด้านประสิทธิภาพ
    • Prettier เคยอยู่ในตำแหน่งครองตลาดในหมู่ตัวจัดรูปแบบโค้ด JavaScript
    • การขาดการแข่งขันทำให้แรงจูงใจในการปรับปรุงประสิทธิภาพและแก้ไข edge case ต่าง ๆ มีน้อย
  • ตอนนี้ Biome มี implementation ที่เข้ากันได้กับ Prettier และเร็วกว่าอย่างมาก ผู้ใช้จึงสามารถย้ายไปใช้ได้
  • Fabio Spampinato ใช้ challenge นี้เป็นโอกาสในการ profile Prettier CLI อย่างจริงจัง และพบความไม่มีประสิทธิภาพขั้นสุดหลายจุด
    • ปัญหาเหล่านี้มีกำหนดจะแก้ไขภายในสิ้นปี

เงินบริจาคและงบประมาณดูแลรักษาของ Prettier

  • เงินรางวัลของ Prettier และการดำเนินงานต่อเนื่องเป็นไปได้ด้วยเงินบริจาคจำนวนมากจากบุคคลและบริษัทหลายแห่ง

  • เงินบริจาคหลักจากบริษัท

    • Indeed: 20,000 ดอลลาร์
    • Frontend Masters: 10,850 ดอลลาร์
    • Sentry: 10,529 ดอลลาร์
    • Salesforce: 10,025 ดอลลาร์
    • Airbnb: 8,426 ดอลลาร์
    • Cybozu: 6,086 ดอลลาร์

  • เงินบริจาคหลักจากบุคคล

    • Shintaro Kaneko: 1,635 ดอลลาร์
    • Suhail Doshi: 1,000 ดอลลาร์
    • icchiman: 500 ดอลลาร์
    • Mariusz Nowak: 270 ดอลลาร์
    • Benoît Burgener: 270 ดอลลาร์
    • Jeremy Combs: 270 ดอลลาร์
    • f_subal: 230 ดอลลาร์
    • ด้วยเงินบริจาคเหล่านี้ Prettier จึงสามารถ จ่ายเงินให้สองคนเดือนละ 1,500 ดอลลาร์ และออก release ต่อเนื่องตลอด 2 ปีที่ผ่านมา
    • Fisker Cheung และ Sosuke Suzuki เป็นผู้รับบทบาทนี้
    • ด้วยงบประมาณปัจจุบัน เหลือ runway 8 เดือน เท่านั้น จึงอยู่ในสถานะที่ต้องการเงินบริจาคเพิ่มเติม
    • หากคุณใช้ Prettier และได้รับประโยชน์ สามารถบริจาคได้ที่ https://opencollective.com/prettier
    • Open Collective ช่วยการดำเนินงานของโปรเจกต์อย่างมาก
    • maintainer สามารถสมัครเข้าร่วมได้โดยไม่ต้องให้ข้อมูลส่วนตัว
    • ทำงานคล้ายธนาคาร และสามารถรับส่งเงินได้ทั่วโลก
    • จัดการเอกสารภาษีอย่างเหมาะสม
    • Prettier ระดมเงินได้รวม 110,000 ดอลลาร์ และนำไปจัดสรรต่อ 75,000 ดอลลาร์
    • เงินรางวัลครั้งนี้เป็นกิจกรรมครั้งเดียว แต่เป้าหมายคือการเติมพลังให้ ecosystem การจัดรูปแบบโค้ด และสร้างประสบการณ์นักพัฒนาที่ดียิ่งขึ้น

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2023-11-28
ความคิดเห็นใน Hacker News

  • ผมสงสัยว่าทำไมทีม Prettier ถึงให้ทุนกับโปรเจกต์อื่น แต่คำตอบก็ยังไม่ค่อยทำให้เข้าใจได้เต็มที่
    ถ้าตั้ง เงินรางวัล สำหรับการปรับปรุง Prettier ก็พอแล้ว แต่ไม่ชัดเจนว่าทำไมต้องสร้างโปรเจกต์คู่แข่งเพื่อสร้างแรงจูงใจในการพัฒนา Prettier
    ยังสงสัยด้วยว่าเป้าหมายสุดท้ายคือการยุบ Prettier แล้วโยกไปใช้เครื่องมือที่ใช้ Rust หรือไม่ และดูเหมือนเป็นการทำให้ระบบนิเวศที่สับสนอยู่แล้วแตกย่อยลงไปอีกโดยไม่จำเป็น

    • ดูเหมือนมีสามเหตุผลที่เรื่องนี้กลายเป็นโปรเจกต์แยก ไม่ใช่เงินรางวัลเพื่อปรับปรุง Prettier
      ข้อแรก การเขียน formatter ด้วย Rust มีลักษณะต่างจากการปรับปรุง codebase ของ Prettier ตัว Prettier ไม่ได้เขียนด้วย Rust และ Rust ก็พิสูจน์แล้วว่าเป็นตัวเลือกที่แข็งแรงสำหรับการทำ formatter ดังนั้นเป้าหมายจึงใกล้เคียงกับการเขียน Rust formatter เอง
      ข้อสอง การขอให้เขียน Rust formatter ที่ Prettier เป็นเจ้าของด้วยเงิน $20k นั้นไม่ค่อยน่าสนใจ สำหรับนักพัฒนาฝีมือดี มันเทียบได้ประมาณงาน 100 ชั่วโมง ซึ่งไม่พอให้ทำโปรเจกต์เสร็จ แต่ถ้าได้ผลตอบแทนเป็นโปรเจกต์ที่ตัวเองเป็นเจ้าของ ก็จะน่าสนใจกว่ามาก
      ข้อสาม ถ้า Prettier เป็นเจ้าของโปรเจกต์ที่ชนะ ทีม Prettier ก็ต้องรับผิดชอบการดูแลรักษาด้วย ทีมที่สร้างขึ้นมาเดิมจะมีแรงจูงใจน้อยลงในการดูแลต่อ และการแข่งขันก็จะหายไป ทำให้ระบบนิเวศคึกคักน้อยลง
    • ในมุมของผู้ดูแลโอเพนซอร์ส สิ่งที่สนใจมากกว่าการที่ทุกคนใช้ implementation เฉพาะของผมคือ ปัญหาได้รับการแก้ไข
      การที่มีคนใช้โค้ดของผมไม่ได้ทำให้ผมได้ประโยชน์โดยตรง และผมก็ทำงานเพื่อสร้างทางออกที่เข้าถึงได้ ถ้าผมมี passion กับการจัดรูปแบบโค้ด JS ก็คงดีใจไม่น้อยถ้ามีใครสักคนแก้ปัญหานั้นได้ด้วยวิธีที่เร็วกว่า
    • มีความแตกต่างมากระหว่าง “เราเป็นผู้เล่นรายใหญ่เดิม และนักพัฒนา JavaScript ไม่มีทางเลือกอื่นที่ใช้ได้จริง” กับ “ฝั่ง Rust ทำสำเร็จแล้ว และมีทางเลือกที่ค่อนข้าง viable เกิดขึ้น”
      มันดูใกล้เคียงกับปัญหาการหลุดออกจาก จุดเหมาะสมเฉพาะที่ เราอาจชี้ไปที่คอขวดด้านประสิทธิภาพที่ใหญ่ที่สุดแล้วบอกว่าสามารถปรับปรุงได้ แต่ถ้าไม่มีตัวเปรียบเทียบที่ดีกว่าในเชิงวัตถุ ก็ยากที่จะมั่นใจ
      การเลียนแบบคือคำชมที่จริงใจที่สุด และข้อเท็จจริงที่ว่าปัญหายาก ๆ สามารถแก้ได้ด้วยภาษาอื่นนั้นเองก็สร้างคุณค่าขึ้นในกระบวนการแข่งขัน
      ถ้าไม่มีทางเลือกจริง ก็ไม่มีการแข่งขันเต็มรูปแบบ ถ้า implementation ใน Rust ตัดทอน test suite ออกไปไม่เกิน 5% แล้วยังเร็วกว่า ก็จะบอกอะไรเราได้มากเกี่ยวกับขีดจำกัดเชิงทฤษฎีของปัญหานี้เมื่อเทียบกับ implementation มาตรฐาน
      ผมไม่ได้รู้ลึกในด้านนี้ แต่คิดว่าเมื่อมี implementation ที่คล้ายกันในภาษาอื่น ก็มักมีคุณค่าเชิงนามธรรมบางอย่างที่ได้รับเสมอ
    • เมื่อคนที่มีมุมมองและความตั้งใจต่างกันลงมือ implement ก็อาจเผยให้เห็นทิศทางการปรับปรุงใหม่ ๆ ได้
      https://biomejs.dev/formatter/#differences-with-prettier
      Biome ไม่ได้ทำตามการตัดสินใจแบบเดียวกับ Prettier และพบ จุดไม่สะดวก หลายจุดที่แยกออกไป แค่นี้ก็เพียงพอแล้วที่จะเห็นคุณค่าของการพัฒนาแบบขนาน
    • แนวทางที่มีข้อจำกัดและภาระต่างกันสามารถค้นพบพื้นที่ปรับปรุงที่มองไม่เห็นในโปรเจกต์เดิมได้
      อาจเป็นเพราะไม่ได้ติดอยู่กับสิ่งที่เรียกว่า วิธีคิดแบบ Prettier

  • ดูเหมือนหลายคนพูดถึงเหตุผลกัน แต่ไม่ได้มองประเด็นนี้ควบคู่ไปด้วย: “ขณะทำให้ผ่านทุก test โปรเจกต์ Biome ได้ค้นพบบั๊กจำนวนมากและการตัดสินใจที่น่าสงสัยหลายอย่างของ Prettier และทำให้สามารถปรับปรุงสิ่งเหล่านั้นได้”
    สำหรับผม นี่หมายความว่าการมี implementation อีกชุดหนึ่ง ช่วยให้ sanity check implementation ของตัวเองได้

  • ข่าวนี้น่าตื่นเต้นมากจริง ๆ
    ทีม Biome ทำความเข้ากันได้กับ Prettier ได้ถึง 95% ด้วยความเร็วที่น่าทึ่ง https://github.com/biomejs/biome/issues/720
    ด้วย Rust จึงสามารถเร่งความเร็วการจัดรูปแบบ JavaScript ได้มาก และเป็นเหมือนการเดินตามกระแสของ Python formatter ruff
    แม้ในบทความจะไม่ได้พูดถึง แต่ Wasmer ก็ตั้ง เงินรางวัล $2,500 สำหรับการคอมไพล์ Biome ไปเป็น WASIX ด้วย และก็ดีที่ได้เห็นทีมนั้นทำงานเพื่อสิ่งนี้
    หวังว่าอีกไม่นาน Biome จะรันบน Wasmer ได้: https://wasmer.io/, https://wasix.org/, https://console.algora.io/challenges/prettier

    • เพิ่งเคยเห็น WASIX ครั้งแรก แต่พออ่านแล้วดูเหมือน การกลับชาติมาเกิดของ JVM
      อยากรู้ว่าเข้าใจแบบนี้ถูกไหม ถ้าเข้าถึงระบบได้และไม่ใช่ sandbox จริง ๆ ก็ไม่รู้ว่าข้อดีของการรันโค้ดบน WASIX คืออะไร
    • อยากรู้ว่ามีใครทราบเหตุผลที่ต้องการให้คอมไพล์เป็น WASIX ได้ไหม

  • การปรับปรุงความเร็วเป็นเรื่องน่ายินดีเสมอ แต่คงดีถ้า Prettier ดื้อด้านน้อยลงหน่อย
    โดยเฉพาะเรื่อง ความยาวบรรทัด มันไม่ยอมปล่อยการจัดรูปแบบของผมไว้เฉย ๆ โค้ดที่จัดรูปแบบด้วย Prettier อ่านยากกว่าโค้ดที่ไม่ได้จัดรูปแบบมาก และเป็นปัญหาที่ผมไม่เจอใน formatter ตัวอื่นอย่าง rustfmt

    • อยากรู้ว่ามีตัวอย่างไหมว่าโค้ดของ Prettier อ่านยากกว่ามากตรงไหน
      ผมแทบไม่เจอปัญหาแบบนั้น และค่อนข้างพอใจกับ Prettier มาตลอด
    • เคยลองใช้ตัวเลือก print width หรือยัง: https://prettier.io/docs/en/options.html#print-width
    • ปัญหาจริง ๆ ของ Prettier คือมันแทบจะกลายเป็น มาตรฐานโดยพฤตินัย ไปแล้ว
      ส่วนตัวผมไม่ชอบ Prettier เลย แต่ชอบ Svelte และ formatter ทางการของ Svelte เท่าที่ผมรู้ก็ใช้ Prettier ดังนั้นกับ Svelte ผมจึงใช้ Prettier และกับอย่างอื่นอีกบางอย่างก็เหมือนกัน
      ถ้าเป็นสถานการณ์ที่ผู้ใช้เลือกเครื่องมือเอง หลักการแบบ “มีความเห็นชัดมาก และถ้าต้องการตั้งค่าเพิ่มก็ไปใช้ที่อื่น” อาจยอดเยี่ยมได้ แต่เมื่อมันกลายเป็นตัวเลือกเดียวโดยพฤตินัยสำหรับผู้ใช้บางกลุ่ม ก็ควรปรับตั้งค่าได้มากขึ้นอีกหน่อย
    • เรื่องความยาวบรรทัด Prettier มีผลข้างเคียงที่แนบเนียนกว่านั้น และนั่นทำให้ผมหลีกเลี่ยง formatter ที่ดื้อด้าน
      Prettier เปลี่ยน diff ในแบบที่ไม่ได้ตั้งใจ
      ใน destructuring assignment ถ้าลบสมาชิกหนึ่งตัวออกจนความยาวบรรทัดต่ำกว่าขีดจำกัด diff อาจกลายเป็น +1/-5 แทนที่จะเป็น 0/-1 ได้ ผู้รีวิวจะดูได้ยากทันทีว่าระหว่างการลบ 5 บรรทัดกับเพิ่ม 1 บรรทัดนั้น อะไรหายไปกันแน่
      ถ้าพยายามแก้ typo ในคอมมิตก่อนหน้าด้วย interactive rebase ของ Git, Prettier อาจจัดรูปแบบ code block ทั้งก้อนใหม่จนคอมมิตถัด ๆ ไปอาจนำไปใช้ไม่ได้
      พอตั้งให้รัน Prettier ด้วย pre-commit hook แล้วลอง stage แค่บางส่วนของการเปลี่ยนแปลงในไฟล์ ก็จะเกิดปัญหาน่าสนุกอีกแบบ ผมขอผ่าน
    • เห็นด้วย ยิ่งไปกว่านั้น ผมอยากพูดด้วยซ้ำว่า ถ้าไม่มี Prettier เลย คงดีกว่า

  • ยังหงุดหงิดอยู่ที่ eslint plugin หลายตัวเอา linter ดี ๆ ออกแล้วแทนที่ด้วย Prettier
    Prettier บังคับเกินไป เดาเหตุผลยาก และเป็นอีกเครื่องมือหนึ่งที่ผมไม่เคยต้องการ

    • กฎสไตล์ที่ถูกเลิกใช้ถูกพอร์ตไปยังโปรเจกต์ใหม่แล้ว: https://eslint.style/guide/why
    • จุดประสงค์ของเครื่องมือแบบนั้นก็คือการยุติ การถกเถียงเรื่องสไตล์ นั่นแหละ
    • ไม่ค่อยเข้าใจว่ากรณีไหนที่ต้อง “อนุมาน” Prettier
      นึกออกแค่บางครั้งมีปัญหา merge conflict เท่านั้น

  • แม้จะมีกระแสการพอร์ตไป Rust แต่เพราะ Prettier รันทุกครั้งที่บันทึกไฟล์ การเพิ่มความเร็ว น่าจะมีผลมากทีเดียว
    อีกไม่นานจะลองใช้ Biome และขอแสดงความยินดีกับโปรเจกต์ Biome

    • ไม่เคยรู้สึกหน่วงตอน Prettier รันกับไฟล์เดียว
      ประสิทธิภาพจะสำคัญเมื่อรัน formatter กับทั้ง repository
      ในการใช้งานแบบโต้ตอบ ควรใช้โปรเซสที่เปิดค้างและวอร์มแล้ว ซึ่งทำให้เวลาเริ่มต้นของ Node ไม่สำคัญ ตามอุดมคติแล้ว type checking, linting, highlighting และ formatting ควรอยู่ใน language service เดียวกัน ทำ incremental parsing ทุกครั้งที่กดแป้น และอัปเดต AST ที่แชร์กัน
    • งานนี้ทำให้นึกถึงกระแส ruff ในชุมชน Python
      คาดหวังว่าจะมี การปรับปรุงประสิทธิภาพและความเร็ว ที่ส่งผลกว้าง
    • แนะนำให้ใช้เครื่องมือ lint-staged เพื่อให้ Prettier รันเฉพาะไฟล์ที่เปลี่ยน ไม่ใช่ทั้งชุดทุกครั้งที่บันทึก
      ในโปรเจกต์ใหญ่ ความแตกต่างมากทีเดียว

  • “ตอนนี้เราสามารถโฟกัสด้านสำคัญถัดไปได้ นั่นคือประสิทธิภาพ Prettier ไม่เคยเร็วโดยธรรมชาติ แต่ก็เร็วพอสำหรับการใช้งานส่วนใหญ่ จุดนี้ทำให้ไม่พอใจมาตลอด จึงอยากทำอะไรสักอย่าง จะมีวิธีไหนดีกว่าการแข่งขันอย่างเป็นมิตร เมื่อวันที่ 9 พฤศจิกายน ผมตั้ง เงินรางวัล $10k ให้โปรเจกต์ Rust ที่ผ่าน test suite ของ Prettier ได้ 95%”
    ไม่เข้าใจว่าการที่บางอย่างเขียนด้วย Rust จะนำไปสู่ประสิทธิภาพที่ดีกว่าได้อย่างไร อาจแค่ transpile codebase เดิมไปเป็น Rust แล้วรับรางวัลก็ได้

    • พอเห็นคำว่า “แค่” ก็ทำให้คิดว่าสิ่งที่ตามมาคงไม่ง่ายแน่
      เพราะถ้ามันง่ายจริงก็คงไม่จำเป็นต้องใส่คำขยายแบบนั้น
      ในกรณีนี้ไม่รู้ว่าการ transpile codebase JavaScript ไปเป็น Rust นั้นง่ายหรือไม่ สองภาษานี้มีโมเดลความคิด ไลบรารีที่ใช้ และวิธีเขียนโค้ดต่างกันพอสมควร และถึงจะมี transpiler จาก JS เป็น Rust อยู่ ก็สงสัยว่าจะทนทานพอใช้กับ codebase ขนาด Prettier ได้หรือไม่
    • Rust แบบ idiomatic มัก เร็วกว่า 5–10 เท่า เมื่อเทียบกับโค้ด JavaScript/TypeScript ที่ดูคล้ายกัน โดยแทบไม่ต้อง optimize เพิ่ม
      ขึ้นอยู่กับงานและไม่ได้เป็นแบบนั้นเสมอไป แต่ parser ที่จัดการสตริงเยอะ ๆ ถือเป็นกรณีที่เข้าข่ายชัดเจน
    • ในงานประมวลผลสตริง Rust เร็วกว่า JS มาก
      https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/fasta.html
      https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/knucleotide.html
    • คำตอบที่ได้รับจาก vjeux คือแบบนี้: “ทุกวันนี้มีเครื่องมือเว็บเร็ว ๆ จำนวนมากที่เขียนด้วย Rust”
      https://twitter.com/Vjeux/status/1722769322299609565
      ผมยังไม่เชื่อ และดูเหมือนว่า vjeux จะขึ้นขบวน กระแส Rust ไปแล้ว

  • โปรเจกต์ที่ชนะคือ Biome ซึ่งเป็น fork หรือการเปลี่ยนชื่อของโปรเจกต์ Rome ที่ Sebastian McKenzie ผู้สร้าง Babel เริ่มไว้เมื่อหลายปีก่อน
    ดูเหมือนว่า sebmck จะหายไปประมาณปีที่ผ่านมา และเพราะสิทธิ์เข้าถึงทรัพยากรของโปรเจกต์จำนวนมากมีแค่เขาที่ถืออยู่ ผู้ร่วมพัฒนาจึงอัปเดตไม่ได้ ทำให้ต้อง fork
    หวังว่าเขาจะสบายดี และนอกเหนือจากเรื่องนั้น ก็ดีใจที่โปรเจกต์ Biome ดูเหมือนจะเดินหน้าไปได้ดี

  • ไม่เข้าใจว่าทำไมต้องเป็น Rust เท่านั้น
    แค่เป็น “อะไรที่เร็วกว่า” ไม่ได้เหรอ? การทำด้วย Rust เร็วจริงหรือเปล่า? ก็ยังสงสัยด้วยว่าเรื่องอย่าง ความปลอดภัยของหน่วยความจำ หรือการรั่วไหลของหน่วยความจำ สำคัญกับโปรแกรมแบบ Prettier จริง ๆ ไหม

    • โดยเฉพาะใน HN มีคนเสียงดังจำนวนมากที่มองว่า Rust เป็นภาษาที่เร็วที่สุดและปลอดภัยที่สุดในตอนนี้
      ดังนั้นในระดับหนึ่ง นี่อาจเป็น ชาเลนจ์เงินรางวัล แบบ “ถ้าพูดอย่างนั้น ก็พิสูจน์ให้ดูเองสิ”

  • สงสัยว่า benchmark ของ Biome มีอยู่ที่ไหนไหม
    ประสิทธิภาพดีกว่า Prettier แน่ชัดแค่ไหน?

    • เจอบางส่วนที่นี่: https://github.com/biomejs/biome/blob/main/benchmark/README.md
      อ้างว่าเร็วกว่า 25 เท่า แต่ตัวเลขค่อนข้างเก่าแล้ว เลยไม่แน่ใจว่ายังเชื่อได้เหมือนเดิมไหมในตอนนี้ที่เพิ่มฟีเจอร์เข้ามามากแล้ว ถึงอย่างนั้นถ้ายังอยู่แถว ๆ นั้นก็ถือเป็นผลงานที่ยอดเยี่ยมมาก