2026 में फिर से Rails की ओर लौटना

• बैंड के setlist management app (setlist.rocks) को बनाते हुए लंबे समय बाद Ruby on Rails डेवलपमेंट का आनंद फिर से खोजा
• नवीनतम Rails 8 पारंपरिक MVC संरचना को बनाए रखते हुए Hotwire(Stimulus·Turbo) आधारित “no-build” frontend, Solid Cache/Queue/Cable आदि के साथ आधुनिक बना है
• SQLite को इतना optimize किया गया है कि सिर्फ default settings के साथ भी यह real service के लिए उपयुक्त हो गया है, और Kamal deployment tool से container-आधारित zero-downtime deployment आसान हो गई है
• Rails की “Convention over Configuration” philosophy और समृद्ध gem ecosystem की वजह से idea से prototype तक तेज़ी से implementation संभव है
• Ruby और Rails की लोकप्रियता पहले की तुलना में घटी है, लेकिन वे अब भी परिपक्व और सुसंगत OSS framework के रूप में डेवलपमेंट का आनंद देते हैं

---

साइड प्रोजेक्ट और Rails की ओर वापसी

• बैंड की setlist और song notes को manage करने के लिए web app खुद विकसित किया, और मौजूदा spreadsheet या chat से अधिक कुशल तरीका अपनाने की कोशिश की
• डेवलपमेंट के दौरान Rails की सरलता और productivity को फिर से महसूस किया, और हालिया जटिल web ecosystem की तुलना में “शुद्ध डेवलपमेंट का आनंद” मिलने की बात कही
• Ruby को अब भी स्वाभाविक syntax और expressiveness वाली भाषा माना गया, जिसमें सोच को code में बदलना आसान है
• Stack Overflow 2025 सर्वे के अनुसार Ruby और Rails की लोकप्रियता घटी है, लेकिन personal project में अब भी इन्हें पसंद किया जाता है

Rails 8 में बदलाव और frontend

• Rails 8 मौजूदा MVC संरचना को बनाए रखते हुए Hotwire(Stimulus·Turbo) आधारित frontend integration प्रदान करता है
  • Turbo link click और form submit को intercept करके SPA स्तर की responsiveness देता है
  • Stimulus सिर्फ ज़रूरी हिस्सों में JS behavior जोड़कर न्यूनतम JavaScript लेखन से interactive UI बनाना संभव करता है
• Importmap की मदद से Webpack, npm के बिना JS library को सीधे CDN से लाया जा सकता है
• AI tools का उपयोग करके UI बनाया गया, लेकिन रचनात्मकता और code की कलात्मकता के बीच दुविधा भी दिखाई गई

डेवलपमेंट workflow और productivity

• Rails की “Convention over Configuration” philosophy से model, routing, controller और view को तेज़ी से व्यवस्थित किया जा सकता है
  • उदाहरण के तौर पर Tag model बनाना, RESTful routing को automate करना, और JSON response handling की प्रक्रिया दिखाई गई
• ERB template और live reload की मदद से तेज़ prototyping संभव है
• समृद्ध gem ecosystem के जरिए CSV, PDF जैसी कई सुविधाओं को आसानी से integrate किया जा सकता है

backend सुधार: Solid* series और SQLite

• Solid Cache/Queue/Cable Rails 8 में default रूप से शामिल हैं, जिससे Redis के बिना cache, job queue और websocket को संभाला जा सकता है
  • Solid Cache DB-आधारित caching से RAM बचाता है और setup को सरल बनाता है
  • Solid Queue DB-आधारित background job management देता है, और सिर्फ SOLID_QUEUE_IN_PUMA=1 setting से इसे चलाया जा सकता है
  • Solid Cable DB-आधारित Action Cable adapter के रूप में real-time features को support करता है
• SQLite में database.yml के pragmas: settings के जरिए WAL mode, NORMAL synchronization जैसी optimizations default रूप से लागू होती हैं
  • अलग DB server के बिना भी छोटे production environment में व्यावहारिक उपयोग संभव है

deployment automation और Kamal

• पहले के Capistrano·Ansible-आधारित deployment की जटिलता का ज़िक्र करते हुए, Kamal को Rails 8 के default deployment tool के रूप में पेश किया गया
  • container build → push → server deployment → health check → zero-downtime switch की प्रक्रिया को automate करता है
  • kamal-proxy traffic switching और SSL handling की ज़िम्मेदारी लेता है
  • .kamal/secrets file के जरिए environment variable-आधारित secure secret management का समर्थन मिलता है
