Scrappy - दोस्तों और सिर्फ अपने लिए छोटे ऐप बनाना
(pontus.granstrom.me)- Scrappy एक होममेड सॉफ़्टवेयर बनाने का टूल है, जो गैर-विशेषज्ञों को भी आसानी से अपने छोटे ऐप खुद बनाने में मदद करता है
- बड़े commercial ऐप या enterprise ऐप से अलग, यह व्यक्तिगत और रचनात्मक छोटे-छोटे समस्याओं को स्वतंत्र रूप से हल करने देता है
- यह canvas-आधारित UI, आसान code editing, real-time collaboration और sharing फीचर देता है, इसलिए non-programmer भी इसका उपयोग कर सकते हैं
- हर ऐप (Scrapp) मूल रूप से multiplayer environment में होता है, और account बनाए बिना तुरंत उपयोग व collaboration संभव है
- AI code generation या मौजूदा टूल्स से अलग, Scrappy यूज़र के direct manipulation और ownership पर ज़ोर देता है
परिचय और पृष्ठभूमि
- अधिकांश software या तो mass market में बेचने के लिए बनाए जाते हैं या बड़े पैमाने के customized apps होते हैं
- लेकिन वास्तव में हर व्यक्ति की ज़रूरतें पूरी करने वाले छोटे, personal customized apps बहुत कम मिलते हैं
- Scrappy एक research prototype है, जो किसी को भी अपने दोस्तों और परिवार के लिए सरल और रचनात्मक ऐप खुद बनाने में मदद करता है
- Scrappy का लक्ष्य यह ठोस रूप से दिखाना है कि programming expertise के बिना भी ज़्यादा लोग रचनात्मक और personal software बना सकें
Scrappy क्या है
- Scrappy में बनाए गए ऐप को Scrapp कहा जाता है
- प्रमुख उदाहरण:
- प्राथमिक कक्षा के बच्चों के लिए arithmetic practice app: कठिनाई स्तर बदला जा सकता है
- स्थानीय इवेंट attendee counter: कई प्रवेश द्वारों से आने-जाने वाले लोगों का प्रबंधन
- meeting cost calculator clock: real-time में मीटिंग की लागत की गणना
- साप्ताहिक household chores management: सदस्यों के अनुसार लचीला schedule management
Scrappy में ऐप बनाने का अनुभव
- Scrappy में Figma, Miro, Google Slides जैसे infinite canvas पर button, text field जैसे objects रखे जाते हैं
- Inspector panel में properties को सीधे बदला जा सकता है, और button जैसी चीज़ों में JavaScript code भी जोड़ा जा सकता है
- ऐप बनाना drag/drop, property editing और code insertion को चरणबद्ध तरीके से दोहराते हुए पूरा होता है
मुख्य विशेषताएँ:
- बुनियादी behavior configuration: fields और buttons रखकर तुरंत behavior जोड़ा जा सकता है
- reactive formulas: खास conditions पर प्रतिक्रिया देने वाले real-time property changes लागू किए जा सकते हैं
- multiplayer synchronization: state हमेशा real-time में save और sync होती रहती है
- live editing: run और edit के बीच अलगाव नहीं, हर समय real-time modification संभव
- selective sharing: ऐप के सिर्फ कुछ हिस्सों को अलग से share और connect किया जा सकता है
- visible data manipulation: spreadsheet की तरह data देखते हुए debugging और editing संभव
Scrappy को विकसित करने का कारण
- Scrappy user-driven programming को साकार करने वाले “small computing”, “casual programming”, “home-cooked software” जैसे रुझानों से जुड़ा है
- मौजूदा visual programming (block, node-wire आधारित) से अलग रास्ता लेते हुए, यह intuitive manipulation और scripting को जोड़ता है
- इसे HyperCard, Visual Basic, concurrent online media आदि से प्रेरणा मिली है, और productivity campus tools तथा real-time collaboration (Google Docs, Figma आदि) के अनुभव को महत्वपूर्ण माना गया है
- Scrappy बड़े commercial apps या AI auto-generation approach से अलग, यूज़र को direct control देता है और personalization, fun और creativity को अधिकतम करता है
- सीधे code generate किए बिना भी, यह ऐप बनाने का ज़्यादा आसान और human-friendly अनुभव देता है
Scrappy किन उपयोगकर्ताओं के लिए है
- work process optimizer: वे लोग जो किसी expert की मदद के बिना जटिल workflow को बेहतर बनाना चाहते हैं
- teachers और students: command line, environment settings जैसी सहायक तकनीकों के बिना programming के मूल पर ध्यान दे सकते हैं
- hobby developers: mass apps की जटिलता से बाहर निकलकर जल्दी कई projects explore करना चाहने वाले
- DIY पसंद करने वाले: घर या शौक की तरह अपने लिए खुद ऐप बनाना चाहने वाले यूज़र
फिलहाल Scrappy में पूरी तरह शुरुआती लोगों के लिए ऐप बनाना अभी भी कठिन है (कुछ JavaScript ज्ञान चाहिए), लेकिन sharing और remixing non-programmer भी कर सकते हैं.
Scrappy में किस तरह के ऐप बनाना अच्छा है?
- दोस्तों/जान-पहचान वालों के साथ sharing: ज़्यादातर Scrapp कई यूज़रों के real-time collaboration के लिए उपयुक्त हैं
- लगातार modification और improvement: ऐप चलते समय भी तुरंत बदलाव संभव, कोई deployment/build प्रक्रिया नहीं
- छोटे पैमाने की calculation या manipulation: जटिल system की तुलना में shared document + थोड़ी computing के लिए अधिक प्रभावी
- यूज़र friction को न्यूनतम करना: account creation जैसे अनावश्यक चरणों के बिना सिर्फ लिंक से access और उपयोग
- कम संख्या में भरोसेमंद उपयोगकर्ता: यदि permission control या mission-critical विश्वसनीयता ज़रूरी हो तो यह उपयुक्त नहीं है
ऐप आइडिया उदाहरण: customized flashcards, meeting agenda, online workshop management, family bulletin board, travel planner आदि
Scrappy vs mass apps
अगर कोई लोकप्रिय ऐप मिल नहीं रहा हो, या उपयुक्त विकल्प न हो, तो उसे Scrappy से खुद बनाकर share किया जा सकता है। Scrappy के फायदे:
- सिर्फ ज़रूरी फीचर्स: अनावश्यक तत्व नहीं
- व्यक्तिगत अपनापन: खुद बनाया गया ऐप ज़्यादा अर्थपूर्ण और लगाव वाला होता है
- मज़ेदार modification: रंग, layout को स्वतंत्र रूप से बदलना और humor जोड़ना संभव
- आसान remix/share: दूसरे यूज़र आसानी से बदलकर दोबारा इस्तेमाल कर सकते हैं
- collaboration-केंद्रित design: कई यूज़र एक साथ manipulate और edit कर सकते हैं
- तुरंत उपयोग: account signup के बिना सिर्फ लिंक क्लिक करके तुरंत इस्तेमाल
- स्पष्ट data ownership: data local में store होता है, इसलिए पूरा control यूज़र के पास रहता है
Scrappy vs AI-आधारित ऐप निर्माण
AI ऐप को अपने-आप generate कर सकता है, लेकिन Scrappy की ताकत आसान समझ, real-time collaboration और creative ownership में है
- आसान समझ वाली संरचना: जटिल code के बिना visual object-आधारित
- real-time सहयोग समर्थन: कई यूज़र एक साथ collaborate और edit कर सकते हैं
- ज़्यादा मज़ा और creativity: तुरंत feedback और सक्रिय modification का आनंद देता है
Scrappy vs HyperCard और उसके बाद आए टूल्स
- internet-friendly sharing: Scrappy ऐप सिर्फ लिंक से online share किए जा सकते हैं
- real-time collaboration environment: simultaneous editing/execution support
- modern UI और interaction: infinite canvas, कई तरह के objects support
- JavaScript scripting: आधुनिक और व्यापक रूप से इस्तेमाल की जाने वाली भाषा में behavior
- ज़्यादा विविध interactive objects: string, number, date, JSON आदि support
- reactive formulas और state connection: spreadsheet जैसे dynamic relationships सेट किए जा सकते हैं
आगे की योजना
- non-programmer उपयोगकर्ताओं के लिए entry barrier कम करना
- code autocomplete, आसान debugging, relationship visualization, समझने में आसान error messages, AI-आधारित assistant
- आसान और तेज sharing, public gallery, mobile support को मज़बूत करना
- फीचर enhancement और विस्तार
- collection और data processing फीचर्स को मज़बूत करना, repetitive object management, reusable components की शुरुआत
- Scrappy की extensibility (नए objects support), conceptual consistency में सुधार आदि
1 टिप्पणियां
Hacker News राय
मुझे इस प्रोजेक्ट की दिशा पसंद है, लेकिन hosted SaaS मॉडल मेरे लिए सही नहीं लगा। छोटे counter जैसी एक-दिन की projects के लिए ठीक है, लेकिन अगर कोई छोटा app कई साल चलाना हो, तो dependency समस्या बन जाती है। Learning curve चाहे जितनी कम हो, वह रहती तो है ही, और लंबे समय तक इस्तेमाल के लिए मैं ऐसी accessibility, आसान language, और ऐसे tools को ज़्यादा पसंद करता हूँ जिनसे मैं खुद GUI जोड़ सकूँ। मेरा मानना है कि code को पूरी तरह छिपाने की ज़रूरत नहीं है; लोगों के लिए उसे इस तरह आसान बनाया जाना चाहिए कि वे वास्तव में कुछ कर सकें। MySpace पर कितने लोगों ने CSS सीखी थी, यह याद करें—शुरुआत copy-paste से होती है, लेकिन बाद में लोग उसे अपनी ज़रूरत के हिसाब से tweak करने लगते हैं। आजकल मैं ज़्यादातर HTML/CSS/JS इस्तेमाल करता हूँ, और अगर सच में backend चाहिए हो तो plain PHP (बिना framework) लेता हूँ। हाँ, इस तरीके की कमी यह है कि यह browser से बँधा रहता है, लेकिन काम पर इस तरह से बने छोटे projects (AutoHotKey सहित) 10 साल से ज़्यादा समय से लगभग बिना maintenance के ठीक चल रहे हैं। खासकर AutoHotKey scripts को मैंने 8 साल पहले macOS पर जाने के बाद छोड़ दिया था, लेकिन सहकर्मी आज भी उन्हें रोज़ कई बार इस्तेमाल करते हैं। अगर AutoHotKey कभी काम करना बंद भी कर दे, तब भी बना हुआ code इस्तेमाल किया जा सकता है। लेकिन SaaS solutions में यह जोखिम है कि अगर founder की रुचि कहीं और चली जाए, तो सब फिर से बनाना पड़े। ऐसे “scrappy” solutions ढूँढ़ने वाले लोग हर बार दोबारा बनाना नहीं चाहते—यही मूल बात है.
CardStock का लेख में ज़िक्र नहीं था, लेकिन इसका लक्ष्य और approach Scrappy से मिलते-जुलते लगते हैं। Scrappy के विपरीत, CardStock open source है और local में चलता है। CardStock / GitHub repository देखें। Decker भी open source है, और Scrappy roadmap की कई ज़रूरतें—table data query language, grid widget, और “Contraption” के रूप में parts abstraction—पहले से लागू करता है। Decker देखें.
Roadmap में mobile पर बने apps को अच्छी तरह चलाने की बात है, लेकिन mobile editing को दायरे से बाहर रखा गया लगता है (“हथेली के आकार की touchscreen Scrapps editing के लिए असुविधाजनक है” ऐसा कहा गया है)। लेकिन अब बहुत से लोग mobile को ही अपना एकमात्र computing device मानते हैं, और code से लेकर novel तक mobile पर लिखते हैं। इसलिए, भले कुछ असुविधा हो, अगर mobile editing interface पर भी विचार किया जाए तो इस tool का प्रभाव कहीं बड़ा हो सकता है।
मैंने जो सबसे अच्छे काम किए उनमें एक यह था कि Apple Watch walking records को एक बड़े map पर रखने वाला simple app एक हफ़्ते में बनाया, उसे AppStore पर डाला और दोस्तों के साथ साझा किया। एक साल बाद भी दोस्त और कभी-कभी app को यूँ ही खोज लेने वाले लोग पूरे शहर में चलकर verification messages भेजते हैं, और यह बहुत संतोष देता है। कमाई भले न हो, लेकिन अनुभव सच में सार्थक था। OP की तरह, दोस्तों के लिए मज़े-मज़े में simple apps बनाना सबसे बड़ी खुशी है.
Spreadsheet जितना वास्तव में end-user के काम आने वाला programming environment मैंने नहीं देखा.
vibe coding अभी developers को replace नहीं करेगी, लेकिन ऐसे simple systems में यह सबसे मज़बूत competitor होगी। अगर LLM से simple app (HTML+embedded JS) बनवाओ, तो थोड़ा बहुत edit करके काफ़ी polished नतीजा मिलता है, और visual रूप से भी बेहतर लगा उदाहरण.
हम इस विषय को programmer के नज़रिए से देख रहे हैं, लेकिन असली अवसर community में हो सकता है। उदाहरण के लिए, इसे परिवार-आधारित personal app store की तरह शुरू किया जा सकता है (Masterson style)। Security नहीं, क्योंकि सब परिचित हैं, और invite के बिना कोई योगदान भी नहीं कर सकता। बस एक विचार है.
अगर UI elements को blank sheet पर drag-and-drop करना पड़े, grid snap लगातार UI element size से टकराता रहे, और आख़िर में code autocomplete, visual programming, API मदद या AI support के बिना plain JavaScript ही टाइप करनी पड़े—तो क्या सच में यही अंतिम रूप है?
मैं भी पूरी तरह सहमत हूँ कि beginners के लिए block-based की बजाय “scriptable components” approach बेहतर है। अभी mobile पर हूँ, इसलिए जल्द desktop पर आज़माने का इरादा है। Analysis में एक बात छूट गई: लोग “easy sharing” और “zero cost” चाहते हैं। Minimal environment में app बनाना तो आसान है, लेकिन distribution (app store barrier) / hosting समस्या है, इसलिए परिवार या परिचितों के लिए भी $5/महीना देने में झिझक होती है। सच कहें तो professional developers भी ऐसे ही सोचते हैं.
“कंप्यूटर लोगों के लिए काम करें, और cooking या word processing की तरह सबकी गतिविधि बन जाएँ” जैसी दिशा पढ़कर लगा कि यह बहुत सामान्य-सी बात है। “live updates सहित, सब कुछ free. LLM…” जैसी भाषा में em-dash (-) बहुत ज़्यादा थे, इसलिए यह AI-generated copy जैसी लगी। व्यक्तिगत रूप से, अगर मुझे लगे कि content AI ने लिखा है, तो मेरी रुचि बहुत जल्दी कम हो जाती है। Creator की गलती नहीं कहूँगा, लेकिन ऐसी copy में मेरी भी ख़ास दिलचस्पी नहीं होती.