- Bun 1.0 จัดการการรัน บิลด์ ทดสอบ และดีบัก JavaScript กับ TypeScript ได้ในเครื่องมือเดียว และอยู่ในสถานะเสถียรพร้อมใช้งานจริง
- มีเป้าหมายเป็น ทางเลือกแทน Node.js โดยรองรับ Node API และการ resolve โมดูล เช่น
fs,path,net,__dirname,process, การ resolvenode_modulesและแอปพลิเคชันที่ใช้ Express, Koa, Hono รวมถึง Next.js, Remix, Nuxt, Astro, SvelteKit, Nest, SolidStart, Vite สามารถทำงานบน Bun ได้ - มี native build สำหรับ Windows เป็นครั้งแรก แต่ยัง อยู่ในขั้นทดลองอย่างมาก และปัจจุบันรองรับเฉพาะ JavaScript runtime ส่วน package manager, test runner และ bundler ถูกปิดใช้งาน
- การเปลี่ยนแปลงหลัง Bun 0.8 เพิ่มการรองรับ Next.js, Astro, Nest.js และคำสั่ง
bun devที่เคยถูกเลิกสนับสนุนถูกลบออกแล้ว ตอนนี้จะรันสคริปต์"dev"ในpackage.jsonแทน - Node.js API ที่รองรับใหม่ ได้แก่
child_process.fork()และ IPC,fs.cp(),fs.cpSync(),fs.watchFile(),fs.unwatchFile()และ Unix socket ของnode:http - มี JavaScript transpiler ในตัว runtime จึงรันไฟล์
.js,.ts,.cjs,.mjs,.jsx,.tsxได้โดยไม่ต้องมี dependency เพิ่มเติม - รองรับ ESM และ CommonJS พร้อมกัน ทำให้ใช้
importและrequire()ในไฟล์เดียวกันได้โดยไม่ต้องพึ่งนามสกุลไฟล์หรือการตั้งค่า"type": "module"ในpackage.json - มี Web standard API ในตัว เช่น
fetch,Request,Response,WebSocket,ReadableStreamจึงใช้งานได้โดยไม่ต้องมีแพ็กเกจอย่างnode-fetchและws - ใช้ hot reloading ได้ด้วยตัวเลือก
--hotและBun.serve()ก็อยู่ในขอบเขตของ hot reloading ด้วย - Bun API มี
Bun.file(),Bun.write(),Bun.serve(),bun:sqlite,Bun.passwordสำหรับจัดการ file I/O, เซิร์ฟเวอร์ HTTP/WebSocket, SQLite รวมถึงการ hash และตรวจสอบรหัสผ่านด้วย bcrypt·argon2 - package manager มี
bun install,bun add,bun remove,bun updateและเป็นแบบเข้ากันได้กับ npm โดยอ่านpackage.jsonและเขียนลงในnode_modules - test runner
bun:testมี API ที่เข้ากันได้กับ Jest และจะ remap การ import@jest/globalsกับvitestเป็นbun:testภายใน - bundler รองรับการ bundling และ minify JavaScript กับ TypeScript พร้อม API ปลั๊กอินที่เข้ากันได้กับ esbuild และมี JavaScript macros ที่รันฟังก์ชัน JavaScript ตอน bundle เพื่อ inline ค่า
1 ความคิดเห็น
ความคิดเห็นบน Hacker News
ผมมีส่วนร่วมในการพัฒนา Bun อยู่ ถ้ามีคำถามก็ยินดีตอบ
อยากให้ผู้ดูแลเปลี่ยนลิงก์เป็นบทความบล็อก เพราะอธิบายได้ดีกว่าหน้า GitHub release
บทความบล็อก: https://bun.sh/blog/bun-v1.0
สิ่งที่น่าประทับใจที่สุดคือใช้
importกับrequire()ในไฟล์เดียวกันได้ และไม่ต้องสนใจ.js/.cjs/.mjsหรือ"type": "module"ถ้าไม่ใช่เรื่องนี้ ระบบนิเวศ Node.js ก็แทบจะอยู่ในสภาพพังอย่างสมบูรณ์ และดูเหมือนว่า Bun อาจช่วยกู้มันได้ สิ่งที่ยอดเยี่ยมที่สุดของ Bun ในความเห็นผมไม่ใช่ประสิทธิภาพ แต่เป็น การตัดสินใจที่ใช้งานได้จริงและเป็นมิตรกับนักพัฒนา ซึ่ง Jarred ทำมาอย่างต่อเนื่อง
มันแค่เลือกชุดการประนีประนอมอีกแบบหนึ่ง และผลลัพธ์ก็น่าจะทำให้แพ็กเกจอีกชุดหนึ่งใช้งานไม่ได้ ผมอยากรู้ว่ามีหลักฐานอะไรที่บอกได้ว่า Bun ไขความลับที่เครื่องมืออื่นแก้ไม่ได้แล้ว
สำหรับผม นี่คือ วิธีที่ถูกต้อง ระบบนิเวศที่แตกแยกของ Node สร้างความเสียหายอย่างมากต่อทั้งภาษาและ runtime
importเทียบกับrequireถ้าไม่ได้ใช้แอป React หรือโซลูชันสำเร็จรูป ระบบนิเวศ JS สมัยใหม่ก็เจ็บปวดจริง ๆ โดยเฉพาะในฐานะคนทำไลบรารีเล็ก ๆ นึกไม่ออกเลยว่าคนเริ่มต้นใหม่จะรู้สึกยากและแทบคลั่งแค่ไหน
แค่ข้อเท็จจริงที่ว่า Bun แก้ปัญหานั้นได้ก็เป็นเหตุผลเพียงพอให้ลองใช้แล้ว ผมไม่คิดว่าจะรู้สึกคาดหวังกับ JS runtime หรือ build tool อีกตัวแบบนี้ และหวังว่าทีม Bun จะช่วยให้แต่ละวันของผมยังมีสติขึ้นอีกหน่อย
bundlerช่วง 6 เดือนที่ผ่านมาก็ถือว่าโอเคโดยรวมมีปัญหาน้อยมาก แต่จนกว่าโปรเจกต์ต่าง ๆ จะแก้ ผมก็เลี่ยงด้วย
pnpm patchและการแก้เมตาดาต้า ปี 2023 เรียกได้ว่าเป็นปีของโมดูล และสถานการณ์ก็ใช้ได้type: moduleและ.js/.cjs/.mjs/.tsในแอป production แน่นอนว่าต้องชัดเจนว่าใช้อะไร แต่ในการทำ prototype พฤติกรรมที่ผ่อนปรน ของ Bun ทำให้เขียนโค้ดก่อน แล้วค่อยไปกังวลเรื่องที่เหลือทีหลังได้
สำหรับ release 1.0 ที่ตัดสินใจยังไม่ implement
node:ทั้งหมด ผมคิดว่าน่าจะมีถ้อยคำที่ดีกว่า drop-in replacement ได้ไหมผมผิดหวังค่อนข้างมากตรงที่สองโปรเจกต์แรกที่ลองไม่ใช่การแทนที่แบบ drop-in และตอนนี้ก็เริ่มสงสัยการสื่อสารทั้งหมดของ Bun
บริบทคือทั้งสองโปรเจกต์ใช้
oscที่ต้องการdgramผมเจอตั๋วติดตามคำขอฟีเจอร์เมื่อ 9 เดือนก่อน แต่ไม่มีแผน implement และค้นหาdgramในหน้าประกาศครั้งนี้ก็ไม่เจออะไรเลยข้อเสนอเร็ว ๆ คืออยากให้ระบุโมดูลที่ Bun 1.0 ยังไม่รองรับ และใส่ไว้ในส่วนความเข้ากันได้กับ Node.js
แก้ไข: เจอเอกสารการรองรับ Node แล้ว — https://bun.sh/docs/runtime/nodejs-apis น่าจะลิงก์ไว้ใน release note ด้วย
ดูคร่าว ๆ เหมือนมีโมดูลที่ implement แล้ว 17 ตัว, implement บางส่วน 17 ตัว, ยังไม่ implement 7 ตัว
1.0.0-betaมากกว่า1.0.0ผมเพิ่งติดตั้ง v1.0.0 แล้วรัน
bun replแต่ล้มเหลวด้วย exit code 1 และกลายเป็นว่า REPL พยายามใช้พอร์ต 3000 ซึ่งในสภาพแวดล้อมของผมถูกใช้อยู่แล้ว จากบั๊กที่รายงานใน GitHub ดูเหมือนจะมีปัญหาเล็ก ๆ แบบนี้อยู่พอสมควร ดังนั้นคงต้องระแวงคำกล่าวอ้างทั้งหมดในระดับหนึ่งถึงอย่างนั้น ผมก็ประทับใจอย่างมากกับความเร็วและผลลัพธ์ ไม่คิดว่าโปรเจกต์นี้จะมาถึงจุดนี้ได้เร็วขนาดนี้ และคิดว่าจะใช้เวลานานกว่านี้มาก เมื่อเทียบกันแล้ว Deno เริ่มก่อนตั้งนานแต่ตอนนี้รู้สึกตามหลังอยู่มาก ผมเลยคิดว่าจะลองใช้ Bun กับโปรเจกต์ส่วนตัว
จากประสบการณ์เฉพาะตัว เรากำลังทดลอง Bun กับแอปพลิเคชันขนาดใหญ่ที่มีลูกค้าปัจจุบันหลายล้านคน และปัญหาเดียวจนถึงตอนนี้ไม่ใช่ตัว Bun เอง แต่เป็น
patch-packageที่ยังไม่รองรับไฟล์ lockbun.lockbBun เร็วกว่า Yarn อย่างไม่มีข้อกังขา พูดในฐานะคนที่ชอบ Yarn มากจริง ๆ
“Note — For a detailed breakdown of Node.js compatibility, check out: bun.sh/nodejs.”
ในรายการละเอียดมีระบุโมดูลที่ไม่รองรับไว้
ใช้ AWS SDK v3 ไม่ได้เพราะเกิดข้อผิดพลาดระหว่าง parse response,
node:cryptoยัง implement ไม่ครบจึงใช้สิ่งที่พึ่งพาoctokitหรือjsonwebtokenไม่ได้, ไม่มีjest.resetAllMocks()เลยรัน test ไม่ได้ และในอีกโปรเจกต์หนึ่งbun testบอกว่าเรียก shared library ผิดแล้วไม่ยอมรันเลยดังนั้น workflow ในเครื่องคือ “ลองรันด้วย Bun ถ้าล้มเหลวก็รันใหม่ด้วย Node” อย่างน้อยก็คงใช้แทน npm ได้ แต่ยังจินตนาการไม่ออกว่าจะใช้รัน service จริง ๆ ตอนมันทำงานได้ก็น่าทึ่งมากจริง ๆ เลยตั้งตารออนาคต แต่ถ้าจุดขายคือความเข้ากันได้กับ Node ผมคิดว่ายังเรียกว่า 1.0 ได้ยาก
สงสัยว่าเคยคิดจะย้ายแชตชุมชนไปยังแพลตฟอร์มอื่นที่ไม่ใช่ Discord หรือไม่
Discord ถูกพูดถึงบน HN หลายครั้งเพราะปัญหาเรื่องการเข้าถึง ความเป็นส่วนตัว และการผูกติดกับแพลตฟอร์มปิด และดูเหมือนจะไม่ค่อยสอดคล้องกับจิตวิญญาณโอเพนซอร์สด้วย [1] ก็น่าอ่านประกอบ
[1] https://drewdevault.com/2021/12/28/Dont-use-Discord-for-FOSS...
ในคอมเมนต์ประกาศ Bun 0.6 คำถามคล้ายกันก็ถูก downvote จนเกือบโดน flag: https://news.ycombinator.com/item?id=35970869
ในคอมเมนต์ประกาศ Bun 0.8 คำถามเดียวกันก็แทบไม่ได้รับความสนใจ และปฏิกิริยาประมาณว่า “โปรเจกต์อื่น ๆ ก็ใช้กันทั้งนั้น…”: https://news.ycombinator.com/item?id=37244294
พูดตรง ๆ Discord เป็นที่ที่ดีสำหรับโปรเจกต์ซอฟต์แวร์เสรีและโอเพนซอร์สในการวางการสื่อสารของชุมชน ข้ออ้างในบทความที่ว่า “การเลือก Discord เป็นการทำให้แพลตฟอร์มนั้นชอบธรรมและดึงคุณค่าออกจากแพลตฟอร์ม FOSS” ดูค่อนข้างไม่หนักแน่น Discord เป็นแพลตฟอร์มที่ชอบธรรมจริง ๆ ใช้ฟรี มีฟีเจอร์น่าสนใจมากมาย และการเข้าถึงก็ดี ที่สำคัญ การเลือก Discord ไม่ได้ทำให้คุณค่าของแพลตฟอร์มสื่อสาร FOSS หายไป
คำพูดว่า “ใช้ IRC สิ” ก็ไม่ถูกต้อง IRC เข้าถึงได้ยากมากสำหรับคนจำนวนมากที่ไม่คุ้นเคยกับคอมพิวเตอร์และซอฟต์แวร์
Bun ได้เงินทุนจาก VC เลยสงสัยเรื่อง แผนทำเงิน
เวลาเห็นเทคโนโลยีใหม่ ๆ จะพิจารณาว่า “อีก N ปีข้างหน้า เทคโนโลยีนี้ยังมีโอกาสถูกพัฒนาอย่างคึกคักอยู่แค่ไหน” Bun ต้องหาเงินให้ได้ไม่ทางใดก็ทางหนึ่ง ไม่อย่างนั้นเงินทุนก็จะขาด
การที่ไลเซนส์ของ Bun เป็น MIT นั้นยอดเยี่ยม และทำให้มีความหวังว่าแม้บริษัทจะล้ม โปรเจกต์ก็อาจไม่ตาย อยากให้บริษัทประสบความสำเร็จ แต่ถ้าจะนำ Bun มาใช้ ก็อยากรู้ว่าภายหลังจะมีการ upsell แบบไหน
Oven จะให้บริการ serverless hosting ที่เร็วมากและ continuous integration สำหรับแอป JavaScript ทั้งแบ็กเอนด์และฟรอนต์เอนด์ และจะขับเคลื่อนด้วย Bun
มีแผนรองรับเฟรมเวิร์กฟรอนต์เอนด์อย่าง Next.js, Vite, SvelteKit, SolidStart และเฟรมเวิร์กแบ็กเอนด์อย่าง Express, Fastify, NestJS
แผนคือจะรันเซิร์ฟเวอร์ของตัวเองที่ edge ของศูนย์ข้อมูลทั่วโลก และ Oven ตั้งใจจะผสาน JavaScript stack ทั้งหมดแบบ end-to-end ไปจนถึงฮาร์ดแวร์ เพื่อสร้างความเป็นไปได้ใหม่ ๆ
bun deployเป็นกลยุทธ์ที่พบบ่อย คือดึงการยอมรับจากนักพัฒนาในวงกว้างก่อน แล้วค่อยพาไปสู่การโฮสต์แอปพลิเคชันของตัวเองอย่างนุ่มนวล
พยายามตาม side project ของคนคนเดียวแล้วลำบากมาก เลยย้ายทุกอย่างไป Rollup และไม่หันกลับไปอีก
ความกังวลของโปรเจกต์ที่ได้ทุน VC กับ side project แบบสุ่มย่อมต่างกันแน่ แต่ความเสี่ยงสุดท้ายของทั้งคู่คือ “ถ้าคนที่สร้างมันสนับสนุนเราไม่ได้แล้วจะทำอย่างไร”
เป็นวิธีโปรโมตทุกอย่างว่าเป็น “โอเพนซอร์ส” เพื่อให้ได้ bug report ฟรี การมีส่วนร่วม การตลาด และการยอมรับ แล้วค่อยดันเข้าไปสู่ผลิตภัณฑ์เชิงพาณิชย์
ข้อเสนอที่ว่า Bun อาจแทนที่ความสับสนที่ซ้อนกันเป็นชั้น ๆ ของเครื่องมือบน Node นั้นน่าสนใจมาก
เพราะจะช่วยลด
node,ts-node,nodemon,tsc,jest,ts-jest,webpack, Babel, สเปกโมดูล 2 แบบที่เข้ากันไม่ได้, ความวุ่นวายของ UMD, package manager 3 ตัว และไฟล์ตั้งค่าที่เพิ่มขึ้นแบบระเบิดจากสิ่งเหล่านี้ระบบเครื่องมือรอบ ๆ JavaScript เป็นความเจ็บปวดที่ใหญ่ที่สุดอย่างชัดเจน และทำให้ ES6 + TypeScript ซึ่งเดิมเป็นภาษาที่ค่อนข้างทรงความสามารถและใช้งานสบาย กลายเป็นงานจุกจิกเต็มตัว หวังว่า Bun จะทำได้
น่าจะให้ความรู้สึกคล้ายตอนย้ายจาก CMake ไป Cargo
บล็อกโพสต์นี้แสดง value proposition ของ ซอฟต์แวร์ all-in-one ที่เรียบง่ายกว่าได้อย่างโน้มน้าวมาก
ช่วงนี้รู้สึกดึงดูดกับซอฟต์แวร์แบบ “batteries included” มากกว่า “ไปเอาทุกอย่างมาเอง” เลยตั้งตารอจะลองใช้ Bun
รู้สึกเหมือนเป็นเวอร์ชัน runtime ของเครื่องมือ Rome ที่พยายามแทนที่ซอฟต์แวร์หลายตัวด้วยตัวเดียวที่เร็วกว่า Rome ล้มเหลวและถูก เปลี่ยนเป็น OSS โดยทีมใหม่ แล้ว หวังว่า Bun จะประสบความสำเร็จกว่า แต่ก็เป็นปัญหาที่แก้ยากอย่างชัดเจน
เหมือน Apple ถ้าเป็นเจ้าของและควบคุมฮาร์ดแวร์กับระบบปฏิบัติการเอง ก็สามารถปรับแต่งระบบได้ลึก และยังทำให้มั่นใจได้ว่าอุปกรณ์ทั้งหมดทำงานร่วมกันอย่างลื่นไหล ชุดเครื่องมือ all-in-one ช่วยลดภาระในการวิ่งหาโซลูชันที่สมบูรณ์แบบ และทำให้ใช้โซลูชันที่อยู่ตรงหน้าอยู่แล้ว
อยากฟังจากคนที่เคยใช้ทั้ง Bun และ Deno ว่าในทางปฏิบัติแล้ว ฝั่งไหนเป็น ผู้สืบทอด Node ที่น่าเชื่อถือกว่ากัน
เว็บไซต์ของ Bun อ้างว่าประสิทธิภาพดีกว่า Deno มาก เลยสงสัยว่าเป็นแบบนั้นจริงไหม และถ้าใช่ก็อยากรู้ว่าทำไม Deno ก็ดูเหมือนมีเป้าหมายคล้ายกัน
ยังสงสัยด้วยว่าระหว่างสองโปรเจกต์นี้มีความแตกต่างเชิงปรัชญามากไหม เช่น Bun พยายามนำทุกอย่างมา implement ใหม่ ส่วน Deno ต้องการแนวทางใหม่หลังยุค Node อะไรทำนองนั้นหรือเปล่า มีใครเคยใช้ทั้งคู่มากพอไหม?
ทั้ง Bun และ Deno เป็นเครื่องมือที่มีฐานจากเงินลงทุน VC เลยมีข้อสงสัยพื้นฐานเรื่องการทำรายได้และความยั่งยืน
จุดขายหลักของ Bun ดูเหมือนจะเป็นประสิทธิภาพ แต่แทบไม่เคยเจอปัญหาประสิทธิภาพใหญ่ ๆ กับ Node เลย มันไม่ได้เร็วสุด ๆ ก็จริง แต่มีโอกาสชนข้อจำกัดด้าน I/O มากกว่าความเร็วของ Node มาก
จุดขายหลักของ Deno คือ “Node ที่ทำมาอย่างถูกต้อง” ในหลายด้าน เช่น packaging ที่ดีกว่า การใช้ ES6 อย่างเต็มรูปแบบ และข้ออ้างนั้นก็น่าสนใจ แต่ดูเหมือนว่าจะเลิกพยายามสร้าง ecosystem ใหม่ แล้วหันไปเพิ่มความเข้ากันได้กับ Node แทน
ขณะเดียวกัน การปรับปรุงล่าสุดของ Node เอง เช่น test runner ในตัวและการรองรับ
.envในตัว ก็น่าชื่นใจ ดังนั้นจึงหาเหตุผลหนักแน่นที่จะใช้ Bun หรือ Deno ได้ยาก และต่อให้เปลี่ยนไปใช้ ก็ยังต้องมีเส้นทางที่ชัดเจนในการกลับมาใช้ Node หากเครื่องมือรุ่นใหม่เหล่านี้ไม่ยั่งยืนBun พยายามรวมทุกอย่างไว้ด้วยกันและทำให้เร็วมาก พร้อมกับรักษาความเข้ากันได้กับ Node ให้มากที่สุดเท่าที่ทำได้ ไม่ได้ทิ้ง ecosystem เดิม
Deno เคยมีมุมมองที่ค่อนข้างเผชิญหน้ากับ ecosystem ของ Node และตอนนี้กำลังเพิ่มการรองรับกลับเข้ามา
ถ้ามองในฐานะผู้สืบทอด ผมคิดว่า Bun เป็นตัวเลือกเดียว เพราะพยายามสร้างนวัตกรรมด้วยฟีเจอร์ใหม่ ๆ ขณะยังรักษาความเข้ากันได้กับ Node
Deno ดูใกล้เคียงกับ runtime ทางเลือกของ Node ที่ยึดหลักความปลอดภัยเป็นอันดับแรกมากกว่า และยังมีการรองรับ TypeScript กับ JSX ในตัว รวมถึงเครื่องมืออย่าง linter ด้วย อีกทั้งยังอิง V8 ด้วย ดูเหมือนเป็นรูปแบบที่ Ryan Dahl มองย้อนหลังว่า Node ควรจะเป็นแบบนี้
Bun ในเชิงเทคนิคอิง WebKit ซึ่งไม่แน่ใจว่าทำไม และดูเหมือนไม่ใช่แค่ runtime แต่เป็น เครื่องมือแบบ all-in-one ที่ดีกว่า ยังให้ความเข้ากันได้พื้นฐานกับ framework เดิม ๆ ด้วย Deno จนไม่นานมานี้ยังไม่เข้ากันกับ npm และก็สงสัยเหมือนกันว่านั่นเป็นเจตนาตั้งแต่แรก หรือเป็นการเปลี่ยนทิศทางระหว่างทาง
เดือนที่แล้วเราได้ทดสอบทั้ง Deno และ Bun ในฐานะ runtime ทางเลือก สรุปคือ สำหรับ codebase ที่ซับซ้อนพอสมควร Bun แทบจะทำงานได้เสมอ ส่วน Deno แทบจะใช้ไม่ได้เสมอ
ตอนนี้เรารัน test ทั้งบน Node.js และ Bun และเลิกพยายามนำ Deno มาใช้แล้ว
แก้ไข: ดูเหมือนว่ากำลังเปลี่ยนไป ขอบคุณที่แก้ข้อมูลให้
เดิมทีตั้งใจจะปล่อยเมื่อวาน แต่มี test เรื่องการ stream body ของ
fetch()ที่ล้มเหลวและต้องแก้บทความบล็อกไม่ควรถูกเผยแพร่ก่อนที่ Bun 1.0 จะขึ้น GitHub แต่ลิงก์เปิดให้เข้าถึงได้สาธารณะ และมีบั๊กที่ทำให้ซ่อน draft ใน RSS feed ไม่ได้
บั๊กจริง ๆ ไม่ได้อยู่ที่การ stream body ของ
fetch()แต่อยู่ใน binding ของ JavaScriptCore ที่ดึง property จาก object ซึ่งอาจไม่ได้กำหนด property นั้นไว้ โค้ดบางส่วนตรวจแค่ว่าค่าเป็นJSCellหรือไม่ โดยไม่ได้ตรวจว่าเป็น object หรือเปล่า แม้โดยทั่วไปJSCellจะเป็น object แต่สิ่งอย่าง symbol หรือ BigInt ไม่ใช่JSObjectเธรดเมื่อวาน: https://news.ycombinator.com/item?id=37424724
เป็นคำแนะนำเพิ่มเติม สามารถให้ตัวอย่าง Ansible playbook/task set สำหรับการติดตั้งแบบ “ดาวน์โหลดจากอินเทอร์เน็ต ไม่ใช่จาก repository ของ distribution” พร้อม checksum ที่เหมาะสมอย่าง SHA-256 ได้ Puppet ก็เช่นกัน แต่อาจซับซ้อนกว่าเล็กน้อย
จะช่วยลดงานของผู้ดูแลระบบลงได้บ้าง และถ้าอยากตั้งชื่อก็อาจเรียกว่า SAX หรือประสบการณ์ของผู้ดูแลระบบ
ถ้า Bun สามารถรันและบันเดิลแอป TypeScript React ได้โดยค่าเริ่มต้น ก็สงสัยว่าข้อดีของการใช้ Vite.js บน Bun คืออะไร
คู่มือบนเว็บไซต์ทางการแสดงวิธีใช้ Bun + Vite.js ตอนสร้างแอป TypeScript React เลยทำให้สับสน [1]
บน GitHub ก็มี issue ที่เกี่ยวข้องเช่นกัน [2]
หรือ Vite.js จะรับหน้าที่ในสถานการณ์ที่ซับซ้อนกว่าหรือ use case ขั้นสูงที่ Bun จัดการไม่ได้? การใช้ Vite.js ของผมก็แค่เริ่มจากการตั้งค่า TS+React พื้นฐานแล้ว build เท่านั้น เลยอาจมีอะไรที่ผมมองข้ามไปก็ได้
[1] https://bun.sh/guides/ecosystem/vite
[2] https://github.com/oven-sh/bun/issues/250
ยังไม่เคยลองใช้ Bun เอง แต่เข้าใจว่าสำหรับการรันเซิร์ฟเวอร์พัฒนาในเครื่องจะใช้ Bun แทน Node ได้, สำหรับการบันเดิลจะใช้ Bun แทน esbuild หรือ tsc, Rollup หรือการผสมกันของเครื่องมือเหล่านั้นได้, และสำหรับการแปลงโค้ดจะใช้ Bun แทน Babel กับ TypeScript ได้
สิ่งที่ Vite มอบให้คือการจัดองค์ประกอบที่ช่วยตั้งค่าการพัฒนาแอปพลิเคชันฝั่งฟรอนต์เอนด์ให้ง่าย และให้ ประสบการณ์นักพัฒนา ที่ดีเวลาทำงานในเครื่อง
ตอนนี้ยังมีความซับซ้อนด้านการตั้งค่าอยู่ จึงมองว่าการผสานสองตัวนี้เข้าด้วยกันยังไม่ได้ดีมาก
ความเข้ากันได้กับ ecosystem เดิมเป็นเป้าหมายหลักของ Bun ดังนั้นจึงตั้งใจให้ผู้คนเริ่มใช้กับ codebase เดิมได้ทันที แล้วค่อย ๆ นำไปใช้ในส่วนอื่นมากขึ้น
และเนื่องจาก meta framework ใหม่ ๆ ส่วนใหญ่ เช่น Nuxt, SvelteKit, Astro, SolidStart, Qwik ทำงานอยู่บน Vite จึงสามารถเปิดเส้นทางให้รับ Bun ไปใช้ได้
tscอยู่แล้วทำไมยังต้องใช้ Viteผมมองว่า Bun ไม่ได้ถึงขั้น “รันแอป TypeScript React” มากนัก แต่เป็นการมีการแปลง JSX/TSX มาให้โดยค่าเริ่มต้นมากกว่า