• GitLab CI के साथ integration करके सिर्फ git push से deployment संभव है, जो पुराने Heroku की सरलता की याद दिलाता है

authentication और अन्य सुविधाएँ

• Rails 8 built-in authentication generator (auth generator) देता है, जिससे Devise की तुलना में अधिक सरल authentication system बनाया जा सकता है
• Devise अब भी अपनी समृद्ध features और documentation की वजह से उपयोगी है, लेकिन Rails के default authentication की सरलता भी आकर्षक मानी गई

Rails ecosystem की वर्तमान स्थिति और स्थायित्व

• Ruby और Rails की लोकप्रियता घटी है, लेकिन Shopify·Basecamp·SoundCloud·GitHub जैसी प्रमुख सेवाएँ अब भी इनका उपयोग करती हैं
• कई gem maintenance phase में हैं, लेकिन Rails अब भी हर साल लगातार release cycle बनाए रखता है
• इसे “नए डेवलपरों की आमद भले कम हुई हो, लेकिन अब भी आनंद से डेवलपमेंट किया जा सकने वाला framework” कहा गया

निष्कर्ष

• Rails ने भले ही नवीनतम trends से कुछ दूरी बना ली हो, लेकिन इसे डेवलपमेंट का आनंद और सरलता वापस दिलाने वाले tool के रूप में रेखांकित किया गया
• लोकप्रियता से अधिक बनाने के आनंद और रचनात्मकता को महत्व देते हुए, अंत में “एक बार फिर Rails को आज़माकर देखो” का संदेश दिया गया

[joyfui]

मुझे याद है कि Rails में यह "configuration over convention" नहीं, बल्कि "convention over configuration" था...

[savvykang]

> most of the web frameworks I’d (...) required endless amounts of XML boilerplate and other configuration to wire things up. Rails ने यह सब हटा दिया और “convention over configuration” की धारणा पेश की।

लगता है कि LLM ने शब्द क्रम बदले बिना इनपुट के क्रम में ही आउटपुट दिया है। मूल पाठ में यह सही है।

[xguru]

LLM ऐसी चीज़ें भी गलत कर देता है। मैंने इसे ठीक कर दिया है। धन्यवाद

[GN⁺]

Hacker News की राय

• मुझे Rails सच में बहुत पसंद है, लेकिन बड़े non-static typed codebase पर काम करने के बाद अब personal projects के अलावा Rails पर लौटना मुश्किल लगता है
  types के बिना बड़े codebase को maintain करना RubyMine जैसे शक्तिशाली IDE के साथ भी किसी दुःस्वप्न से कम नहीं है
  आजकल Sorbet कितना आगे बढ़ चुका है, खासकर RoR के साथ इसकी tuning कैसी है, यह जानने की जिज्ञासा है

  • इन दिनों Rust/Loco सबसे दिलचस्प framework लगता है
    यह Rails की philosophy को अच्छी तरह follow करता है और साथ ही Rust सीखना आसान बनाता है
  • IHP Haskell-आधारित, Rails से प्रेरित framework है, जो दोनों दुनियाओं के फायदे जोड़ने की कोशिश करता है
    वीकेंड पर आज़माने लायक है
  • समस्या सिर्फ types की कमी नहीं है, बल्कि runtime पर functions या properties define होने की संरचना के कारण debugging लगभग असंभव हो जाती है
    असली production data को local में clone करना पड़ता है या server में SSH से घुसकर REPL में state देखनी पड़ती है
    IDE में debugging करना नरक जैसा अनुभव था
    मुझे Ruby सच में बहुत पसंद थी, लेकिन live debugging झेलने के बाद यह कठिन लगने लगा
  • यह जानने की जिज्ञासा है कि बड़े non-static codebase इतने दुःस्वप्न जैसे क्यों होते हैं
  • आजकल agentic coding की वजह से language या framework का महत्व धीरे-धीरे कम हो रहा है
    अब Ruby या Python को खास तौर पर चुनने की वजह नहीं बचती
    Python शायद ML क्षेत्र में कुछ समय और टिकेगा, लेकिन आखिरकार गायब हो जाएगा

