ฉันกังวลเกี่ยวกับ Bun

 (wwj.dev)
4 คะแนน โดย GN⁺ 7 시간 전 | 3 ความคิดเห็น | แชร์ทาง WhatsApp
  • Bun เป็นทั้งรันไทม์ JavaScript ที่รวดเร็วและเครื่องมือที่ช่วยให้ทำงานกับ TypeScript ได้สะดวก แต่หลัง Anthropic เข้าซื้อกิจการในเดือนธันวาคม 2025 ความกังวลก็เพิ่มขึ้นว่า Bun อาจได้รับผลกระทบจากนโยบายผลิตภัณฑ์และแนวทางการดำเนินงาน
  • ในประกาศการเข้าซื้อกิจการระบุว่า Bun จะยังคงเป็นโอเพนซอร์สภายใต้สัญญาอนุญาต MIT และยังคงพัฒนาโดยทีมเดิมต่อไป อีกทั้งยังบอกด้วยว่า Claude Code ถูกแจกจ่ายในรูปแบบไฟล์ปฏิบัติการของ Bun ดังนั้น Anthropic จึงมีแรงจูงใจโดยตรงที่จะรักษา Bun ให้มีเสถียรภาพ
  • หลังเดือนเมษายน 2026 เป็นต้นมา มีการตั้งคำถามเกี่ยวกับ Claude Code ทั้งเรื่องคุณภาพที่ลดลง พฤติกรรมจำกัดการใช้งาน ข้อจำกัดต่อ third-party harness ความสับสนด้านการคิดค่าบริการ และการสื่อสารที่ล่าช้า โดย engineering postmortem ของ Anthropic มองว่าสาเหตุมาจากปัญหาในชั้นผลิตภัณฑ์ เช่น การลดค่าเริ่มต้นของความพยายามในการให้เหตุผล และการเปลี่ยนพรอมป์ต
  • ตามรายงานของ TechCrunch และ Gigazine Claude Code อาจเรียกเก็บเงินเพิ่มสำหรับการรองรับ third-party harness อย่าง OpenClaw หรือแม้แต่เพียงมีการกล่าวถึง OpenClaw ใน git history ก็อาจทำให้ระบบปฏิเสธคำขอหรือก่อให้เกิดการคิดเงินเพิ่มได้ ซึ่งสะท้อนถึงพฤติกรรมที่คาดไม่ถึง
  • ความกังวลไม่ได้อยู่ที่คุณภาพของ Bun เองหรือทีม Bun แต่เป็นความเป็นไปได้ที่นโยบายของ Anthropic จะซึมเข้ามาใน Bun ทำให้บางโปรเจกต์เริ่มย้ายไปใช้ pnpm สำหรับการจัดการแพ็กเกจ และหันมาแนะนำ pnpm สำหรับโปรเจกต์ JavaScript·TypeScript ใหม่ด้วย

เบื้องหลังที่ทำให้ความกังวลเกี่ยวกับ Bun เพิ่มขึ้น

  • Bun เป็นรันไทม์ JavaScript ที่รวดเร็วและใช้งานได้จริง ช่วยให้ทำงานกับ TypeScript ได้สะดวกในสคริปต์ขนาดเล็ก แอป การทดสอบ และเครื่องมือต่าง ๆ
  • ด้วยการติดตั้งที่รวดเร็ว การทดสอบที่เร็วขึ้น การบันเดิลที่ดีกว่า และภาระจาก toolchain ที่ลดลง จึงเป็นเครื่องมือที่ถูกคาดหวังให้ประสบความสำเร็จในฐานะทางเลือกแทน Node.js
  • แกนของความกังวลไม่ได้อยู่ที่คุณภาพของ Bun เอง แต่คือความเสี่ยงที่หลังจาก Bun เข้าไปอยู่ภายในAnthropicแล้ว จะได้รับอิทธิพลจากนโยบายผลิตภัณฑ์และแนวทางการดำเนินงาน

การเข้าซื้อโดย Anthropic และความคาดหวังในช่วงแรก

  • Anthropic เข้าซื้อ Bun ในเดือนธันวาคม 2025
  • ตามประกาศการเข้าซื้อ Bun จะยังคงเป็นโอเพนซอร์สภายใต้สัญญาอนุญาต MIT ต่อไป พัฒนาโดยทีมเดิม และโรดแมปก็ยังคงโฟกัสที่เครื่องมือ JavaScript ประสิทธิภาพสูงและความเข้ากันได้กับ Node.js
  • ในประกาศมีข้อความว่า “Claude Code ships as a Bun executable to millions of users. If Bun breaks, Claude Code breaks. Anthropic has direct incentive to keep Bun excellent.”
  • ตอนนั้นจึงมองได้ว่า เนื่องจาก Claude Code ทำงานอยู่บน Bun ทำให้ Anthropic มีแรงจูงใจโดยตรงที่จะรักษา Bun ให้เร็วและเสถียร
  • ตรรกะนั้นยังคงใช้ได้อยู่ในตอนนี้ แต่ก็เกิดความกังวลขึ้นว่าเริ่มเห็นรอยร้าวในวิธีที่ Anthropic ดำเนินงานด้านซอฟต์แวร์ผลิตภัณฑ์

