फ्रेमवर्क और कई लाइब्रेरी के बिना वेबसाइट बनाना

 (kodingkitty.com)
3 पॉइंट द्वारा GN⁺ 2023-07-05 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Koding Kitty ने एक छोटी कंपनी की वेबसाइट के लिए static HTML-केंद्रित stack अपनाया, जिससे बड़े CMS या framework के बिना भी जरूरी pages और blog चलाए जा सके
  • चयन के मानदंड speed, development सुविधा, सस्ती hosting, और कम complexity थे; WordPress, no-code, framework और Jamstack में जरूरतों की तुलना में setup और learning burden ज्यादा था
  • content को Markdown या visual editor के बजाय सीधे HTML में लिखा, जिससे text और HTML/CSS/JS widgets मिले हुए posts की संरचना आसानी से संभाली जा सकी
  • दोहराए जाने वाले structures और common blocks को Jinja templates से संभाला गया, और 45 lines की Python script change detection, HTML rendering और Tailwind CSS CLI call को जोड़ती है
  • static site होने के कारण सस्ती hosting काफी थी; Hetzner webhosting 2 EUR से शुरू होती है और Hacker News front page के traffic spike को भी झेल सकी

सरल stack चुनने की वजह

  • Koding Kitty की website का technology stack हाल की lightweight web development trend को follow करने के बजाय वास्तविक requirements के हिसाब से जानबूझकर सरल रखा गया
  • लक्ष्य developers के लिए कम friction वाला setup था, और माना गया कि complex frameworks और libraries के combination की तुलना में सरल solution customers के लिए बेहतर हो सकता है
  • अलग लेकिन अति-भारी न लगने वाला design कई तरीकों से बनाया जा सकता था, लेकिन मौजूदा setup जरूरत के दायरे के अनुसार चुना गया है

requirements और शुरुआती मानदंड

  • शुरुआत से ही इसे static website बनाने का निर्णय लिया गया
  • जरूरी features front page, showcase और blog तक सीमित थे, उससे ज्यादा बहुत कुछ नहीं चाहिए था
  • चार मानदंड थे
    • तेज website
    • तेज development
    • सस्ती hosting
    • न्यूनतम complexity

जिन विकल्पों पर विचार किया, लेकिन हटाया

  • WordPress और समान CMS

    • माना गया कि WordPress ने internet में बड़ी भूमिका निभाई है
    • लेकिन modest requirements के लिए यह जरूरत से ज्यादा था
    • content को database में store करने की जरूरत नहीं थी, और plugins या visual editor भी जरूरी नहीं थे

  • no-code tools

    • web coder के लिए no-code tools इस्तेमाल करना अटपटा लगा
    • वे content को खुद own करना और website को अपनी पसंद के अनुसार control करना चाहते थे
    • coding से बनाना no-code WYSIWYG editor की तुलना में ज्यादा तेज लगा
    • शुरुआती learning और लगातार learning की जरूरत भी बोझ थी

  • frameworks

    • framework का अनुभव था, लेकिन पूरा setup लाना नहीं चाहते थे
    • database, settings, libraries, admin features जैसे components बहुत ज्यादा हो सकते थे
    • पूरी तरह customize किया जा सकता था, लेकिन नतीजा अंततः WordPress जैसा रूप ले सकता है, ऐसा आकलन किया गया

  • Jamstack और static site generators

    • static site generator requirements के लिए अच्छा fit लगता था
    • भाषा चुनकर code लिखने के बाद button या script से तेज static site बनाई जा सकती है
    • हालांकि initial setup और शुरुआती/लगातार learning की जरूरत थी
    • Markdown में blog लिखने की सुविधा को माना गया, लेकिन कुल मिलाकर ज्यादा सरल solution चुना गया

