9 पॉइंट द्वारा GN⁺ 2025-11-09 | 2 टिप्पणियां | WhatsApp पर शेयर करें
  • Snap द्वारा बनाया गया Valdi एक cross-platform UI framework है जो iOS, Android, macOS पर native performance देता है, और declarative TypeScript में लिखे UI को हर platform के native view में सीधे compile करता है
  • यह WebView या JavaScript bridge के बिना काम करता है, और automatic view recycling, optimized layout engine, viewport-based rendering जैसी तकनीकों से उच्च प्रदर्शन बनाए रखता है
  • instant hot reload, VSCode debugging, TSX syntax support आदि के जरिए development speed बढ़ाता है, और मौजूदा native apps के साथ integration भी लचीले तरीके से सपोर्ट करता है
  • TypeScript और native code के बीच type-safe binding, protobuf support, C++·Swift·Kotlin integration आदि के जरिए गहरा native integration architecture देता है
  • यह 8 साल तक Snap के production apps में परखी गई तकनीक है, और बड़े पैमाने की animation, gesture, multithreaded processing जैसे advanced features सहित scalable UI development foundation प्रदान करता है

Valdi का overview

  • Valdi, Snap का वह cross-platform UI framework है जिसे 8 साल तक production apps में इस्तेमाल किया गया
    • declarative TypeScript में UI लिखने पर यह iOS, Android, macOS के native views में सीधे compile करता है
    • WebView या JavaScript bridge के बिना native performance देता है
  • यह फिलहाल beta stage में है, और open source environment में tools व documentation के stabilization के बाद stable version में जाने की योजना है

मुख्य विशेषताएँ और उदाहरण

  • basic component example में HelloWorld class के भीतर और का उपयोग कर सरल UI बनाया जाता है
  • यह TypeScript-आधारित declarative component structure का उपयोग करता है, और हर platform पर एक ही code से चल सकता है
  • official documentation, installation guide, API reference, Codelab जैसी development materials उपलब्ध हैं

performance optimization

  • native performance सुनिश्चित करने के लिए इसने निम्न architecture अपनाया है
    • automatic view recycling: global view pooling system के जरिए screens के बीच views को reuse करना, inflation latency को कम करना
    • independent component rendering: parent rendering को प्रभावित किए बिना केवल individual components को update करना
    • C++-based layout engine: main thread पर न्यूनतम overhead के साथ काम करना
    • viewport-aware rendering: सिर्फ स्क्रीन पर दिखने वाले views को inflate करके infinite scroll performance को बेहतर बनाना
  • इसके लिए Performance Optimization Guide नामक संबंधित documentation भी उपलब्ध है

developer experience

  • hot reload feature से code changes तुरंत reflect होते हैं
  • VSCode debugging support: breakpoint set करना, variables inspect करना, performance profiling, heap dump capture करना संभव है
  • TSX syntax और type safety के साथ परिचित development environment मिलता है

लचीला integration architecture

  • मौजूदा native app में Valdi embed किया जा सकता है (Embed Valdi in native)
  • Valdi के भीतर native view का उपयोग किया जा सकता है (Embed native in Valdi)
  • Polyglot modules के जरिए C++, Swift, Kotlin, Objective-C code के साथ type-safe integration संभव है
  • full-stack architecture के जरिए background worker threads का उपयोग कर पूरी functionality implement की जा सकती है

native integration

  • automatic code generation के जरिए TypeScript interfaces को Kotlin, Objective-C, Swift bindings में बदला जाता है
  • Polyglot modules के जरिए platform APIs और third-party native libraries तक सीधे पहुंच संभव है
  • bidirectional communication के जरिए complex data structures और callbacks का सुरक्षित आदान-प्रदान किया जा सकता है
  • protobuf support से efficient data serialization संभव है

परखी हुई स्थिरता और सुविधाएँ

  • यह Snap की प्रमुख production features को चलाने वाली core technology है
  • advanced animation, real-time rendering, complex gesture system का समर्थन करता है
  • Flexbox layout, multithreaded workers, native animations, advanced gesture recognition, built-in test framework, Bazel-integrated build जैसी कई सुविधाएँ शामिल हैं

support और license

  • Discord community के माध्यम से support उपलब्ध है
  • MIT license के तहत जारी, इसलिए इसे स्वतंत्र रूप से उपयोग और योगदान किया जा सकता है