• मुझे भी अच्छा लगा कि किसी ने यह बात खुलकर कही
  इन दिनों मैं अत्यधिक microservices architecture से थक चुका हूँ
  शाम को मैं ऐसे projects छूता हूँ जो बिना अनावश्यक structure के बस समस्या हल करते हैं
  पहले मैं PHP structure के साथ बहुत काम करता था, लेकिन Rails हो या PHP, दोनों आखिरकार समस्या हल करने के औज़ार ही हैं

  • इस साल की शुरुआत से मैं नए project में RoR इस्तेमाल कर रहा हूँ, और यह सचमुच ताज़ी हवा जैसा अनुभव है
    पुराने desktop IDE development की तरह लगता है, मानो सब कुछ “एक डिब्बे के अंदर” चल रहा हो
    web development के जटिल components को manage करने से निकलकर, productivity-केंद्रित सादगी वापस मिलने जैसा एहसास है
    और ऊपर से TypeScript न इस्तेमाल करना पड़े, यह तो और भी अच्छा है। मुझे TypeScript बहुत verbose और अनावश्यक boilerplate का ढेर लगता है
  • यह जानने की जिज्ञासा है कि STOA का मतलब क्या है
  • “सोच और code के बीच translation न्यूनतम हो जाता है” — यह बात Ruby के सार को बहुत अच्छी तरह व्यक्त करती है

• हम 2007 से production में Rails app लगातार चला रहे हैं
  Rails की लंबी उम्र का रहस्य इसकी उम्र में नहीं, बल्कि इसकी stability और practicality में है
  backend में JavaScript इस्तेमाल करने से efficiency बढ़ती है — यह दावा पहले ही गलत साबित हो चुका है
  ज़्यादातर tech stack बदलाव resume optimization या trend anxiety की वजह से होते हैं, असली engineering ज़रूरतों की वजह से नहीं
  Rails चुपचाप असली business को लगातार चलाता रहा है
  कोई भी यह नहीं मानेगा कि NPM के 31 लाख packages, RubyGems के 1.9 लाख packages की तुलना में अनिवार्य रूप से अधिक functionality देते हैं

  • हम भी 2011 से दो कंपनियों में production में Rails इस्तेमाल कर रहे हैं
    Inertia + Vue.js पर migration चल रहा है, और यह इतना शक्तिशाली संयोजन है कि backend में लगभग कोई बदलाव नहीं करना पड़ता
    productivity gains की वजह से hiring की कठिनाई भी काफी हद तक संतुलित हो जाती है
  • NPM में packages ज़्यादा होने का मतलब है कि users भी ज़्यादा हैं
    जितने ज़्यादा users, ecosystem उतना healthy
    लेकिन RubyGems में भी बहुत से पुराने packages हैं, इसलिए सीधी तुलना करना मुश्किल है

• RoR या Django की “batteries included” philosophy अच्छी है, लेकिन पुराने projects का maintenance बहुत समय लेता है
  5–6 साल पुराने project को update करना हो तो dependency management बड़ा बोझ बन जाता है
  इसलिए आजकल मैं Go में simple frameworks के साथ, या बिल्कुल बिना framework के development करना पसंद करता हूँ

  • मैं 3 लाख lines से ज़्यादा वाले Django codebase को manage कर रहा हूँ, और direct dependencies सिर्फ 32 हैं
    अगर सिर्फ ज़रूरी libraries इस्तेमाल की जाएँ, तो maintenance आसान रहता है
  • समस्या शायद लगातार बदलाव (churn) है
    security patch के अलावा update करना ज़रूरी क्यों है, यह सवाल उठता है
  • Laravel में मुझे ऐसी समस्या लगभग नहीं हुई
    पिछले डेढ़ साल में 5 major versions upgrade किए, फिर bhi यह अपेक्षाकृत सरल रहा
  • आखिरकार maintenance की कठिनाई dependency management strategy पर निर्भर करती है
    शुरुआत में सावधानी से setup कर लिया जाए तो लंबे समय तक बहुत कम छेड़छाड़ करनी पड़ती है
  • क्या “batteries included” होना उल्टा upgrades को कठिन बना देता है? मुझे तो इसका उल्टा लगता है

• मुझे लगता है upgrade experience को कम आँका जाता है
  Next.js में हर major version पर structure लगभग पूरी तरह बदल जाता है, जबकि Rails में gradual deprecation cycle धीमा है, इसलिए यह कहीं ज़्यादा stable है
  जब आप product को लगातार ship कर रहे हों, तब नवीनतम paradigm से कहीं अधिक महत्वपूर्ण interface stability होती है

  • यह बात सच में वही समझ सकता है जिसने Rails को लंबे समय तक चलाया हो
    Next.js में pages → app router transition असल में पूरे replatforming के बराबर बदलाव था
    इसके उलट Rails में documented upgrade path और predictable deprecation cycle है
    rbenv/asdf की वजह से Ruby version management भी environment mismatch की समस्या लगभग खत्म कर देता है
  • Next का app router transition एक संरचनात्मक बड़ा बदलाव था, इसलिए इस बिंदु पर TanStack Start जैसे कम opinionated विकल्पों पर विचार करना उचित है