KittyStack की संरचना

  • Koding Kitty का setup चार requirements के इर्द-गिर्द व्यवस्थित किया गया

  • तेज website

    • static website तेजी से चलती है

  • तेज development

    • content Markdown या advanced editor में नहीं, बल्कि HTML में लिखा जाता है
    • Koding Kitty के posts में text और HTML/CSS/JS widgets मिलाए जाते हैं, इसलिए सीधे HTML लिखना उपयुक्त था

  • सस्ती hosting

    • static site hosting की लागत provider और जरूरी add-on features पर निर्भर करती है
    • static site के लिए बड़े hardware setup की जरूरत नहीं होती, इसलिए minimal setup चुना जा सकता है
    • Hetzner webhosting 2 EUR से शुरू होती है
    • Koding Kitty site Hacker News front page पर आने जैसे traffic spike को भी झेल सकती है

  • न्यूनतम complexity

    • कुछ pages और posts में repeating patterns हैं
    • copy-paste से भी काम चल सकता है, लेकिन समय के साथ इसे control करना मुश्किल हो सकता है
    • loops और header/footer जैसे code blocks शामिल करने की सुविधा चाहिए थी

Jinja और build flow

  • repeating structures और common files को include करना Jinja templates से संभाला गया
  • Jinja loops, navigation bar और footer जैसी files को include करने, और अन्य template features देता है
  • team को पहले Jinja-based framework इस्तेमाल करने का अनुभव था, इसलिए नया system सीखने की जरूरत नहीं पड़ी

सरल toolchain

  • अंतिम static pages 45 lines की Python script से generate किए जाते हैं
    • इसमें comments और खाली lines भी शामिल हैं
  • build flow इस प्रकार है
    • developer index.src.html को modify करता है
    • Watchdog.py file changes detect करता है
    • Jinja template को index.html में render करता है
    • Tailwind CSS CLI call करके styles.min.css बनाता है
  • development के दौरान Live Server files serve करता है और changes पर reload करता है
  • deployment के समय files को FTP से manually upload किया जाता है

कम complex web development के फायदे

  • web development को बहुत कुछ sacrifice किए बिना भी simple रखा जा सकता है
  • choices को कुछ विकल्पों तक सीमित करना उल्टा ज्यादा freedom जैसा महसूस हो सकता है
  • कई customers के लिए ज्यादा तेज, ज्यादा simple और ज्यादा सस्ता solution मददगार हो सकता है
  • web पर व्यापक रूप से देखते हुए यह आकलन करना जरूरी है कि क्या वही result कम complex technology stack से हासिल किया जा सकता है

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

