Zasper - ตัวแทน JupyterLab ที่ทันสมัยและมีประสิทธิภาพที่พัฒนาด้วยภาษา Go

 (github.com/zasper-io)
9 คะแนน โดย GN⁺ 2025-01-03 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Zasper เป็น IDE ที่ออกแบบมาเพื่อรองรับความพร้อมใช้งานพร้อมกันขนาดใหญ่
    • ให้การใช้หน่วยความจำขั้นต่ำและความเร็วที่ยอดเยี่ยม พร้อมรองรับการเชื่อมต่อพร้อมกันหลายรายการ
    • เหมาะสำหรับการรันแอปพลิเคชันข้อมูลสไตล์ REPL แบบเดียวกับ Jupyter Notebook
    • ในปัจจุบันรองรับอย่างเต็มรูปแบบบน macOS และรองรับแบบจำกัดบน Linux
  • Benchmark
    • Zasper ใช้ RAM และ CPU น้อยกว่ามากถึง 4 เท่าเมื่อเทียบกับ JupyterLab
    • JupyterLab ใช้ RAM ประมาณ 104.8 MB และ 0.8 CPU ในขณะที่ Zasper ใช้ RAM 26.7 MB และ 0.2 CPU
  • เหตุผลที่ทำ Zasper
    • ในตลาดมีเครื่องมือหน้า UI ที่คล้าย JupyterLab เช่น Databricks Notebooks และ Deepnote Notebooks อยู่ แต่ส่วนใหญ่ไม่ใช่แบบฟรีและต้องทำงานบนคลาวด์
    • Zasper ทำงานได้ราบรื่นบนเครื่อง local และใช้ทรัพยากรที่มีอยู่ได้อย่างมีประสิทธิภาพเพื่อรับประกันประสิทธิผลสูงสุด
    • ภาษา Go ให้การรองรับโปรโตคอล REST, RPC และ WS ได้ดีเยี่ยม และเด่นด้าน concurrency และ performance
    • Python เหมาะกับงานแบบ asynchronous ที่เน้น I/O แต่มีข้อจำกัดกับงานที่เน้น CPU
  • มีฟีเจอร์ครบครัน เช่น editor, terminal, launcher, Jupyter Notebook, version control, command palette, dark mode
  • มีให้ใช้งานทั้งแบบ Electron app และ web app
  • Roadmap
    • Zasper ตั้งเป้าเป็น ecosystem IDE ที่ทรงพลังสำหรับนักวิทยาศาสตร์ข้อมูลและวิศวกร AI โดยมีแนวทางการพัฒนาต่อไปดังนี้:
      • รองรับไม่เฉพาะ Jupyter Notebook แต่รวมถึงแอปข้อมูลที่ปรับแต่งโดยผู้ใช้ได้ด้วย
      • ทำให้การบูรณาการกับเครื่องมือที่มีอยู่เป็นเรื่องง่าย
      • ให้บริการ Zasper Hub เพื่อการ deploy แบบ self-hosted ใน cloud

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

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

 
GN⁺ 2025-01-03
ความคิดเห็นจาก Hacker News

  • ผู้เขียนของ Zasper อธิบายว่าการจัดการเคอร์เนล Jupyter ของ Zasper ที่สร้างด้วย Go coroutine มีประสิทธิภาพดีกว่าวิธีของ Python ใน JupyterLab

    • Zasper ใช้ RAM และ CPU ได้เพียงประมาณ 1/4 เมื่อเทียบกับ JupyterLab
    • ฟีเจอร์ต่าง ๆ เช่นการค้นหายังไม่ได้รับการปรับแต่ง จึงยังคงช้า
    • ผู้เขียนกำลังพัฒนาโครงการนี้แบบเต็มเวลาเพียงคนเดียว และวางแผนจะปรับปรุงในอนาคต
    • คาดหวังว่าจะได้รับการตอบรับที่ดีสำหรับร่างแรก

  • Marimo ดูน่าสนใจในฐานะแนวทางเลือกแทน Jupyter ที่รวมข้อดีของ Streamlit และ Jupyter เข้าด้วยกัน

  • มีการตั้งคำถามว่าการลดการใช้หน่วยความจำและ CPU ที่กล่าวถึงมีความสำคัญเชิงปฏิบัติจริงหรือไม่

    • เนื่องจากโค้ด Python ใช้ทรัพยากรมากกว่าอยู่แล้ว จึงไม่ชัดเจนว่าการใช้ Goroutine ของ Go จะช่วยได้มากน้อยเพียงใด

  • มีความคิดเห็นว่าถึงแม้ JupyterLab จะดูเก่า แต่มันยังคงทันสมัยอยู่เพราะมีการพัฒนาอย่างต่อเนื่อง

  • มีการชี้ให้เห็นว่าเครื่องมือนี้มีให้ใช้ได้เฉพาะบน macOS และ Linux สนับสนุนเพียงบางส่วน โดยรองรับเฉพาะ IPython

    • การเพิ่มประสิทธิภาพด้วย Go ถูกลดประสิทธิผลลงเพราะต้องใช้ Electron

  • มีความต้องการให้ Jupyter มีหน้าตาแบบ rstudio และเน้นว่าความสำคัญคือความสามารถในการรันบล็อกโค้ด

    • ชอบฟีเจอร์ "open console for notebook" ของ JupyterLab แต่ยังไม่พบวิธีส่งข้อความหรือสลับโฟกัสด้วยทางลัดคีย์บอร์ด
    • ด้วยเหตุนี้จึงไม่ใช้การรองรับ Jupyter ใน VSCode

  • มีความคิดเห็นว่าควรพิจารณาใช้ Wails สำหรับ UI

    • แม้จะใส่ความพยายามกับ Go อย่างมาก แต่การเลือกใช้ Electron กลับน่าเสียดาย

  • มีข้อสงสัยว่ามีข้อได้เปรียบอะไรบ้างเมื่อเทียบกับการรองรับ Jupyter notebook ของ VSCode

  • สงสัยว่าหากตัดการเชื่อมต่อใน frontend ที่กำลังทำงานอยู่แล้วเชื่อมต่อกลับใหม่ จะสูญเสีย output หรือไม่

  • ดูเหมือนเป็นโปรเจกต์ที่จะแทนที่ JupyterLab frontend โดยยังคงการเชื่อมต่อกับ Jupyter kernel

    • โดยหลักการแล้วอาจรองรับ kernel ของ JavaScript หรือภาษาอื่นได้
    • ชี้ว่าการทดสอบของโปรเจกต์นี้ทำเฉพาะกับ IPython และตั้งความสนใจในทิศทางที่โครงการจะพัฒนาต่อไป