परिचय

Native Shell (संक्षेप में NSH) हर प्लेटफ़ॉर्म के लिए एक नेटिव UI फ़्रेमवर्क है। आप ऐप को एक बार, एक ही ऐप मॉडल के साथ बनाते हैं: कंपोनेंट, सिग्नल, स्टाइल और हर जगह वही API। NSH उसे iOS, Android, macOS, Windows, Linux और वेब पर चलाता है, और हर बार वह उस प्लेटफ़ॉर्म के अपने ऐप की तरह चलता है: उसी प्लेटफ़ॉर्म के अपने व्यू से बना, उसी के अपने टेक्स्ट सिस्टम से एडिट होने वाला, और वैसे इस्तेमाल होने वाला जैसी उसके यूज़र्स को उम्मीद होती है। पूरा ऐप Rust में लिखें, स्क्रीन TSX में लिखें, या दोनों को एक ही इंजन पर मिलाएँ। उसी इंजन के ऊपर, आपके शिप किए हुए ऐप रन टाइम पर नया UI ले सकते हैं, जो आपकी टीम ने लिखा हो या किसी मॉडल ने जनरेट किया हो, साइन किए गए मॉड्यूल के रूप में और होस्ट द्वारा कॉन्फ़िगर किए गए सैंडबॉक्स में।

#नेटिव का मतलब

NSH में नेटिव की दो परतें हैं: प्लेटफ़ॉर्म की बुनियाद, और प्लेटफ़ॉर्म का इंटरैक्शन।

प्लेटफ़ॉर्म की बुनियाद। हर प्लेटफ़ॉर्म का अपना एक बैकएंड है, जो उस प्लेटफ़ॉर्म के पहले से मौजूद UI पर बना है:

टेक्स्ट सिलेक्शन और उसका मेन्यू, इनपुट मेथड, एक्सेसिबिलिटी और स्क्रॉलिंग प्लेटफ़ॉर्म से आते हैं, और नया OS रिलीज़ इनमें जो कुछ लाता है, वह ऐप तक अपने-आप पहुँच जाता है। नेटिव कंपोनेंट, जैसे मैप, वेब व्यू, वीडियो प्लेयर या होस्ट द्वारा रजिस्टर किया गया कोई भी व्यू, उसी हायरार्की में एक और व्यू होते हैं, जिन्हें बाकी व्यू के साथ ही लेआउट, क्लिप और स्क्रॉल किया जाता है (नेटिव कंपोनेंट)।

प्लेटफ़ॉर्म का इंटरैक्शन। NSH जो कंपोनेंट nsh/base में देता है, वे वैसे ही व्यवहार करते हैं जैसा हर डिवाइस के यूज़र्स को उम्मीद होती है, इसलिए ऐप को उन्हें सिर्फ़ एक बार लिखना होता है:

पेज, डायलॉग, कीबोर्ड और स्टेटस बार भी इसी विचार पर चलते हैं: नेविगेशन स्टैक हर प्लेटफ़ॉर्म की अपनी गति के साथ पुश और पॉप होते हैं, और बैक बटन, Escape और स्वाइप-बैक वही करते हैं जो वहाँ करते हैं (नेविगेशन)।

#फ़ोन से डेस्कटॉप और वेब तक

NSH में क्रॉस-प्लेटफ़ॉर्म का मतलब है कि हर डिवाइस को वह ऐप मिलता है जिसकी वह उम्मीद करता है, न कि वही स्क्रीन छोटी या बड़ी करके:

• एक ऐप मॉडल। ऐप के कंपोनेंट, स्टेट, बिज़नेस लॉजिक और स्क्रीन साझा हैं; हर बैकएंड उन्हें अपने प्लेटफ़ॉर्म से मैप करता है।
• आकार बदलने वाले लेआउट। Flexbox और CSS grid को हर प्लेटफ़ॉर्म पर Taffy लेआउट करता है, और Tailwind के ब्रेकपॉइंट (md:, lg:) और विंडो का आकार (Rust में window()) सिर्फ़ साइज़ नहीं, बल्कि संरचना बदलते हैं: एक चैट ऐप चौड़ी विंडो में साइडबार, बातचीत और संदेश साथ-साथ दिखाता है, और फ़ोन पर एक बार में एक स्क्रीन (लेआउट, Tailwind)।
• हर डिवाइस का अपेक्षित इनपुट। डेस्कटॉप पर पॉइंटर, होवर, राइट क्लिक, शॉर्टकट और फ़ोकस; फ़ोन पर टच, जेस्चर, सॉफ़्टवेयर कीबोर्ड और पेज नेविगेशन। जहाँ ऐप को हर प्लेटफ़ॉर्म के लिए कुछ अपना चाहिए, वहाँ desktop={{…}} प्रॉप्स और platform.select यही बताते हैं (प्लेटफ़ॉर्म-विशिष्ट कोड)।
• हर टारगेट पर जाँचा हुआ। nsh test ऐप के टेस्ट हेडलेस चलाता है, और वही टेस्ट macOS, Windows, Linux और GPUI विंडो, iOS सिमुलेटर, Android डिवाइस या ब्राउज़र में, प्लेटफ़ॉर्म के अपने इनपुट के साथ चलाता है (टेस्टिंग और ट्रेसिंग)।

एक चैट क्लाइंट जैसे ऐप को लें। उसका डेवलपर उसे डेस्कटॉप पर nsh run से बनाता है, फ़ोन का लेआउट जाँचने के लिए उसे nsh run --target ios से iOS सिमुलेटर में खोलता है, फिर nsh run --target web से ब्राउज़र में, हर बार वही प्रोजेक्ट, और nsh package इंस्टॉल होने वाले ऐप और वेबसाइट बनाता है। जो काम पहले हर प्लेटफ़ॉर्म के लिए एक पूरी टीम लेती थी, उसे एक इंजीनियर संभाल सकता है, जबकि बैकएंड साथ-साथ बनता रहता है।

#पहले Rust

NSH Rust में बना है, और Rust इसके साथ ऐप लिखने के लिए एक फ़र्स्ट-क्लास भाषा है:

• पूरे ऐप Rust में। UI, लॉजिक और कंपोनेंट Rust में होते हैं, जो हर प्लेटफ़ॉर्म पर नेटिव कोड में कंपाइल होते हैं, और Rust के ओनरशिप, टाइप, थ्रेड और crates.io इकोसिस्टम के साथ आते हैं। कंप्यूटेशन नेटिव स्पीड पर चलता है, और बड़ा डेटा, पार्सिंग और सिस्टम का काम उस भाषा में रहता है जो उनके लिए सबसे उपयुक्त है (Rust के साथ बनाना)।
• दूसरा रास्ता TSX। TSX तेज़ी से लिखी जाने वाली स्क्रीन, प्लगइन, छोटे ऐप और रन टाइम पर पहुँचाए जाने वाले UI के लिए उपयुक्त है। यह Rust वाले इंजन पर ही चलता है, उन्हीं प्रिमिटिव, बेस कंपोनेंट और सिग्नल के साथ।
• दोनों साथ। एक Rust ऐप TSX स्क्रीन ले सकता है, और TSX स्क्रीन ऐप के Rust कंपोनेंट, मॉड्यूल और क्लास इम्पोर्ट करती हैं।
• एक टूलचेन। एक अकेला nsh एक्ज़ीक्यूटेबल हर टारगेट के लिए ऐप बनाता, बिल्ड करता, टाइप-चेक करता, हॉट रीलोड के साथ चलाता, टेस्ट करता, पैकेज करता और साइन करता है। यह अपना TSX बंडलर और TypeScript चेकर साथ लाता है, इसलिए Rust, Swift, Kotlin या C++ से आने वाला डेवलपर Rust और nsh इंस्टॉल करता है, और काम शुरू कर देता है (इंस्टॉलेशन, CLI)।

#एक ऐप

वही काउंटर, Rust और TSX में:

use nsh_core::prelude::*;

#[component]
pub fn Counter() -> impl IntoElement {
    let count = signal(0);
    view()
        .flex_1()
        .items_center()
        .justify_center()
        .gap_3()
        .child(text(move || count.get().to_string()).text_5xl().font_weight(FontWeight::BOLD))
        .child(
            view()
                .rounded_lg()
                .bg(rgb(0x2563eb))
                .px_5()
                .py_3()
                .active(|s| s.opacity(0.6))
                .on_press(move || count.update(|n| *n += 1))
                .child(text("Tap").text_lg().text_color(white())),
        )
}