การเปลี่ยนแปลงของมุมมองต่อ Claude Code

  • ประเด็นกังวลหลักไม่ได้อยู่ที่คุณภาพของโมเดลของ Anthropic เอง
  • กลุ่มโมเดลที่คาดว่าเป็น Claude Opus 4.6 ยังถูกประเมินว่าเป็นโมเดลที่ดีสำหรับงานเขียนโค้ด การเขียน การให้เหตุผล และงานพัฒนาทั่วไป
  • ปัญหาอยู่ที่ชั้นผลิตภัณฑ์รอบตัวโมเดล และข้อสรุปสำคัญคือประสบการณ์ใช้งาน Claude Code ในตอนนี้แย่ลงอย่างมาก
  • ราวหนึ่งปีก่อน Claude Code ให้ความรู้สึกว่าเป็นเครื่องมือที่สามารถอ่านโปรเจกต์ สร้างการแก้ไขที่มีจุดโฟกัส รันคำสั่ง แก้ข้อผิดพลาด และเดินหน้าต่อได้
  • ในเวลานั้น Claude Code เป็นหนึ่งในเครื่องมือ AI สำหรับเขียนโค้ดยุคแรก ๆ ที่ทำให้เชื่อว่าเวิร์กโฟลว์ของนักพัฒนาสามารถเปลี่ยนจากแบบเน้น autocomplete ไปเป็นแบบเน้นagentได้
  • แม้ในเดือนธันวาคม 2025 Claude Code จะเริ่มแย่ลงแล้ว แต่ก็ยังใช้งานได้ และการเข้าซื้อ Bun ก็ยังพอเข้าใจได้ในมุมที่ Anthropic กำลังสร้างอนาคตของเครื่องมือเขียนโค้ด

ปัญหาของ Claude Code หลังเดือนเมษายน 2026

  • ตั้งแต่เดือนเมษายน 2026 นักพัฒนาเริ่มตั้งข้อสังเกตเกี่ยวกับคุณภาพของ Claude Code พฤติกรรมจำกัดการใช้งาน ข้อจำกัดของ third-party harness การคิดค่าบริการที่สับสน และการสื่อสารที่ล่าช้า
  • Anthropic เผยแพร่ engineering postmortem และชี้ว่าต้นเหตุมาจากปัญหาในชั้นผลิตภัณฑ์ เช่น การลดค่าเริ่มต้นของความพยายามในการให้เหตุผล บั๊กของเซสชันเก่า และการเปลี่ยนพรอมป์ตที่ทำลายคุณภาพการเขียนโค้ด
  • การวิเคราะห์หลังเหตุการณ์นี้ยังดีกว่าการทำเหมือนไม่มีอะไรเกิดขึ้น และถูกมองว่าเป็นหนึ่งในไม่กี่ครั้งที่ Anthropic ยอมรับความรับผิดชอบของตัวเอง
  • ตาม รายงานของ TechCrunch Anthropic แจ้งผู้สมัครสมาชิก Claude Code ว่าจะต้องจ่ายเพิ่มเพื่อรองรับ OpenClaw และ third-party harness อื่น ๆ
  • ตาม รายงานของ Gigazine เพียงมี OpenClaw อยู่ใน git history ก็อาจทำให้ Claude Code ปฏิเสธคำขอหรือทำให้เกิดการคิดเงินเพิ่มได้
  • รายงานดังกล่าวอ้างคำพูดของ Theo ว่า แม้จะเรียกใช้ claude -p "hi" โดยตรงในรีโพซิทอรีว่างเปล่า ก็ยังสามารถกระตุ้นพฤติกรรมนี้ได้ เพียงเพราะมีการกล่าวถึง OpenClaw ในคอมมิตล่าสุดภายใน JSON blob
  • เหตุการณ์ที่เกี่ยวข้องยังสามารถตรวจสอบได้จากคลิปวิดีโอ
  • พฤติกรรมลักษณะนี้ทำให้ผลิตภัณฑ์ดูเหมือนถูกปล่อยการเปลี่ยนแปลงออกมาโดยที่ทีมภายในยังไม่ได้ใช้งานจริงในระดับประสบการณ์โค้ดมากพอ
  • จากมุมมองภายนอก Claude Code ดูเหมือนกำลังมุ่งไปผิดทาง ด้วยข้อจำกัดที่มากขึ้น การคิดเงินที่แปลกประหลาด และพฤติกรรมไม่คาดคิดที่เปลี่ยนไปตามข้อความในคอมมิต
  • กระแสแบบนี้ถูกอธิบายด้วยคำว่า enshittification

