การเปิดตัวอย่างเป็นทางการของโปรแกรมแก้ไขโค้ด Zed สำหรับ Windows ได้สร้างความตื่นตัวอย่างมากในชุมชนนักพัฒนา แม้การประกาศจะเน้นย้ำถึงการผสานรวมกับ Windows อย่างเป็นธรรมชาติด้วยการเรนเดอร์ DirectX และการรองรับ WSL แต่การสนทนาของผู้ใช้กลับเผยให้เห็นภาพที่ซับซ้อนยิ่งขึ้นเกี่ยวกับความท้าทายในการใช้งานและทางเลือกทางเทคนิคต่างๆ ข้อคิดเห็นจากชุมชนในช่วงสัปดาห์ที่ผ่านมาแสดงให้เห็นว่านักพัฒนากำลังเผชิญกับทุกอย่าง ตั้งแต่ขนาดการติดตั้งไปจนถึงความเข้ากันได้ของ GPU ซึ่งวาดภาพความเป็นจริงของการเปลี่ยนมาใช้โปรแกรมแก้ไขใหม่ที่มุ่งเน้นประสิทธิภาพนี้
คำสัญญาด้านประสิทธิภาพพบกับข้อจำกัดในโลกจริง
การตลาดของ Zed เน้นย้ำถึงประสิทธิภาพที่ใช้การเร่งความเร็วจาก GPU และการรองรับจอแสดงผล 120Hz แต่ประสบการณ์ผู้ใช้กลับเผยให้เห็นข้อจำกัดในทางปฏิบัติบางประการ ผู้ใช้ Windows หลายคนรายงานว่าพบข้อผิดพลาด Unsupported GPU เมื่อรัน Zed ผ่านการเชื่อมต่อ Remote Desktop ซึ่งระบบจะเปลี่ยนไปใช้ Microsoft Basic Render Driver โดยค่าเริ่มต้น สิ่งนี้ทำให้นักพัฒนาที่ทำงานจากระยะไกลไม่สามารถใช้โปรแกรมแก้ไขนี้ในสภาพแวดล้อมการทำงานปกติของพวกเขาได้ ทางแก้ไขชั่วคราว—ซึ่งคือการตั้งค่าตัวแปรสภาพแวดล้อมเพื่อบังคับให้ทำงาน—มาพร้อมกับคำเตือนด้านประสิทธิภาพที่สร้างความกังวลให้กับผู้ใช้ที่พึ่งพาการตั้งค่าการพัฒนาจากระยะไกล
น่าผิดหวังจริงๆ ฉันกำลังใช้งานเครื่องพัฒนาของฉันผ่านทาง Remote Desktop (ผ่าน RSD/mstsc)
นอกจากข้อกำหนดของ GPU แล้ว ผู้ใช้บางส่วนยังตั้งคำถามว่าการมุ่งเน้นด้านประสิทธิภาพนี้ตอบโจทย์ความต้องการที่แท้จริงของพวกเขาหรือไม่ แม้โปรแกรมแก้ไขจะรู้สึกรวดเร็วสำหรับการแก้ไขพื้นฐาน แต่ผู้แสดงความคิดเห็นหลายคนสังเกตว่าการทำงานของ TypeScript LSP อย่างเช่นการข้ามไปยังคำประกาศ (jump to declaration) รู้สึกช้ากว่าใน VS Code ทั้งที่ทั้งคู่ใช้เซิร์ฟเวอร์พื้นฐาน (tsserver) เดียวกัน สิ่งนี้ชี้ให้เห็นว่าการประมวลผลฝั่งไคลเอ็นต์และการจัดการข้อความอาจกำลังสร้างจุดติดขัดที่หักล้างประโยชน์ของการเรนเดอร์ด้วย GPU สำหรับเวิร์กโฟลว์การพัฒนาบางประเภท
การเปรียบเทียบประสิทธิภาพจากรายงานของชุมชน
- เวลาในการเริ่มต้น: โดยทั่วไปแล้วรวดเร็ว แม้ว่าการคอมไพล์จากซอร์สโค้ดบน Windows จะมีรายงานว่าช้า
- TypeScript LSP: ผู้ใช้บางคนรายงานว่า "jump to declaration" ช้ากว่า VS Code
- ไฟล์ขนาดใหญ่: ไม่มีข้อร้องเรียนเฉพาะเจาะจงเกี่ยวกับการจัดการไฟล์ขนาดใหญ่ (ไม่เหมือนกับโปรแกรมแก้ไขบางตัวที่มีปัญหากับไฟล์ minified)
- การใช้หน่วยความจำ: การใช้ RAM ที่ต่ำกว่าโปรแกรมแก้ไขแบบเว็บถูกมองว่าเป็นข้อดี
- ความหน่วงของอินพุต: การรองรับจอแสดงผล 120Hz ได้รับการชื่นชม แม้ว่าบางคนจะตั้งคำถามถึงประโยชน์ในทางปฏิบัติสำหรับการแก้ไขข้อความ
คำถามเรื่อง 400MB: ความกังวลเกี่ยวกับขนาดการติดตั้ง
หนึ่งในหัวข้อที่ถูกพูดถึงมากที่สุดเกี่ยวข้องกับขนาดการติดตั้งของ Zed ซึ่งผู้ใช้หลายคนรายงานว่าอยู่ที่ประมาณ 400MB สิ่งนี้ทำให้หลายคนในชุมชน Rust ประหลาดใจ เนื่องจากโดยทั่วไปแล้วแอปพลิเคชันที่เขียนด้วย Rust มักขึ้นชื่อเรื่องความมีประสิทธิภาพ ขนาดที่ดูเหมือนจะมาจากการเชื่อมโยงไลบรารีที่จำเป็นแบบคงที่ (static linking) ซึ่งรวมถึงไลบรารีการเรนเดอร์กราฟิกส์ที่กำหนดเองของ Zed (GPUI) และโมดูล tree-sitter จำนวนมากสำหรับการเน้นไวยากรณ์ (syntax highlighting)
การถกเถียงนี้เผยให้เห็นความตึงเครียดพื้นฐานในการพัฒนาซอฟต์แวร์สมัยใหม่ ผู้ใช้บางส่วนมองว่าไฟล์ปฏิบัติการขนาดใหญ่เป็นสิ่งที่ยอมรับไม่ได้ และแย้งว่าเราควรมุ่งมั่นที่จะเขียนซอฟต์แวร์ที่ดีขึ้น ที่เร็วกว่า เล็กลง และมีความยืดหยุ่นมากขึ้น ในขณะที่บางคนโต้แย้งว่าการเชื่อมโยงแบบคงที่ให้ประโยชน์จริงในเรื่องของการใช้หน่วยความจำที่ลดลงและการติดตั้งที่ง่ายขึ้น ทำให้การแลกเปลี่ยนนี้คุ้มค่าสำหรับเครื่องมือที่ใช้ในชีวิตประจำวัน ที่น่าสนใจคือ มีผู้ใช้หนึ่งคนค้นพบว่าในระหว่างกระบวนการติดตั้ง ไดเรกทอรีขยายตัวชั่วคราวถึง 897MB ก่อนที่จะทำความสะอาดตัวเองเหลือ 408MB ซึ่งชี้ให้เห็นว่ากระบวนการติดตั้งเองอาจมีส่วนทำให้เกิดความสับสนเกี่ยวกับขนาด
ช่องว่างระหว่างแพลตฟอร์มและคุณสมบัติที่ขาดหายไป
ในขณะที่การรองรับ Windows ถือเป็นก้าวสำคัญ的一次 แต่การสนทนาของชุมชนได้เน้นย้ำถึงช่องว่างเฉพาะแพลตฟอร์มหลายประการ ผู้ใช้ Windows ARM64 แสดงความผิดหวังกับการที่ไม่มีเวอร์ชันทางการสำหรับอุปกรณ์ของพวกเขา แม้จะมีผู้แสดงความคิดเห็นหนึ่งคนสามารถคอมไพล์จากซอร์สโค้ดได้สำเร็จก็ตาม สิ่งนี้ส่งผลกระทบต่อนักพัฒนาที่ใช้อุปกรณ์ Surface Pro รุ่นใหม่และเครื่อง Windows ที่ใช้สถาปัตยกรรม ARM อื่นๆ ซึ่งต้องเลือกระหว่างการคอมไพล์ด้วยตนเองที่ซับซ้อนหรือรอการรองรับอย่างเป็นทางการ
โปรแกรมแก้ไขนี้ยังถูกวิพากษ์วิจารณ์ในเรื่องปัญหาการผสานรวมกับ Windows บางประการ ผู้ใช้รายงานว่าลัดคีย์บอร์ดมาตรฐานของระบบเช่น ALT+F สำหรับเมนูไฟล์ไม่ทำงาน และแนวทางการเรนเดอร์แบบ DirectX ทำให้แอปพลิเคชันทำงานคล้ายกับเกมมากกว่าแอปพลิเคชัน Windows แบบดั้งเดิม นอกจากนี้ ผู้ใช้หลายคนยืนยันว่า Zed ในปัจจุบันรองรับเฉพาะไฟล์ที่เข้ารหัส UTF-8 เท่านั้น ทำให้ไม่เหมาะสำหรับการเปิดไฟล์ข้อความทั่วไปหลายไฟล์ที่ใช้การเข้ารหัสอื่นๆ โดยเฉพาะไฟล์ที่มีข้อความที่ไม่ใช่ภาษาอังกฤษ
ความต้องการของระบบ Windows สำหรับ Zed และหมายเหตุความเข้ากันได้
ด้าน | รายละเอียด |
---|---|
ความต้องการ GPU | ต้องการ GPU ที่รองรับ DirectX 11 (ไม่สามารถทำงานบน Microsoft Basic Render Driver) |
การรองรับสถาปัตยกรรม | รองรับเฉพาะ x86_64 (ไม่มี ARM64 Windows builds อย่างเป็นทางการ) |
ขนาดการติดตั้ง | ~400MB (รายงานโดยผู้ใช้หลายราย ขณะติดตั้งอาจใช้พื้นที่ชั่วคราวสูงสุดถึง 897MB) |
การรองรับการเข้ารหัสไฟล์ | รองรับเฉพาะ UTF-8 (ไม่สามารถทำงานกับการเข้ารหัสอื่นสำหรับไฟล์ text/CSV) |
Remote Development | มี WSL integration แต่การเชื่อมต่อ RDP จะแสดงคำเตือนความเข้ากันได้ของ GPU |
Keyboard Shortcuts | Keyboard shortcuts มาตรฐานของ Windows บางตัว (ALT+F, ALT+SPACEBAR) ไม่ทำงาน |
การแสดงผลข้อความ: ความท้าทายที่ยังคงมีอยู่
คุณภาพการแสดงผลฟอนต์ปรากฏเป็นอีกจุดที่ถกเถียงกัน โดยเฉพาะสำหรับผู้ใช้ที่ไม่มีจอแสดงผลความหนาแน่นพิกเซลสูง (high-DPI) แม้ว่าเวอร์ชัน Windows จะใช้ DirectWrite สำหรับการแสดงผลข้อความ—ซึ่งควรให้การปรับให้เรียบแบบซับพิกเซล (subpixel anti-aliasing) ที่ดีกว่าเวอร์ชัน Linux—แต่ผู้ใช้ยังคงรายงานประสบการณ์ที่หลากหลาย บางคนพบว่ามันใช้ได้ในระดับพอรับได้ แต่ไม่เยี่ยมยอด ในขณะที่บางคนที่ใช้มอนิเตอร์ 1440p อธิบายว่ามันเบลอพอที่จะทำให้ปวดหัวหลังจากใช้งานเป็นเวลานาน
การอภิปรายเกี่ยวกับการแสดงผลข้อความสะท้อนให้เห็นถึงความท้าทายในภาพกว้างสำหรับแอปพลิเคชันข้ามแพลตฟอร์ม Zed ถูกออกแบบมาในตอนแรกรอบๆ จอแสดงผล HiDPI ที่มีอยู่ทั่วไปบน macOS และการปรับระบบการแสดงผลสำหรับสภาพแวดล้อมจอแสดงผลที่หลากหลายมากขึ้นของ Windows และ Linux กลับกลายเป็นเรื่องที่ท้าทาย แพตช์ล่าสุดได้ปรับปรุงสถานการณ์แล้ว แต่ชุมชนยังคงแบ่งออกเป็นสองฝ่ายว่าการใช้งานในปัจจุบันนี้เป็นไปตามมาตรฐานระดับมืออาชีพสำหรับการเขียนโค้ดในระยะยาวหรือไม่
ข้อสรุป: มีความหวังแต่ยังต้องผ่านการปรับปรุง
แม้จะมีการวิจารณ์ แต่ผู้ใช้หลายคนก็แสดงความกระตือรือร้นต่อศักยภาพของ Zed อดีตผู้ใช้ Sublime Text โดยเฉพาะชื่นชอบในความรวดเร็วในการตอบสนองและอินเทอร์เฟซที่สะอาดตา โดยมีผู้ใช้หนึ่งคนระบุว่าพวกเขาเปลี่ยนมาใช้ Zed สำหรับการแก้ไขไฟล์อย่างรวดเร็วเพราะรู้สึกว่า VSCode นั้น รก เกินไป การมีลัดคีย์บอร์ดสไตล์ JetBrains และสถาปัตยกรรมที่ไม่ใช้ Electron ได้รับคำชมเชยอย่างสม่ำเสมอจากผู้ที่เบื่อหน่ายกับโปรแกรมแก้ไขที่ใช้เทคโนโลยีเว็บ
ความรู้สึกของชุมชนชี้ให้เห็นว่า Zed กำลังสร้างตำแหน่งที่เฉพาะเจาะจงให้ตัวเองในฐานะโปรแกรมแก้ไขที่ทันสมัยและตอบสนองรวดเร็ว สำหรับนักพัฒนาที่ให้ความสำคัญกับประสิทธิภาพและการออกแบบที่สะอาดตากว่าการปรับแต่งระบบนิเวศอย่างกว้างขวาง อย่างไรก็ตาม การเปิดตัวบน Windows เผยให้เห็นว่าโปรแกรมแก้ไขนี้ยังต้องมีการพัฒนาอีกมาก โดยเฉพาะอย่างยิ่งในด้านการผสานรวมกับแพลตฟอร์ม การรองรับรูปแบบไฟล์ และการปรับให้เข้ากับการกำหนดค่าฮาร์ดแวร์ที่หลากหลาย ตามที่ผู้ใช้หนึ่งคนสรุปไว้ มันดูและรู้สึกน่าทึ่งเมื่อใช้งาน แต่คุณสมบัติที่ขาดหายไป เช่น การรองรับ DevContainer ป้องกันการนำมาใช้เต็มที่สำหรับเวิร์กโฟลว์บางอย่าง
การทดสอบที่แท้จริงจะอยู่ที่ว่าทีมงาน Zed จะแก้ไขข้อกังวลของชุมชนเหล่านี้ได้รวดเร็วแค่ไหน ในขณะที่ยังคงรักษาความเร็วในการเปิดตัวที่น่าประทับใจของพวกเขา ด้วยวิศวกรหลายคนที่รายงานว่ากำลังใช้ Windows เป็นเครื่องมือหลักประจำวันและมีทีมแพลตฟอร์ม Windows โดยเฉพาะ จึงมีรากฐานสำหรับการปรับปรุงอย่างรวดเร็วตามข้อคิดเห็นจากผู้ใช้ในโลกจริง
อ้างอิง: Windows เมื่อไหร่? Windows ตอนนี้เลย
![]() |
---|
ศักยภาพและความท้าทายของโปรแกรมแก้ไขโค้ด Zed ที่ถูกพูดถึงในโพสต์บล็อกที่ให้ข้อมูล |