import { mount, signal, Text, View } from "nsh";

function Counter() {
  const count = signal(0);
  return (
    <View style={{ flex: 1, alignItems: "center", justifyContent: "center", gap: 12 }}>
      <Text style={{ fontSize: 48, fontWeight: "700" }}>{count()}</Text>
      <View
        onPress={() => count.update((n) => n + 1)}
        activeStyle={{ opacity: 0.6 }}
        class="rounded-lg bg-blue-600 px-5 py-3"
      >
        <Text class="text-white text-lg">Tap</Text>
      </View>
    </View>
  );
}

mount(Counter);

एक व्यू (view(), <View>) iOS पर UIView बन जाता है, Android पर ViewGroup, macOS पर NSView, Linux पर GTK विजेट, Windows पर Direct2D से ड्रॉ किया गया रिटेन्ड व्यू और वेब पर HTML एलिमेंट; टेक्स्ट एक नेटिव टेक्स्ट व्यू बन जाता है, और बटन का प्रेस फ़ीडबैक (.active(..), activeStyle) मुख्य थ्रेड पर चलता है। जब आप टैप करते हैं, count.update एक सिग्नल बदलता है, और सिर्फ़ वही टेक्स्ट अपडेट होता है जो उसे पढ़ता है: कंपोनेंट फ़ंक्शन दोबारा नहीं चलता। Rust ऐप शुरू से अंत तक नेटिव कोड है; TSX ऐप में सिर्फ़ मॉड्यूल का अपना कोड JavaScript है।

#रिटेन्ड व्यू

NSH रिटेन्ड है: हर एलिमेंट एक ऐसा व्यू है जिसे प्लेटफ़ॉर्म बनाए रखता है, और अपडेट सिर्फ़ उसे बदलता है जो बदला है।

• सूक्ष्म-स्तरीय अपडेट। Solid जैसे सिग्नल, जो नेटिव रूप से इम्प्लीमेंट किए गए हैं: कंपोनेंट एक बार चलते हैं, और बदलाव होने पर सिर्फ़ वे एक्सप्रेशन दोबारा चलते हैं जो बदले हुए सिग्नल को पढ़ते हैं।
• सिर्फ़ जो बदला, वही थ्रेड पार करता है। एक टर्न के बदलाव साथ में लेआउट किए जाते हैं और प्रति फ़्रेम व्यू ऑपरेशन के एक बैच के रूप में मुख्य थ्रेड को सौंपे जाते हैं; अपरिवर्तित स्टाइल और फ़्रेम नहीं भेजे जाते, और जिन व्यू को किसी ने नहीं छुआ वे जैसे हैं वैसे ही रहते हैं।
• एनीमेशन नेटिव रूप से चलते हैं। टाइमिंग, स्प्रिंग और डेके एनीमेशन, जेस्चर और स्क्रॉल से जुड़े मान प्लेटफ़ॉर्म की फ़्रेम क्लॉक पर कैलकुलेट होते हैं, प्रति फ़्रेम JS को कॉल किए बिना (एनीमेशन)।

यह उन स्क्रीन के लिए उपयुक्त है जिनसे ज़्यादातर ऐप बने होते हैं: चैट, मेल, फ़ॉर्म, लिस्ट, दस्तावेज़, सेटिंग, स्ट्रीम होकर आता AI जवाब, जहाँ एक बार में कुछ ही व्यू बदलते हैं और बाकी इंतज़ार करते हैं। ऐसी स्क्रीन अपडेट के बीच लगभग निष्क्रिय रहती हैं, और ProMotion डिस्प्ले पर स्क्रॉलिंग और एनीमेशन 120 FPS बनाए रखते हैं। NSH परफ़ॉर्मेंस बेंचमार्क में, 500 पंक्तियों की एक कोट टेबल, जो प्रति सेकंड 1,000 बार अपडेट होती है, Linux पर NSH Rust में एक कोर का 18% इस्तेमाल करती है, जबकि GPUI Fast पर सीधे लिखी वही स्क्रीन 20% इस्तेमाल करती है। भारी कंप्यूटेशन Rust में होना चाहिए: TSX QuickJS में चलता है, जो एक इंटरप्रेटर है, जबकि Rust मॉड्यूल नेटिव स्पीड पर चलता है, भले ही उसे TSX कॉल करे; 100,000 पंक्तियों को सॉर्ट करने में इस तरह लगभग 3 ms लगते हैं, जितने साधारण Rust में लगते हैं (परफ़ॉर्मेंस)।

