क्या AI फ्रंटएंड के खोए हुए 10 साल को दोहरा रहा है?

 (mastrojs.github.io)
1 पॉइंट द्वारा GN⁺ 6 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • डेस्किलिंग कुशल श्रम को कम-कौशल तकनीकी संचालन से बदलकर लागत और प्रवेश बाधा कम करती है, लेकिन श्रमिकों की मोलभाव क्षमता भी कमजोर करती है
  • पिछले 10 वर्षों में फ्रंटएंड में frameworks और tools ने browser, accessibility और performance संबंधी ज्ञान को ढक दिया, जिससे front of the frontend विशेषज्ञता पीछे चली गई
  • एजेंटिक AI coding को और ऊंचे abstraction स्तर पर ले जाता है, लेकिन यह non-deterministic है और छोटे input या model बदलावों पर भी नतीजे बहुत बदल सकते हैं, यानी यह एक leaky abstraction है
  • LLM, Stack Overflow copy-paste का ही विस्तार है: skilled लोग तेज़ हो जाते हैं और beginners भी कुछ काम करने वाला बना लेते हैं, लेकिन किसी न किसी को output समझकर ठीक करना ही पड़ता है
  • AI अधिक AI slop और cost cutting ला सकता है, लेकिन quality, users और trade-offs को समझने वाले लोगों की ज़रूरत खत्म नहीं होती

डेस्किलिंग के नज़रिये से फ्रंटएंड और AI coding

  • डेस्किलिंग (deskilling) वह प्रक्रिया है जिसमें skilled labor को ऐसी तकनीक से बदला जाता है जिसे semi-skilled या unskilled worker भी चला सके; इससे लागत घटती है और entry barrier कम होती है, लेकिन workers की bargaining power भी कमजोर होती है
  • पिछले 10 वर्षों में frontend development ने JavaScript frameworks और tools के ज़रिये डेस्किलिंग झेली है, और अब programming के व्यापक क्षेत्र में एजेंटिक AI वैसा ही बदलाव ला रहा है
  • Frontend’s Lost Decade जैसी अभिव्यक्ति बताती है कि browser और user environment को गहराई से समझने वाली frontend विशेषज्ञता को framework-केंद्रित development ने पीछे धकेल दिया

फ्रंटएंड से गायब हुई विशेषज्ञता

  • पहले frontend development में semantic HTML, CSS, browser differences, accessibility, progressive enhancement, network performance, interface design और user testing जैसी विशेषज्ञ जानकारी चाहिए होती थी
  • कुछ practitioners इन क्षेत्रों को आज के “frontend” से अलग बताने के लिए front of the frontend कहते हैं
  • frontend का deskilling frameworks और tools के आने से हुआ, जो browser को JVM या iOS जैसे app runtime की तरह सिर्फ एक compilation target मानते हैं
  • Shadcn radio button जैसे component को उठा लेने पर underlying HTML, browser-specific nuances, page loading performance या accessibility को गहराई से समझे बिना भी feature बनाया जा सकता है
  • कंपनियां सामान्य programmers को आसानी से frontend काम में लगाकर लागत घटा सकती हैं
  • “full-stack developer” का मतलब अब अक्सर ऐसा व्यक्ति नहीं होता जो frontend और backend दोनों को गहराई से समझता हो, बल्कि ऐसा generalist developer होता है जो JavaScript framework से दोनों तरफ का काम कर सके
  • उसी developer को कई projects के बीच आसानी से switch किया जा सकता है, और React Native व Electron से native apps तक का काम दिया जा सकता है
  • entry barrier घटने के फायदे के साथ workers की bargaining power भी कमज़ोर होती है

AI coding: ऊंचा abstraction, लेकिन leaky abstraction भी

  • programming में अभी जो बदलाव हो रहे हैं, वे web developers के पहले झेले बदलावों जैसे ही लगते हैं
  • दिशा यह है कि हाथ से code लिखने वाले skilled काम को ऐसी तकनीक से बदला जाए जिसे semi-skilled या unskilled workers संभाल सकें
  • एजेंटिक AI के साथ काम करने वाले workers को आखिर किन skills की ज़रूरत होगी, labor pricing और local/remote LLM cost कहाँ जाकर टिकेगी, यह अभी साफ नहीं है
  • लेकिन यह साफ दिखता है कि कंपनियां इस तकनीक का इस्तेमाल cost cutting और workers की bargaining power घटाने के लिए कर सकती हैं
  • वर्षों से तराशी गई skill की market value घटना कुछ वैसा ही है जैसा artisans और craftspeople की जगह assembly-line workers ने ली थी
  • deskilling को automation से efficiency बढ़ाने, यानी और ऊंचे abstraction level पर काम करने वाली प्रक्रिया के रूप में भी देखा जा सकता है
  • नई तकनीक details छिपाती है और operators को बड़ी तस्वीर पर ध्यान देने देती है, लेकिन कौन-सी details “महत्वहीन” मानी जाएँ, यह बहुत अहम फैसला है
  • abstraction की details आखिरकार किसी न किसी दिन बाहर आ ही जाती हैं

  • “modern” frontend की leaking abstraction

    • abstraction अक्सर performance cost के साथ आती है; developer productivity के बदले runtime performance का कुछ हिस्सा छोड़ना, तेज़ servers और सामान्य load पर उचित समझौता हो सकता है
    • लेकिन धीमे network पर चलने वाले mobile phones में वही trade-off बिल्कुल अलग समस्या बन जाता है
    • React जैसे भारी client-side JavaScript frameworks और ecosystem packages का अधिक इस्तेमाल accessibility और कमज़ोर phones व धीमे networks पर performance को abstraction के पीछे छिपा देता है
    • नतीजा यह होता है कि लोग उन समस्याओं के बारे में सोचते ही नहीं, और बेपरवाह choices कर बैठते हैं

  • एजेंटिक coding की non-determinism

    • एजेंटिक AI से feature बनाते या bug fix करते समय, हर code line खुद लिखने के बजाय कम शब्दों में high-level बदलाव बताए जाते हैं
    • AI training data और आसपास के context को देखकर छूटी हुई details भरता है; कभी सही अनुमान लगाता है, कभी असफल होता है
    • यह तरीका उपयोगी है या नहीं, यह बहुत हद तक इस पर निर्भर करता है कि coding में आप क्या महत्वपूर्ण मानते हैं
    • एजेंटिक coding compiler की तरह deterministic नहीं है; input या model में छोटे बदलाव भी बिल्कुल अलग परिणाम दे सकते हैं, इसलिए यह पारंपरिक programming abstractions से कहीं ज़्यादा leak करती है
    • AI की तुलना “junior engineer” से इसलिए की जाती है क्योंकि इसमें non-determinism है, लेकिन फर्क यह है कि इंसान AGENTS.md या SKILL.md files को अंतहीन tweak किए बिना भी सीख सकता है