2 टिप्पणियां

 
GN⁺ 2025-11-09
Hacker News राय
  • हमारी कंपनी React Native इस्तेमाल करती है, और मैं ऐप स्टोर तथा प्लेटफ़ॉर्म-विशिष्ट भाषाओं के फर्क के ख़त्म होने का बेसब्री से इंतज़ार कर रहा हूँ
    अगले साल हम शायद सिर्फ़ वेबसाइट-आधारित तरीके पर जाएँ, और मोबाइल ऐप को WebView में लपेटें, जबकि नोटिफ़िकेशन, GPS, HealthKit जैसी सुविधाएँ केवल native code से हैंडल करें
    आजकल AI की वजह से यह भी लगने लगा है कि हर प्लेटफ़ॉर्म के लिए अलग UI बनाना शायद उल्टा बेहतर हो सकता है

    • मैंने भी ऐसा किया था, और पछतावा नहीं हुआ। यह वही है जिसे आम तौर पर “WebView ऐप” कहा जाता है, और इससे हर प्लेटफ़ॉर्म पर काफ़ी अच्छा अनुभव दिया जा सकता है
      असली बात यह है कि UI components को बहुत ज़्यादा अलग या अनोखा न बनाया जाए, और सिर्फ़ button style या back stack जैसी चीज़ों को प्लेटफ़ॉर्म के हिसाब से थोड़ा बदला जाए
      साथ ही, मैंने Service Worker से offline functionality जोड़ी, और app start पर network diagnostic tools चलाए ताकि समस्याएँ जल्दी पकड़ी जा सकें
      हालाँकि मेरा ऐप B2B के लिए था, इसलिए यह सेटअप संभव था
    • लेकिन अगर आपको अब भी WebView को native container में लपेटना ही पड़ रहा है, तो उस बिंदु पर आप पहले ही iOS code signing hell में कदम रख चुके हैं
      मेरे हिसाब से web मूल रूप से app store और code signing को बायपास करने का रास्ता है
      ज़्यादातर सुविधाएँ web से भी संभव हैं, और HealthKit को सिर्फ़ एक अलग companion app से संभाला जा सकता है
      marketing budget से QR code या links को प्रमोट करना app store की प्रतिस्पर्धा से कहीं ज़्यादा असरदार हो सकता है
    • मैं भी हर 10 साल में ऐसा प्रयोग करता हूँ। शुरुआत में तेज़ development speed से प्यार हो जाता है, लेकिन बाद में नए OS features integration या gestures सपोर्ट में इसकी क़ीमत चुकानी पड़ती है
      खासकर iOS में, जिस पल ‘back swipe’ काम नहीं करता, उसी पल पता चल जाता है कि यह WebView है
    • AI Apple की guidelines नहीं बदलता
      मैं business UI एक बार लिखता हूँ और फिर LLM से उसे React Native और React के बीच convert कराता हूँ
      लेकिन Apple अब भी 4.2 minimum functionality rule बनाए हुए है, जिसके तहत “सिर्फ़ वेबसाइट को पैक करके बनाए गए ऐप” reject हो जाते हैं
    • जटिल और लंबे समय तक चलने वाले ऐप को हर प्लेटफ़ॉर्म के लिए तीन बार लिखना लगभग एक दुःस्वप्न है
      features और tests को तीनों प्लेटफ़ॉर्म पर sync रखना पड़ता है, और developers को भी कई stacks में माहिर होना पड़ता है
      ज़्यादातर users को अच्छे WebView implementation और native app में लगभग कोई फ़र्क महसूस नहीं होता, लेकिन इसकी क़ीमत बहुत ज़्यादा है
  • Valdi कॉन्सेप्ट के लिहाज़ से React Native जैसा लगता है
    अब React-आधारित cross-platform frameworks की संख्या React Native, Lynx.js(ByteDance/TikTok), Valdi तक पहुँच गई है
    competition अच्छी बात है, लेकिन क्या यह RN जितना बड़ा ecosystem जल्दी बना पाएगा, इस पर संदेह है
    RN में इस साल Hermes engine improvements, native binding generator, multithreaded animation, Tailwind support जैसी कई प्रगति हुई हैं
    Lynx.js शायद इस मामले में आगे हो सकता है कि वह React के अलावा दूसरे frameworks को भी सपोर्ट करना चाहता है

    • थोड़ा देखने पर पता चला कि Valdi VSCode debugging को पूरी तरह सपोर्ट करता है
      RN का Radon IDE paid है, जबकि Valdi open source है
      यह भी दिलचस्प है कि Valdi RN के Hermes engine का इस्तेमाल करता है
      संबंधित दस्तावेज़ देखने पर AOT/JIT implementation के बारे में जिज्ञासा होती है
  • पहले Snap में मैंने इस प्रोजेक्ट के शुरुआती वर्ज़न (Screenshop! ) को साथ मिलकर debug किया था
    Simon बेहतरीन engineer थे, और इस प्रोजेक्ट का सार्वजनिक होना सच में बहुत अच्छा लगा
    Snap टीम को बधाई

    • यह थोड़ा हैरान करने वाला था कि Snap जैसी सरल ऐप ने cross-platform UI framework में निवेश किया
      कैमरा, AR, notifications, screenshot detection जैसी native integrations अहम होने वाली ऐप के लिए यह और भी ज़्यादा चौंकाने वाला है
    • तब भी यह वाकई शानदार प्रोजेक्ट था, और मुझे याद है कि इसका लक्ष्य open source करना था
      यह हक़ीक़त बनते देख खुशी हो रही है
    • मैंने भी Simon के साथ काम करते हुए web porting की कोशिश की थी, लेकिन नाकाम रहा
      वह बेहद स्मार्ट इंसान हैं, और पूरी टीम को बधाई
    • अब अगर यह फ़्रेमवर्क किसी असली प्रोजेक्ट में इस्तेमाल किया जाए, तो कैसा रहेगा, यह जानने की जिज्ञासा है
    • Composer” नाम याद आ रहा है
  • Snapchat द्वारा बनाए गए UI framework के लिए Discord community — यह निजी तौर पर मुझे बिल्कुल आकर्षक नहीं लगता

    • आजकल कई प्रोजेक्ट अपनी community को Discord पर ले जा रहे हैं
      यह परफ़ेक्ट नहीं है, लेकिन शायद इससे दूर रहना भविष्य की धारा से खुद को अलग कर लेना भी हो सकता है
    • मैं भी Discord काफ़ी इस्तेमाल करता हूँ, लेकिन कामकाजी community के तौर पर यह अब भी असुविधाजनक लगता है
  • दस्तावेज़ में लिखा है, “अगर C++, Objective-C, Kotlin objects को TypeScript में expose किया जाए तो वे Native Reference हैं, और उल्टा होने पर JS Value Reference”
    Swift या SwiftUI का ज़िक्र न होना थोड़ा चिंताजनक लगता है

  • सच कहूँ तो Snap के बनाए framework पर भरोसा करना मुश्किल है
    क्योंकि पहले उसके Android app quality बहुत ख़राब थी

    • यह जानकर झटका लगा था कि पहले वह असल में फ़ोटो नहीं खींचता था, बल्कि camera view का screenshot लेता था
  • Valdi को “एक UI framework जहाँ TypeScript में एक बार लिखो और iOS, Android, macOS पर native performance के साथ चलाओ” के रूप में पेश किया गया है
    यह इस बात पर ज़ोर देता है कि इसमें न webview है न JS bridge

    • मज़ाक में कहा गया, “हमारे पास दोनों हैं। Country and western!”
  • मेरा मानना है कि हर प्लेटफ़ॉर्म की native language में UI दो बार लिखना चाहिए, और common logic को C-family FFI से share कर लेना चाहिए
    आख़िर यह कितना मुश्किल हो सकता है?

    • हम भी उसी दिशा में जा रहे हैं। अभी सिर्फ़ iOS सपोर्ट करते हैं, लेकिन user feedback मिलने के बाद Android तक बढ़ने का प्लान है
      टीम के ज़्यादातर लोग Android users हैं, लेकिन ग्राहक iOS-केंद्रित हैं, इसलिए प्राथमिकता वैसी रखी गई है
      मैंने RN ऐप भी बनाया है, लेकिन अब भी किसी सचमुच जादुई cross-platform solution का इंतज़ार है
    • मैं भी सहमत हूँ। असली बात architecture को इस तरह डिज़ाइन करना है कि business logic UI से अलग रहे
      तब web, mobile, desktop, CLI जैसी अलग-अलग interfaces सिर्फ़ core को कॉल करने वाली पतली layers बन जाती हैं
      पूरी तरह एकसमान UX पाना मुश्किल हो सकता है, लेकिन लंबे समय में 3rd-party framework dependency कम की जा सकती है
  • अगर आप Valdi के state management के बारे में जानना चाहते हैं, तो यह React के class component style को लगभग जस का तस इस्तेमाल करता है
    आधिकारिक दस्तावेज़ उदाहरण में StatefulComponent inherit करके onCreate, onDestroy, onRender implement करने की संरचना है

    • मुझे भी React class components की याद आती है
      आज की तरह दर्जनों useFunction इस्तेमाल करने का तरीका ज़्यादा error-prone और जटिल लगता है
  • अफ़सोस की बात है कि Linux, Windows, HTML targets सपोर्ट नहीं किए जाते

 
clastneo 2025-11-10

RN में ज़्यादातर ऐप का business logic सिर्फ़ JS से भी काफ़ी तेज़ी से चल सकता है.
लेकिन polishing करते-करते असली समस्या यह लगती है कि "platform के हिसाब से behavior अलग-अलग होने के मामले बहुत ज़्यादा होते हैं," इसलिए इसे संतोषजनक तरीके से हल करना काफ़ी मुश्किल हो जाता है.