#यह कैसे चलता है

टूलचेन एक अकेला nsh बाइनरी है। ऐप Rust में, TSX में, या दोनों में लिखा जाता है, और हर एक उसी Rust इंजन तक अपना अलग रास्ता लेता है।

#Rust ऐप

Rust ऐप एक क्रेट है, जो पूरी तरह Rust और Native से बनता है, बिना किसी JavaScript रनटाइम के:

1. बिल्ड। nsh हर टारगेट का रनर बनाता है, यानी iOS, Android, macOS, Windows, Linux या वेब ऐप, जिसमें आपका क्रेट लिंक होता है। कंपोनेंट, स्टेट, हैंडलर और इंजन एक साथ नेटिव कोड में कंपाइल होते हैं।
2. रन। ऐप का रूट कंपोनेंट इंजन थ्रेड पर Rust के रूप में चलता है। रनर में कोई JavaScript इंजन नहीं होता: किसी भी प्लेटफ़ॉर्म पर QuickJS Rust ऐप का हिस्सा नहीं है।

#TSX ऐप

TSX ऐप (एक मॉड्यूल) .tsx / .ts फ़ाइलों का एक सेट है, जिसकी एक एंट्री होती है, आमतौर पर App.tsx:

1. बिल्ड। nsh मॉड्यूल की फ़ाइलों को (rolldown और Oxc के साथ) बंडल करता है और JSX को अपने कंपाइलर से कंपाइल करता है। nsh और nsh/* के इम्पोर्ट इम्पोर्ट ही रहते हैं: रनटाइम उन्हें नेटिव रूप से सर्व करता है, इसलिए बंडल में सिर्फ़ आपका कोड होता है। बंडल QuickJS बाइटकोड में कंपाइल होता है।
2. रन। इंजन थ्रेड बाइटकोड को QuickJS में चलाता है, प्रति व्यू एक VM। कंपाइल किया गया JSX सीधे नेटिव रेंडरर को कॉल करता है, और JavaScript केवल UI का वर्णन करता है और इवेंट संभालता है; स्टाइल पार्स करना, Tailwind क्लास रिज़ॉल्व करना, डिफ़िंग, लेआउट और टेक्स्ट सब Rust में होता है।

#अंतर

दोनों को मिलाया जा सकता है: एक Rust ऐप TSX स्क्रीन ले सकता है, और TSX स्क्रीन उसके Rust कंपोनेंट, मॉड्यूल और क्लास इम्पोर्ट करती हैं; ऐसा ऐप उन्हें चलाने के लिए QuickJS लिंक करता है (Rust के साथ बनाना)।

#साझा इंजन

इंजन से आगे, दोनों रास्ते एक ही हैं। बदलाव प्रति टर्न इकट्ठा किए जाते हैं, Taffy (flexbox और CSS grid) से लेआउट किए जाते हैं, और प्रति फ़्रेम व्यू ऑपरेशन के एक बैच के रूप में मुख्य थ्रेड को सौंपे जाते हैं; मुख्य थ्रेड उस बैच को नेटिव व्यू पर लागू करता है। टेक्स्ट को इंजन थ्रेड पर एक बार मापा और लेआउट किया जाता है (Apple प्लेटफ़ॉर्म पर CoreText, Android पर StaticLayout, Windows पर DirectWrite, Linux पर Pango, वेब पर ब्राउज़र के फ़ॉन्ट मेट्रिक्स) और मुख्य थ्रेड पर सिर्फ़ ड्रॉ किया जाता है।

वेब पर वही इंजन पेज के अंदर चलता है: ब्राउज़र CSS से स्टाइल किए गए HTML एलिमेंट दिखाता है, उन्हें स्क्रॉल करता है, उनका टेक्स्ट सिलेक्ट करता है और इनपुट संभालता है, और nsh package --target web ऐप को एक स्टैटिक साइट के रूप में प्रकाशित करता है, जिसकी फ़ाइलों के नाम उनकी सामग्री से तय होते हैं और जो किसी भी CDN के लिए तैयार है (वेब)।

#डायनामिक UI और AI-जनरेटेड UI

NSH की शुरुआत इस उद्देश्य से हुई थी कि नेटिव ऐप्स रिलीज़ के बाद भी UI ले सकें, और यह आज भी इसके मुख्य उपयोगों में से एक है। ऐप जहाँ भी कोई मॉड्यूल दिखाना हो, वहाँ NshAppView (iOS), NshView (Android), AppView (macOS, Windows, Linux और GPUI ऐप्स) या createPlayer (वेब पेज) एम्बेड करता है, और NSH उसके अंदर TSX मॉड्यूल चलाता है:

• रिलीज़ के बाद डिलीवरी। मॉड्यूल एक साइन किया हुआ पैकेज (.nshpkg) होता है, जिसे ऐप रन टाइम पर डाउनलोड करता है। उसे चलाने से पहले ऐप उसके सिग्नेचर को अपनी भरोसेमंद कुंजियों और एक रिवोकेशन सूची के विरुद्ध जाँचता है (Signed packages)। होस्ट ऐप रनटाइम के साथ आता है; टीमें उसके API के विरुद्ध मॉड्यूल बनाती हैं और अपने समय-क्रम के अनुसार उन्हें डिलीवर करती हैं।
• होस्ट का नियंत्रण बना रहता है। हर मॉड्यूल अपने अलग QuickJS VM में चलता है, जिस पर मेमोरी, कॉल-टाइम और नोड की सीमाएँ लागू होती हैं, और वह केवल उन्हीं चीज़ों तक पहुँचता है जिनकी अनुमति होस्ट देता है: नेटवर्क होस्ट, वेब पेज, स्टेटस बार (Sandbox and capabilities)। कई मॉड्यूल साथ-साथ चल सकते हैं।
• यह ऐप के बाकी हिस्से जैसा दिखता है। मॉड्यूल प्लेटफ़ॉर्म के अपने UI से रेंडर होते हैं, और होस्ट अपने नेटिव व्यू — जैसे मैप, प्लेयर, डिज़ाइन-सिस्टम कॉम्पोनेंट — रजिस्टर कर सकता है ताकि मॉड्यूल उनका उपयोग कर सकें (Native components)।

यही तंत्र ऐप को इंटरफ़ेस के रूप में जवाब देने की सुविधा भी देता है। एक मॉडल छोटा-सा TSX मॉड्यूल लिखता है (फ़ॉर्म, चार्ट, बुकिंग कार्ड), आपका सर्वर उसे जाँचता, बनाता और साइन करता है, और ऐप उसे नेटिव रूप में दिखाता है:

iOS पर, होस्ट का हिस्सा बस कुछ पंक्तियों का होता है:

let app = NshAppView()                         // a UIView: place it anywhere
try app.grantCapabilities(#"{ "network": { "hosts": ["api.example.com"] } }"#)
let info = try await app.loadPackage(at: downloadedFile, trust: trust)   // verified, then run

#AI-फ़्रेंडली

NSH को AI के साथ लिखे जाने वाले सॉफ़्टवेयर के लिए डिज़ाइन किया गया है, जनरेट की गई स्क्रीन के लिए भी और पूरे ऐप्स के लिए भी:

• हर प्लेटफ़ॉर्म के लिए एक ऐप मॉडल। मॉडल को UI लिखने का केवल एक तरीका सीखना होता है, और नतीजा फ़ोन, डेस्कटॉप और वेब पर चलता है; NSH हर प्लेटफ़ॉर्म के अनुसार इंटरैक्शन को ढाल लेता है, इसलिए कुछ भी छह बार जनरेट नहीं करना पड़ता।
• काम के अनुसार Rust या TSX। पूरे ऐप्स और परफ़ॉर्मेंस-क्रिटिकल मॉड्यूल के लिए Rust, स्क्रीन, प्लगइन और हर अनुरोध पर जनरेट होने वाले UI के लिए TSX — दोनों एक ही इंजन पर।
• एक सटीक, जनरेट किया हुआ कॉन्ट्रैक्ट। हर एलिमेंट, प्रॉप, स्टाइल की और मॉड्यूल के लिए TypeScript डिक्लेरेशन Rust सोर्स से जनरेट किए जाते हैं (.nsh/types), और Rust API टाइप्ड हैं, इसलिए जनरेट किए गए कोड को कंपाइलर जाँचता है। ये डॉक्स मॉडलों के लिए सादे टेक्स्ट के रूप में उपलब्ध कराए जाते हैं (llms.txt, llms-full.txt)।
• पूरे चक्र के लिए एक कमांड लाइन। एक एजेंट ऐप बनाता है, उसे बिल्ड करता है, किसी टार्गेट पर चलाता है, उसके टेस्ट चलाता है, नतीजा पढ़ता है, सुधार करता है और पैकेज करता है, यह सब nsh के ज़रिए। nsh test बिना डिवाइस के हेडलेस चलता है, और त्रुटियाँ तथा बनाए गए व्यू रिपोर्ट करता है; कंपाइलर इन-प्रोसेस (nsh_bundler::compile_module) और ब्राउज़र में (Playground) भी चलता है।
• अविश्वसनीय होने पर भी चलाना सुरक्षित। रन टाइम पर डिलीवर किया गया जनरेट कोड अविश्वसनीय कोड है: वह साइन होकर आता है, सीमाओं वाले VM में चलता है और केवल उन्हीं क्षमताओं तक पहुँचता है जो होस्ट देता है।

#यह कहाँ चलता है

#Native Shell और GPUI Shell

Longbridge NSH को अपने क्लाइंट्स के लिए बनाता है। पहली ज़रूरत मोबाइल क्लाइंट के लिए एक प्लगइन लेयर की थी, और शुरुआती बिंदु GPUI Shell था, जो GPUI डेस्कटॉप ऐप्स को JavaScript में एक्सटेंसिबल बनाता है। फ़ोन पर, GPUI द्वारा खुद ड्रॉ किए गए UI को वह सब दोबारा बनाना पड़ता जो प्लेटफ़ॉर्म पहले से करता है — टेक्स्ट सेलेक्शन और उसका मेन्यू (Copy, Share, Translate, Look Up), इनपुट मेथड, एक्सेसिबिलिटी, हर iOS रिलीज़ के साथ आने वाले विज़ुअल मटीरियल — और हर मोबाइल टीम को एक नया UI स्टैक अपनाना पड़ता। इसलिए NSH हर प्लेटफ़ॉर्म के अपने UI से रेंडर करता है, और यह उस प्लगइन लेयर से बढ़कर हर प्लेटफ़ॉर्म पर पूरे ऐप्स के लिए एक फ़्रेमवर्क बन गया।

दोनों की स्थिति अलग है। GPUI Shell GPUI डेस्कटॉप एप्लिकेशन को एक्सटेंड करता है; Native Shell फ़ोन, डेस्कटॉप और वेब पर नेटिव ऐप्स के लिए एक फ़्रेमवर्क है, और इसका GPUI बैकएंड NSH ऐप्स को GPUI और GPUI Kit ऐप्स में एम्बेड करता है (GPUI)।

#तुलना

पूरे ऐप्स के लिए, NSH क्रॉस-प्लेटफ़ॉर्म फ़्रेमवर्क जैसे React Native, Flutter, Qt, GPUI, Slint, Electron और Tauri के बीच आता है; रिलीज़ के बाद डिलीवर होने वाले UI के लिए, वेब व्यू, सर्वर-ड्रिवन UI और मिनी-प्रोग्राम कंटेनरों के बीच। इसका चुनाव है: एक ऐप मॉडल के तहत हर प्लेटफ़ॉर्म का अपना UI और इंटरैक्शन, ऐप की भाषा के रूप में Rust और उसके साथ TSX। Comparing approaches में हर एक पर विस्तार से चर्चा है।

#अगले कदम

• Installation और Getting started: nsh प्राप्त करें, Rust या TSX में पहला ऐप लिखें और उसे हर प्लेटफ़ॉर्म पर चलाएँ।
• Building with Rust: Rust में लिखे ऐप्स, और उनके ऊपर TSX।
• Platforms: क्या कहाँ चलता है, और हर प्लेटफ़ॉर्म पर कैसे चलाएँ, पैकेज करें और एम्बेड करें।
• JSX and components और Reactivity: वे दो विचार जिन पर बाकी सब कुछ टिका है, Rust और TSX दोनों में।
• Signed packages और Sandbox and capabilities: मॉड्यूल डिलीवर करें और तय करें कि वे क्या कर सकते हैं।