HTML First
(html-first.com)- ब्राउज़र की बिल्ट-इन नेटिव क्षमताओं को पहले इस्तेमाल करने से, वेब ऐप बनाते समय अतिरिक्त भाषाओं और toolchain पर निर्भरता कम की जा सकती है
- React ने
props,state, components जैसे patterns के ज़रिए UI development की विश्वसनीयता बढ़ाई, लेकिन development का केंद्र HTML से JavaScript की ओर शिफ्ट कर दिया - इसी दौरान W3C, WHATWG, IETF, TC39 ने वेब की मूल भाषाओं में हज़ारों सुधार जोड़े, और प्रमुख browsers ने इन्हें integrate किया, जिससे React की ज़रूरत के कुछ कारण कमज़ोर पड़ गए
- HTML First, React से संतुष्ट developers को मनाने के बजाय, HTML-केंद्रित approach में रुचि रखने वालों को अपने विचार स्पष्ट करने और साथियों से चर्चा करने की भाषा देने वाला एक रुझान है
- यह एक practical सवाल के करीब है: क्या वेब की मूल भाषाओं और browser features से ही तेज़ और accessible software बनाया जा सकता है
HTML First किस तरह के development की ओर इशारा करता है
- HTML First वेब software बनाते समय HTML, CSS, JavaScript और browser की नेटिव क्षमताओं को प्राथमिकता देता है
- इसका मूल विचार वेब platform के ऊपर जोड़ी जाने वाली abstraction layers को घटाना है
- अतिरिक्त languages और toolchain भी उन layers में शामिल हैं जिन्हें घटाया जाना चाहिए
- लक्ष्य यह है कि browser पहले से जो capabilities देता है, उन्हें केंद्र में रखा जाए और ज़रूरत पड़ने पर ही उनके ऊपर tools जोड़े जाएँ
React के बाद जटिल हुआ web development
- React से पहले interfaces को HTML में लिखना और जिन हिस्सों को HTML मूल रूप से support नहीं करता था, उन्हें jQuery जैसे tools से पूरा करना आम था
- प्रमुख उदाहरण asynchronous requests भेजना और DOM updates करना है
- React जैसी libraries ने पुराने web development की कई समस्याएँ हल कीं
- parent element से child element तक data को स्पष्ट रूप से pass करने वाले
propsऔरstatepatterns ने कुछ खास तरह के bugs घटाए - UI, style और behavior को components में बाँधकर, दूसरों द्वारा बनाई गई चीज़ों को अपने codebase में आसानी से install करना संभव बनाया
- parent element से child element तक data को स्पष्ट रूप से pass करने वाले
- ये फायदे पाने के लिए मुख्यतः HTML इस्तेमाल करने के तरीके से मुख्यतः JavaScript इस्तेमाल करने के तरीके में shift करना पड़ता था
- JavaScript को ज़्यादा जटिल भाषा माना जाता है
- React द्वारा पेश किए गए कई concepts और tools भी साथ में सीखने पड़ते थे
- complexity बढ़ने के बावजूद industry ने इस trade-off को स्वीकार किया, और ऐसी libraries वेब apps बनाने का default तरीका बन गईं
- React से पहले नए developers पहले HTML और CSS सीखते थे, फिर JavaScript सीखते थे
- React के बाद flow बदलकर पहले JavaScript और React सीखने, फिर बाकी चीज़ें सीखने का हो गया
web platform improvements से बना पुनर्विचार का बिंदु
- React approach के फैलने के दौरान W3C, WHATWG, IETF, TC39 ने web की native languages में हज़ारों improvements जोड़े
- ये improvements Chrome, Safari, Firefox, Edge में integrate हुए
- इनमें से कई ने उन कुछ कारणों को सीधे address किया जिनकी वजह से लोग React इस्तेमाल करते थे
- software development की लागत बढ़ने और browser improvements के व्यापक रूप से deploy होने के साथ, अधिक लोग पूछने लगे हैं कि जोड़ी गई layers आज भी सचमुच ज़रूरी हैं या नहीं
- HTML First का विचार अभी industry में अल्पसंख्यक है
- यह approach उन लोगों की मदद पर केंद्रित है जो पहले से HTML-केंद्रित development में रुचि रखते हैं, ताकि वे अपने विचारों को मजबूत कर सकें और साथियों से संवाद करने के लिए भाषा और concepts पा सकें
- मुख्य संदेश यह है कि web की native languages और capabilities का मुख्य रूप से इस्तेमाल करके भी सुंदर, तेज़, उपयोग में आसान और accessible web software बनाना संभव, practical और तर्कसंगत है
1 टिप्पणियां
Hacker News की टिप्पणियाँ
यहाँ का आइडिया पसंद है, लेकिन ईमानदारी से कहूँ तो उदाहरण काफ़ी कमज़ोर हैं
“जहाँ संभव हो, style और behavior को inline HTML attributes में define करो” वाले हिस्से का उदाहरण शायद वास्तव में काम नहीं करेगा, और अगर style और जोड़ने हों तो
ClassList.addमें दिए जाने वाले string parameter ही बस लंबे होते जाएँगेमुझे व्यक्तिगत रूप से
button:active { background: green; }कहीं ज़्यादा पढ़ने में आसान लगता है, लेकिन लेखक शायद “Locality of Behaviour” वाले approach की वजह से इसे जटिल मानता है“अगर library चाहिए, तो JavaScript या custom syntax-केंद्रित library की बजाय HTML attributes का उपयोग करने वाली library लो” इस बात से मैं सहमत हूँ, लेकिन सुझाया गया उदाहरण “on input put me into #output” उस library से भी ज़्यादा अटपटा लगता है जिसे बुरा उदाहरण बताया गया है, और यह तो framework के बिना सीधे JavaScript से भी आसानी से किया जा सकता है
“HTML में compile होने वाली hidden layer की बजाय ‘raw’ HTML को प्राथमिकता दो” के उदाहरण में Rails ERB tag helpers का उपयोग न करने को कहा गया है, लेकिन ये helpers उन कई चीज़ों को संभाल लेते हैं जो minimal template में सीधे लिखने पर काफ़ी गंदी हो जाती हैं। उदाहरण में unique DOM ID, Turbo tags, iteration जैसी वास्तविक बातों को छोड़ दिया गया है
style configuration और behavior अलग होने चाहिए, और सार्थक scale पर दोनों के बीच सिर्फ references के ज़रिए connection रखना ही समझदारी लगता है
तकनीकी रूप से आप एक Python app में सारे SQL database connections और hardcoded SQL को एक ही लंबी file में डाल सकते हैं, लेकिन जैसे वह बुरी आदत होगी, यह सिद्धांत भी वैसा ही लगता है
यह हिस्सा उलझाने वाला है: “अगर library चाहिए, तो JavaScript या custom syntax-केंद्रित library की बजाय HTML attributes का उपयोग करने वाली library लो”
लेकिन सुझाए गए उदाहरण के रूप में _hyperscript [0] दिखाया गया है। यह तो custom syntax-केंद्रित library है, जो बस HTML attribute के अंदर एक नई सीखने वाली language की script डालती है। समझ नहीं आता कि यह बात गंभीरता से कही गई है या नहीं
[0] https://hyperscript.org
उदाहरण भी काफ़ी कमज़ोर हैं। शुद्ध समाधान, यानी सिर्फ़ पहला tip, अपने आप में भी उतना ही अच्छा काम करता है
_नाम के attribute में किसी अजीब DSL statement को value की तरह डालने वाला उदाहरण सच में बहुत अजीब और भ्रमित करने वाला लगता हैइससे बेहतर है कि साफ़-साफ़
onclickया किसी दूसरे event attribute में plain JavaScript statement डाल दो, ताकि तुरंत पता चले कि क्या हो रहा हैमंशा समझ में आती है। HTML की built-in capabilities का उपयोग साफ़-सुथरा और सरल है
लेकिन यह 10 साल पहले भी व्यावहारिक नहीं था और अब भी नहीं है। htmx जैसी चीज़ें React जैसे भारी समाधान से कोई ख़ास बेहतर भी नहीं लगतीं
इस तरह के approach को देखते ही मेरा सवाल हमेशा वही रहता है: dropdown, multi-select, date picker कैसे दिखते हैं? क्या हर browser में date picker होता है? हाँ। क्या उसका look और behavior हर browser में consistent है? नहीं। क्या styling से उसे एक जैसा बनाया जा सकता है? वह भी नहीं
multi-select भी ऐसा ही है। कई items चुनने के लिए Shift/Ctrl click की ज़रूरत पड़ना user experience के लिहाज़ से बिल्कुल ठीक नहीं है। default element अभी भी ऐसे ही काम करता है और इसे बदला नहीं जा सकता। सिर्फ multi-select ही नहीं, सामान्य select element भी देखने में खराब लगते हैं और उन्हें बदलना आम तौर पर मुश्किल होता है
हर नए framework में ऐसे third-party components आने की वजह है। built-in elements काफ़ी नहीं हैं। वजह वही है जैसे MDN के Array page पर built-in features हर साल बढ़ते हैं, फिर भी मेरे 90% projects अब भी lodash पर निर्भर रहते हैं। 10 साल पहले से स्थिति बेहतर ज़रूर हुई है, लेकिन अभी भी कमी है
उपयोगकर्ता अलग-अलग browsers इस्तेमाल कर सकते हैं, लेकिन एक उपयोगकर्ता जिन भी websites पर जाता है, वहाँ अक्सर वही एक browser इस्तेमाल करता है
इसलिए मेरी राय में यह ज़्यादा महत्वपूर्ण है कि date picker एक ही browser के भीतर सभी websites में consistent हो, बजाय इसके कि एक website पर सभी browsers में बिल्कुल एक जैसा हो। हाँ, अगर custom functionality चाहिए तो बात अलग है
जब किसी list से लगातार 10 या 15 items चुनने हों, तो फिलहाल मुझे Shift+click से बेहतर UI नहीं सूझता
काश हर website अपने-अपने बेवकूफ़ाना styles दोबारा गढ़ने के बजाय, असली site design को छोड़कर browser के native look and feel का पालन करती। बेशक, browsers को भी उसे अच्छा दिखाने पर ध्यान देना चाहिए
inputelement browser के हिसाब से interaction में काफ़ी अंतर होने के कारण बदनाम है, जबकि अधिकांश दूसरे HTML elements का कोई एक प्रतिनिधि behavior तय होता हैज़्यादातर दावों से सहमत हूँ, लेकिन यह लेख थोड़ा विरोधाभासी लगता है। क्योंकि यह Tailwind की सिफारिश करता है और साथ ही “build step से बचो” भी कहता है
बहुत बड़े CSS/JS resources deploy करना समावेशन के सिद्धांत के भी खिलाफ है। बहुत से लोगों के पास तेज़ इंटरनेट या पर्याप्त ताकतवर कंप्यूटर नहीं होते
सच कहूँ तो Tailwind जो client-side JavaScript भेजता है उसके बारे में मुझे बिल्कुल पता नहीं है। मेरा आख़िरी अनुभव 2.x का था, इसलिए तब से कुछ बदला है या नहीं, यह पक्का नहीं कह सकता
CSS size के मामले में भी मेरा अनुभव उलटा था; Tailwind output आम तौर पर हाथ से लिखे CSS से काफ़ी छोटा था
बेशक मुझे pure CSS से भी कोई आपत्ति नहीं है, लेकिन उसे भी कम से कम उतनी ही आसानी से गड़बड़ बनाया जा सकता है
लेकिन जहाँ तक मुझे याद है, यह full Tailwind की सभी सुविधाएँ नहीं देता। कुल मिलाकर Fresh असल में Preact और Twind पर काफ़ी हद तक बना हुआ है, और यह बात कि पहले उन libraries को अपनाना पड़ता है, इसे खुलकर न बताना मुझे निराशाजनक लगा
इस लेख के संदर्भ में इसकी सिफारिश थोड़ी अजीब लगती है, इस बात से मैं कुछ हद तक सहमत हूँ, लेकिन build step को बेहद minimal बनाया जा सकता है और यह भी अच्छा है कि नतीजा फिर भी inspect किया जा सकने वाला CSS होता है
मैं अपनी personal site में Tailwind इस्तेमाल करता हूँ, और बाकी सब पूरी तरह pure HTML है। styles लिखते समय CLI को watch mode में चलाना मुझे ज़्यादा परेशान नहीं करता
दोनों हैरान करने वाली तेज़ हैं और 10,000 से ज़्यादा चीज़ें भी parse कर लेती हैं
सिद्धांत या साधारण उदाहरणों में यह मज़ेदार है, लेकिन मैं कोई बड़ा project देखना चाहूँगा जहाँ इसे लागू किया गया हो और यह कि इससे वास्तव में क्या फ़र्क पड़ा
लेख की शुरुआत में बताए गए लक्ष्य बेहतरीन हैं, लेकिन सलाह खुद थोड़ी निराशाजनक लगी। बहुत बुनियादी स्थितियों से आगे यह कैसे काम करेगा, यह साफ़ नहीं दिखता, और उन लक्ष्यों को यह कैसे हासिल करेगा, यह तो और भी कम
web platform का अधिकतम उपयोग करने के पक्ष में हूँ, और complexity को जितना हो सके कम रखने के पक्ष में भी पूरी तरह हूँ। लेकिन मुझे इस बात पर बहुत संदेह है कि ये सिद्धांत उससे यह हासिल कर पाएँगे; उलटे, यह एक ही काम के कई तरीके बनाकर complexity बढ़ा भी सकते हैं
अच्छे इरादे से कहूँ तो, सिर्फ़ इस सूची से यह पता नहीं चलता कि इन सिद्धांतों को वास्तव में परखा गया है या बस यह मान लिया गया है कि ये उम्मीद के मुताबिक काम करेंगे
मैं सच में पूछ रहा हूँ। लोग यह तर्क अक्सर लाते हैं, लेकिन मैं इसे कभी समझ नहीं पाया
मेरी नज़र में web का 95% हिस्सा छोटे से मध्यम आकार के projects का है। ज़्यादातर technologies को इन्हीं पर ध्यान देना चाहिए। simple projects के लिए simple solutions इस्तेमाल करो, और complexity बाद में जोड़ो
divसे बनाना चाहते थे और चाहते थे कि VueJS सारी logic और content को control करेजिन आधे-अधूरे objective नुकसानों का हमें सामना करना पड़ा, उनमें एक accessibility है। links को click event listener लगे
divके रूप में भोलेपन से फिर से बनाने की वजह से site के ज़्यादातर हिस्से में keyboard से navigate नहीं किया जा सकतायह काफ़ी चिंताजनक है। जब regulation आएगा, तब हम जो फेंक चुके हैं उसे वापस पाने के लिए हड़बड़ी में भागदौड़ करेंगे
फिर भी, मशहूर “HTML-first” sites के उदाहरण ढूँढना मुश्किल है, इस बात से मैं कुछ हद तक सहमत हूँ। मुझे इस पर भरोसा है, लेकिन मैंने इसे अच्छी तरह सामने आए हुए वास्तविक उदाहरणों में नहीं देखा। हालाँकि वजह सिर्फ़ education भी हो सकती है। जब तक HTML ताकतवर हुआ, तब तक frontend developer training पहले से ही framework-केंद्रित रूप में गहराई से जड़ जमा चुकी थी
ऐसा नहीं लगता कि लेखक ने सच में इसे ऐसे project में आज़माया है जिसमें दो से ज़्यादा लोग हों और जो मौजूदा browsers के 99% को support करता हो। और यह भी लगता है कि उन्होंने अपना ही code चलाकर नहीं देखा। हो सकता है मेरी स्क्रीन ही स्वादिष्ट न हो, लेकिन
onlickdivका handler नहीं हैअगर आप ऐसा product बनाते हैं जो देखने में काम करता लगता है लेकिन वास्तव में काम नहीं करता, तो वे इसे समझ नहीं पाते। फिर आप ज़रूरत से ज़्यादा वादा करने और कम deliver करने की राह पर धकेल दिए जाते हैं
unit test का एक कम चर्चित फ़ायदा यह है कि यह उस code को, जिसे management देख नहीं सकता, जुड़ने से पहले ज़्यादा quality assurance दिलाता है। यह first screen दिखने और release के बीच के अजीब अंतराल को कम करता है
मैंने 1999 में pure HTML, CSS, pure JS से अपनी पहली website बनाई थी और उसे Geocities पर host किया था
उसके बाद से मैं PHP/WordPress/Yii/Laravel, Ruby/Rails/Sinatra/Jekyll, React/Typescript, ClojureScript के साथ sites और apps बनाता रहा हूँ
अब React, TSX components, CSS-in-TS, Effects, Context मुझे एक आरामदेह घर जैसे लगते हैं। ऐसा लगता है कि आखिरकार web/frontend के लिए एक पूरी programming language मिल गई है। यह functional और reactive programming जैसे आधुनिक सिद्धांतों पर बनी हुई, frontend के लिए स्पष्ट रूप से तैयार की गई भाषा है
अब जाकर लगता है कि मैं वास्तव में software development कर सकता हूँ। उससे पहले का HTML, CSS, pure JS, PHP बस hacking के क़रीब था। Rails full-stack के लिए अच्छा था, लेकिन frontend में कभी चमका नहीं
जब web stack apps के लिए भी तैयार हो जाएगा, तब मैं frameworks को छोड़ दूँगा। अभी के लिए मानता हूँ कि यह शायद sites के लिए काफ़ी हो सकता है
इस साल मैंने हार मान ली। अब bundler, transpiler, और उनके साथ आने वाली हर तरह की फालतू चीज़ों वाले React, Vue, Angular राक्षसों से लगातार लड़ना नामुमकिन हो गया है
Node और npm तो कुछ सेकंड पहले ही बनाए गए नए प्रोजेक्ट पर भी यह फेंक देते हैं कि उसमें “7 गंभीर vulnerabilities और 8 critical vulnerabilities” हैं। हज़ारों फाइलें डाउनलोड करनी पड़ती हैं, और उनमें boolean value wrapper जैसी चीज़ें भी हो सकती हैं
वह दौर, जब Python backend server frontend भी साथ में serve करता था, शायद मेरे लिए खत्म हो चुका है
सच कहें तो आपको भी, और किसी और को भी, यह भारी-भरकम JavaScript frontend फुलाव वास्तव में ज़रूरी नहीं है। बस इसे मना कर दीजिए
backend या cache से हल्के पेज serve कीजिए, और अगर सच में ज़रूरत हो तो शानदार काम CSS से कर लीजिए
फिर आपको तेज rendering time और वैश्विक accessibility मिल सकती है
लेकिन ईमानदारी से कहूँ तो इस लेख के उदाहरण अजीब हैं। Phoenix form helper, जो error और कई convenience features अपने-आप दे देता है, उसे छोड़कर सीधे raw tags क्यों लिखने चाहिए, समझ नहीं आता। भावना समझ में आती है
लगता है कि मुख्य तर्क यह है कि यूज़र View Source दबाकर समझ सके कि क्या हो रहा है। अगर यह वेबसाइट है, तो मैं सहमत हूँ
वेबऐप में, कम-से-कम 50 लाइनों से बड़ा हो तो, आप शायद typed language इस्तेमाल करना चाहेंगे। तकनीकी रूप से special comments में type annotations और TypeScript compiler के साथ
.jsइस्तेमाल किया जा सकता है, लेकिन वह खास सुखद नहीं थापहले मैं इस विचार से काफ़ी मज़बूती से जुड़ा हुआ था, और यह दुखद है कि आजकल ज़्यादातर साइटें पढ़ी न जा सकने वाली एक-पंक्ति HTML के ढेर जैसी हैं। बिना dependency के एक ही HTML file में सब कुछ deploy करने में एक सुंदरता और elegance है। बस 1 network request चाहिए
आखिरकार आसान editing के लिए मैंने एक “build system” बना ही लिया, लेकिन मेरा build system
catहै। यानी यह एक ऐसी self-contained portable software बन जाती है जो एक human-readable file में समाई होती हैइसी तरह, web development की सबसे शानदार बातों में से एक यह है कि आप सिर्फ Notepad और default browser से अपना पहला interactive program बना सकते हैं। बस HTML file को browser में drag-and-drop कर दीजिए। यह जादू जैसा है
अतिरिक्त: self-contained HTML का एक अनपेक्षित फ़ायदा मिला। software bit rot से immune हो जाता है। मैंने पुराना project Web Archive में खोला तो बाहरी JS files archive नहीं हुई थीं। दुखद। लेकिन यह वाला ठीक से load हो गया क्योंकि सारा JS HTML के अंदर था। जीत
https://web.archive.org/web/20210508133239id_/https://andai....
यह पुराने SodaPlay Constructor को एक homage है। editor मैं नहीं बना पाया। source देखने के लिए स्वतंत्र हैं
DOM view, network tab, heap view, और built-in JavaScript pretty-printing feature मौजूद हैं
बेशक “View Source” अब भी महत्वपूर्ण है, लेकिन HTMX वाले लोग जैसा कहते हैं, क्या उसकी अहमियत अब भी उतनी absolute है, इस पर संदेह है
अब
data:URL है, इसलिए यह और भी आसान हो गया है।file://URL की उन समस्याओं से बचने में भी यह उपयोगी है जिनमें HTTP server तक की ज़रूरत नहीं पड़तीhttps://github.com/tc39/proposal-type-annotations
“व्यवहार की स्थानीयता” बहुत ढीले ढंग से परिभाषित नियम है। यह बस separation of concerns के खिलाफ़ जाने वाली चीज़ को नया नाम देना भर है
CSS को दूर से होने वाली डरावनी क्रिया कहना भी बहुत बढ़ा-चढ़ाकर कहा गया है। कुछ अच्छे सिद्धांत हैं, लेकिन तर्क काफ़ी कमज़ोर है और इसे बहुत ज़्यादा सरल तरीके से कहा जा सकता था
अगर “लाल और उछलता हुआ button को नीले और हिलते हुए button में बदलना” जैसी चीज़ के लिए यह पता लगाने में कि किस class में नई implementation चाहिए और क्या reuse हो सकता है, 3 से 7 interfaces और classes की भूलभुलैया से गुज़रना पड़े, तो जो काम 10 मिनट का बदलाव लगता था वह आधा दिन compiler या पिछले developer को मन ही मन कोसते हुए निकल जाता है
बेशक abstraction होना चाहिए, लेकिन व्यवहार को एक ही जगह समेटने का तरीका भी होना चाहिए ताकि एक component बदलने के लिए 6 files न छूनी पड़ें
https://htmx.org/essays/locality-of-behaviour/#conflict-with...
Tailwind इस्तेमाल करने का मतलब है कि कोई third-party library आपके लिए CSS spec को abstract कर रही है, और आप यह मान रहे हैं कि build config के हिसाब से वह abstract की गई quasi-spec मानी जाएगी
क्या अलग किया जाना चाहिए? किस रेखा के आधार पर बाँटना चाहिए? वह रेखा कैसे तय होगी? कब किसी concern को दूसरी class, framework, markup वगैरह में निकालना सही है? और कब उसे साथ रखना बेहतर है?
जवाब है, “यह परिस्थिति पर निर्भर करता है”
अगर कुछ भी अलग नहीं करेंगे तो spaghetti बन जाएगा, और अगर हर जगह अधिकतम separation करेंगे तो ऐसा over-abstracted code बन जाएगा जिसे maintain करना spaghetti जितना ही मुश्किल होगा
अगर defaults अच्छी तरह काम करते हैं, तो customization अनिवार्य नहीं है। इसलिए CSS जैसी चीज़ों से मिलने वाला efficiency gain सरलता के पीछे चला जाता है
अगर HTML को document/presentation language माना जाए, तो styling को नकारा नहीं जा सकता। CSS सिर्फ़ styling ही नहीं बल्कि animation भी जोड़ता है
वैसे भी CSS को aspect-oriented programming की तरह भी देखा जा सकता है
यहाँ वर्णित असली समस्या languages और frameworks के पार अच्छे tools की कमी है
जहाँ संभव हो, ज़्यादा simple frameworks पर निर्भर होना समझ में आता है। लेकिन build step हटा दो वाली सोच लगभग पूरी तरह मज़ाक जैसी है
build step को और efficient बनाइए, और ज़रूरत हो तो उसे production में शामिल मत कीजिए
और यह भी समझ नहीं आता कि HTML में attributes जोड़ने को प्राथमिकता क्यों दी जाए। क्या हम document बनाकर उसे website की तरह host कर रहे हैं? इसके अलावा किस दुनिया में यह पसंदीदा तरीका है? CSS को खोजना मुश्किल नहीं है, बल्कि बेहतर CSS practices को बढ़ावा देना चाहिए
frontend scripting styling को धुंधला कर सकती है, लेकिन अगर ज़रूरत नहीं है तो उस तरीके पर निर्भर होने की भी ज़रूरत नहीं। JavaScript से attributes डालने की तुलना में style document में डालना आसान है, इसलिए यह बात पहले से ही स्पष्ट है
सिर्फ़ ज़रूरी चीज़ें इस्तेमाल करो जैसी कुछ सलाह समझ में आती है और स्पष्ट भी है। लेकिन बाकी बातें या तो उलझी हुई हैं या खुलकर बेतुकी लगती हैं। पूरा HTML page copy किया जा सकता है, यह क्यों अच्छी बात मानी जाए, यह भी समझ नहीं आता। सच कहूँ तो इससे फ़र्क नहीं पड़ता, और अगर कुछ pages का HTML न भी देखा जा सके तो HTML सीखने के लिए पहले से ही सचमुच लाखों resources मौजूद हैं
कुल मिलाकर यह पढ़कर बस अजीब-सा लगता है
यह पूरा लेख anti-pattern है और बुरी सलाह देता है। ऐसा लगता है जैसे इसे किसी ऐसे व्यक्ति ने लिखा है जिसने complex websites बनाते हुए growth pains झेले ही नहीं
शुरुआत में हम भी websites ऐसे ही बनाते थे, लेकिन side effects, टकराते हुए class names, और खराब internal observability की वजह से चीज़ें टूटने लगीं, और फिर React बचाने आया
जिस pattern की ज़रूरत है वह progressive enhancement है, और output साफ़-सुथरा, compressed HTML होना चाहिए जिसे JavaScript आगे enhance करे। यानी build step चाहिए। यह लेख जो सलाह देता है, उससे बिल्कुल उलटा
अगर backend में पहले से NodeJS इस्तेमाल नहीं हो रहा है, तो जब तक सच में ज़रूरत न हो ReactJS से बचना ही बेहतर है