ความกังวลที่ลามมาถึง Bun

  • Bun ฝังตัวอยู่ลึกภายใน Claude Code และเพราะ Claude Code ดูเหมือนกำลังแย่ลง จึงเกิดความกังวลว่า Bun อาจเดินไปในทิศทางเดียวกัน
  • ไม่ได้หมายความว่า Bun แย่ หรือทีม Bun หมดความสนใจแล้ว
  • ปัญหาคือยิ่ง Bun และทีม Bun ถูกรวมเข้ากับ Anthropic มากขึ้น ก็ยิ่งเป็นไปได้ว่านโยบายของ Anthropic จะเข้ามาด้วย
  • หากนโยบายที่ดูเหมือนทำให้ Claude Code เสียหายเริ่มส่งผลกับ Bun ด้วย ก็อาจเกิดปัญหาในลักษณะที่ดูเหมือนทีมไม่ได้ใช้งานผลิตภัณฑ์ของตัวเองจริง ๆ ขึ้นใน Bun ได้เช่นกัน
  • เพียงแค่ความเป็นไปได้นี้ก็ทำให้ยากที่จะมั่นใจว่าจะใช้ Bun ต่อไปในบางโปรเจกต์หรือไม่

ย้ายไปใช้ pnpm ไปก่อนในช่วงนี้

  • Bun มีฟีเจอร์มากกว่า pnpm ภายในเครื่องมือเดียว
  • Bun รองรับ TypeScript โดยไม่ต้องมีขั้นตอน build แยกต่างหาก มีบันเดลเลอร์แทน Vite และมีฟีเจอร์ทดสอบแทน vitest
  • การรวมความสามารถเหล่านี้ไว้ใน toolchain เดียวเป็นข้อดีใหญ่จริง ๆ
  • pnpm ไม่ได้เป็นตัวแทน Node.js และก็ไม่ใช่ตัวแทน Bun แต่เป็นเพียงตัวจัดการแพ็กเกจ
  • อย่างไรก็ตาม หากสิ่งที่ใช้ Bun บ่อยที่สุดในงานประจำวันคือการจัดการแพ็กเกจ ทั้ง Bun และ pnpm ต่างก็มีการติดตั้งที่รวดเร็ว การรองรับ monorepo ที่ดี และการใช้พื้นที่ดิสก์อย่างสมเหตุสมผล
  • โปรเจกต์บางส่วนที่ใช้งาน Bun อยู่ในตอนนี้จึงเลือกย้ายออกจาก Bun ไปใช้ pnpm
  • ตอนนี้หากมีคนถามว่าควรแนะนำอะไรสำหรับโปรเจกต์ JavaScript หรือ TypeScript คำตอบก็คือ pnpm

นี่ไม่ใช่คำแนะนำให้เลิกใช้ Bun

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

ความเป็นไปได้ที่ยังเหลืออยู่และบทสรุป

  • ยังคงหวังว่า Bun จะรักษาคุณภาพที่ยอดเยี่ยมต่อไป ทีม Bun จะยังปล่อยผลงานที่ดีออกมา และ Anthropic จะให้ความเป็นอิสระมากพอสำหรับการตัดสินใจที่เหมาะกับ ecosystem ของ JavaScript
  • Anthropic มีทั้งเงิน อำนาจในการกระจายซอฟต์แวร์ และเหตุผลเชิงปฏิบัติที่ต้องใส่ใจประสิทธิภาพและเสถียรภาพของ Bun
  • Bun อาจยังแข็งแกร่งขึ้นได้หลังผ่านสถานการณ์นี้
  • อย่างไรก็ตาม ความเชื่อมั่นต่อสถานการณ์ปัจจุบันก็ลดลงเมื่อเทียบกับเดือนธันวาคม 2025
  • Claude Code ในอดีตเคยดูเหมือนเป็นหลักฐานว่า Anthropic เข้าใจเครื่องมือสำหรับนักพัฒนา แต่ตอนนี้กลับดูเหมือนเป็นสัญญาณเตือนว่า Anthropic อาจไม่เข้าใจสิ่งที่จำเป็นต่อการดูแลและปรับปรุงผลิตภัณฑ์ในระยะยาว
  • Bun ยังยอดเยี่ยมอยู่ แต่ยากจะรู้ว่าจากนี้จะมุ่งหน้าไปทางไหน
  • สถานการณ์อาจเปลี่ยนไปโดยสิ้นเชิงในอีกหนึ่งปีข้างหน้า จึงมีแผนจะกลับมาตรวจสอบอีกครั้งว่าการคาดการณ์นี้ถูกต้องหรือไม่

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

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

 
click 3 시간 전

ยอมรับว่าเพราะ bun ทำให้ node เปลี่ยนไปเยอะเหมือนกัน แต่พอเห็นในรีโพมีแต่ AI เปิด PR มาตบมือกันเอง ก็กลัวว่าจะไปเหยียบกับระเบิด regression ที่ทำให้ของที่เคยใช้ได้กลับใช้ไม่ได้
ก่อนที่ anthropic จะเข้าซื้อกิจการ ผมเคยใช้ bun เป็นหลัก แต่ตอนนี้กลับไปใช้ node อีกแล้ว
ผมยังคิดว่าฟีเจอร์ sfx เป็นฟีเจอร์ไม้ตายอยู่เหมือนเดิม แต่ถ้าไม่ได้ต้องการสิ่งนั้น ก็ยังไม่ค่อยรู้ว่ามีเหตุผลอะไรที่ต้องรีบใช้ bun ตอนนี้
 