1 टिप्पणियां

 
GN⁺ 2023-07-05
Hacker News की राय

  • फ़ोटो पोर्टफोलियो के लिए भी मैं इसी तरह के approach पर आकर टिक गया। डेवलपमेंट से फ़ोटोग्राफी में आने के बाद यह अच्छा लगा कि मुझे दूसरे फ़ोटोग्राफरों की तरह Squarespace पर निर्भर नहीं होना पड़ता
    Ghost, Statamic, Phoenix/Vapor से बने server-based options और कई सामान्य static site generators आज़माने के बाद, आखिरकार मैं templates के बिना pure HTML लिखकर उसे rsync से Hetzner server पर अपलोड करने के तरीके पर आ गया
    navigation जैसे common UI के लिए templates न होना थोड़ा खटकता है, लेकिन regex से कुछ मिनटों से ज़्यादा लगने वाला कोई बदलाव अभी तक नहीं आया, और शुरुआत में greedy regex ने एक बार content उड़ा दिया था तो git ने बचा लिया
    image size और format के हिसाब से variants बनाना झंझट वाला है, लेकिन इससे Ghost जैसे fixed layout पर निर्भर हुए बिना नए layouts आज़माने को मिलता है। और ज़्यादातर static site generators के libraries या CLI tools की तुलना में, RAW editor Capture One से web के लिए images export करने पर quality थोड़ी बेहतर लगी
    यह धीमा है, लेकिन मुझे यह फ़ोटोबुक बनाने के ज़्यादा करीब लगता है। शुरुआत में मेहनत ज़्यादा लगती है, लेकिन एक बार खत्म हो जाए तो हो जाता है, और अगले 20 साल तक अलग-अलग CMS के बीच घूमकर चीज़ें तोड़ने की ज़रूरत नहीं पड़ती

    • basic previous/next navigation और consistent menu, header, footer को server-side includes से संभाला जा सकता है
    • मेरी personal photography website Svelte + TailwindCSS, Flickr API, और Netlify का इस्तेमाल करती है
      असल में यह कुछ HTML files पर templates की ताकत जोड़ने जैसा ही है, और Flickr API के ज़रिए इस साइट के लिए बने album से photos लाता है, जबकि Netlify पर सिर्फ git push करते ही auto deploy हो जाता है
      hosting सहित कुल लागत 0 डॉलर है, और Flickr app से फ़ोन पर photos manage किए जा सकते हैं। Netlify की वजह से असली server box को छूने की भी ज़रूरत नहीं पड़ती, यह भी अच्छा है
    • Vapor का उपयोग अनुभव कैसा था, यह जानना चाहूँगा
      हाल में मैंने जो तरीका इस्तेमाल किया, वह भी मददगार हो सकता है(https://news.ycombinator.com/item?id=36592641). Google Sheet को data source की तरह इस्तेमाल करना आसान था, और photo file system पर बदलते तब भी शायद उतना ही आसान होता
    • मैं भी Smugmug से निकलकर ऐसा कुछ करने की सोच रहा था, तो जानना चाहता हूँ कि क्या आप अपना portfolio या source share कर सकते हैं

  • यह ‘simple’ कम और simplistic ज़्यादा लगता है। अगर आप कुछ भी न करें और कोनों को काट दें, तो एक अपेक्षाकृत simple website बनाई जा सकती है
    इस page पर दिखने वाले लगभग इकलौते non-trivial feature, यानी dark mode, को ही देखें: इसे lazy-loaded JS से संभाला गया है, इसलिए हर page load पर बच न सकने वाली white flash होती है। इसे सही करने का तरीका CSS body class approach होना चाहिए, और जो समाधान काम ही न करे, वह simple हो या complex, उसका कोई मतलब नहीं
    और localStorage तथा dark mode setting जैसी JS की 3 लाइनों के लिए https://hyperscript.org/ जैसे custom ‘hyperscript’ interpreter को पूरा का पूरा लाना, “simplicity is the ultimate sophistication” जैसी भावना के उलट है। सिर्फ उसी काम के लिए 96KB की uncached library लाना अजीब है, और क्या इसी वजह से HTML validation भी fail हो रही है, यह भी सोचने वाली बात है
    आखिर में, binary toggle system/browser settings को ignore करता है, इसलिए यह dark mode का खराब implementation है। अगर smartphone OS में dark mode on हो, तब भी user के खुद चालू करने तक light mode ही दिखेगा, और time या ambient light के हिसाब से बदलने वाली system settings का भी सम्मान नहीं होगा। localStorage expire हो सकता है और devices भी बदलते हैं, इसलिए यह setting बार-बार करनी पड़ती है; ऐसे में user शायद developer की कही हुई ‘simple’ implementation से सहमत न हो

    • अगर लक्ष्य जितना हो सके उतनी simple website बनाना है, तो dark mode होना ही नहीं चाहिए। 90 के दशक में भी simple और पढ़ने में आसान websites थीं, और dark mode trend से पहले light mode ही काफ़ी था
      system/browser settings, time-based switching, ambient light जैसी चीज़ों को ध्यान में रखें तो complexity simple website की philosophy से टकराती है। बेहतर है dark mode को हटा दिया जाए; HN भी हमेशा light mode में है, फिर भी रात में पढ़ने में कोई बड़ी दिक्कत नहीं होती
    • मैं मानता हूँ कि lazy-loaded JS वाला तरीका गलत है, लेकिन media query वाला तरीका भी पेचीदा है
      आम तौर पर आप prefers-color-scheme का सम्मान भी करना चाहते हैं और toggle भी देना चाहते हैं, और अगर user ने पहले साइट पर खुद कोई विकल्प चुना हो तो उसे प्राथमिकता भी देना चाहते हैं। तब भी JS और localStorage की ज़रूरत पड़ती है
      मेरा पसंदीदा तरीका inline style में body {visibility: hidden; opacity: 0;} डालना है। पिछला page दिखता रहने दें, फिर DOMContentLoaded पर prefers-color-scheme और localStorage देखकर सही body class सेट करें और उसके बाद page render होने दें
    • पढ़ते समय मैंने सोचा, “यह शानदार analysis है,” और फिर author को देखकर बात समझ में आ गई। OP से कहूँ तो, यह https://gwern.net के लेखक हैं, और इस साइट ने कई technical blogs और personal site designs को गहराई से प्रभावित किया है, साथ ही इसमें बहुत से मौलिक और बेहतरीन ideas हैं
      मेरी साइट CSS से light/dark theme का सम्मान करती है और इसमें manual toggle नहीं है। JS के बिना pure HTML/CSS site रखना मेरा निजी लक्ष्य है, और light/dark setting में user की preference का सम्मान होना चाहिए। अगर toggle की ज़रूरत है, तो वह साइट के अंदर नहीं बल्कि browser toolbar की setting होनी चाहिए
      अगर /u/gwern यह पढ़ रहे हों, तो मेरी साइट https://daveon.design/ पर gwern design और Tufte.css का प्रभाव है। इसमें पुराने publications, manuscripts और मेरी personal taste भी मिली हुई है, लेकिन एक modern और साफ-सुथरी personal website कैसी दिख सकती है और उसमें क्या हो सकता है, इसकी पहली प्रेरणा देने वाले सबसे अहम उदाहरणों में gwern शामिल थे
    • Mac पर Firefox, Chrome, Safari और Android पर Firefox, Chrome में white flash दिखाई नहीं देती। पहली load, refresh, और dark/light switch—सब बस ठीक से काम करते लगते हैं
    • यह सही बात है। दुर्भाग्य से, टूटी हुई लेकिन simple दिखने वाली सोच भी उतनी ही आम है जितनी टूटी हुई और फूली हुई approaches

  • अगर ज़ोर देकर कहूँ, तो अभी SvelteKit + Skeleton इस्तेमाल करने लायक प्रोटोटाइप बहुत तेज़ी से बनाने के मामले में सचमुच प्रभावशाली है
    Svelte को ठीक से न भी जानते हों, तो file-based routing समझ लेना काफ़ी है; बाकी ज़्यादातर चीज़ें ज़रूरत पड़ने तक लगभग HTML ही रहती हैं, Tailwind डिफ़ॉल्ट रूप से शामिल होता है, और themes भी काफ़ी हद तक vanilla के क़रीब हैं
    पिछले कुछ महीनों में मैंने Astro, Lit, Next.js, Go built-in templates, pug, Eleventy वगैरह कई चीज़ें आज़माईं, और अब तक लगभग हर मामले में यही कॉम्बिनेशन सबसे ज़्यादा पसंद आया है

    • SvelteKit शानदार है, लेकिन Skeleton से सहमत होना मुश्किल है। शुरुआत में यह productive और safe लगता है, लेकिन इसमें कई pitfalls हैं, और जब कोई चीज़ पसंद न आए तो customize करना मुश्किल हो जाता है
      Skeleton की अपनी साइट https://www.skeleton.dev/docs/get-started ही देख लें: Page Down दबाने पर भी scroll नहीं होता, navigation bar पर mouse hover करने पर भी scroll नहीं होता, और print करने पर स्क्रीन पर दिख रहा हिस्सा ही कटकर आता है। मैंने यह मुद्दा उठाया था, लेकिन अभी भी इसकी priority ज़्यादा नहीं है, जबकि बहुत-सी साइटें यह component pattern इस्तेमाल कर रही हैं
      लगता है Skeleton यह मानता है कि dark theme के colors उलट देने से ठीक-ठाक light theme बन जाएगी, लेकिन असल में ऐसा नहीं है। DaisyUI ज़्यादा mature है, performance बेहतर है, ज़्यादा व्यापक रूप से इस्तेमाल होती है, और accessibility को गंभीरता से लेती है। बिना JS के सिर्फ CSS animations से इतना कुछ कर लेना भी हैरान करने वाला है, और यह मुश्किल HTML/CSS हिस्सों को संभाल लेती है, जबकि आसान Svelte वाला हिस्सा आप खुद लिख सकते हैं। Svelte dependency भी कम है, इसलिए DaisyUI HTML को दूसरे frameworks में ले जाना आसान है
    • सहमत हूँ। यह framework है, लेकिन JS बंद होने पर भी ठीक से काम करने वाली static site आसानी से output कर देता है, Svelte जाने बिना भी इस्तेमाल किया जा सकता है, और ज़रूरत हो तो Svelte भी इस्तेमाल कर सकते हैं
      Tailwind तुरंत काम करने लगता है, और Netlify जैसी जगह पर deploy करना भी बहुत आसान है। अभी के हिसाब से यह सबसे अच्छा static site builder है, और मुझे लगता है कि यह लेख में बताए गए तरीके से काफ़ी ज़्यादा सरल है
    • मुझे minimalism पसंद है, और इस नज़रिए से Astro और SvelteKit दोनों इस्तेमाल किए हैं; SvelteKit, खुद एक बहुत छोटी component library Svelte के ऊपर रखी गई एक बहुत पतली layer जैसा लगता है
      +page.ts और सही configuration के साथ static website भी बनाई जा सकती है, और चाहें तो इसे multi-page app या single-page app तक भी ले जा सकते हैं
    • “क्या इनपुट दें तो आख़िरी page ऐसा दिखेगा” स्टाइल के examples ज़्यादा नज़र नहीं आते। install करके process follow करने से पहले, ऐसे examples हों जिन्हें बस सीधे देखकर समझा जा सके, तो अच्छा होगा
    • अच्छा सुझाव है। दूसरे web frameworks के साथ आपके अनुभव के बारे में भी और सुनना चाहूँगा, और यह भी जानना है कि क्या आपने Flutter भी आज़माया है

  • अरे भाई, HTML और CSS से वेबसाइट बनाना तो पागलपन जैसा लगता है
    मज़ाक अलग, templates को छोड़ दें तो मैं भी लगभग यही stack इस्तेमाल करता हूँ। अगर आप web developer नहीं हैं, तो CSS framework की ज़रूरत समझना मुश्किल है, और खुद बना लेना काफ़ी आसान पड़ता है। site generators में Hugo भी इस्तेमाल किया, लेकिन उससे ज़रा भी समय नहीं बचा
    कुछ महीने पहले CSS skills बेहतर करने के लिए मैंने कुछ कंपनी वेबसाइटों को recreate करके देखा था, और HTML व CSS भर से उनका बाहरी रूप सबका सब दोबारा बनाया जा सकता था। लेकिन उन कंपनियों की असली वेबसाइटें JS बंद करते ही दिखती ही नहीं थीं
    हम framework के ऊपर framework, नई language, नए tools जोड़ते जा रहे हैं, और उनमें से ज़्यादातर सिर्फ complexity और अगली पीढ़ी के लिए व्यस्त काम बढ़ाते हैं। जिन 5% वेबसाइटों को सचमुच इसकी ज़रूरत होती है, वे अलग मामला हैं
    यह भी दिलचस्प था कि यह असली service बेचने वाली साइट थी, और इसकी pricing कैसी थी यह जानने की जिज्ञासा भी हुई

    • design बनाना और उसे लगातार एक जैसा बनाए रखना बहुत मुश्किल लगता है। इसलिए pre-defined CSS होना अच्छा लगता है, नहीं तो नतीजा बिखरा हुआ दिखता है
    • कुल मिलाकर सहमत हूँ, लेकिन Astro को मैंने काफ़ी सफलतापूर्वक इस्तेमाल किया है

  • मेरे हिसाब से सबसे minimal और productive तरीका बस PHP इस्तेमाल करना है। वह भाषा मूल रूप से ऐसे ही काम के लिए बनाई गई थी
    साधारण साइट के लिए न composer चाहिए, न router logic; बस header/footer/navigation फ़ाइलें अलग बना लें और हर page में include कर दें

    • library के बिना भी करीब 100 lines में router और layout बनाया जा सकता है। router सिर्फ फ़ाइल के मौजूद होने की जाँच करे, और layout में header.php, pagename.php, footer.php include कर दें। साधारण साइटों के लिए मैं यही करता हूँ, और यह बहुत आसान और तेज़ है
    • PHP न भी हो, तो कोई भी server-side scripting language चलेगी। असल बात यह है कि साइट को refactor करने लायक बनाने के लिए data और code blocks को नाम देकर save और load कर सकें
      अगर HTML, CSS या JS की तरह external HTML insert कर पाता, तो यह भी ज़्यादातर मामलों में ज़रूरी नहीं होता। काश इसे मनचाहे तरीके से इस्तेमाल करने दिया जाता
    • अगर सादगी चाहिए, तो PHP + HTML को मात देना मुश्किल है। single-purpose scripts से बड़े कामों के लिए मैं इतनी दूर तक सादगी नहीं ले जाना चाहूँगा और आम तौर पर अलग template library रखूँगा, लेकिन ऐसा कर पाना अपने-आप में अच्छी बात है
    • मंशा से सहमत हूँ, लेकिन अगर 5–20 घंटे लगाए जाएँ, तो Eleventy आधारित एक असरदार customized site generator बनाया जा सकता है और Netlify पर मुफ़्त में deploy भी किया जा सकता है
      कुछ बदलें, git commit/push करें, और 30 सेकंड के भीतर बदलाव दुनिया भर में दिखने लगते हैं। काफ़ी बढ़िया है, और अलग server hosting की भी ज़रूरत नहीं पड़ती
    • simple frameworks बहुत हैं, लेकिन कुछ और चीज़ें जोड़ते-जोड़ते हम जल्दी ही फिर उसी आम bloated हालत में लौट आते हैं

  • “जितना संभव हो उतना सरल, लेकिन उससे ज़्यादा सरल नहीं” वाली बात याद आती है। शायद यह Albert Einstein का कथन नहीं है
    शुद्ध HTML + CSS, और CSS को हर HTML tag के अंदर या पेज के भीतर रखना, शुरुआत के लिए ठीक है। जैसे ही पेज दो हो जाते हैं, आप CSS को अलग फ़ाइल में निकाल देते हैं
    लेकिन जब आप एक ही फ़ॉर्मैट वाले कई पेजों की साइट बनाना शुरू करते हैं, तो include वाले template system और static site generator की ज़रूरत पड़ती है
    अगर पेज data-driven हों, तो ऐसा programmable site generator चाहिए जो data लेकर पेज बना दे, और अगर data “real-time” हो, तो हर view के लिए पेज बनाना पड़ेगा, इसलिए कम से कम PHP वाले क्षेत्र में, और आगे चलकर running server वाले आधुनिक web framework के क्षेत्र में पहुँचना पड़ता है
    मैंने हाल ही में शौक से जुड़ी एक pro bono साइट बनाई। यह dance promotion और event साइट है, और मालिक एक dance teacher हैं जिन्हें तकनीक की ज़्यादा समझ नहीं है। मैंने Eleventy(https://www.11ty.dev/) से Netlify free tier पर static site generate की, और teacher आने वाले events define कर सकें, इसके लिए Google Sheet से data लाने वाला custom build code जोड़ा
    इसे बनाने में दस-बारह घंटे लगे, लेकिन अब यह बिना किसी operations/management cost के अच्छी तरह चल रही है। इससे समझ आया कि पूरी तरह न्यूनतम सेटअप और Rails/Phoenix/Django स्तर के बीच एक मज़बूत sweet spot मौजूद है

    • OP भी आख़िरकार Jinja templates और Tailwind styling, यानी दो libraries, का इस्तेमाल करता है। यह pure HTML/CSS और Django/Phoenix/Rails + Angular/React/Vue के बीच का एक अच्छा मध्य मार्ग है
    • मैं आम तौर पर किसी चीज़ के दो बार आने पर refactor कर देता हूँ, लेकिन मैंने यह भी सुना है कि DRY को तीन बार तक टालना effort के मुकाबले payoff के लिहाज़ से बेहतर break-even संभावना देता है
      हालाँकि, किसी साइट में पेजों की संख्या लगभग तय है कि 3 से ज़्यादा होगी, इसलिए यह सामान्य code block के 3 बार इस्तेमाल होने की संभावना से थोड़ा अलग मामला हो सकता है
    • जानना चाहता हूँ कि क्या आपने इसे open source के रूप में जारी किया है, या कोई similar project मिला है
      यह भी जानना चाहता हूँ कि क्या संरचना ऐसी है जहाँ Google Sheets API को client side से call करके data भरा जाता है, और अगर हाँ, तो क्या कोई cache layer है, या हर client हर बार नई copy लेता है

  • framework और complexity पर बहस अब सच में बहुत उबाऊ हो गई है
    अगर client multi-stage publishing workflow, internationalization, compliance accessibility के साथ custom CMS माँगता है, तो client की अपेक्षित timeline में उसे बनाने के लिए शक्तिशाली tools चाहिए। enterprise में ऐसे client बहुत होते हैं, इसलिए ऐसे tools की माँग भी बड़ी है। अगर आपने सिर्फ B2C किया है तो यह चौंकाने वाला लग सकता है, लेकिन tech industry का पानी के नीचे वाला बड़ा हिस्सा यही है
    यह सही है कि static blog के लिए complex Next.js setup या Vite toolchain की ज़रूरत नहीं होती। लेकिन जो लोग इन tools पर गंभीरता से चर्चा करते हैं, वे simple blog site बनाने की बात नहीं कर रहे होते। tutorial का छोटा किया गया example भले blog हो, असली problem अलग होती है
    इसलिए framework से नफ़रत थोड़ी कम होनी चाहिए। अगर सरल तरीक़े से वेबसाइट बनाने का कोई अच्छा idea है, तो tutorial जारी कीजिए, और अगर वह आकर्षक होगा तो लोग सही जगहों पर उस तरीक़े का इस्तेमाल करेंगे। बस इतना है कि किसी धुँधले दुश्मन जैसे “spicy toolchain और trendy framework” को खड़ा करके उसके विरोध में बात करने से बचना चाहिए

    • इस बातचीत में शामिल बहुत से लोगों ने कभी उन problems पर सीधे काम ही नहीं किया जिनमें ऐसे tools उपयोगी होते हैं। वे engineer हो सकते हैं, लेकिन frontend को छुआ नहीं है, इसलिए बुनियादी स्तर से आगे नहीं जानते, या वे CS student हो सकते हैं जिन्होंने Jekyll से personal blog बना लिया और समझते हैं कि अब उन्हें frontend development सब आता है
      या फिर वे लंबे समय तक ऐसे internal business app बनाते रहे हों जिनके users दो अंकों में हों और UX requirements भी न हों, और इस वजह से खुद को सब जानने वाला मानते हों। इस तरह के कम-जानकारी वाले फ़ैसले चर्चा को पटरी से उतार देते हैं
    • अगर आप complex चीज़ें करते हुए framework नहीं इस्तेमाल करते, तो आख़िरकार आप खुद एक और framework बना लेते हैं
      फ़र्क बस इतना होता है कि इस बार उस codebase को विरासत में पाने वाले व्यक्ति को कोई updates नहीं मिलेंगे, और Stack Overflow पर मदद पाना भी मुश्किल होगा
    • सहमत हूँ। framework जो complexity लाते हैं, वह मुझे पसंद नहीं, फिर भी यही बात सही है
      समझ नहीं आता कि लोग क्यों मानते हैं कि हर काम में अलग tool नहीं इस्तेमाल किया जा सकता। कुछ मौकों पर framework की ज़रूरत नहीं होती, लेकिन मेरे अनुभव में ऐसे मामले कम होते हैं, जब तक आप बहुत ही simple और कम बदलने वाली चीज़ न बना रहे हों
      team और client वाले माहौल में “simple tools” वाली साइट वास्तव में कैसे चलेगी, यह कल्पना करना मेरे लिए मुश्किल है; यह आलोचना नहीं, सच में न जानने वाली बात है

  • यह तरीका भी मुझे पहले से ही बहुत जटिल लगता है
    मैंने लेख Gemtext, यानी Gemini के लिए markdown, में लिखे, उन्हें HTML में convert किया, और index pages generate करने के लिए एक Python script बनाई
    CSS सिर्फ 42 lines की थी, इसलिए उसे हर पेज में ही डाल दिया, और मैंने यह भी हिसाब लगाया कि हर फ़ाइल में 42 lines बढ़ने की लागत दूसरी HTTP request से कभी ज़्यादा नहीं होगी
    Python libraries या templates के बिना यह उम्मीद से कहीं ज़्यादा सरल निकला। सबसे कठिन हिस्सा mailing list पर भेजे जाने वाले emails generate करना था। कई frameworks और static site generators का विश्लेषण करने में महीनों लगे, और ठीक-ठाक CSS ढूँढने में कई हफ़्ते
    git history के अनुसार, WordPress के 18 साल के रिकॉर्ड import करने समेत, मैंने दो हफ़्ते हैकिंग करके इसे पूरा किया। pure Python होने की वजह से कुछ नया सीखना नहीं पड़ा, और bug होने पर आसानी से ठीक या बदल सकता हूँ। क्योंकि यह मेरा code है
    computer scientists यह बात पूरी तरह भूल गए हैं कि हर चीज़ को reuse करने की कोशिश करने के बजाय वे बस ad-hoc custom solution भी code कर सकते हैं। सीखने और अनुकूलित करने में लगने वाला समय, सीधे खुद बनाने के समय से ज़्यादा होता है
    कोड: https://git.sr.ht/~lioploum/ploum.net
    साइट: https://ploum.net

    • Email? Python script? Git? कमाल की Rube Goldberg machine है
      मेरी साइट 2003 में balsa wood से तराशकर Ethernet cable पर epoxy से चिपकाए गए 6502 processor से serve होती है। जब कुछ बदलना होता है, तो मैं hair dryer से EPROM गरम करता हूँ ताकि मनचाहे bits flip हो जाएँ। न templates, न code, न bloat
    • शानदार blog है। मैं सिर्फ design देखने के लिए खोला था, लेकिन लगातार 4 लेख पढ़ गया
      नीचे scroll करते हुए tech history को फिर से देखने का एहसास काफ़ी nostalgic लगा

  • अगर मैं गलत नहीं समझ रहा हूँ, तो यह औसत static site generator से बहुत अलग नहीं लगता। यह Python-आधारित Jinja templates से HTML files बनाने और Ruby-आधारित Liquid templates से HTML/Markdown files बनाने वाले Jekyll के बीच के फर्क जैसा लगता है

    • तैयार framework इस्तेमाल करने के बजाय इसे खुद बनाया गया है। और यह ठीक है। कुछ बनाना मज़ेदार होता है
    • मेरा भी यही विचार था। अगर लक्ष्य सादगी था, तो मौजूदा static site generator का इस्तेमाल न करके एक custom generator खुद बनाना अजीब विकल्प लगता है
      include के लिए PHP site या कोई तैयार static site generator कहीं ज़्यादा समझदारी भरा लगता

  • समझ नहीं आता। static site generator नहीं चाहिए था, इसलिए आखिर में static site generator ही खुद लिख लिया