- ช่วงหลังมีทั้งคำวิจารณ์และความกังวลเกี่ยวกับ โมเมนตัม ของ Deno Deploy, KV, Fresh รวมถึงบริษัทและโปรเจ็กต์โดยรวม
- คำวิจารณ์บางส่วนก็มีเหตุผล และการที่ทีม ไม่ได้เปิดเผยความคืบหน้าอย่างเพียงพอ ด้วยตัวเองก็ยิ่งเพิ่มความสับสน แต่ข่าวลือและคำวิจารณ์จำนวนมากนั้นเป็นเพียง การคาดเดาที่ไม่มีมูลหรือข้อมูลที่ไม่ตรงกับข้อเท็จจริง
- หลังการเปิดตัว Deno 2 (ตั้งแต่เดือนตุลาคม 2023 เป็นต้นมา) อัตราการนำไปใช้ตามตัวชี้วัดผู้ใช้งานจริงรายเดือน เพิ่มขึ้นมากกว่า 2 เท่า
- ความเข้ากันได้กับ Node ที่แข็งแกร่ง ของ Deno 2 ช่วยขจัดอุปสรรคสำคัญในการใช้งานจริง และแพลตฟอร์มก็ เร็วขึ้น ทรงพลังขึ้น และเรียบง่ายขึ้น
การเปลี่ยนแปลงและวิวัฒนาการของ Deno Deploy
- หนึ่งในคำถามที่ถูกถามมากที่สุดคือเหตุผลของการ ลดจำนวนรีเจียนที่ใช้งานได้ ของ Deno Deploy ในช่วงหลัง
- เบื้องหลังการลดลงนี้ นอกจากเรื่องต้นทุนแล้ว ยังมีเรื่อง รูปแบบการใช้งานจริงและความต้องการที่เปลี่ยนไป ด้วย
- แอปส่วนใหญ่ไม่ได้ต้องการทุกรีเจียน แต่ให้ความสำคัญกับความเร็ว การดีบัก และการปฏิบัติตามข้อกำหนดใน พื้นที่ที่ใกล้กับข้อมูล มากกว่า
- หลังเปิดตัว Deploy จำนวนรีเจียนเปลี่ยนจาก 25 เป็น 35 และปัจจุบันอยู่ที่ 6 รีเจียน
- หลายรีเจียน แทบไม่มีการใช้งานจริง และการกระจายมากเกินไปกลับทำให้ประสิทธิภาพลดลง (เช่น latency และปัญหาด้านความจุ)
- ขณะนี้กำลังสร้างวิสัยทัศน์ของ “edge” แบบที่ใช้งานได้จริงและตอบโจทย์ผู้ใช้อีกครั้ง
- กำลังพัฒนา Deploy เวอร์ชันใหม่ และแพลตฟอร์มกำลังวิวัฒน์ไปสู่การโฮสต์ แอปพลิเคชันเต็มรูปแบบ
- มีแผนรองรับ subprocess, งานเบื้องหลัง, OpenTelemetry, build pipeline, รีเจียนแบบ self-hosted เป็นต้น
- เร็ว ๆ นี้จะมีความสามารถให้ตรึงแอปไว้กับรีเจียน หรือรันบนคลาวด์ของตัวเองได้
ทิศทางของ KV (key-value store)
- Deno KV คือสโตร์ที่มี API เรียบง่าย ให้ทั้ง ความสอดคล้องทั่วโลกโดยไม่ต้องตั้งค่า และ ความสามารถแบบเรียลไทม์
- เหมาะกับข้อมูลเซสชัน ฟีเจอร์แฟลก และสถานะการทำงานร่วมกัน แต่ ไม่ได้มีไว้สำหรับเป็นฐานข้อมูลอเนกประสงค์
- สำหรับความต้องการด้านการจัดการข้อมูลที่กว้างขึ้น กำลังเดินหน้าสองแนวทาง
- เสริมการผสานรวม ฐานข้อมูลเชิงสัมพันธ์ เดิมเข้ากับ Deno Deploy ให้แน่นแฟ้นขึ้น
- เดินหน้าโปรเจ็กต์ใหม่เพื่อทำให้ การเชื่อมโยงระหว่าง compute กับ state ง่ายขึ้น (ได้แรงบันดาลใจจาก Cloudflare Durable Objects)
- ตามทิศทางนี้ KV จะยังคงอยู่ในสถานะ เบตา และจะรับมืออย่างต่อเนื่องเฉพาะบั๊กสำคัญหรือประเด็นด้านความปลอดภัย
- ในอนาคต โปรเจ็กต์อื่นจะเข้ามารับบทบาทที่เป็นแกนกลางหรือบทบาทที่พัฒนาต่อจากเดิมของโซลูชันด้านการจัดการ state โดยรวม
สถานะของเฟรมเวิร์ก Fresh
- Fresh ยังคงเป็น รากฐานของทุกแอปและเว็บภายในบริษัท และยังได้รับการดูแลและปรับปรุงอย่างต่อเนื่อง
- ทีมตระหนักดีถึงความคาดหวังสูงและการรอคอยที่ยาวนานสำหรับ Fresh 2
- แทนที่จะรีบออกเวอร์ชันใหม่ ทีมให้ความสำคัญกับ การขัดเกลาคุณภาพพื้นฐานและโครงสร้าง ก่อน
- โปรดดูบล็อกโพสต์เกี่ยวกับ รายละเอียดการปรับปรุง ที่เพิ่งประกาศ
- มีแผน ปล่อย Fresh 2 เวอร์ชันเสถียร ภายในปีนี้
Deno: แพลตฟอร์มที่เป็นมากกว่ารันไทม์
- Deno ไม่ใช่แค่รันไทม์ แต่เป็น แพลตฟอร์มระบบ JavaScript แบบครบวงจร
- ด้วยชุดเครื่องมือเดียวกัน สามารถทำงานแบบบูรณาการได้ทั้ง เขียน รัน ทดสอบ ดีพลอย และมอนิเตอร์
- ความเป็นหนึ่งเดียว การตั้งค่าเริ่มต้น แฟลก และการเชื่อมต่อระหว่างเครื่องมือต่าง ๆ กำลังได้รับการเสริมให้แข็งแกร่งขึ้นอย่างต่อเนื่อง
- เป้าหมายไม่ใช่เพียงความเท่าเทียมด้านฟีเจอร์ แต่คือการสร้าง ระบบนิเวศแบบบูรณาการ
- มุ่งยกระดับ คุณภาพเชิงแก่นแท้ของการพัฒนา JavaScript และกำลังท้าทายตัวเองด้วยการขยายขอบเขตเพื่อไปให้ถึงจุดนั้น
เป้าหมายและเหตุผลของแพลตฟอร์มนี้
- ภาษาสคริปต์ มีบทบาทที่ขาดไม่ได้ในการพัฒนางานจริงอย่างรวดเร็ว
- JavaScript มีอนาคตที่สดใสยิ่งขึ้นในแง่ของความเป็นมาตรฐาน ระบบนิเวศขนาดใหญ่ และความสามารถในการขยายไปใช้งานได้หลากหลาย
- จำเป็นต้องมีแพลตฟอร์มแบบ “batteries included” และ Deno ก็มุ่งไปในทิศทางนั้น (มีระบบจัดการสิทธิ์ เว็บเซิร์ฟเวอร์ observability linter type check ฯลฯ มาให้เป็นพื้นฐาน)
- มอบ ประสบการณ์แบบรวมศูนย์แทนเครื่องมือที่กระจัดกระจาย
แผนในอนาคตและการสื่อสารที่เข้มข้นขึ้น
- Deno ไม่ได้กำลังหดตัว แต่กำลังก้าวเข้าสู่ ช่วงขยายตัว
- แพลตฟอร์มยังคงปรับปรุง ความเร็ว ความเข้ากันได้ และความสมบูรณ์ อย่างต่อเนื่อง และ JSR ก็เติบโตขึ้นภายใต้ธรรมาภิบาลที่เป็นอิสระ
- เดินหน้ากิจกรรมหลากหลายเพื่อระบบนิเวศ JavaScript ควบคู่ไปกับความร่วมมือในชุมชนอย่าง TC39/ WinterTC
- จากประสบการณ์ของ Deploy และ KV กำลังพัฒนาผลิตภัณฑ์ใหม่ที่ ยั่งยืนและกระจายตัว อย่างต่อเนื่อง และจะมีข่าวเพิ่มเติมออกมาในเร็ว ๆ นี้
- เพื่อลดข้อถกเถียงและความไม่ไว้วางใจ จะ เสริมการสื่อสารให้มากขึ้น และให้ความสำคัญกับความเชื่อมั่นจากนักพัฒนา
3 ความคิดเห็น
ถ้าเทียบกันแล้ว bun ดีกว่า deno ไหม?
ข่าวลือเรื่อง Deno ซบเซา: ถูกพูดเกินจริงไปมาก
ดูเหมือนว่านี่จะเป็นการตอบกลับโพสต์นี้นะ
เขายังโพสต์แยกต่างหากเกี่ยวกับสาเหตุที่การอัปเดต Fresh ล่าช้าด้วย การอัปเดต Fresh 2 ของเว็บเฟรมเวิร์ก Deno
ความคิดเห็นจาก Hacker News
ดูเหมือนว่าจะชัดเจนมาตั้งแต่แรกแล้วว่า นักพัฒนาส่วนใหญ่ไม่ได้ดีพลอยแค่ฟังก์ชัน stateless แบบง่าย ๆ แต่โดยทั่วไปมักสร้างแอปจริงที่สื่อสารกับฐานข้อมูลเหมือนแอปฟูลสแตก การเพิ่งมาตระหนักเรื่องนี้ตอนนี้จึงให้ความรู้สึกว่าเป็นสิ่งที่ค่อนข้างแน่นอนอยู่แล้ว
รับรู้ว่าช่วงหลังมีเสียงวิจารณ์ต่อ Deno, Deploy, KV, Fresh และแนวโน้มการเติบโตโดยรวม แต่ยังไม่ค่อยเห็นการกล่าวถึงหรือคำตอบต่อประเด็นแนวโน้มการเติบโตโดยเฉพาะ เลยสงสัยว่าเป็นการตั้งใจเลี่ยงหรือไม่ ในเมื่อยอมรับว่าคำวิจารณ์บางส่วนใช้ได้จริง ก็น่าจะยิ่งน่าเชื่อถือกว่านี้ถ้าเปิดเผยด้วยว่าคำวิจารณ์ไหนที่ถูกต้อง และจะจัดการอย่างไร มองว่าการที่บริษัทซื่อสัตย์ถึงขั้นยอมรับข้อเสียของตัวเองกลับเป็นปัจจัยบวกต่อการตัดสินใจเลือกใช้ ขอยกประสบการณ์ว่าชอบแนวทางที่เปิดเผยข้อดีข้อเสียอย่างโปร่งใสแบบหน้า pro/con ของ Migadu
เหตุผลที่คาดหวังกับ Deno ในช่วงแรกคือมันไม่ยึดติดกับความเข้ากันได้กับของเดิม และสามารถเริ่มต้นใหม่ได้อย่างสะอาดด้วยความซับซ้อนน้อย แม้จะมีจุดที่ใช้งานไม่สะดวกกว่า Node บ้าง แต่ก็ยังรู้สึกว่ารับได้ ทว่าหลังจากนั้นกลับเริ่มยึดติดกับความเข้ากันได้กับ Node มากขึ้นเรื่อย ๆ แทนที่จะสร้างทางออกของตัวเอง จนตอนนี้รู้สึกว่าโครงสร้างแบบสองชั้นกลับซับซ้อนกว่า Node เสียอีก แพ็กเกจ Node ควรจะทำงานบน Deno ได้ตามธรรมชาติ แต่ในความเป็นจริงกลับมี edge case จำนวนมากที่ใช้ไม่ได้เพราะ API บางส่วนยังไม่รองรับหรือมีบั๊ก เฟรมเวิร์กทดสอบที่ชอบที่สุดอย่าง AVA ก็ยังไม่รองรับ ก่อนหน้านี้ยังพอเมินชั้นความเข้ากันได้ของ npm แล้วใช้เฉพาะ Deno เองได้ แต่ตอนนี้เริ่มน่ารำคาญขึ้นเรื่อย ๆ แค่ดูตัวเลือก command line ก็เห็นว่าหลายปีมานี้ซับซ้อนขึ้นมาก และส่วนใหญ่ก็มีไว้เพื่อเชื่อมกับ npm ซึ่งสำหรับฉันเป็นแค่ข้อมูลที่ไม่จำเป็น สิ่งที่อยากได้ที่สุดจากความเข้ากันได้กับ Node คือให้ Deno linter รองรับการตั้งค่า ESLint แต่ดูเหมือนจะไม่สนใจเรื่องนี้ ถึงอย่างนั้นก็ยังอยากให้ Deno ประสบความสำเร็จ เพราะมันช่วยผลักดันให้ Node ดีขึ้น เพียงแต่ทิศทางของ Deno ตอนนี้ไม่ค่อยรู้สึกสอดคล้องกับจุดประสงค์ตั้งต้นแล้ว
รู้สึกว่า Deno หลงทิศทาง เดิมทีวางตำแหน่งตัวเองแบบเรียบง่ายว่าเป็น JS/TS runtime ที่ปลอดภัยและเร็ว สร้างด้วย Rust แต่ตอนนี้ในเมนูดรอปดาวน์ ‘Products’ บนเว็บไซต์กลับมีผลิตภัณฑ์หลายตัวเพิ่มเข้ามาอย่างดูรก ๆ เหมือนพยายามเดินตามแนวทางที่ Vercel ทำแพลตฟอร์ม deploy ต่อจาก NextJS
ความคาดหวังต่อ Deno หายไปตั้งแต่มันเพิ่มความเข้ากันได้กับ Node แล้วละทิ้งคำมั่นสัญญาเดิม สำหรับฉันเสน่ห์หลักของ Deno คือการตัดความซับซ้อนและมรดกเก่าที่ไม่ต้องการจาก Node ออกไป แต่ตอนนี้แทบไม่ต่างจาก Node แล้ว เหลือแค่ความต่างเล็กน้อยอย่าง TypeScript ในตัวและ permissions bun.sh เองก็รองรับ Node compatibility เหมือนกัน เลยสงสัยว่ามีใครรู้จักเอนจินสคริปต์ TypeScript ฝั่งเซิร์ฟเวอร์ที่ไม่ได้มุ่งตามความเข้ากันได้กับ Node บ้างหรือไม่
มองว่า npm compatibility เป็นเพียงการเพิ่มความสามารถ จึงไม่จำเป็นต้องมองว่าเสียอะไรไป ไม่จำเป็นต้องใช้ Node API เลยก็ได้ และใช้เฉพาะไลบรารีที่ต้องการจาก jsr.io ก็เพียงพอ ในทางปฏิบัติก็ยังได้ประสบการณ์พัฒนาที่แตกต่างจาก Node บน Deno อยู่ดี เพียงแต่คนที่ต้องการ “ความบริสุทธิ์” แบบสมบูรณ์มีไม่มากนัก ดังนั้นการเลือกความนิยมและความเป็นประโยชน์ใช้สอยจึงอาจเป็นเรื่องน่ายินดีมากกว่า
ตั้งข้อสงสัยว่าทำไมถึงต้องการ TypeScript runtime ที่ไม่มุ่งรองรับ Node แม้ Node จะมีปัญหาหลายอย่าง แต่ก็ยังใช้งานได้ดีพอจนแพร่หลายมาก หากจะสร้างทางเลือกเชิงปฏิบัติได้จริง ก็ต้องมีอย่างใดอย่างหนึ่งคือ (1) มีข้อดีที่เด่นมากพอให้คนยอมรับต้นทุนการย้ายระบบครั้งใหญ่ หรือ (2) มีต้นทุนการย้ายต่ำพร้อมการปรับปรุงที่ชัดเจนในด้านประสิทธิภาพ ความน่าเชื่อถือ หรือการใช้งาน แต่ Deno กลับพลาดทั้งสองด้าน มันรันโค้ด Node เดิมไม่ได้ ขณะเดียวกันก็ไม่มีข้อดีแบบก้าวกระโดดมากพอ จึงเป็นแนวทางที่มีข้อจำกัดและดึงดูดได้เพียง “พวกอุดมคติ” หรือ “นักพัฒนางานอดิเรก”
ถ้าถามถึง TypeScript runtime ที่ไม่มุ่งตาม Node ก็พอนึกถึง workerd ของ Cloudflare Workers แต่โดยพื้นฐานแล้วมันไม่ใช่ backend runtime อเนกประสงค์ และแทบไม่มีแพ็กเกจพื้นฐานหรือความสามารถในตัวให้ใช้งานจริงมากนัก
ส่วนตัวชอบใช้ JSDoc ซึ่งไม่เกี่ยวกับ Node และยังได้ข้อดีคล้ายกันโดยไม่ต้องมีความซับซ้อนของสายการคอมไพล์
หากไม่ได้จำเป็นต้องยึดติดกับ JS ในฝั่ง backend ก็สมเหตุสมผลที่จะพิจารณาทางเลือกที่ดีกว่าแทน TypeScript หากควบคุมสแตกทั้งหมดได้ ก็ไม่มีเหตุผลนักที่จะต้องอยู่กับภาษาแบบ compile-to-JS
คิดว่าบทความล่าสุดน่าจะเป็นปฏิกิริยาต่อโพสต์ก่อนหน้านี้ https://news.ycombinator.com/item?id=43863937
แม้จะเป็นบทความที่ CEO เขียน แต่เนื้อหากลับมุ่งไปที่การสร้างความชอบธรรมให้การตัดสินใจภายในมากกว่าจะตอบคำวิจารณ์ที่เป็นรูปธรรมเกี่ยวกับ Deno โดยตรง ถึงอย่างนั้นก็ยังให้ความรู้สึกว่าชุดผลิตภัณฑ์ Deno ทำงานได้ค่อนข้างดีในสภาพแวดล้อม Deno เอง
ตอนนี้ยังไม่เกิดความเชื่อมั่นหรือความมั่นใจ คงได้รู้ในไม่ช้าว่า Deploy จะออกมาเป็นอย่างไร แต่ในกรณีของ KV ถ้าไม่มีความตั้งใจจะพัฒนาต่อหลังสถานะเบตา ก็ไม่เห็นเหตุผลเลยที่จะใช้กับโปรเจ็กต์ใหม่ ส่วน Fresh บอกว่าจะรีแฟกเตอร์เป็นอัลฟาช่วงปลาย Q3 แต่จริง ๆ แล้วมันก็เป็นเฟรมเวิร์กที่มีให้แค่พื้นฐานอยู่แล้ว และแม้แต่โครงสร้างแบบไม่มี build/compile ซึ่งเป็นจุดเด่นที่พอมองเห็นได้ก็จะหายไปด้วย ตัว runtime ยังพัฒนาต่อเนื่องก็จริง แต่ก็น่าสนใจที่ใน release notes กลับเน้นเรื่องความเข้ากันได้กับ Node/NPM อย่างมาก จนสวนทางกับคำประกาศว่า “ไม่ได้มุ่งสู่ความเท่าเทียมด้านฟีเจอร์กับ runtime อื่น”
คิดว่าการตัดสินใจหยุดพัฒนา KV ต่อเป็นทางเลือกที่แย่มาก บริษัทต่าง ๆ ไม่ได้ไม่ใช้ KV เพราะฟีเจอร์มันแย่ แต่เพราะมันยังติดป้ายเบตาอยู่ ผู้แสดงความเห็นบอกว่าเคยใช้ Cloudflare Workers KV เยอะมาก และไม่ได้สนใจ Durable Objects มากนัก จึงเคยคาดหวังกับ Deno KV แต่ตอนนี้คงต้องตัดออกจากตัวเลือก ให้ความเห็นว่าการประกาศผลิตภัณฑ์ใหม่แล้วปล่อยทิ้งแทบจะทันทีนั้นดูแย่มากในเชิงกลยุทธ์ด้วย
เล่าว่าเคยพิจารณาจะใช้ KV แต่พอมองไม่เห็นอนาคตก็ต้องหันไปมองทางเลือกอื่นอย่างตรงไปตรงมา
สงสัยว่าประเด็นที่ว่านักพัฒนาส่วนใหญ่ดีพลอยไม่ใช่ฟังก์ชัน stateless แบบง่าย ๆ แต่เป็นแอปฟูลสแตกที่ผูกกับฐานข้อมูลแน่นแฟ้นนั้น จริง ๆ ใช้ได้กับฝั่ง serverless โดยรวมด้วยหรือไม่ ถ้าใช่ มันสอดคล้องกับเจตนาเดิมของขบวนการ serverless หรือเป็นเพียงการเลือกเพื่อหลีกเลี่ยงโครงสร้างพื้นฐานที่ซับซ้อนอย่าง Docker/Kubernetes กันแน่
มีคำอธิบายว่า Deno Deploy มักถูกถามบ่อยเรื่องจำนวน region ที่ลดลง ฝั่ง Deno อธิบายทิศทางการปรับให้เหมาะสมว่า แอปส่วนใหญ่ไม่ได้จำเป็นต้องทำงานได้จากทุกที่ทั่วโลก แต่ควรเร็วในจุดที่ใกล้ข้อมูล แก้บั๊กง่าย และสอดคล้องกับข้อกำกับดูแลในพื้นที่เท่าที่จำเป็น อย่างไรก็ตาม ผู้แสดงความเห็นบอกว่าตนเองไม่ได้ใช้ Deno Deploy เพราะตำแหน่ง region ในทางปฏิบัติยังไม่ใกล้พอจนกังวลเรื่องประสิทธิภาพ และก็มีตัวเลือกอื่นมากมายที่อยู่ใกล้ทั้งข้อมูลและผู้ใช้มากกว่า อีกทั้งเรื่องการปฏิบัติตามข้อกำกับก็มักเพียงพอในระดับประเทศอยู่แล้ว จึงมองว่าทิศทางการปรับให้เหมาะสมแบบนี้ยังไม่ค่อยน่าเชื่อถือ