Deno 2.8

 (deno.com)
1 คะแนน โดย GN⁺ 4 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • deno add และ deno install จะตีความชื่อแพ็กเกจที่ไม่มีคำนำหน้าใน CLI เป็นแพ็กเกจ npm: โดยค่าเริ่มต้น ทำให้ใช้แทน npm install·yarn·pnpm install ในโปรเจ็กต์ Node เดิมได้ง่ายขึ้น
  • deno audit fix จะอัปเกรดแพ็กเกจ npm ที่มีช่องโหว่ใน dependency ไปเป็นแพตช์เวอร์ชันที่ใกล้ที่สุดซึ่งยังคงเป็นไปตามข้อจำกัดของเวอร์ชันโดยอัตโนมัติ และจะแสดงรายการที่ต้องเปลี่ยนเมเจอร์เวอร์ชันแยกต่างหาก
  • มีการเพิ่มคำสั่งย่อยใหม่คือ deno ci, deno pack, deno transpile, deno why, deno bump-version เพื่อรองรับการติดตั้งแบบทำซ้ำได้, การสร้าง tarball สำหรับเผยแพร่ npm, การแปลง TS→JS, การติดตามเส้นทาง dependency และการอัปเดตเวอร์ชันของ workspace
  • ความเข้ากันได้กับ Node.js API เพิ่มขึ้นจากประมาณ 42% ใน Deno 2.7 เป็น 76.4% (3,405/4,457) ใน Deno 2.8 ตามเกณฑ์ของชุดทดสอบของ Node เอง และมี node: โมดูลจำนวนมากที่ถูกโหลดแบบหน่วงเวลา ทำให้โปรแกรมที่ไม่ได้ใช้โมดูลเหล่านั้นเริ่มทำงานได้เร็วขึ้น
  • ประสิทธิภาพ เมื่อเทียบกับ Deno 2.7.1 การติดตั้ง npm แบบ cold เร็วขึ้น 3.66 เท่า จาก 3,319ms เหลือ 906ms, node:buffer base64 ดีขึ้น 3.07 เท่า, throughput ของ node:http ดีขึ้น 2.21 เท่า และ node:crypto scrypt ดีขึ้น 2.12 เท่า
  • การเปลี่ยนแปลงด้านความเข้ากันได้ คือ setTimeout และ setInterval แบบ global จะคืนค่าเป็นอ็อบเจ็กต์ Timeout ของ Node แทนตัวเลข ดังนั้นโค้ดที่เก็บค่าที่คืนมาเป็น number หรือนำไปใช้กับการตรวจชนิดหรือคำนวณเลข ต้องแก้เป็น NodeJS.Timeout เป็นต้น
  • มี TypeScript 6.0.3 ฝังมาให้ และ deno check กับ LSP จะรวม lib.node โดยค่าเริ่มต้น ทำให้ตีความชนิดของ Node เช่น NodeJS.*, Buffer, process ได้โดยไม่ต้องตั้งค่าเพิ่ม
  • ในด้าน การดีบัก แท็บ Network ของ Chrome DevTools จะแสดงทราฟฟิกจาก fetch(), node:http/node:https, WebSocket ของ Deno และสามารถสร้าง V8 profile, SVG flamegraph และรายงาน Markdown ได้ด้วย --cpu-prof, --cpu-prof-flamegraph, --cpu-prof-md
  • ในด้าน การจัดการแพ็กเกจและ workspace มีการเพิ่มโปรโตคอล catalog:, deno install --os --arch, --prod, nodeModulesLinker: "hoisted", min-release-age ใน .npmrc และ --package-json เพื่อช่วยเรื่องการทำเวอร์ชันให้เป็นมาตรฐานเดียวกันใน monorepo, การติดตั้งข้ามแพลตฟอร์ม, การติดตั้งแบบ production และการย้ายจากโปรเจ็กต์ Node เดิม
  • deno compile สามารถตรวจจับโปรเจ็กต์ Next.js, Astro, Fresh, Remix, SvelteKit, Nuxt, SolidStart, TanStack Start, Vite SSR แล้วรัน deno task build พร้อมสร้าง entry point ที่เหมาะสม และยังแสดงความคืบหน้าระหว่างประมวลผล dependency tree ของ npm ขนาดใหญ่ด้วย
  • ในด้าน การทดสอบและ Web API ค่าเริ่มต้นของ sanitizeOps และ sanitizeResources ใน Deno.test() เปลี่ยนเป็น false, มีการเพิ่ม timeout รายเทสต์และ coverage ระดับฟังก์ชัน รวมถึงรองรับ OffscreenCanvas, Headers·Request·Response·Streams ที่โอนย้ายได้, SHA3 digest และ Web Crypto แบบ P-521
  • การอัปเกรดและพื้นฐานรันไทม์ คือ deno upgrade จะลดขนาดดาวน์โหลดจากราว 48MB เหลือ 3~6MB ด้วย delta update เมื่อทำได้, สามารถติดตั้ง PR build ได้ด้วย deno upgrade pr <number> และ V8 ถูกอัปเกรดจาก 14.6 เป็น 14.9

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

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

 
GN⁺ 4 시간 전
ความเห็นจาก Hacker News

  • Deno มีโมเดลสิทธิ์แบบพื้นฐานมาให้จึงมีประโยชน์ เขียนด้วย Rust และรองรับ TypeScript แบบเนทีฟ
    ผมไม่ได้คลุกอยู่ลึกกับ ecosystem ของเว็บดีเวลอปเมนต์/Node/Bun แต่ตลอดหลายปีที่ผ่านมาก็ใช้ Deno กับเซอร์วิสเล็ก ๆ อย่างพอใจ เลยสงสัยว่าทำไม Bun ถึงดูเหมือนเติบโตเร็วมาก ไม่แน่ใจว่าคนใช้มันเป็น bundler เป็นหลักและใช้เป็น JavaScript runtime น้อยกว่าหรือเปล่า
    แค่ระบบสิทธิ์อย่างเดียวก็ทำให้ Deno น่าสนใจแล้ว เลยไม่ค่อยเข้าใจว่าทำไมคนย้ายจาก Node ไป Bun แต่ไม่ไป Deno

    • Deno กับ Bun ตอนเปิดตัวมีจุดโฟกัสต่างกันพอสมควร Deno คือ Ryan ผู้สร้างดั้งเดิมของ Node พยายามแก้หลายอย่างที่เขามองว่าผิดใน Node ส่วน Bun ตั้งเป้ามาตั้งแต่ต้นเรื่องความเข้ากันได้กับ Node และการรันเฟรมเวิร์กยอดนิยมอย่าง Next.js
      อยู่นานทีเดียวที่ dependency และ framework จำนวนมากทำงานบน Deno ได้ไม่ดี และในช่วงแรก ๆ มันยังติดตั้ง dependency จาก npm ไม่ได้ด้วยซ้ำ มองย้อนกลับไปที่การโจมตี supply chain ของ npm หลายครั้ง Ryan อาจจะตัดสินใจถูกก็ได้
      เพราะงั้น Bun เลยดูเหมือน Node ที่ดีกว่าและใช้งานสะดวกกว่า มีของอำนวยความสะดวกเยอะ และแทบไม่ต้องตั้งค่าอะไรเพิ่มก็ใช้ได้เลย ดูเหมือนทีม Deno เองก็รู้ว่าถ้าจะสำเร็จต้องมีความเข้ากันได้กับ Node และช่วงไม่กี่ปีที่ผ่านมาก็โฟกัสตรงนั้น ตอนนี้ผมมองว่า Deno เข้ากันได้กับ Node มากกว่า Bun แล้ว
    • เวลาเริ่ม โปรเจกต์ TypeScript งานอดิเรก เล็ก ๆ คุณใช้แค่ Bun ตัวเดียวก็พอ แทนที่จะต้องจมอยู่ในทะเลของ npm/yarn/berry/pnpm/bubble/vite/webpack/rollup/rolldown/rollout/swc/esbuild/teatime
      อนึ่ง ในรายชื่อพวกนั้นมีบางส่วนเท่านั้นที่เป็นท่าไม้ตายโปเกมอน ที่เหลือคือเครื่องมือจริงใน ecosystem ของ JS/TS
    • ผมใช้ทั้งคู่และชอบทั้งสองตัว Bun ใกล้เคียงกับการเป็นตัวแทน Node แบบ drop-in มากกว่า
      เวลาที่ไม่อยากไปยุ่งกับการตั้งค่าเทสต์, tsconfig หรือ ES modules มันก็มักจะใช้งานได้เลย ส่วน Deno มี standard library ที่ดีมาก รองรับ CLI ยอดเยี่ยม และเมื่อก่อนผมก็ชอบ deno deploy มาก แต่เดี๋ยวนี้มันค่อนข้างจุกจิกแล้ว
    • ผมทำแบ็กเอนด์เป็นหลัก แต่เวลาต้องไปแตะฟรอนต์เอนด์นิดหน่อยในโปรเจกต์ส่วนตัว Deno ดูเป็นตัวเลือกที่สมเหตุสมผลที่สุด
      มันทำงานด้วยแล้วดีมาก เลยน่าเสียดายที่ยังไม่แพร่หลายในหมู่คนสาย JS มากกว่านี้
    • ผมใช้ Deno อยู่ประมาณปีหนึ่ง และก็ชอบมันเพราะข้อดีที่พูดไปก่อนหน้า แต่มีปัญหาเรื่องความเข้ากันได้กับแพ็กเกจอย่าง Astro, Prisma, Vite มากเกินไป
      สุดท้ายเลยย้ายไป Bun แล้วทุกอย่างลื่นขึ้นมาก

  • สงสัยว่าเดี๋ยวนี้ Deno อยู่ในสภาพไหนแล้ว
    Node เป็นทางออกที่มั่นคงและคงจะอยู่ต่อไปอีกนาน ตอนนี้ก็ใช้ TypeScript ได้แล้ว และดูเหมือนอีกไม่นานจะสร้างแอปเป็นไฟล์ executable เดี่ยวได้ รวมถึง native dependency ด้วย
    Bun ดูวุ่น ๆ แต่เร็ว และแนวทางที่รวมทุกอย่างไว้ใน standard library ก็น่าสนใจ แถมยังถูก Anthropic ซื้อกิจการไปแล้ว
    Deno เคยมีเรื่องเล่าที่ดีเกี่ยวกับ sandbox และการดึง dependency ภายนอกที่ง่าย แต่ตอนนี้ sandbox ดูจะกลายเป็นของทั่วไปไปพอสมควรแล้ว และวิธี import ของมันสุดท้ายก็ไม่แน่ใจว่าดีกว่า npm add มากขนาดนั้นไหม

    • Deno เพิ่งปลดพนักงานไปราวครึ่งบริษัทเมื่อประมาณ 2 เดือนก่อน: https://news.ycombinator.com/item?id=47467746
    • มีใครมองการถูก Anthropic ซื้อกิจการเป็นเรื่องบวกด้วยเหรอ?
    • ถ้าอยากให้ ecosystem ไม่หยุดนิ่ง การมีหลายตัวเลือก เป็นเรื่องดี
    • ตอนนี้ก็ทำการแจกจ่ายแบบ ไฟล์ executable เดี่ยว ได้อยู่แล้ว CLI ของผลิตภัณฑ์ผมก็เป็นแอป Node แบบ single executable
    • ไม่รู้มาก่อนเลยว่าจะทำ single executable ที่รวม native dependency ได้ด้วย นั่นเป็นฟีเจอร์ที่ทรงพลังมาก

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

    • มันสนุกมากจริง ๆ เวลาได้ใช้ แทบจะรู้สึกเหมือน ส่วนผสมของ JavaScript กับ Go
      มันเร็ว ยืดหยุ่น มีการจัดการแพ็กเกจที่มีสติกว่าและทรงพลังกว่าทางเลือก JS/TS อื่น ๆ มีโมเดลความปลอดภัยที่ดีกว่า มี standard library ที่ดีกว่า และยังเร็วมากด้วย

  • เผื่อคนที่ไม่คุ้นชื่อ Deno, Deno คือ JavaScript และ TypeScript runtime
    มีรีวิวเปรียบเทียบ Deno 2.6 กับคู่แข่งอย่าง Bun 1.3 และ Node.js 25: https://www.devtoolreviews.com/reviews/bun-vs-node-vs-deno-2...

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

  • รอบการออกรุ่นที่สม่ำเสมอ ของ Deno น่าประทับใจ อยากรู้ว่าเวอร์ชันนี้มีการปรับปรุงประสิทธิภาพอะไรบ้าง

  • คำสั่ง deno pack ใหม่เป็นส่วนเสริมที่ดีสำหรับการแพ็กแบบปลอดภัยและเรียบง่าย
    ถ้าใช้ Node.js ก็มีคำสั่งเดี่ยวที่คล้ายกันได้ผ่าน https://www.npmjs.com/package/ts-node-pack
    ตอนนี้ Node.js รองรับการ import โมดูล .ts แล้ว ดังนั้น repository มากขึ้นน่าจะใช้แนวทางนี้ได้โดยไม่ต้องมีขั้นตอน build หรือใส่ build output ลงไปใน checkout

    • อ่านบล็อกโพสต์นี้แล้วทำให้ผมลังเลทันที deno pack อาจแทน workflow npm publish เดิมของแพ็กเกจโอเพนซอร์สผมได้ และอาจช่วยให้ผมขยับงานไปทาง Deno-first / Deno-centric ต่อได้
      ในทางกลับกัน การที่ Node รองรับ TypeScript มากขึ้นก็ทำให้รู้สึกว่าการเปลี่ยนไปเป็น npm package สำหรับ TypeScript โดยเฉพาะ อาจเป็นสัญญาณเล็ก ๆ ที่ส่งถึง ecosystem ได้เหมือนกัน
      ถึงอย่างนั้นก็ยังดีใจที่ JSR มีตัวตนอยู่ในฐานะ ecosystem ที่ค่อนข้างสะอาดกว่า
    • ฟังดูคล้ายกับ DNT(https://github.com/denoland/dnt) ที่มีมานานแล้วพอสมควร
      เพียงแต่พอมาอยู่ใน Deno CLI แล้ว การมองเห็น ก็มากขึ้นอย่างชัดเจน

  • ถ้า Deno ยึดคุณค่าเริ่มต้นของตัวเองไว้นานกว่านี้อีกหน่อย แรงกดดันเรื่องความเข้ากันได้กับ Node อาจถูก AI agent ช่วยอุดช่องว่างได้พอสมควร
    เพราะแรงกดดันส่วนใหญ่เกิดจากเรื่องความคุ้นชิน ถ้าคุณรู้แค่วิธีตั้งค่าด้วย express.js คุณก็จะรู้สึกว่าเครื่องมือหรือ runtime ใด ๆ หลังจากนั้นควรมี abstraction คล้ายกันเพื่อให้การย้ายผ่านเป็นไปอย่าง “ลื่นไหล” โดยไม่เกี่ยวเลยว่าทางแก้แรกเริ่มนั้นแย่แค่ไหน
    ทุกวันนี้เราสามารถส่งมอบชุดเทคโนโลยีที่จำเป็นไปพร้อมกับผลิตภัณฑ์และแนะนำเทคโนโลยีใหม่ให้ดีเวลอปเปอร์ได้ ซึ่งบางครั้งแทนเอกสารได้จริง และค่อนข้างดีในการแสดงให้เห็นแนวทางทางเลือกที่ดีกว่า

    • ถ้า JS/TS SDK ที่ได้จากผู้ให้บริการ SaaS ใช้บน Deno ไม่ได้แบบไม่ต้องแก้ไข ผมจะไม่เสียเวลาแม้แต่วินาทีเดียวเพื่อไปแก้มัน

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

  • หลังการเปิดตัว Edge.js [1] ก็ดีที่ได้เห็น Deno เริ่มจริงจังกับ ความเข้ากันได้กับ Node.js มากขึ้น
    ในเวลาแค่ประมาณ 2 เดือน มันขยับจากช่วง 40% กว่า ๆ ไปเป็นราว 75% ไม่ว่าจะบังเอิญหรือไม่ก็ตาม นี่เป็นก้าวที่ชัดเจนในทิศทางที่ถูกต้อง
    ทีม Deno ทุกคนทำได้ดีมาก
    [1] https://edgejs.org/

    • โปรโมตตัวเองไม่เบื่อบ้างเหรอ?

  • ผมห่อหุ้มแนวปฏิบัติแบบ Node ส่วนใหญ่ไว้แล้วใช้ Deno เป็น runtime มันทำงานได้ดี
    ถ้าโปรเจกต์เป็น TypeScript ล้วน ผมก็รันด้วย Deno ไปเลย ตัวเลือกเสริมด้านความปลอดภัยก็ดี และผมก็ชอบที่สคริปต์ติดตั้งถูกปิดไว้เป็นค่าเริ่มต้น
    ถ้าคุณยังใช้ Node ตรง ๆ อยู่ ผมว่าเลิกเถอะ อย่างน้อยใช้ Bun ก็ยังดีกว่า
    สำหรับงานแบบ agent-based แทบไม่มีเหตุผลจะใช้ภาษาอื่นนอกจาก Rust กับ TypeScript จะเถียงก็ได้ แต่เรื่อง type safety, memory safety และคอร์ปัสงานขนาดมหาศาลนั้นสำคัญมาก เอเจนต์จะสำรวจได้ง่ายเมื่อมีข้อผิดพลาดที่จุกจิกและมีแพตเทิร์นฝังอยู่ ส่วนฝั่ง UI นั้น TypeScript สมเหตุสมผลที่สุดเพราะมีตัวอย่างดีไซน์อยู่มหาศาล