LLM, Stack Overflow copy-paste का विस्तार है

  • LLM उपयोग की सबसे नज़दीकी तुलना पुराने Google search इस्तेमाल से की जा सकती है
  • सही forum post या Stack Overflow answer को search result के पहले page पर लाने के लिए सटीक keywords चुनना भी developers को सीखना पड़ता था
  • LLM prompting भी training data के सही संयोजन को वापस लाने की प्रक्रिया है, और यह fuzzy web search की तरह बहुत high-dimensional space में retrieval के अधिक करीब है
  • search results wording के छोटे बदलावों और Google search index में बदलावों के प्रति संवेदनशील थे, और LLM भी input phrasing तथा model बदलावों के प्रति संवेदनशील हैं
  • हाल में Google ने search को input terms के अधिक normalization की दिशा में बदला है; इससे Google-fu से अनजान लोगों के लिए search आसान हुई, लेकिन skilled users के लिए वह कम शक्तिशाली भी बनी
  • Google और Stack Overflow ने programming को हमेशा के लिए बदल दिया; manuals पढ़ने के बजाय answers copy-paste करके भी चौंकाने वाली आवृत्ति से कुछ हद तक काम करने वाला परिणाम मिल जाता था
  • LLM उसी प्रवाह का विस्तार है
    • यह जानने वालों को थोड़ा और तेज़ बनाता है कि वे क्या कर रहे हैं
    • और जो लोग ठीक से नहीं जानते, उन्हें भी कुछ हद तक काम करने वाली चीज़ बनाने देता है
  • abstraction किसी दिन leak करती ही है, और तब किसी को गहराई से समझना पड़ता है कि वास्तव में हो क्या रहा है, ताकि उसे ठीक किया जा सके
  • जैसे junior developers को Stack Overflow answer इस्तेमाल करने से पहले उसे पढ़कर समझना सिखाया जाता था, वैसे ही अब LLM output को पढ़ना, समझना और existing codebase में उसकी जगह समझना सिखाना होगा

quality और business के बीच की दूरी

  • कुछ programmers कभी Stack Overflow answers को सच में समझने के स्तर तक पहुँचे ही नहीं; result काम करे, बस वही काफी मान लिया गया
  • कई कंपनियां भी, भले सार्वजनिक रूप से न मानें, इस approach से संतुष्ट थीं
  • अब हालत यह है कि कंपनियां output को देखना तक ज़रूरी न समझते हुए भी खुलकर बताती हैं कि वे AI कितना इस्तेमाल कर रही हैं
  • LLM के valid use cases निश्चित रूप से हैं, लेकिन code खराब करने और संगठन की communication व process बिगाड़ने के नए तरीके भी बहुत हैं
  • code review की तरह ही, workflow में LLM को कैसे इस्तेमाल और integrate किया जाए, इस पर मतभेद बड़े हैं; अगर team के values मेल न खाएँ तो काम का flow बुरी तरह बिगड़ सकता है
  • कई कंपनियां खराब software बनाते हुए भी ठीक-ठाक चलती रहती हैं
  • programmers जो मानना चाहते हैं उसके विपरीत, business success और software quality का संबंध बहुत कम ही होता है
  • आम तौर पर brand, pricing जैसी चीज़ें अधिक प्रभाव डालती हैं, और software projects को अक्सर success/failure की लगभग समान संभावना वाले black box की तरह treat किया जाता है
  • frontend में भी slow websites और बहुत सारे cookie banners conversion को नुकसान पहुँचा सकते हैं, लेकिन उनका असर brand loyalty या pricing जैसे factors से कम होता है, और competitors की websites भी अक्सर धीमी होती हैं
  • “React चुनने पर किसी की नौकरी नहीं गई” जैसी मानसिकता में quality से ज़्यादा safe choices को तरजीह दी जाती है
  • इसका मतलब यह नहीं कि users और craftsmanship की परवाह करना छोड़ देना चाहिए, लेकिन ऐसे workplaces ढूँढना मुश्किल होता जा रहा है जहाँ यह संभव हो
  • hype कम होने और LLM किन कामों के लिए वास्तव में उपयुक्त हैं और किनके लिए नहीं, यह समझ बनने पर कुछ संतुलन लौट सकता है, लेकिन पेशा पहले जैसा नहीं रहेगा