• मैं 10 साल से ज़्यादा समय से Rails के साथ DevOps से लेकर solo web developer तक सब कुछ करता आया हूँ, और दोबारा मौका मिले तो भी यही चुनूँगा
  Rails एक साफ-सुथरा और उत्पादक framework है जिसमें सब कुछ मौजूद है
  Stack Overflow survey में भी यह अब तक “अगले project में इस्तेमाल करना चाहूँगा” वाली Top 5 stacks में रहा है

  • Rails का “one-person framework” वाला स्वभाव सचमुच आकर्षक है
    infrastructure setup की चिंता लगभग नहीं करनी पड़ती, और deployment भी सरल है
  • Rails पर वास्तविक काम करने वाले लोग शायद survey में भाग लेना ज़रूरी नहीं समझते
    अंत में अहम बात दूसरों की नज़र नहीं, बल्कि अपने लिए सही tool चुनना है
  • Rails 2004 में launch हुआ था, और अब यह 20 साल से अधिक पुराना framework है
    यह Django से 1 साल पहले आया था
  • Stack Overflow 2025 survey में Rails ने web framework “Admired vs Desired” श्रेणी में 10वाँ स्थान हासिल किया
    survey link

• पहले मुझे लगता था कि Ruby/Rails ज़्यादातर समस्याओं का सबसे बेहतरीन समाधान है, और आज भी मैं यही मानता हूँ

• मैंने Rails इस्तेमाल नहीं किया, लेकिन आजकल के web development environment की अव्यवस्था से मैं सहमत हूँ
  इसलिए मैंने भविष्य को देखते हुए Elixir और Phoenix चुना

  • पिछले कुछ दिनों में जब भी मैंने कहा कि मैं Ruby में project कर रहा हूँ, पाँच लोगों ने Elixir सुझाया
    अगला project मैं ज़रूर इसमें आज़माना चाहता हूँ
    Elixir में ऐसी कौन-सी बात है जो इसे इतना आकर्षक बनाती है, और पहली बार देखते समय किन points पर ध्यान देना चाहिए — यह जानना चाहता हूँ

• 10 साल पहले मैंने Sweden की एक बड़ी broadcasting company का streaming frontend Rails में बनाया था
  Heroku पर 10 लाख से अधिक concurrent users संभाले थे, और यह सचमुच बहुत अच्छी तरह चला
  बाद में मैं streaming infrastructure, API, AI/ML जैसे दूसरे क्षेत्रों में चला गया, लेकिन Rails इसलिए नहीं छोड़ा कि वह fail हुआ था, बल्कि समस्या की प्रकृति बदल गई थी
  Rails data model और business logic-केंद्रित समस्याओं के लिए उपयुक्त है, जबकि concurrency या infrastructure-केंद्रित समस्याओं में दूसरी languages अधिक उपयुक्त होती हैं
  Ruby आज भी सुंदर और expressive language के रूप में बहुत याद आती है

  • मैं भी “समस्या के अनुसार tool चुनो” वाली philosophy से सहमत हूँ
    लेकिन अपनी पसंदीदा language के प्रति व्यक्तिगत पक्षपात को पूरी तरह छोड़ना आसान नहीं होता
    यह जानने की जिज्ञासा है कि आपने अगला project किस language में किया

• जिन्हें static typing की कमी खलती है, उनके लिए Sorbet जैसा शानदार समाधान मौजूद है
  इससे Ruby की productivity, static typing और LSP integration — सब एक साथ मिल सकते हैं
  Shopify की वजह से Rails में Sorbet support भी अच्छा है
  मुझे यह ecosystem इतना पसंद है कि आज भी Rails में काम करना चाहूँगा
  AI tools की प्रगति की वजह से अब लगता है कि सीमा सिर्फ कल्पना की है

  • इन दिनों AI क्षेत्र में सबसे बड़ी चर्चा OpenClaw की है
    इसी के आधार पर मैंने 24x7 store monitoring और Slack notifications देने वाला e-commerce agent बनाया है
    अगर आप AI-related project कर रहे हैं, तो selzee.com/openclaw ज़रूर देख सकते हैं