आप Rails का सही इस्तेमाल नहीं कर रहे हैं
(bananacurvingmachine.com)- Rails 8 और Vite इंटीग्रेशन को लेकर दो डेवलपर्स की बातचीत के ज़रिए, बेवजह जटिल हो चुके आधुनिक वेब डेवलपमेंट माहौल पर व्यंग्य किया गया है
- एक डेवलपर Vite, React, Babel, Tailwind, Docker, Husky जैसे ढेरों टूल जोड़ते हुए इसे ‘modern’ स्टैक बताता है
- वहीं दूसरा व्यक्ति बिना किसी सेटअप के सिर्फ़ बेसिक Rails से तुरंत चलने वाला ऐप दिखाकर सादगी की उपयोगिता सामने लाता है
- जटिल टूलचेन पर निर्भर मौजूदा स्थिति पर तंज कसते हुए, ‘बस Rails इस्तेमाल करो’ का संदेश उभारता है और सादगी के गुण पर फिर सोचने को कहता है
- यह भी दिखाता है कि Rails का मूल उद्देश्य रहा उत्पादकता, एकरूपता, और डेवलपमेंट का आनंद अब भुलाया जा रहा है
> “Just F#$%^& use Rails”
मूल बातचीत का अनुवाद
Kevin: अरे, Rails 8 के लिए Vite ट्राय किया? बहुत तेज़ है।
John: नाम सुना है। वह build tool है न? Rails में पहले से ऐसा कुछ नहीं था?
Kevin: था। लेकिन Vite ज़्यादा modern है। Node और npm इंस्टॉल करने पड़ते हैं, और कुछ scripts सेट करनी पड़ती हैं, लेकिन यह इसके लायक है।
John: रुको, अब Rails को Node चाहिए?
Kevin: हाँ, अगर React इस्तेमाल करना है तो। आजकल सब React ही इस्तेमाल करते हैं।
John: Rails में उसके लिए कुछ था नहीं क्या?
Kevin: था, लेकिन अब React Refresh के साथ Vite इस्तेमाल करना पड़ता है। तब components तुरंत refresh होते हैं। और अगर TypeScript चाहिए, तो उसका सेटअप भी करना होगा।
John: सुनने में ही जटिल लग रहा है।
Kevin: अरे नहीं, कुछ खास नहीं। Babel इंस्टॉल करो, .babelrc सेट करो, vite-plugin-ruby जोड़ो, और styles के लिए PostCSS इस्तेमाल करो।
John: PostCSS?
Kevin: हाँ। और फिर, जाहिर है Tailwind भी इस्तेमाल करना चाहिए — मज़ाक नहीं, तुम CSS एक-एक लाइन खुद तो नहीं लिखना चाहोगे।
John: बिल्कुल नहीं।
Kevin: फिर ESLint और Prettier से कोड साफ़ करो, और commit से पहले Husky hooks भी लगा दो, तब सब परफेक्ट है।
John: तो Vite, React, Babel, PostCSS, Tailwind, ESLint, Prettier, Husky। बस इतना ही?
Kevin: लगभग। अगर server-side rendering भी चाहिए, तो Next.js या Remix इस्तेमाल करना होगा।
John: रुको, हम अभी भी Rails की ही बात कर रहे हैं न?
Kevin: हाँ। आजकल hybrid stack का ही ज़माना है! और अगर JS framework के बिना reactive components चाहिए, तो StimulusReflex या Hotwire भी ठीक हैं।
John: StimulusReflex? किसी Marvel character जैसा लग रहा है।
Kevin: हा हा, सच में है। यह real-time updates के लिए है। लेकिन ActionCable कॉन्फ़िगर करना पड़ेगा, और Redis भी चाहिए।
John: Redis?
Kevin: हाँ, pub/sub layer चाहिए होती है। चिंता मत करो, बस एक Docker container और चला लो।
John: Docker भी इस्तेमाल करना पड़ेगा?
Kevin: बिल्कुल। dependencies अलग रखने के लिए यह ज़रूरी है। पूरा environment recreate करना है तो Docker Compose, Fly.io deployment, और GitHub Actions से pipeline भी चलानी होगी।
John: यह तो... काफ़ी जटिल है।
Kevin: दोस्त, यही modern web development है। बहुत simple है। तुम क्या कर रहे हो?
John: बस थोड़ा छेड़छाड़ कर रहा हूँ।
(John एक command चलाता है। ऐप तुरंत boot हो जाता है। form भी काम करता है, loading भी तेज़ है, और navigation बिजली की तरह तेज़ है।)
Kevin: वाह, यह तो काफ़ी complex लग रहा है। कौन-सा stack है?
John: बस सादा Vanilla Rails।
> Just F#$%^& use Rails.
3 टिप्पणियां
मैं उन सभी टूल्स को पसंद करता हूँ। ये दोनों टूल्स ऐसे हैं जिनके ecosystem और उद्देश्य कुछ जगहों पर एक-दूसरे से मिलते हैं, लेकिन ये पूरी तरह एक जैसे टूल्स नहीं हैं, इसलिए इन्हें कठिनाई के आधार पर नहीं आँकना चाहिए।
viteके साथ लिखें तो आप scripts को बहुत व्यापक और बारीकी से बना सकते हैं। वहीं Stimulus या Hotwire script development को न्यूनतम रखने के लिए ज़्यादा उपयुक्त हैं।लगता है कि ज़्यादातर सामग्री frontend development पर फोकस की हुई है...
Hacker News राय
इस लेख को 10 साल से भी ज़्यादा समय से बार-बार लिखा जा रहा है
कथित “complexity” दरअसल अलग-अलग समस्याओं को हल करने वाले tools की एक सूची भर है
tools खुद समस्या नहीं हैं; असलियत यह है कि modern web development में मूलभूत जटिलता मौजूद है
इसी तरह की “छिपी हुई” complexity ASP.NET या desktop GUI frameworks में भी दिखती है
उदाहरण के लिए, अगर Rails को API backend के रूप में इस्तेमाल किया जाए और frontend React संभाले, तो वह पारंपरिक Rails monolith से पूरी तरह अलग architecture बन जाता है
Vite, React, Prettier जैसे tools की सूची पूरी तरह अलग समस्याओं के लिए चुने गए विकल्प हैं (अगर frontend के लिए Rails इस्तेमाल करना है, तो बस Rails इस्तेमाल करें; मुझे बीच का रूप खास पसंद नहीं)
असली समस्या सीखने के तरीके में है
आजकल कई developers web की बुनियादी चीजें (HTML, CSS, server-side logic, database) सीखने से पहले framework सीखते हैं
हर tool के होने की अपनी वजह है, और ये सभी modern web के लिए ज़रूरी tools हैं
“बहुत ज़्यादा हैं” कहकर देखना industry की वास्तविकता को ठीक से न देखना है
complexity web development की मूलभूत चीज़ नहीं है
बल्कि अब हम कम चीज़ों से ज़्यादा काम कर सकते हैं
Hotwire लगभग vanilla Rails की तरह काम करता है, और WebSocket के ज़रिए real-time में content update होने वाला modern अनुभव एक ही लाइन में सेट किया जा सकता है
Rails में JS deploy करने का सामान्य तरीका भी import maps की वजह से बहुत आसान हो गया है (अलग build step की ज़रूरत नहीं)
Tailwind भी बहुत आसानी से जोड़ा जा सकता है
deployment भी kamal की वजह से काफी आसान हो गया है
इसलिए मैं इस बात से सहमत नहीं कि complexity कोई मूलभूत सच्चाई है, और Hotwire का काम complexity कम करना है
सीखने की दिशा “ज़्यादा सीखो” नहीं बल्कि “कम चीज़ों से ज़्यादा करो” होनी चाहिए
20 भाषाएँ या servers जानने से ज़्यादा असली कौशल यह है कि 4 चीज़ों से 3 लोगों की टीम के साथ 1000 लोगों से आगे निकल जाओ
लोगों को tools के अस्तित्व से समस्या नहीं है; शायद उन्हें इस माहौल से आपत्ति है कि सबको ये सब ज़रूर इस्तेमाल करना चाहिए
हर tutorial, हर YouTube video का शीर्षक “ज़रूर इस्तेमाल करें MONGOOSE stack!” जैसा होता है, इसलिए कई शुरुआती लोग baking blog में भी ज़बरदस्ती redis डालने लगते हैं
सच तो यह है कि ज़्यादातर sites बिना किसी खास stack के भी आराम से चल सकती हैं
लेकिन ऐसी बात का कोई प्रचार नहीं करता, इसलिए कई junior developers को यह पता ही नहीं होता
मैं मानता हूँ कि पहले fundamentals सीखने चाहिए, लेकिन कंपनियों के service प्रचार के बीच यह संदेश पहुँचाना आसान नहीं है
मैं Rails में तो काफी beginner हूँ, लेकिन दूसरी भाषाओं का लगभग 10 साल का अनुभव है
ज़रूरत पड़े तो tools जोड़ना ठीक है (वास्तव में ज़रूरत है या नहीं, वह अलग बात है)
लेकिन Rails मूल रूप से ORM से लेकर console और scaffolding code generation तक सब कुछ शामिल करने वाला एक बहुत बड़ा all-in-one framework है
अगर अतिरिक्त tools की ज़रूरत पड़ती है, तो क्या फिर Rails खुद पर दोबारा विचार नहीं करना चाहिए?
शायद कुछ ज़्यादा modular चीज़ बेहतर हो
“vanilla Rails” शब्द ही मुझे warning sign जैसा लगता है। इतना भारी framework भला vanilla कैसे हो सकता है?
इस लेख का सार यह है कि लोग शुरू से यह खुद नहीं सोचते कि उन्हें सच में “modern web application” चाहिए भी या नहीं, और उन्हें यह भी नहीं पता होता कि सिर्फ vanilla Rails भी पर्याप्त हो सकता है
vanilla Rails के default choices को खुद समझने की कोशिश कम है
“modern web development की complexity” का ज़िक्र सिर्फ समस्या-स्थिति का वर्णन है, कोई अनिवार्य शर्त नहीं
अगर आप सिर्फ database और कुछ SQL queries वाली site में npm packages के हज़ारों dependency घसीट रहे हैं, तो आप कुछ गलत कर रहे हैं
मैं 2007 से Rails code लिख रहा हूँ
stack के जटिल होने की अपनी वजहें हैं, और इस लेख के मानक के अनुसार “सही तरीके से” करने वाली टीम वास्तव में लगभग है ही नहीं
Omakase framework (Rails की तरह, जहाँ ज़्यादातर चीज़ें framework तय करता है) की समस्या सिर्फ शुरुआती choices नहीं, बल्कि बाद की choices को भी लगातार साथ लेकर चलना और पूरी टीम को उसी दिशा में खींचना है
Rails शक्तिशाली है, लेकिन maintainers भी भविष्य को पूरी तरह नहीं देख सकते
इसलिए आज लगभग कोई app सच में vanilla Rails पर वापस नहीं गया है
पहले Docker से पहले Rails deployment सच में बहुत झंझट भरा था। rsync या tarball के बजाय Capistrano जैसे deployment system की ज़रूरत पड़ती थी।
Docker या k8s भी सुविधाजनक हैं, लेकिन पुराने समय की तुलना में ये खास तौर पर बदतर नहीं हैं
अगर pre-Docker दौर के Rails deployment को आप “rsync करके tarball खोल देना” के रूप में याद करते हैं, तो वह सच में बहुत खराब setup था
“पुराने” Capistrano से deploy करना उससे कहीं बेहतर था
काश आप थोड़ा और बताते कि “rsync या tarball से कई instances पर push करना” खास तौर पर किस तरह समस्या था
सुनने में तो यह इतना गंभीर नहीं लगता
इसी वजह से मुझे हमेशा Sinatra से लगाव रहा है
अफ़सोस की बात है कि Rails जो out-of-the-box utilities देता है, उनका JS दुनिया में अभी भी ठीक से विकल्प नहीं है
ज़्यादातर JS developers इस बात को अच्छी तरह नहीं समझते
लेकिन JS हमेशा से wheel को फिर से बनाने वाला ecosystem रहा है
JS की सबसे बड़ी ताकत यह है कि हर किसी के पास नया platform बनाने का मौका होता है
कई JS platforms को एक साथ जोड़कर भी कुछ न कुछ चल ही जाता है; यह बहुत scalable, hackable है, और सब कुछ local पर स्थायी रूप से build करके fixed site बनाना भी संभव है
लेकिन इस आज़ादी के साथ संयम भी चाहिए
टीम की ज़िम्मेदारी होती है कि वह हर समय नया framework लाने को उतारू teammate को रोके
Ember.js, Rails खेमे के बड़े नामों द्वारा बनाया गया एक all-in-one framework (“batteries included”) है
फिर भी वह दूसरे frameworks जितना सफल नहीं हुआ; उसके पीछे कोई न कोई वजह है
JS ecosystem में भी AdonisJS जैसा backend framework है जिसमें सब कुछ शामिल है
लेकिन NodeJS ecosystem, Rails या Django जैसे opinionated frameworks के खिलाफ प्रतिक्रिया के रूप में microframeworks से शुरू हुआ था
Express का concept भी “जल्दी और जैसे-तैसे” बनाकर इस्तेमाल करना था
JS में भी Rails जैसे कई full-stack frameworks हैं
Sails नाम का framework भी है
JS, Rails की समस्या से अलग समस्याएँ हल कर रहा है, इसलिए frameworks का रूप अलग होना स्वाभाविक है
Rails में utilities तो बहुत हैं, लेकिन लंबी अवधि में codebase को नियमित रूप से update करना और Rails के trends के साथ चलते रहना थकाऊ हो सकता है
Stimulus और Hotwire अब “rails way” बन चुके हैं
documentation ध्यान से पढ़ने पर भी सब कुछ बहुत उलझाऊ लगता है
किसी न किसी तरह बार-बार हाथ से JS components फिर से बनाने जैसा महसूस होता रहता है
मुझे लगता है कि Rails 8 + Inertia.js + React का संयोजन उल्टा “wheel reinvention” कम करवाता है, खासकर अगर shadcn components इस्तेमाल करें तो
इस बात से सहमत हूँ
हमने भी Hotwire frontend को Inertia से बदला, और फर्क सच में बहुत बड़ा था
जब तक आप 100% अकेले छोटे project पर काम नहीं कर रहे, Hotwire बहुत जल्दी ऐसा गड़बड़झाला बन जाता है जिसे टीम में कोई ठीक से छू नहीं पाता
मुझे तो Stimulus इतना पसंद आया कि Rails से उठाकर सीधे Phoenix app में भी इस्तेमाल किया
लेकिन मुझे लगता है कि समस्या इस tool को लेकर गलतफ़हमी है
Stimulus, React का विकल्प नहीं है
अगर आप दसियों हज़ार लाइनों वाले JS app के आदी हैं, तो React आपके लिए सही हो सकता है
लेकिन अगर server-side मुख्य है और आप कुछ दर्जन लाइनों के JS से UX बेहतर करना चाहते हैं, तो Stimulus एकदम सही है
Phoenix में यह static HTML और dynamic LiveViews के बीच बहुत अच्छे से फिट होने वाला minimal solution है
किसी ने भी Stimulus से SPA बनाने को नहीं कहा, और अगर ऐसा करेंगे तो साफ़ है कि मुश्किलें आएँगी
Stimulus सच में बहुत छोटा है; यह HTML hooks वाला event system है जो Rails के request lifecycle के साथ अच्छी तरह मेल खाता है
मुझे जानना है कि क्या किसी ने Stimulus से सच में बहुत जटिल चीज़ सफलतापूर्वक बनाई है
मेरी भावना तो यही है कि उस स्तर तक ले जाना बहुत कठिन है
मैं खुद को Rails fanboy कह सकता हूँ, फिर भी Stimulus और Hotwire की मौजूदा स्थिति से निराश हूँ
concept शानदार है, implementation भी शायद अच्छा हो
लेकिन documentation इतनी भयानक रूप से कम है कि शुरुआत करने का मन ही नहीं होता, और किसी project में “अगर इसे अपनाया तो बाद में dead end में फँस तो नहीं जाएँगे” इसका जवाब देने लायक जानकारी भी नहीं मिलती
मैंने Stimulus को Symfony के साथ छोटे interactions के लिए इस्तेमाल किया है; इसका API छोटा और अच्छी तरह डिजाइन किया हुआ है, इसलिए काफ़ी अच्छा लगा
Turbo/Hotwire पूरा अभी तक इस्तेमाल नहीं किया, और जटिल या stateful pages के लिए मैं आम तौर पर Vue इस्तेमाल करता हूँ
वैसे भी अब greenfield projects (जो बिल्कुल शुरू से बनाए जाते हैं) लगभग गायब ही हो गए हैं
संस्थापकों को छोड़ दें तो greenfield बहुत कम हैं, और अगर कुछ बेचना हो तो लगभग 99% चीज़ें Shopify wrapper या उसी तरह की किसी चीज़ से निपटा दी जाती हैं
बड़ी कंपनियों में भी greenfield कई तरह की constraints और internal frameworks से बँधा होता है, इसलिए “rails new” से शुरू करने का मामला ही नहीं होता
ऐसी बहसों का खास मतलब नहीं है; पिछले 10, 15-20 सालों से ऐसी ही बहसें और लेख बार-बार दोहराए जा रहे हैं, और यह अब थकाऊ और उबाऊ लगने लगा है
नए लेख नहीं, कुछ नया बनाकर दिखाइए
पूरी तरह सहमत
मैंने Ruby/Rails में 10 साल काम किया है, और जो सबसे “नया” codebase मिला वह भी 5 साल से पुराना था
सच कहूँ तो मैंने नया greenfield Rails app बनाया है, लेकिन वह भी API-only microservice था, इसलिए frontend की ज़रूरत ही नहीं थी
कुछ आकार वाली कंपनियों में Rails frontend solutions को लगभग नज़रअंदाज़ किया जाता है
Hotwire जानने वाले engineers शायद न मिलें, लेकिन React या Vue developers बहुत मिल जाते हैं
Rails का FE stack भी बार-बार बदलता रहता है, इसलिए उसके साथ बने रहना मुश्किल है (जैसे CoffeeScript का दौर याद है), documentation भी ढंग की नहीं, और व्यावहारिक प्रभाव भी बहुत कम है
इसलिए ऐसी बहसें वास्तविक दुनिया से कटी हुई लगती हैं
मैं इस दावे से सहमत नहीं कि “greenfield projects अब संस्थापकों को छोड़कर कहीं नहीं बचे”
अगर उदाहरण सिर्फ पुराने enterprise monoliths या Fortune 500 तक सीमित हों, तो वह पूरे औसत का प्रतिनिधित्व नहीं करते बल्कि बहुत छोटा अपवाद हैं
उल्टा, मुझे “rails new” का sane और तुरंत उपयोगी defaults के साथ तैयार होना काफी प्रभावशाली लगता है
यह Hello World और बहुत ही साधारण API docs के बीच की खाई को अच्छी तरह भरता है
Rails ज़रूरी नहीं कि इस्तेमाल करें, लेकिन यह पहलू सीखने लायक है
सुनने में प्यारा लगता है, लेकिन यह उस वास्तविकता की बात नहीं करता जिसमें एक Rails app के बढ़ने के साथ bundler, webpacker, sprockets, Propshaft, importmaps, jsbundling वगैरह के बीच लगातार migrate करना पड़ता है
autoloader से zeitwerk, Turbo से Hotwire तक, व्यवहार में ऐसे बदलाव सच में बहुत हुए हैं
Rails newsletters के ads तक देखें तो “experts आपकी Rails app upgrade करने में मदद करेंगे” जैसी चीज़ें भरी पड़ी हैं
अच्छा लगा कि किसी ने यह बात उठाई
“बस vanilla Rails इस्तेमाल करो” कहना आसान है, लेकिन पिछले 5 सालों में Rails के लगभग हर version में JS management का तरीका पूरी तरह बदल गया है
अभी भी बहुत से gems sprockets पर निर्भर हैं, इसलिए Rails तरीके से चलें तब भी मजबूरी में JS की जटिल गुत्थी बन जाती है
अभी हालत सच में उलझी हुई है। शायद कभी बेहतर हो, लेकिन इसमें Rails की ज़िम्मेदारी भी साफ़ है
CoffeeScript को भी मत भूलिए
हाल तक जिस कंपनी में मैं काम करता था, वहाँ अब भी CoffeeScript port को टाला जा रहा था, और नया code Vue में लिखा जा रहा था
अगर किसी project में 30 से ज़्यादा developers अलग-अलग विशेषज्ञता के साथ एक साथ काम नहीं कर रहे, तो frontend/backend split से आने वाली complexity की सच में ज़रूरत नहीं होती — यह मैंने अपने अनुभव से सीखा है
freelance दिनों में मैंने 1-2 लोगों की टीम में भी बेवजह बहुत over-engineering की, लेकिन अब मैं बस Django के ऊपर थोड़ा Tailwind लगाकर काम करता हूँ
हमने इस साल Django developers की hiring की, और लगभग हर applicant Django से सिर्फ एक thin API backend बनाता था, जबकि frontend React में बड़ा बनाया जाता था (कई बार business logic भी frontend में ठूँस दी जाती थी)
वजह पूछने पर लगभग कोई ठीक से समझा नहीं पाया
आखिरकार हम सिर्फ उन्हीं कुछ applicants तक सीमित रह गए जो server-side rendering का उपयोग करते थे
अगर सच में बहुत interactive frontend चाहिए, तो तब अलग से सोचना पड़ सकता है
मैं भी सहमत हूँ
ज़्यादातर industry में ग्राहक के नज़रिए से किसी को इससे फर्क नहीं पड़ता कि ultra scalability और microservices चाहिए या साधारण monolith और PostgreSQL ही काफी हैं
लगता है कई लोग सिर्फ नई तकनीक के पीछे भागते हुए अनंत scalability को लक्ष्य मानकर setup करते हैं
असल में Rails साधारण design के साथ भी बहुत उपयोगी है, और लोग “boring” या “fun नहीं” लगने की वजह से over-engineering कर बैठते हैं
लेकिन Rails सच में batteries-included है, और अगर over-engineering बंद कर दें तो यह बस अच्छे से काम करता है
एक समय पर आकर productivity सबसे महत्वपूर्ण मूल्य लगने लगती है
आज चीज़ें ज़्यादा जटिल हो गई हैं, लेकिन यह विचार नया नहीं है
15 साल पहले जब Django सीख रहा था, तब tutorial में Vagrant, VirtualBox, Chef के खास versions install करने को कहा जाता था और मैं लगभग पागल हो गया था
आज भी मुझे Django पसंद है और मैं उसका उपयोग करता हूँ, लेकिन उन tools की मुझे कोई ज़रूरत नहीं लगती
Django Rest Framework तो उल्टा ध्यान भटकाने वाली चीज़ लगी
“web development tooling fatigue” बिल्कुल वास्तविक है
10 साल पहले भी यह वास्तविक था, और इस तरह की गड़बड़ी अक्सर इसलिए पैदा होती है क्योंकि developers अपने hobby-like पसंद-नापसंद को काम पर ले आते हैं
और जोड़ दूँ कि सिर्फ frontend ही नहीं, DevOps की दुनिया में भी हाल कुछ ऐसा ही है
नतीजा यह होता है कि उस क्षेत्र में नौकरी के लिए आपको हर tool आना चाहिए, ऊपर से 10 साल का अनुभव, कई backend, SQL, Docker — सब कुछ माँगा जाता है
अगर आप इसे पेशेवर रूप से करते हैं तो एक बार setup करके काम चल जाता है, लेकिन one-off project हो या web development आपका मुख्य काम न हो, तो यह थकाऊ लगना बिल्कुल स्वाभाविक है
फिर भी इससे बचा जा सकता है
मैंने Fresh(https://fresh.deno.dev/) framework से एक website बनाई थी, और वह अकेला ही काफ़ी था
आम तौर पर Node/Webpack संयोजन की तुलना में यह बहुत सरल था, और Typescript तथा TSX तक इस्तेमाल किए जा सकते थे
अगर कई लोग साथ काम कर रहे होते तो शायद ESLint जैसी चीज़ जोड़ता, लेकिन उसके बिना भी शुरुआत करना बेहद आसान था