औद्योगिकीकरण के बाद भी बची रहने वाली skills

  • जब रोज़मर्रा की चीज़ें और इमारतें industrial process से mass-produce होने लगीं, तब एक प्रतिक्रिया यह थी कि factories में ऐसी चीज़ें बनाई जाएँ जो पुराने styles की नकल कर handcrafted जैसी लगें
  • इस historicism के जवाब में, 20वीं सदी की शुरुआत में Bauhaus ने factory worker और artisan को विरोधी मानने के बजाय, दोनों को साथ काम करने और industrial manufacturing को आधार मानकर art व craft को फिर से विकसित करने का रास्ता बनाया
  • Bauhaus का आग्रह था कि designer workshop में लौटकर materials को सीधे समझे, लेकिन अंतिम लक्ष्य mass-producible design हो
  • software craft के करीब है क्योंकि लिखा गया program किसी manufacturing stage से गुज़रे बिना “जैसा है” वैसा ही user तक पहुँचता है; लेकिन यह industrial design जैसा भी है क्योंकि वही चीज़ हज़ारों users तक deploy की जाती है
  • हाथ से code लिखने की क्षमता अब भी ज़रूरी है, और जैसे industrial designer को product materials जानने चाहिए, वैसे ही web designer को HTML और CSS में बहुत सहज होना चाहिए
  • Google, Stack Overflow, ready-made libraries, और LLM beginners के लिए शुरुआत आसान बनाते हैं, लेकिन वे किसी चीज़ को बस किसी तरह चलाने वाली प्राकृतिक बाधाओं को भी लगातार कम करते हैं
  • industrialization ने बहुत से सस्ते plastic products बनाए जिनमें उपयोग और user का पर्याप्त विचार नहीं था, लेकिन अच्छा industrial design आज भी मौजूद है
  • word processors ने बुरी formatting वाले दस्तावेज़ बहुत बनाए, लेकिन typography और graphic design फिर भी खत्म नहीं हुए
  • Wix और Next.js ने बहुत सी धीमी और कम-accessible websites बनाना आसान किया, लेकिन front of the frontend practitioners अब भी मौजूद हैं
  • AI बहुत सारा AI slop संभव बनाता है, लेकिन इसका मतलब यह नहीं कि अपने काम को समझने और उसकी परवाह करने वाले लोगों की ज़रूरत खत्म हो गई