GN⁺ 7 시간 전
ความเห็นจาก Hacker News

  • ไม่เห็นด้วยกับสมมติฐานทั้งหมด: ต่อให้ยังไม่ถูกซื้อกิจการ Bun ก็ต้องหาวิธีสร้างรายได้ สักวันอยู่ดี
    การที่บริษัทแม่มีพฤติกรรมไม่ดีในซอฟต์แวร์ตัวอื่นอย่าง Claude Code ไม่ได้แปลว่า Bun จะต้องแย่ลงตามไปด้วยเสมอไป เข้าใจความกังวล แต่ยังคงมอง Bun ในแง่บวกอยู่
    Claude Code เป็นผลิตภัณฑ์หลักของ Anthropic และกำลังเติบโตเร็วมาก การเปลี่ยนแปลงเล็กน้อยก็อาจกลายเป็นประเด็นเรื่องการคิดเงินได้ ในทางกลับกัน Bun เป็น JavaScript runtime จึงโฟกัสกับการเป็น runtime ที่ดีที่สุดได้ และไม่ได้กระทบรายได้หรือกำไรขาดทุนของ Anthropic โดยตรง จึงไม่จำเป็นต้องรีบออกแพตช์เพราะการใช้งานเกินขอบเขตเหมือน Claude Code มากนัก
    อีกไม่กี่ปีข้างหน้าจะเป็นอย่างไรยังไม่แน่ชัด แต่ ณ ตอนนี้ที่เพิ่งถูกซื้อกิจการ ยังไม่ได้กังวลมาก

    • น่าสนใจที่ผู้คนยอมรับคำอธิบายเรื่อง การใช้งานเกินขอบเขต กันเร็วมาก ห้องแล็บ AI ใหญ่ ๆ รู้มานานแล้วว่าพวกเขาไม่ได้กำไรจากผู้ใช้ที่ใช้แพ็กเกจสมัครสมาชิกหนัก ๆ ไม่ว่าผู้ใช้จะใช้เอเจนต์หรือเครื่องมือรันแบบใดก็ตาม ราคาที่ยุติธรรมและทำกำไรได้คือการคิดค่าบริการตามการใช้โทเคนจริง
      ห้องแล็บเหล่านี้พยายามฆ่าการแข่งขัน เพราะเครื่องมือรันของบุคคลที่สามเสี่ยงจะทำให้โมเดลภาษาขนาดใหญ่พื้นฐานกลายเป็นสินค้าทั่วไป ขณะเดียวกันก็เล่นเกมไก่ว่าใครจะยอมขาดทุนได้นานกว่ากัน
      สุดท้ายก็ต้องตั้งราคาสินค้าให้เหมาะสม และได้แต่หวังว่าก่อนถึงตอนนั้นจะกำจัดคู่แข่งไปหมดแล้ว แต่ดูเหมือนพวกเขาจะแพ้เกมนี้อยู่แล้ว โมเดลที่มีประโยชน์เล็กลงทุกปีและต้นทุนการรันก็ถูกลงจนผ่านจุดที่การพัฒนาเครื่องมือรันของบุคคลที่สามจะเดินหน้าต่อได้โดยไม่ต้องพึ่งฐานผู้ใช้แบบสมัครสมาชิกแล้ว
      เดิมพันหลักที่ว่า “AI ที่มีประโยชน์ต้องใช้ฮาร์ดแวร์ที่แพงมาก” ล้มเหลวไปแล้ว และเดิมพันที่สองว่าจะผูกผู้ใช้ไว้กับระบบนิเวศก่อนแล้วค่อยสร้างรายได้ทีหลังก็น่าจะล้มเหลวเช่นกัน สุดท้ายก็ต้องแข่งกันด้วย ความสามารถของตัวผลิตภัณฑ์เอง ซึ่งทำกำไรได้น้อยกว่ามาก
    • ผมมองว่าสถานการณ์ที่ว่า “ต่อให้ก่อนถูกซื้อ Bun ก็ต้องหาวิธีสร้างรายได้สักวัน” นั้นไม่สมเหตุสมผลอยู่แล้ว การที่ผู้คนไปพึ่งพา JavaScript runtime ที่ต้องสร้างรายได้สักวัน ก็ดูแปลก และยิ่งแปลกเข้าไปอีกที่มันถูกซื้อโดยหนึ่งในบริษัทขาดทุนตัวแทนของอุตสาหกรรมที่ขาดทุนหนักที่สุด แต่คนก็ยังมีความหวังกันอยู่
    • ดูเหมือนคุณจะประเมินผลกระทบของ นโยบายและวัฒนธรรม ของบริษัทต่อผลิตภัณฑ์ต่ำเกินไป
      ตอนนี้บางทีมเดินหน้าแบบทุ่มหมดหน้าตักกับ AI และถึงขั้นไม่อยากดูโค้ดเองแล้ว ผมเห็นกับตาและผลลัพธ์ก็ออกมาตามคาด มันใช้ได้ดีในระดับหนึ่ง แต่โดยเฉพาะเมื่อแต่ละทีมมีศัพท์เทคนิคและความเข้าใจไม่ตรงกัน ความซับซ้อนจะสะสม ความผิดพลาดก็จะพอกพูน และสุดท้ายก็จะไม่มีคนหรือทีมที่รู้จริงแล้วว่าซอฟต์แวร์ทำงานอย่างไร
      ยังมีแนวโน้มที่จะไม่ให้คนทดสอบหรือทำประกันคุณภาพ แต่เพิ่มจาก unit test และ integration test ไปสู่การให้ AI ควบคุมเบราว์เซอร์หรือเครื่องมือด้วย วัฒนธรรมของ Anthropic อาจเปลี่ยนวิธีทำงานและวิธีคิดของทีม Bun ได้
      ถ้าวัฒนธรรมและวิธีคิดแบบนี้กลายเป็นมาตรฐาน โมเดลก็ต้องดีขึ้นมาก ๆ ไม่อย่างนั้น คุณภาพซอฟต์แวร์ จะตกลง
      Matt Pocock มีวิดีโอพูดไว้ดีมาก: https://youtu.be/v4F1gFy-hqg
      “โค้ดไม่ได้ราคาถูก โค้ดที่แย่มีราคาแพงที่สุดเท่าที่เคยมีมา เพราะถ้าคุณมี codebase ที่แก้ไขยาก คุณก็ใช้ประโยชน์จากความอุดมสมบูรณ์ที่ AI มอบให้ไม่ได้ แต่กับ codebase ที่ดี AI ทำงานได้ดีมาก ๆ จริง ๆ”
      พอปล่อยให้โค้ดแย่สะสมตัวเองแล้ว จะดึงกลับมายากมาก
    • ถ้าใช้ตรรกะเดียวกัน GitHub ก่อนถูกซื้อกิจการก็ต้องหาวิธีสร้างรายได้สักวันเหมือนกัน การที่บริษัทแม่อย่าง Microsoft เคยมีพฤติกรรมแย่กับ Embrace, Extend, Extinguish หรือกับ MS Windows ไม่ได้แปลว่า GitHub จะต้องแย่ลงไปด้วย ดังนั้นการบอกว่าเข้าใจความกังวลแต่ยังมอง GitHub ในแง่บวก ก็ไม่ได้ต่างจากข้ออ้างนี้เลย
    • Anthropic ซื้อ Bun มาไม่ใช่เพื่อชุมชน JavaScript โดยรวม แต่เพื่อปกป้องและขยาย การลงทุนใน Claude Code เรื่องนี้อาจดูชัดเจนอยู่แล้ว แต่ก็ควรพูดให้ชัด ในระยะยาวผลลัพธ์จะเป็นไปตามแรงจูงใจ

  • ผมไม่เข้าใจว่าทำไมคนถึงใช้ Deno หรือ Bun แทน Node การมีคู่แข่งของ JavaScript runtime เป็นเรื่องดี แต่ผมไม่ค่อยเห็นประโยชน์ที่ได้จากการย้ายออกจาก Node
    Bun ไม่มี REPL และ JavaScript engine ก็แย่กว่า ส่วน Deno ดูเหมือน Node ที่ถูกจำกัดและมีระบบ permission ที่น่ารำคาญติดมาด้วย และเท่าที่รู้ก็ไม่มี sqlite ทั้งคู่บอกว่าเร็ว แต่ดูเหมือนจะเร็วแค่ใน benchmark ที่คัดมา และจาก workload ที่ผมลองเองเมื่อราว 1 ปีก่อน ทั้งคู่ช้ากว่า Node
    แต่ก็จำได้ว่าเคยส่งมอบเครื่องมือ ERP เล็ก ๆ ตัวหนึ่ง และเครื่องมือสำหรับห่อโปรเจกต์เป็น *.exe ของ Bun ดูแข็งแรงที่สุด เลยใช้ Bun ตอนนั้นทั้งระบบเขียนด้วย Node แบบไม่มี dependency แล้วใช้ Bun แค่ตอน deploy ซึ่งประสบการณ์ส่วนนั้นดีกว่า Node ชัดเจน

    • Deno ก็มี sqlite: https://docs.deno.com/examples/sqlite/
    • ประสบการณ์นักพัฒนา ของ Bun ดีกว่า Node มาก โดยเฉพาะในโปรเจกต์ TypeScript
    • Deno ดีตรงที่ผู้ใช้แค่รันได้เลยโดยไม่ต้องมี ขั้นตอนติดตั้ง แยก

  • Bun เองก็แทบไม่เคยถูกดูแลจัดการอย่างเหมาะสมอยู่แล้ว แต่ละฟีเจอร์เต็มไปด้วยบั๊กและช่องโหว่ แก้ไม่กี่อย่างในแต่ละรีลีสก็มีอย่างอื่นพังตามมา
    patch release ล่าสุดตัวหนึ่งยัดทั้งฟีเจอร์ใหญ่และ breaking change มามากพอ ๆ กับที่ซอฟต์แวร์ส่วนใหญ่จะเจอในสอง major version
    ทั้งที่ผมใช้มันหลัก ๆ แค่เป็นตัวรันสคริปต์กับตัวจัดการแพ็กเกจ npm แต่ปริมาณงานที่ต้องเสียไปเพื่อหาว่าเวอร์ชันไหน “ดี” นั้นน่าตกใจ ผมเคยเจอหลายครั้งที่ patch version ค้างกลางการติดตั้งแบบกะทันหัน จนอยู่ช่วงหนึ่งอัปเกรดไม่ได้เลย
    ประมาณสอง minor version ก่อนหน้านี้ ดูเหมือนมันจะทำ สคริปต์ postinstall พังหมดเมื่อใช้ร่วมกับ trustedDependencies ไม่มีคำอธิบายใน release note และเหมือนไม่มีใครรายงานใน GitHub issue ด้วย ช่วง 1.1 ยังพอทำให้ Bun build trustedDependency ใน postinstall ได้ แต่หลังจากนั้นทำไม่ได้อีก และพังมาหลายเดือนแล้ว

    • มี GitHub issue เรื่องค้างตอนติดตั้งอยู่ ตัวสแกนความปลอดภัยส่งรายการ dependency ทั้งหมดเป็นอาร์กิวเมนต์บรรทัดคำสั่ง ซึ่งใน monorepo ขนาดใหญ่บน Linux ทำให้เกิน ARG_MAX
      spawn ค้างเงียบ ๆ โดยไม่คืน error และเพราะตัวสแกนแยกจาก postinstall --ignore-scripts ก็เลยไม่ช่วย พังมาตั้งแต่ 1.3.5 เป็นอย่างน้อย

  • ผมทำงานอยู่ที่ Bun และโพสต์นี้ค่อนข้างทำให้งงอยู่เหมือนกัน ทั้งผมเองและทีม Bun ใช้ Bun ทุกวันและปรับปรุงมันต่อเนื่อง ความเร็วในการพัฒนาจริง ๆ แล้วกลับเพิ่มขึ้นด้วยซ้ำ หลังจากเข้าร่วมกับ Anthropic แล้ว เสถียรภาพของ Bun ก็ดีขึ้นมาก
    สิ่งที่จะมาใน Bun เวอร์ชันถัดไปมีทั้งการลดขนาดไบนารี Windows x64 ลง 17MB [0], ลดขนาดไบนารี Linux ลง 8MB [1], แฟลก CLI --no-orphans สำหรับปิด child process ที่ยังค้างอยู่แบบ recursive [3], การแคช SSL context สำหรับ client TCP และ Unix socket ซึ่งช่วยลดการใช้หน่วยความจำอย่างมากใน database client อย่าง Mongoose/MongoDB [4], experimental HTTP/3 และ HTTP/2 client ใน fetch [5], experimental HTTP/3 support ใน Bun.serve() [6], และไลบรารีประมวลผลภาพในตัว Bun.Image [7]
    ยังรวมถึงการปรับปรุงความน่าเชื่อถือของ node:fs, Worker, BroadcastChannel และ MessagePort ด้วย
    เพราะการซื้อกิจการโดย Anthropic ทำให้ Bun ไม่จำเป็นต้องเป็นธุรกิจที่ต้องสร้างรายได้อีกต่อไป Claude Code พึ่งพา Bun และวิศวกรซอฟต์แวร์จำนวนมากก็พึ่งพา Claude Code ในการทำงาน จึงมีแรงจูงใจสูงมากที่จะทำให้ Bun ดีขึ้น
    [0]: https://github.com/oven-sh/bun/pull/30219
    [1]: https://github.com/oven-sh/bun/pull/30098
    [2]: https://github.com/oven-sh/WebKit/pull/211
    [3]: https://github.com/oven-sh/bun/pull/29930
    [4]: https://github.com/oven-sh/bun/pull/29932
    [5]: https://github.com/oven-sh/bun/pull/29863
    [6]: https://github.com/oven-sh/bun/pull/30032

    • การซื้อกิจการในอุตสาหกรรมนี้มักลงเอยแบบเดิมในระดับหนึ่ง ซอฟต์แวร์ที่ถูกซื้อจะค่อย ๆ แย่ลงเมื่อทีมเดิมรับผลตอบแทนแล้วจากไป และวัฒนธรรมเดิมก็ถูกแทนที่ด้วยวัฒนธรรมของเจ้าของใหม่
      Bun อาจเป็นข้อยกเว้นได้ แต่จะบอกว่าความกังวลนี้ไม่มีมูลเลยก็คงไม่ได้
      CEO ของ Anthropic มักพูดคาดการณ์เกินจริงว่า AI จะมาแทนโปรแกรมเมอร์มนุษย์ได้เกือบหมด และ Anthropic ก็นำความเชื่อนั้นไปใช้กับ Claude Code จนกำลังทำมันให้กลายเป็น สปาเกตตีที่บำรุงรักษาไม่ได้
    • ฟีเจอร์ที่ดีที่สุดที่ Bun เพิ่งให้มาคือ ไบนารีแบบพกพา เพราะผู้ใช้จำนวนมากยังใช้ Linux distribution รุ่นเก่าอยู่ ความสามารถในการพกพาจึงสำคัญมาก Node กับ Deno ต้องการ Linux ที่ใหม่กว่า หรือพูดให้ชัดคือ glibc รุ่นใหม่กว่า
    • คำว่า “ทำงานอยู่ที่ Bun” นี่เป็นการพูดน้อยไปมาก ถึงจะมีความกังวลเกี่ยวกับ Anthropic แต่ตราบใดที่ Jarred ยังเป็นผู้นำอยู่ ผมไม่คิดว่า Bun จะหลุดทาง เขาน่าจะใช้ประโยชน์จากเสถียรภาพและเงินทุนขององค์กรที่ใหญ่กว่าได้ดี

  • ผมใช้เวลาหลายชั่วโมงย้าย backend ของเว็บลับมีดจาก Bun ไป Node และรู้สึกดีที่หลีกเลี่ยง ผลของการถูกผูกติด ได้ ตอนแรกผมค่อนข้างเชียร์ Bun มาก แต่ยิ่งนานก็ยิ่งมั่นใจน้อยลง
    สิ่งที่จะคิดถึงคือการ query sqlite ด้วย tagged template literal, Bun.password.verify ที่ใช้ argon2 เป็นค่าเริ่มต้น, การ import HTML, การแปลง JSX และการโหลดไฟล์ .env อัตโนมัติ
    https://burlyburr.com เรียก https://backend.burlyburr.com

    • Node ก็รองรับ การ query sqlite ด้วย tagged template literal
      https://nodejs.org/api/sqlite.html#databasecreatetagstoremax...
    • ผมสงสัยว่าคุณแค่ใช้ helper library เล็ก ๆ เพื่อเอาฟีเจอร์ที่คิดถึงกลับมาไม่ได้หรือ อย่างน้อย Node ก็มี SQLite และ Argon2 อยู่แล้ว ถ้าปัญหาอยู่ที่ interface ก็น่าจะแก้ได้ไม่ยาก
    • Node ก็รองรับการโหลด .env อัตโนมัติและ sqlite เช่นกัน

  • ผมไม่คิดว่า Bun จะทำงานได้ดีอยู่แล้วแม้ก่อนถูกซื้อกิจการ ผมยังใช้มันกับสคริปต์เล็ก ๆ อยู่ แต่ถ้าในที่ทำงานผมคงไม่ deploy service ด้วย Bun
    ด้วยปัญหาหน่วยความจำและความเข้ากันไม่ได้ที่ไม่ยอมถูกแก้ ผมมองว่ามันเป็นของเล่นที่พอใช้ได้และแสดงให้เห็นว่า Node.js ยังมีพื้นที่ให้พัฒนา
    อย่างเช่นผมตามดู https://github.com/oven-sh/bun/issues/14102 อยู่เรื่อย ๆ สุดท้ายไลบรารีต่าง ๆ ก็ต้องใส่เงื่อนไขว่า “ถ้าเป็น Bun ให้ทำ x” ซึ่งมันตรงข้ามกับ ความเข้ากันได้ เลย

    • ผมเคยลองใช้ใน production กับบางโปรเจกต์ แต่ทั้งสองโปรเจกต์ต้องย้อนจาก Bun กลับไป Node อันหนึ่งมี memory leak หนักอย่างที่ว่า อีกอันเจอ error จากความต่างของ API ในจุดอย่าง TextDecoderStream ผมคงไม่ลองใหม่จนกว่าจะถึง Bun v2

  • ทิศทางของ Claude Code และ Anthropic ดูเหมือนกำลังไปทางซ่อนบางอย่างจากผู้ใช้แบบฝืน ๆ ใครที่จำความวุ่นวายตอนที่พฤติกรรมการอ่าน xxx.yy เปลี่ยนจากอ่านไฟล์เดียวเป็นอ่าน 1 หรือ 2 ไฟล์ได้คงพอจำได้
    หลังจากนั้นก็มีการเปลี่ยนแบบนี้อีก และมักจะตั้งค่าไม่ได้หรือทำได้ยากมาก ผมเข้าใจเจตนาทางธุรกิจนะ คืออยากให้ใช้ AI ให้มากที่สุด เอามนุษย์ออกจากวงจร แล้วเก็บข้อมูลเทรนเพิ่มกับการใช้โทเคนให้มากขึ้น
    แต่ผลที่ได้คือ Claude Code แย่ลงมากและเชื่อถือได้น้อยลงมาก มันให้ความรู้สึกเหมือนพยายามแอบแย่งพวงมาลัยไปจากผู้ใช้ และถ้าตามตรรกะนั้นต่อไป ก็จะมีหลายอย่างถูกทำให้ดูสมเหตุสมผลขึ้นเรื่อย ๆ
    ตอนนี้สิ่งที่เพิ่มขึ้นอย่างชัดเจนคือ ความไม่ไว้วางใจ

  • ผมเห็นด้วยกับผู้เขียนต้นฉบับ และก็เข้าใจว่าบางคนอาจรู้สึกว่านี่ยังเป็นปฏิกิริยาที่เร็วเกินไป
    ตอนนี้เราอยู่ในโลกที่ต่างจากเดิมมาก และผู้คนก็รับรู้ ความกังวลด้านจริยธรรม มากขึ้น พร้อมทั้งตั้งใจจะยืนหยัดเพื่อไม่ให้ความผิดพลาดในอดีตเกิดซ้ำอีก
    ในเกณฑ์ทางเทคนิคอาจถือว่าเร็วไป แต่ในเกณฑ์ของความกังวลด้านจริยธรรมก็สมเหตุสมผล การกระทำที่ไม่ถูกต้องไม่ใช่สิ่งที่จะย้อนกลับได้ง่ายเหมือนเมื่อก่อน และถ้าอยากหลีกเลี่ยงผลกระทบใหญ่จากการตัดสินใจแบบนั้น ก็ต้องลงมือเชิงรุก

    • อยากรู้ว่ามีหลักฐานอะไรที่บอกว่าผู้คนรับรู้เรื่องจริยธรรมมากขึ้นกว่าเดิม ผมไม่เห็นว่าตอนนี้คนมีจริยธรรมมากขึ้นกว่าสมัยก่อน ตัวอย่างเช่นพอจะเห็นคนฝั่ง BDS เพิ่มขึ้นนิดหน่อย แต่เรื่องอื่นนอกจากนั้นผมไม่ค่อยเห็น
    • พอมองจากการบ่นเรื่องที่ Firefox กับ Safari ไม่รองรับ Chrome OS platform API หรือความจริงที่ว่า Chrome ถูกแจกจายไปทั่ว ผมไม่คิดว่าคนกำลังยืนหยัดตาม ข้อพิจารณาด้านจริยธรรม กันจริง ๆ

  • ผู้เขียนปิดท้ายด้วยการไล่รายการสิ่งที่ชอบใน Bun แต่ pnpm ไม่มี รายการหลัก ๆ คือ native TS support, บันเดลเลอร์แบบ Vite และตัวรันทดสอบสไตล์ Vitest/Jest
    ถ้าไม่นับบันเดลเลอร์ Node ก็มีครบหมดแล้ว syntax ของตัวรันทดสอบอาจต่างกัน แต่ TypeScript ก็ “ใช้งานได้เลย” เป็นค่าเริ่มต้น และตัวรันทดสอบในตัวก็ใช้งานได้ดีพอ ผมไม่ค่อยแน่ใจว่าจำเป็นต้องไว้อาลัยให้ Bun ขนาดนั้นไหม

    • เพื่อความยุติธรรม Node ไม่มีของพวกนี้จนกระทั่ง Deno และ Bun เข้ามาท้าทาย Deno อย่างเดียวด้วยเหตุผลบางอย่างไม่สามารถสร้างการเปลี่ยนแปลงใหญ่ได้ แต่การมีอยู่ของ Bun ส่งผลจริงกับ Node Technical Steering Committee
      จะบอกว่าการตลาดบนโซเชียลมีเดียที่ชาญฉลาดของ Jarred Sumner เป็นส่วนสำคัญที่สร้างแรงส่งในตอนนี้ก็ได้ เขาทำให้คนหันมาพูดถึง และ Node ก็ได้ประโยชน์จนดีขึ้น
      นอกจากนี้การที่ Bun ผลักดันให้รองรับ Node API ให้ได้มากที่สุด ก็ทำให้ Deno เดินไปในระดับความเข้ากันได้แบบเดียวกัน จนตอนนี้โค้ดส่วนใหญ่แทบไม่ถูกผูกติดกับ runtime เท่าเดิม ผมไม่รู้ว่าจะใช้ Bun ใน production จริงไหม แต่แค่ Bun เคยมีอยู่ก็ทำให้ ระบบนิเวศ JavaScript ดีขึ้นมากแล้ว จึงน่ายินดี
    • Node เพิ่ม native TypeScript ตั้งแต่เมื่อไหร่? รัน node main.ts ได้ตรง ๆ โดยไม่ต้องมี dependency เลยหรือ
    • ถ้ารวมถึงการเขียน TypeScript compiler ใหม่ด้วย ความเกี่ยวข้องของ Bun ก็ยิ่งลดลงไปอีก

  • พูดตามตรง ผมไม่ได้ใช้ Bun มากนักนอกจากเอาไว้ทดสอบโมดูลบ้างเป็นครั้งคราว ในชีวิตประจำวันผมใช้ Deno เป็นหลัก และช่วงหลายปีที่ผ่านมา script shell หลายตัวก็เขียนด้วย Deno
    ผมค่อนข้างชอบประสบการณ์ใช้งานล่าสุด และวิธีอ้างอิงโมดูลจาก repository โดยตรงก็ดีมากโดยเฉพาะกับ script shell
    แต่ผมก็ยังกังวลว่ามันจะทำ รายได้ ได้มากพอโดยยังเปิดฟีเจอร์ไว้แบบนี้หรือไม่ หรืออย่างน้อยจะเปิดให้คนอื่น clone ตามได้หรือไม่ ดังนั้นผมจึงเข้าใจความกังวลบางส่วน
 
jjpark78 3 시간 전

https://github.com/oven-sh/bun/issues/17723

ถ้าแก้อันนี้ได้สักหน่อย ก็น่าจะลองเอาไปรันฝั่งแบ็กเอนด์ดูสักครั้ง...