Show HN: Ant – एक JavaScript runtime और ecosystem

मूल लेख ↗ Hacker News चर्चा ↗

प्रोजेक्ट का दायरा और स्थिति

  • नया JavaScript runtime और ecosystem, जो छोटे आकार, तेज़ startup, sandboxing, और node compatibility का दावा करता है।
  • इसमें अपना engine (“Ant Silver”), registry, package manager, sandbox/hypervisor integration, और desktop app framework तथा binary compilation की योजनाएँ शामिल हैं।
  • कुछ लोगों को यह दायरा उत्साहजनक लगता है; अन्य इसे एक युवा प्रोजेक्ट के लिए समय से पहले “all-in-one” और जटिल मानते हैं।

Desktop apps और binary size

  • इसे HTML/CSS/JS को desktop apps में पैक करने के लिए हल्के Electron विकल्प के रूप में इस्तेमाल करने में रुचि दिखाई गई।
  • एक अलग “ant-desktop” टूल शुरुआती विकास में है; अभी इसमें केवल Chromium-only renderer है; WebView और अन्य backends की योजना है।
  • बताया गया runtime binary लगभग 8 MB है, जिससे Electron-आकार के bundles की तुलना में आशावाद और desktop build sizes को लेकर सवाल उठे।

Performance और engine design

  • V8 की तुलना में, कहा गया कि सरल JIT tiers, ICU Unicode data की अनुपस्थिति, और JS startup snapshot न होने के कारण Ant काफ़ी छोटा है।
  • एक बाहरी साइट से benchmarks दिखाते हैं कि Ant अभी V8 से बहुत धीमा है और ES6-complete भी कम है, लेकिन लेखक का दावा है कि engine लगभग पूरी तरह rewritten है और हाल में performance में सुधार हुआ है।
  • टिप्पणीकार व्यापक, स्वतंत्र benchmarks और fuzzing की मांग करते हैं, खासकर यदि इसका लक्ष्य V8/LLVM-स्तर के engines से प्रतिस्पर्धा करना है।

Sandboxing और hypervisor

  • विज्ञापित “VM-isolated sandbox” Linux पर KVM और macOS पर Hypervisor.framework के जरिए लागू किया गया है, जिसमें patched Nanos kernel चलता है।
  • memory lazily allocate होती है और default 256 MB limit है; लगभग 35 MB Ant और VM द्वारा उपयोग होता है।
  • कुछ लोग performance को लेकर संशय में हैं, खासकर nested virtualization के साथ; अन्य लोग FaaS और अधिक सुरक्षित npm-style execution के लिए बड़ी संभावनाएँ देखते हैं। Windows support पूछा गया, लेकिन उत्तर नहीं मिला।

Ecosystem (registry, tooling, compatibility)

  • Ant अपनी खुद की registry और package manager की योजना बना रहा है; कई टिप्पणीकार सुझाव देते हैं कि एक और registry बनाने के बजाय JSR का उपयोग किया जाए।
  • npm protocol compatibility एक घोषित लक्ष्य है, जिससे यह सवाल उठता है कि अलग registry की आवश्यकता क्यों है।
  • WSL1 support, WebGPU, और sandboxing का antx के साथ interaction कैसे काम करता है—इन सवालों के अधिकतर जवाब नहीं मिले।

लेखकत्व, AI, और trust से जुड़ी चिंताएँ

  • शुरुआती संस्करणों में reportedly किसी अन्य JS engine (Elk) का code शामिल था, जिससे AGPL और originality के सवाल उठे; वर्तमान code को पूर्ण rewrite बताया गया है।
  • engine को “hand-built” कहने वाली marketing language पर लंबी बहस छिड़ती है:
    • कुछ का तर्क है कि LLM-assisted, “vibe-coded” काम को hand-built नहीं कहा जाना चाहिए।
    • अन्य लोग prompt करने और LLMs की supervision को नया सामान्य मानते हैं और इसे प्रमुख रूप से disclose करना आवश्यक नहीं समझते।
  • अतिरिक्त संदेह इन बातों से पैदा होता है:
    • कंपनी साइट पर /jobs पेज का काम न करना (जिसे अंदरूनी मज़ाक बताया गया)।
    • साइट पर custom-renamed serif font, जिसे एक commercial typeface पहचाना गया, और जिसके आधार पर एक टिप्पणीकार ने “stealing” का पैटर्न होने का आरोप लगाया।
  • समग्र sentiment उत्साही (“slick”, “very interesting”) से लेकर सतर्क या अविश्वासी तक फैला है; कई लोग विचारों को पसंद करते हैं लेकिन provenance और दीर्घकालिक विश्वसनीयता को लेकर सावधान हैं।

मौजूदा runtimes से तुलना

  • कई टिप्पणीकारों का कहना है कि Deno पहले से ही कई समान सुविधाएँ देता है (sandboxing, compilation, गंभीर team backing)।
  • Bun को performance-focused runtime के रूप में बताया गया है, जिसमें compilation और optimization features हैं।
  • कुछ लोग सवाल करते हैं कि mature alternatives मौजूद होने पर “smaller and faster” होना ही एक और JS runtime अपनाने के लिए पर्याप्त कारण है या नहीं।