आगे के बदलाव और trade-offs

  • दूसरे industries की तरह, काम को सही तरीके से करने वाले हिस्से का अनुपात कुल परिदृश्य में और छोटा हो सकता है
  • साथ ही, चीज़ें अधिक आसान और सस्ती बनने से कुल pie लगातार बड़ी होती जाएगी
  • अच्छे काम के बदले पारिश्रमिक पाने वाले लोगों की absolute संख्या बढ़ेगी या घटेगी, यह अभी कहना मुश्किल है
  • कभी-कभी तेज़ prototype या MVP निकालना ही सही फैसला होता है
  • अगर product-market fit अभी नहीं मिला है, तो हर चीज़ को future-proof बनाने से ज़्यादा तेज़ iteration और learning महत्वपूर्ण हो सकती है
  • लेकिन यह पता होना चाहिए कि आप क्या सीखना चाहते हैं, और उस learning को validate कैसे करेंगे
  • सही समय आने पर आमतौर पर एक कदम पीछे हटकर शुरुआत से सही तरीके से करना बेहतर होता है
  • उदाहरण के लिए, खराब architecture वाले frontend में बाद में अच्छी performance हासिल करना बहुत कठिन होता है
  • सरल stack से शुरू करके बाद में features जोड़ना, इसका उल्टा करने से आसान होता है
  • Mastro अच्छी performance और simple stack से शुरुआत को स्पष्ट रूप से प्रोत्साहित करता है
  • चाहे आप services खरीदें, open source libraries इस्तेमाल करें, LLM-generated code लें या खुद लिखें, system के हर हिस्से में कौन-से trade-offs हो रहे हैं, यह समझना ज़रूरी है
  • hype उतरने के बाद industry यह समझेगी कि AI बस toolkit का एक और tool है
  • तब तक, AI के नाम पर बदसूरत code, टूटी हुई communication और भयावह layoffs सामने आते रह सकते हैं

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 6 시간 전
Hacker News की राय

  • OP जिस गहरी विशेषज्ञता को मिस कर रहा है, वह दरअसल बहुत से लोगों के लिए काफ़ी असुविधाजनक चीज़ थी
    अलग-अलग browser की quirks, accessible components को खुद implement करना, CSS specificity की महारत से रोज़ी कमाना—यह सब समझ में आता है, लेकिन ज़्यादातर मामलों में यह आकस्मिक जटिलता के ज़्यादा करीब है। ज़्यादा लोगों का कुछ बना पाना साफ़ तौर पर अच्छी बात है, और अगर उसके कुछ नतीजे थोड़े धीमे हों या accessibility कमज़ोर हो, तो वह एक चुना जा सकने वाला trade-off है
    यह कहा जा सकता है कि abstraction ऐसे नतीजे थोपती है जिन्हें users ने चुना नहीं, लेकिन मुझे यह भी लगता है कि LLM शायद accessibility conventions को मुझसे बेहतर समझता हो

    • accessibility, intuitiveness, compatibility, responsiveness, scalability, architecture, performance जैसे UX/software development के कम दिखने वाले पहलुओं को सही तरह संभालना हमेशा मुश्किल रहा है
      लेकिन ultra-high-level frameworks और अब LLM ने इन हिस्सों को बिगाड़ते हुए भी आधा-पका MVP जल्दी निकालना आसान बना दिया है, और इस वजह से “चल जाएगा” और “वाकई अच्छा” के बीच का फ़ासला और बढ़ रहा है। जो लोग “अच्छा” बनाने की कोशिश करते हैं, उनके लिए “चल जाएगा” को धक्का देने वालों से प्रतिस्पर्धा करना लगातार कठिन होता जा रहा है
      नतीजतन ज़्यादा overtime, software quality में गिरावट, और शायद कुल मिलाकर job satisfaction में कमी आती है। आजकल हाल यह है कि बुनियादी functionality वापस लाने के लिए developers को dev tools और uBlock से टूटी हुई websites को ठीक करना या distractions हटाना पड़ता है, और मैंने यहाँ भी लोगों को यही करते देखा है(https://news.ycombinator.com/item?id=47042747)। पहले Flash या शुरुआती browser दौर में भी इस तरह खुद हाथ नहीं लगाना पड़ता था
      एक कम anecdotal उदाहरण भी है: https://news.ycombinator.com/item?id=47390945
      इससे भी बुरी बात यह है कि इन कटौतियों से बचाया गया ज़्यादातर पैसा केवल संगठन के सबसे ऊपरी स्तर तक ही पहुँचता है
    • AI बार-बार यह गलती करती है कि animated object को blur object के पीछे रख देती है, जिससे browser लगातार repaint करता रहता है
      Google के AI mode में भी ऐसा था, और दूसरी websites में भी साफ़ लगता है कि vibe coding से ऐसी ही चीज़ें डाली गई हैं
      शुरुआत में मुझे समझ नहीं आया कि GPU usage अचानक क्यों बढ़ रहा है और fan इतनी तेज़ क्यों चल रही है, लेकिन अब दिख रहा है कि यह AI की आम गलतियों में से एक है और कोई ठीक से test नहीं करता। इंसान भी यह गलती कर सकते हैं, लेकिन अब तक अपनी पूरी ज़िंदगी में मैंने यह लगभग कभी नहीं देखा था
      मैं 240Hz monitor इस्तेमाल करता हूँ, तो browser प्रति सेकंड 240 बार repaint करने की कोशिश कर रहा था, और uBlock Origin से block करना ही एकमात्र रास्ता था। यह बेतुका है
    • “हम अपनी craftsmanship खो रहे हैं” तरह की पोस्टों की संरचना हमेशा एक जैसी निराशाजनक होती है
      और भी बुरी बात यह है कि बीच में पहुँचकर वे खुद अपनी दलील काटने लगती हैं
      उदाहरण के लिए, अगर आप कहते हैं कि “कौन-सी details महत्वपूर्ण हैं यह तय करना बहुत अहम, कभी-कभी subjective फ़ैसला है, और आख़िरकार details हमेशा बाहर आ ही जाती हैं,” तो इसका मतलब यही हुआ कि यह नई technology भी आख़िरकार गहरी तकनीकी समझ को पुरस्कृत करेगी। क्योंकि इससे बचा नहीं जा सकता। इस हिस्से से मैं सहमत हूँ। लेकिन फिर कुल tone यह क्यों है कि “AI मेरी skills को सस्ता commodity बना रही है”?
      websites तकनीकी रूप से 10 साल पहले की तुलना में आम तौर पर बेहतर हुई हैं। इनमें ज़्यादा features हैं, ये तेज़ हैं, और SSL/accessibility/responsive design अब ज़्यादा मज़बूत default बन चुके हैं। content farms, SEO, news sites की समस्या ads और corporate incentives से पैदा हुई एक अलग तरह की भयानक विफलता है, यह React की गलती नहीं है
    • “LLM accessibility conventions को मुझसे बेहतर समझेगा” — यह असल में इसलिए है क्योंकि दूसरे लोगों ने उन्हें समझकर लिख दिया है
      LLM कभी-कभी उसका फ़ायदा उठा सकता है। लेकिन अगर लोग लिखना ही बंद कर दें, तो उसके बाद क्या होगा?
      मैं इससे सहमत हूँ कि ज़्यादा लोगों का कुछ बनाना अच्छी बात है। बाकी सब बराबर हो तो जितने ज़्यादा लोग, उतना बेहतर। अगर “AI” हर जगह इसलिए फैल रही होती क्योंकि उसमें कोई निर्विवाद सुधार था, तो स्थिति और भावना दोनों बहुत अलग होतीं
      फिर भी लोगों को अपने काम से “generate” किए गए ज्ञान पर अपने-आप कोई स्वाभाविक अधिकार नहीं मिल जाता। अगर attribution और compensation को गंभीरता से लिया जाए, और training सिर्फ़ उसी material पर हो जिसके लिए सामग्री बनाने वालों को भुगतान किया गया हो, तो शायद बस CSS सीख लेना ही कहीं ज़्यादा तेज़ और सस्ता पड़े
    • गहरी विशेषज्ञता को नज़रअंदाज़ करके hacks और lazy abstractions पर खड़ी की गई convenience, मेरी नज़र में modern multi-MB frameworks और Electron तक पहुँचने वाली एक प्रतिगमन है
      बेशक किसी को users के computer/memory usage, खराब हुए अनुभव, बर्बाद bandwidth, 8 अरब लोगों पर पड़ने वाली अतिरिक्त energy cost और environmental impact की परवाह नहीं है
      क्या ज़्यादा लोगों का public infrastructure बनाना भी “साफ़ तौर पर अच्छी बात” है? अगर उसका नतीजा और खराब सड़कें, और खराब पुल, और fail होते systems हों तो? software भी ऐसा ही है, और सच कहें तो ज़्यादातर चीज़ें भी

  • जिस “frontend तकनीक” के बारे में कहा गया कि यह relevance खो रही है, उसका बड़ा हिस्सा दरअसल सहज न लगने वाले exceptions, browser incompatibility, historical baggage, और exceptions के भी exceptions के minefield से रास्ता निकालना था
    आधुनिक frontend, यानी “leaky abstractions का tower”, आखिरकार web development के लिए एक commonsense mental model के काफ़ी करीब है। यह web standards और conventions जैसी अजीब विस्फोटक नींव के ऊपर ज़बरदस्ती चढ़ाया गया ढांचा है, फिर भी यह काम करता है और बस थोड़ा-बहुत leak करता है — यह अपने-आप में एक उपलब्धि है

    • “web development के लिए commonsense mental model” कहना ही विरोधाभासी है। या तो यह exceptions के minefield की दुनिया है, या फिर commonsense model — दोनों एक साथ नहीं हो सकते
      हम अब भी exceptions के minefield में ही हैं, और यह मानना मुश्किल है कि frontend बनाने वाली तकनीकें अब साफ़, पूर्वानुमेय, और historical baggage से मुक्त हो गई हैं
      हमने बस बुनियादी गलतियों और incompatibility के ऊपर प्लास्टर चढ़ाया है, उन्हें हल नहीं किया। React इस बात को हल नहीं करता कि HTML को UI toolbox के रूप में design नहीं किया गया था। Next.js इस बात को हल नहीं करता कि JavaScript design mistakes से भरी हुई है, जो उसे एक सुरक्षित और समझदार language बनने से रोकती हैं। Tailwind इस समस्या को हल नहीं करता कि CSS को styling के लिए design न किए गए markup को सजाने के लिए ad-hoc तरीके से लाया गया था
      अभी LLM बस इतना कर रहा है कि उसे प्लास्टर के नीचे छिपा डर statistics model के भीतर “पता” है। उस model को ऐसे दौर के examples पर train किया गया है, जहाँ 99% काम पिछले प्लास्टर की परतों की दरारें फिर से भरना ही था
    • मैं expert नहीं हूँ, लेकिन अगर आपने आम लोगों के सामने दिखने वाला frontend deploy किया है, तो frontend कुछ-कुछ The Wizard of Oz की yellow brick road जैसा है
      अगर आप छोटे और ठीक-ठाक best practices के दायरे से बाहर नहीं जाते, तो कुछ उबाऊ लेकिन परखे हुए libraries के साथ भी काफ़ी अच्छा experience दे सकते हैं
      लेकिन जैसे ही आप आज के trendy frontend framework से, या उससे भी बुरा, कल के trendy framework से उलझते हैं, या किसी दूसरे developer की किसी एक खास तरीके पर अड़ी हुई अजीब पसंद के साथ तालमेल बैठाना पड़ता है, या hope और duct tape से जोड़े गए “genius” hacks सँभालने लगते हैं, complexity और interaction के तरीके exponentially बढ़ जाते हैं
    • मूल लेख उस golden age के खोने का शोक मना रहा है जो कभी था ही नहीं
      मैं उस दौर से गुज़रा हूँ। IE6-only plain JavaScript को bug-ridden jQuery ने replace किया, फिर उसे unmaintainable Angular single-page apps ने, और उसके बाद monstrous React codebases ने
    • यह अज्ञान दिखाने वाली बात लगती है
      असल में इससे कहीं ज़्यादा है
      मैंने interview में बहुत से लोगों को “Next.js expert” बनकर आते देखा है, लेकिन वे उसके अलावा कुछ और नहीं कर पाते। वह skill नहीं, सिर्फ़ knowledge है, और आजकल वह मुफ़्त में हर जगह उपलब्ध है
    • यह समझने की क्षमता कि वह leaky abstraction किस tower में, किस floor पर, किस room में है, अब भी बहुत कीमती है और हो सकता है LLM उसे न देख पाए
      सिर्फ़ इसलिए कि किसी चीज़ को किसी committee ने शुरुआत से perfectly design नहीं किया, इसका मतलब यह नहीं कि आप सब कुछ भूलकर किताब बंद कर दें और मशीन को हिसाब लगाने दें
      मैं भी दूसरा वाला तरीका इस्तेमाल करता हूँ, इसलिए मुझे पता है कि उसमें क्या-क्या गलत होता है, लेकिन मैं इतना भी बहकता नहीं कि unmaintainable chaos बना दूँ। जब-जब agents पटरी से उतरते हैं, मेरी frontend skills सचमुच बहुत काम आती हैं

  • “frontend एक highly specialized skill थी, जिसमें semantic HTML, CSS, browser differences, accessibility, progressive enhancement, network performance, interface design, user testing आदि जानना पड़ता था” — यह बात पिछली पीढ़ी के frontend developers, यानी C/C++ developers, को काफ़ी मज़ेदार लगेगी
    web को entry barrier बहुत कम करने और skill को de-skill करने वाली चीज़ माना जाता था। Assembly programmers ने भी शायद C/C++ developers के बारे में कुछ ऐसा ही सोचा होगा

    • हर layer को लगता है कि वही सबसे important, सबसे specialized, और सबसे skilled layer है
      लेकिन हर layer ग़लत है। क्योंकि हर layer अपने नीचे की layer के abstractions पर बनी है। Physics और mathematics तक नीचे जाएँ, तो set theorists भी कुछ axioms मानकर चलते हैं। Logicians क्या करते हैं, यह किसी को नहीं पता
    • वह quote लेख से नहीं है, और लेख से उसका कोई संबंध भी नहीं है, तो पता नहीं यह सब क्या हो रहा है

  • “यह दुखद है कि नई process कम quality के results बना रही है, और लगता है बहुत से लोगों को फ़र्क नहीं पड़ता” — इस तरह की दलील शायद इस धारणा पर टिकी है कि AI से पहले यह ज़्यादातर काम skilled craftsmen quality के प्रति समर्पण के साथ करते थे
    जिसने industry में सचमुच काम किया है और ईमानदार है, वह जानता होगा कि हक़ीक़त ऐसी नहीं थी। औसत से नीचे बहुत कुछ था
    और “quality” को आप कैसे define करते हैं, इस पर भी यक़ीन से नहीं कहा जा सकता कि AI का output कम quality का है। AI असहज uniformity ला सकता है, लेकिन साथ ही, model ने जिन conventions पर training ली है, वे पसंद हों या न हों, ज़्यादातर end users के लिए “काम” करती हैं, इसलिए कई नतीजे काफ़ी उपयोगी भी होते हैं

    • यह “दीवार पर एक ईंट और रख देने” जैसा ज़्यादा है
      पहले भी बस requirements पूरी करने भर का minimum काम करके उसे success घोषित करने का बहुत दबाव था। अब लगता है वह दबाव असहनीय हो गया है
    • AI से पहले skilled craftsmen quality के लिए समर्पित थे — इस धारणा पर, कुछ लोगों ने अपने career में किस्मत से ऐसे दौर सचमुच देखे भी हैं
      लेकिन मैं इस बात से सहमत हूँ कि वह AI से पहले ही ग़ायब हो चुका था
    • quality का baseline डरावना रूप से नीचे लगता है
    • सही है। jQuery और Bootstrap से पहले का web बिखरा हुआ था और उसमें coding करना भी मज़ेदार नहीं था
      low quality की बात करें, तो वह तब और भी ज़्यादा सामान्य थी

  • हाल में मैंने भी कुछ ऐसा ही सोचा था
    मैंने कम-से-कम 10 साल से फ्रंटएंड डेवलपमेंट लगभग नहीं किया है, लेकिन मैं इतना पुराना ज़रूर हूँ कि मुझे वह दौर याद है जब 2000 के दशक के आखिर में अचानक सब लोग web GUI हाथ से बनाने के बजाय framework इस्तेमाल करने लगे थे, और जो लोग अब भी HTML/CSS/JS और database query हाथ से लिखते थे उनका मज़ाक उड़ाया जाता था। नौकरी के विज्ञापनों में भी अचानक PHP/HTML/CSS/SQL/JS की जगह Ruby on Rails, Django, Spring, GWT, और बाद में Angular जैसी तकनीकों की माँग होने लगी थी
    यह अजीब तरह से आज जैसा ही लगता है। बिना गहरी जानकारी के भी कुछ ही मिनटों में काम करने वाला web application बनाया जा सकता था, और वह जादू जैसा लगता था। फिर बाद में documentation को सरसरी तौर पर देखकर और search करते हुए framework के भीतर customization करते-करते एक बिंदु पर आकर आगे बढ़ना बंद हो जाता था। क्योंकि अंदर से यह कैसे काम करता है, इसकी बिल्कुल समझ नहीं होती थी। vibe coding webapp की तरह, दोपहर भर में जोड़-तोड़ कर बनाए गए standard framework webapp दूर से ही पहचाने जा सकते थे, लेकिन managers पर उनका बड़ा प्रभाव पड़ता था
    दिलचस्प बात यह है कि developers अपने मुख्य frontier model के बारे में लगभग उसी तरह बात करते हैं जैसे 15~20 साल पहले GUI developers अपने पसंदीदा web framework के बारे में बात करते थे। वे tools को मानवीय गुण दे देते हैं, यहाँ तक कि उनसे अपनी पहचान भी जोड़ लेते हैं, और फिर इस बात पर झुंझलाते हैं कि version X में जो काम होता था वह X.1 में खराब हो गया, और “अब मैं 10 गुना तेज़ develop करता हूँ”, “अब मैं फिर से XYZ हाथ से लिखूँगा” जैसी बातें बार-बार सुनाई देती हैं

    • दूसरी तरफ़, बाद में framework का इस्तेमाल standardization की दिशा में एक अच्छी कोशिश भी था
      ऐसा भी नहीं कि ऐसा खुद का बनाया GUI कोई फ़ायदा हो जिसे कोई और चला ही न सके
      व्यक्तिगत रूप से मुझे Nuxt/Next जैसी चीज़ें पसंद नहीं जो बहुत बड़ी “महसूस” होती हैं, लेकिन Vue पसंद है। हालांकि अभी मैं ज़्यादातर JavaScript हटाना चाहता हूँ, इसलिए server-side template के साथ HTMX या Alpine जैसी दिशा में जाना चाहता हूँ
      मेरी निजी राय में, जितनी कम technologies हों उतना बेहतर है। पहले एक दौर ऐसा भी था जब webapp में custom code की एक लाइन जोड़ने से पहले ही तरह-तरह की बेकार चीज़ें भरी होती थीं
    • 2000 के दशक की शुरुआत में भी web developers हर चीज़ हाथ से कोड करने से थक चुके थे, और framework या CMS जैसी automation ढूँढ रहे थे
      2004 में भी मैंने directory tree में txt फाइलें रखकर, और PHP से line break की जगह tag जोड़कर उन्हें HTML में डालने जैसे बुनियादी तरीके से साइट बनाई थी। उस समय विकल्प भारी-भरकम content management system थे
      काम की जगह पर lead developers द्वारा बनाए गए दो भयानक PHP framework झेलने के बाद मैं Django तक पहुँचा, इसलिए Django जैसा framework मेरे लिए ज़्यादा क्रमिक बदलाव था और कहीं ज़्यादा सुखद भी
      बेशक, अगर आप इसे और आगे धकेलकर object में version control जोड़ने जैसी दिशा में जाते, तो चीज़ें बहुत पेचीदा हो जातीं, काम करने की गारंटी भी नहीं रहती, और उन्हें ठीक करने का रास्ता भी नहीं बचता
      फिर भी, बुनियादी रवैया अभी जैसा ही लगता है

  • हम software industry में हैं। इस industry का मूल ही बहुत दोहराए जाने वाले कामों को automate करना है
    frontend projects बहुत दोहराव वाले होते हैं, और अब AI वह काम कर रहा है। यह शानदार बात है, और इससे कहीं ज़्यादा दिलचस्प चीज़ें बनाने के लिए बहुत समय खुल जाता है
    जो skill अब उतनी relevant नहीं रही उसका deskilling होना कंप्यूटर के आविष्कार के बाद से इस industry में लगातार होता आया है। क्योंकि समस्याएँ AI से या किसी और तरीके से हल कर दी जाती हैं
    आगे बढ़िए और नई skill सीखिए। सच तो यह है कि AI को प्रभावी ढंग से इस्तेमाल करना भी एक skill है, जिससे कुछ लोग अब भी जूझते हैं। चीज़ें अभी भी अपने-आप नहीं बन जातीं। सही prompt दें तो काम हो सकता है, लेकिन क्या आप सही तरह से prompt कर रहे हैं? क्या tool वही कर रहा है जो आपने माँगा? आपको यह कैसे पता? क्या आपने जाँच की? मैं खुद भी AI को prompt करने में बहुत समय लगाता हूँ, और मैं निश्चित ही बेहतर हो रहा हूँ, लेकिन यह अभी भी लगभग full-time job जैसा है
    लगभग 10 साल बाद हम शायद पीछे मुड़कर देखेंगे कि software बनाने का यह तरीका बहुत अक्षम था। tools बेहतर होंगे और AI अधिक autonomous हो जाएगा। अगर आप दिन भर वही prompts दोहराने में समय लगा रहे हैं, तो किसी न किसी को, या किसी चीज़ को, उसे भी automate करना होगा

    • software का उद्देश्य मानव इच्छा को ऐसी अवस्था में encode करना है जिसे मशीनें समझ और संप्रेषित कर सकें
      यहाँ शिकायत यह है कि यह automation ऐसी चीज़ encode कर देने का जोखिम रखती है जो आप चाहते ही नहीं थे
    • frontend को छोड़ने के बजाय, AI से बनी नई efficiency को frontend और backend दोनों को और आगे बढ़ाने के लिए resources मुक्त करने चाहिए
      दुनिया को जितना software हम अभी बना पा रहे हैं, उससे कहीं ज़्यादा की ज़रूरत है
    • “frontend projects बहुत दोहराव वाले होते हैं” — इसका मतलब आखिर है क्या, समझ नहीं आता
      यह इतना खराब नज़रिया है कि कहाँ से इसका विरोध शुरू करूँ, यही समझ नहीं आता। क्या हर UI में button होने भर से वह दोहराव वाला हो गया?
      अगर लोग सच में ऐसा मानते हैं, तो फिर समझ आता है कि UX 90 के दशक से क्यों बिगड़ा हुआ है, और बाद में क्यों और खराब हुआ
    • आपको यह जानकर हैरानी हो सकती है कि बनाने लायक “दिलचस्प चीज़ें” इतनी ज़्यादा हैं ही नहीं

  • AI coding product prototype बनाने में बहुत मददगार है, लेकिन साथ ही ऐसे products भी पैदा करती है जिन्हें दूर से देखकर ही समझ आ जाता है कि वे AI से बने हैं
    अभी-अभी भी एक startup ने अपना app demo किया, और उस app में साफ़ vibe coding UI वाली फील थी
    उन्हें जो feedback मिला वह ठंडा था, लेकिन बिल्कुल सटीक था। बात कुछ ऐसी थी: “ठीक-ठाक है, लेकिन यह बहुत साफ़ दिखता है कि इसे AI से बनाया गया है, और अगर ऐसा है तो जो दूसरा व्यक्ति इसे चाहेगा वह भी इसे AI से बहुत जल्दी बना सकता है, इसलिए आप जो बेच रहे हैं उसमें ज़्यादा value नहीं है”

    • काश ऐसा और ज़्यादा हो। LLM से बने UI भी, और उन्हें पर्याप्त मान लेने वाले लोग भी, दोनों ही बर्दाश्त से बाहर हैं
    • मज़ेदार बात यह है कि अगर बस एक बुनियादी design system और CSS सेट कर दी जाए, तो AI से बना frontend code काफ़ी स्वाभाविक रूप से फिट बैठता है
      लेकिन ज़्यादातर लोग इतनी बुनियादी परवाह भी नहीं करते
      गोल कोने अब भी कभी न ख़त्म होने वाला ट्रेंड हैं, और जो चीज़ पहले से ठीक से परिभाषित नहीं है, वह सब मानो उसी आकार से संक्रमित हो जाती है
    • यह किसी वास्तविक घटना से ज़्यादा दिमाग़ की कल्पना जैसा लगता है
      कोई सक्षम venture capitalist ऐसी निरर्थक feedback नहीं देगा। अगर चीज़ अच्छी है तो अच्छी है, इससे क्या फ़र्क पड़ता है कि उसे AI ने बनाया? क्या अगर वही गुणवत्ता वाला product vibe coding जैसा न दिखता तो वह ठीक था? यह तो सिर्फ़ वही लोग मुद्दा बनाएँगे जो वैचारिक रूप से AI के विरोधी हैं

  • कभी-कभी ऐसा लगता है कि 2000 के शुरुआती वर्षों में AJAX या DOM manipulation के बिना सिर्फ HTML से जटिल user interface बनाने की तकनीकें पिरामिड निर्माण तकनीकों की तरह लगभग गायब हो चुकी हैं
    युवा full-stack developers में एक तरह की “de-skilling” दिखती है, इसलिए कई लोग यह तक मानते हैं कि form validation करने के लिए JavaScript ज़रूरी है
    एक बार AJAX इस्तेमाल करना और DOM को manipulate करना शुरू कर दें, तो asynchronous communication की जटिलता लगभग अनिवार्य रूप से React जैसी किसी चीज़ के पैमाने तक पहुँच जाती है. document.title="A new title" जैसा लिख सकते हैं और कुछ import करने की भी ज़रूरत नहीं होती, फिर भी अगर frontend को सिर्फ “server से data आने पर UI update करना” मानें, तो जटिल applications में UI के कई हिस्से update करने पड़ते हैं, और किसी बिंदु पर आप communication या state management bus जैसी कोई चीज़ बना लेते हैं. क्या इसे किसी और तरह बनाया जा सकता था? बिल्कुल
    अगर React ecosystem में कोई समस्या है, तो वह यह नहीं कि वह abstractions के ऊपर abstractions बनाता है, बल्कि यह कि वह abstraction leak करता है. अगर आप बहुत साधारण चीज़ बना रहे हैं और उसकी appearance की ज़्यादा परवाह नहीं है, तो CSS समझे बिना भी Bootstrap या MUI इस्तेमाल कर सकते हैं. लेकिन ग्राहकों के सामने रखने लायक professional-grade काम करने के लिए HTML, CSS, JS और project में इस्तेमाल होने वाले हर framework को समझना पड़ता है

    • खासकर HN पर अक्सर लगता है कि React का नाम interactive web के प्रति व्यापक असंतोष के लिए चार-अक्षरी गाली की तरह इस्तेमाल होता है
      React की आलोचना करने वाले ज़्यादातर लोग वास्तव में यह नहीं समझते कि React किस समस्या का समाधान करता है. अगर आप उन्हें कोई पर्याप्त रूप से जटिल webapp का source code दिखाएँ जो React पर निर्भर नहीं है, तो वे उसके भीतर खुद बनाया हुआ React जैसा विकल्प ढूँढ सकते हैं

  • मैं इस बात से सहमत नहीं हूँ कि NextJS की server-side rendering, lazy loading वगैरह इस्तेमाल करने वाली frontend application चलाना, सिर्फ HTML, JS, CSS वाले दौर की तुलना में “आसान” है
    जटिलता का स्तर और user expectations पूरी तरह अलग जगह पर हैं
    ऊपर से skilled engineers की संख्या लगभग 1000 गुना बढ़ चुकी है, और अब वैश्विक बाज़ार से प्रतिस्पर्धा करनी पड़ती है. 2000 के शुरुआती वर्षों में प्रतिस्पर्धा लगभग नहीं थी. श्रमिकों की skills का बाज़ार की माँग से संबंध आम तौर पर ढीला-ढाला होता है, लेकिन अब स्थिति बेहद प्रतिस्पर्धी है