स्टैटिक साइट पैरेडॉक्स
(kristoff.it)- व्यक्तिगत ब्लॉग या संपर्क पेज जैसी सरल साइटों के लिए भी आम उपयोगकर्ता WordPress जैसे CMS पर बने रहते हैं, जबकि स्टैटिक HTML साइटें उल्टा पेशेवर इंजीनियरों के लिए चलाना अधिक आसान हो गया है
- स्टैटिक साइट खुद बनाने के लिए डोमेन खरीदना, होस्टिंग चुनना, DNS सेटिंग, SSG चुनना, और डिप्लॉयमेंट पाइपलाइन बनाना जैसी कई मध्यवर्ती प्रक्रियाएं खुद संभालनी पड़ती हैं
- इंजीनियर GitHub Pages या Cloudflare Pages के जरिए free hosting और custom domain का लाभ लेते हैं, लेकिन आम उपयोगकर्ता उन मामलों में भी, जहां स्टैटिक साइट पर्याप्त होती, अधिक महंगी और भारी सेवाओं पर निर्भर हो जाते हैं
- SuperHTML को उपयोगकर्ताओं को diagnostics रिपोर्ट करने वाला पहला HTML language server बताया गया है, जबकि मौजूदा diagnostics टूल्स अधिकतर किसी खास frontend framework से बंधे होते हैं, इसलिए केवल vanilla HTML के साथ उनका उपयोग करना कठिन होता है
- अगर सरल web development को आसान नहीं बनाया गया, तो वेब गैर-विशेषज्ञों से दूर होता जाएगा और आम उपयोगकर्ता social network जैसे बंद प्लेटफ़ॉर्मों की ओर धकेल दिए जाएंगे
स्टैटिक साइट के अधिक कठिन हो जाने का विरोधाभास
- दो व्यक्तिगत वेबसाइट उदाहरणों की तुलना की गई है
- एक जटिल CMS है जो PHP में लिखा गया है और जिसके लिए web server, कई workers, Redis cache, और SQL database की जरूरत होती है
- उसका frontend भी Single Page Application के रूप में लोड होता है, JSON के रूप में कंटेंट मांगता है, और फिर client पर दोबारा assembled होता है
- दूसरी साइट स्टैटिक HTML फ़ाइलों और एक-दो CSS फ़ाइलों से बनी है, और इसमें JavaScript नहीं है
- ऊपर से देखने पर लगता है कि आम उपयोगकर्ता सरल स्टैटिक साइट इस्तेमाल करेंगे और पेशेवर इंजीनियर जटिल संरचना, लेकिन वास्तव में स्थिति लगभग उलटी है
- अगर आम उपयोगकर्ता खुद स्टैटिक साइट चलाना चाहें, तो उन्हें कई चरणों से गुजरना पड़ता है
- डोमेन खरीदना
- होस्टिंग प्लेटफ़ॉर्म ढूंढना
- DNS सेट करना
- SSG चुनना या खुद बनाना
- डिप्लॉयमेंट पाइपलाइन कॉन्फ़िगर करना
- इसके उलट software engineers, GitHub Pages, Cloudflare Pages आदि के जरिए free hosting और custom domain support का फायदा उठा सकते हैं
- नतीजतन, उन 99% मामलों में भी जहां स्टैटिक वेबसाइट पर्याप्त होती, आम उपयोगकर्ता ज्यादा खर्च और ज्यादा compute resources लेने वाले जटिल समाधानों में बंध जाते हैं
सरल वेब को आसान बनाने वाले टूल्स की जरूरत
- Boston की SquiggleConf प्रस्तुति HTML language server को implement करने के अनुभव पर थी, और इसका निष्कर्ष web accessibility की समस्या तक पहुंचता है
- SuperHTML को उपयोगकर्ताओं को diagnostics रिपोर्ट करने वाला पहला HTML language server बताया गया है, और संबंधित लेख Hacker News फ्रंटपेज पर पहुंचा
- linters मौजूद हैं और editor diagnostics भी संभव हैं, लेकिन वे आमतौर पर किसी खास frontend framework से बंधे होते हैं
- इसी वजह से उपयोगकर्ता, जब वास्तव में जटिलता की जरूरत नहीं होती, तब भी framework चुनने पर मजबूर हो जाते हैं
- वेब सिर्फ software engineers का नहीं है, और वेब जितना अधिक जटिल बनाया जाएगा, आम उपयोगकर्ता उतना ही social network नाम की बाड़ के भीतर धकेले जाएंगे
- startup या big tech के लिए आर्थिक प्रोत्साहन इस समस्या को अपने आप हल करने के अनुकूल नहीं हैं, इसलिए सरल वेब को और आसान बनाना जरूरी है
1 टिप्पणियां
Hacker News की राय
WordPress छोड़कर static site अपनाने के लिए marketing टीमों को मनाने की कोशिश के कई कड़वे अनुभव रहे हैं
अंत में असली बात editing की आसानी ही है। WordPress site hosting, technical lead, accounting team या readers के लिए नहीं, बल्कि editors के लिए optimize होती है, और site edit करने वाले लोग ही तय करते हैं कि implementation कैसा होगा
अगर उनके सामने ऐसी site रखी जाए जो 100ms से कम में render होती है, पूरी तरह सुरक्षित है, hosting cost 0 रुपये है, लेकिन Markdown files और थोड़ा Git deployment मांगती है, और दूसरी तरफ WordPress हो जो धीमा, महंगा, vulnerable और लगातार maintenance मांगने वाला है, लेकिन editing experience अच्छा है, तो वे हमेशा WordPress चुनते हैं
मुझे हमेशा उलझन होती है कि इन लोगों के पास choice क्यों होती है, लेकिन वही experiment कई बार करने पर भी नतीजा हमेशा वही रहा
Text editor और Git सीखने के बजाय WordPress चुनना अजीब क्यों है, यह समझ नहीं आता। Experiment ऐसा होना चाहिए कि एक तरफ अच्छा editing experience देने वाला tool हो जो पीछे से static site और Git deployment बनाता हो, और उसकी तुलना WordPress से हो। तब secondary requirements यानी security और speed मायने रख सकती हैं
यह blog से ज़्यादा एक custom application जैसा है, जिसे non-experts clicks और drag के ज़रिये अपनी मनचाही functionality के हिसाब से गढ़ सकते हैं। जब तक hack न हो जाए या कोई ऐसी custom feature need न आ जाए जिसके लिए सचमुच engineer चाहिए, coding की भी ज़रूरत नहीं पड़ती
Hugo, Ghost वगैरह इस्तेमाल करने पर बात “इसके लिए अलग platform चाहिए” तक पहुँचती है, और वह platform Shopify, accounting system, social network/membership plugin, job board वगैरह बन जाता है। WordPress ऐसी चीज़ बन गया जिसे किसी भी चीज़ में बदला जा सकता है
कोई consultant से अपनी जरूरत बताता तो जवाब मिलता, “मैं इसे WordPress में setup कर दूँगा,” और क्योंकि सब WordPress इस्तेमाल करते थे, problem आने पर, plugin में थोड़ा बदलाव करने पर, या email sending hook जोड़ने के लिए किसी को ढूँढना आसान था। PHP consultants के दौर ने WordPress का दबदबा बनाया
समस्या यह है कि paid solutions समेत ज़्यादातर चीज़ें complete solution नहीं हैं। इस्तेमाल शुरू करते ही जल्दी पता चल जाता है कि WordPress बेवकूफाना constraints थोपता है। आप online store को उस entity/metadata system की performance disaster से बाहर design नहीं कर सकते, जहाँ मध्यम आकार की query में भी 5 सेकंड लगते हैं और 50 unoptimized secondary queries बनती हैं। कुछ plugins तो WordPress को bypass करके अपनी database tables तक बना लेते हैं
Blog के अलावा WordPress की architecture खराब है, लेकिन इसे हर चीज़ के tool की तरह इस्तेमाल किया जाता है। दूसरे CMS ऐसा नहीं करते, इसलिए लोग उन्हें इस्तेमाल नहीं करते
Content को अब भी generated static files के रूप में CDN के जरिए distribute किया जा सकता है। Static site का मतलब Markdown और Git मांगना नहीं है
मैंने लंबे समय तक ऐसी toolchain खोजी जिसमें बिल्कुल भी technical experience न रखने वाला intern भी technical details में उलझे बिना updates deploy कर सके, लेकिन अभी तक नहीं मिली
सबसे करीब तरीका headless CMS के ऊपर static site generator लगाना है, लेकिन सच कहूँ तो वे सब अच्छे नहीं हैं
2016 में जब मैं स्थानीय व्यवसायों के लिए परिचयात्मक साइटें बनाने वाली एक agency में काम करता था, एक ग्राहक ने अपनी बनाई website में reservation system के लिए एक छोटा iframe डालने को कहा। उन्होंने जो भेजा वह एक Word document था, और बाद में पता चला कि वे उसे HTML में export करके सस्ते shared hosting पर डाल रहे थे
यह उनके लिए बहुत अच्छी तरह काम करता था। वे अपना online menu हमेशा up to date रख पाते थे, क्योंकि जिस Word document से वे printed menu बनाते थे, उसी से सीधे export कर देते थे। उस समय internally हमने थोड़ा मजाक उड़ाया था, लेकिन अब सोचता हूं तो अफसोस होता है। जब restaurant चलाने जैसे लाखों ज्यादा जरूरी काम हों, तो यह दरअसल जीनियस तरीका है
static site बनाना अब भी ज्यादा आसान है। बस HTML generate करने वाले authoring tools आजकल या तो खास अच्छे नहीं हैं, या अगर ठीक भी हैं तो site serve करने के लिए server पर चलने वाली कोई प्रक्रिया साथ में जुड़ जाती है
मेरा काम “इसे और बेहतर बनाया जा सकता है” कहकर मजाक उड़ाना नहीं, बल्कि उनके solution को improve करना है; और यह सुनिश्चित करना है कि मैं जो solution दूं वह मौजूदा तरीके जितना, हो सके तो उससे बेहतर काम करे, और जो सफलता वे पहले ही पा चुके हैं उसमें बाधा न डाले
बहुत से developers मानना नहीं चाहते, लेकिन इस तरह के temporary web solutions अक्सर उन कई strategies से बेहतर काम करते हैं जिन्हें कोई skilled web developer अकेले implement करेगा
अहम बात यह है कि business क्या प्रदान करता है और customers से कैसे जुड़ता और interact करता है। कभी-कभी Word document को HTML में export करना ही काफी होता है। technology से सुधार किया जा सकता है, लेकिन असली जादू business चलाने वाले लोगों में होता है
ऐसे solutions को बेहतर बनाने का तरीका ढूंढना कभी-कभी सचमुच काफी मुश्किल होता है। आप बेहतर website बना सकते हैं और उसे sophisticated infrastructure पर deploy कर सकते हैं, लेकिन आखिर में क्या customers उसे ज्यादा पसंद करते हैं? क्या business बेहतर होता है? यह हिस्सा बिल्कुल भी मामूली नहीं हो सकता
मैं कई सालों से ऐसा अच्छा alternative खोज रहा हूं जो Word के HTML export से ज्यादा सही HTML बनाए और ज्यादा विकल्प भी दे
मुझे ऐसी चीजें पसंद हैं। Vue template से बनी single HTML file sites भी बहुत हैं, public Notion documents के रूप में publish की गई sites भी हैं, और iCloud की inline photo library भी। यह हैरान करता है कि चीजों को बस जोड़ देना कितना आसान और व्यापक रूप से संभव हो गया है, और यह भी महसूस कराता है कि हम शुरुआत से खुद बनाने की कोशिश में कितनी बार काम को जटिल बना देते हैं
जब समय नहीं होता, तो छोटे micro sites या one-off sites जल्दी जोड़कर बनाने के लिए mmm.page जैसी चीजें भी पसंद हैं। ऐसे tools explore करना मजेदार है
लेकिन कुछ pages के “documents” दरअसल dates और text वाली tables का समूह हैं, जिन्हें ग्राहक खुद manage करता है। आखिर में जिस समाधान पर पहुंचे, वह भी कुछ वैसा ही था। वे Word document में table डालकर हमें देते हैं, और हम उसे HTML/CSS में export करके सही जगह पर रख देते हैं
यह elegant भी नहीं है और scalable solution भी नहीं, लेकिन जिस use case में लागू होता है, उसमें यह निस्संदेह सबसे आसान तरीका है
तब भी यह अद्भुत था और अब भी है। चुपचाप, हमने computing को सभी तक पहुंचाने का सपना पूरा कर लिया
अभी Asheville में इस समस्या का बड़ा सामना हो रहा है। जब mobile phone service मुश्किल से वापस आई, तब भी सभी लोग टूटते रहने वाले खराब 3G पर थे, और basic survival information देने वाली कोई भी website load नहीं हो रही थी
अच्छे लोगों ने text-only news site बनाई, और आज Buncombe county website पर भी low-bandwidth site दिखी, लेकिन खोलकर देखा तो फिर भी 130KB Bootstrap CSS और 50KB jQuery rendering को block कर रहे थे
लोगों का ऐसा करना बहुत अच्छी बात है, लेकिन citizens को इसकी जरूरत डेढ़ हफ्ते पहले थी। अब तक वे पता लगा चुके हैं कि पानी, खाना, non-potable water वगैरह कहां मिलेगा। इस घटना के दौरान technology को इतनी बुरी तरह fail होते देखना उदास कर देने वाले तरीके से आंखें खोलने वाला अनुभव रहा
power company का outage map login के पीछे छिपा है, और fancy clustering और UI features के साथ render होता है, इसलिए अच्छी connection पर भी पहले से ही धीमा है। इसलिए status check करने या outage report करने में भी काफी समय लगता है
power company को phone भी कर सकते हैं, लेकिन उन्होंने menu keypad tones के बजाय voice navigation से चुना है, और खराब 4G या 2G connection पर distorted voice को यह ठीक से पहचान नहीं पाता
लंबी wavelength और low power की जरूरत है। लेकिन accessibility बहुत कम है, और मुझे ठीक से नहीं पता कि ऐसा किसी उचित कारण से है या नहीं
Black Mountain से लेकर Tennessee और Georgia borders तक connectivity टूट गई थी। मुझे संदेह है कि कितने लोगों को खराब 3G भी वापस मिल पाया होगा। मुझे बस इतना पता है कि वहां रहने वाले लोगों से संपर्क बनाए रखना मुश्किल था
मैंने अपना कुछ बेहतरीन काम unstable hotel Wi‑Fi से जुड़े 12-inch MacBook पर किया है। इसलिए मैं page speed को बहुत गंभीरता से लेता हूं
इस disaster के दर्द को एक वाक्य में कहें तो यह हर तरह से communication breakdown था
“वेब सिर्फ software engineers की चीज़ नहीं है। हम वेब को जितना जटिल बनाते जाते हैं, उतना ही आम users को उन बाड़ों के भीतर धकेलते हैं जिन्हें हम social networks कहते हैं” — इस बात से मैं बहुत सहमत हूँ
इस quote वाले हाल के conference Squiggle Conf से जुड़ा podcast भी है: https://changelog.com/jsparty/339
समय के साथ लोगों की “basic website” से अपेक्षित features बहुत बढ़ गए हैं
programmer होते हुए भी मैं static site generator के जाल में कई बार फँसा हूँ
side project को static site generator से शुरू किया, और जैसे ही कोई छोटा feature जोड़ने का मन हुआ, लगा कि काश बस एक simple Rails या PHP app से शुरू किया होता — यह झुंझलाने वाला है
आजकल अगर मुझे static site चाहिए होती है, तो बस HTML files के folder से शुरू करता हूँ। tools पर बहस करने या टालते रहने के बजाय idea से execution तक का रास्ता कहीं कम जटिल और तेज़ होता है
मैं HTML और CSS सीधे लिखने में काफी संतुष्ट हूँ, लेकिन सबको इसकी सलाह नहीं दूँगा
एक और अच्छी बात यह है कि बाद में Rails में “escape” करने का फैसला भी करें, तो HTML files के folder को Rails के public/ folder में copy कर सकते हैं। upgrade path काफी आसान है
Ruby side में Jekyll सबसे मशहूर है, लेकिन यह Markdown या किसी दूसरे lightweight markup language में blog लिखने वाले खास use case के लिए बना है। दूसरे कामों में जबरन ढाला जा सकता है, लेकिन general-purpose static site generator के तौर पर यह बहुत सुविधाजनक नहीं है
अगर आप कुछ ऐसा चाहते हैं जिसे Rails में copy/paste करना आसान हो, तो Rack-based static site generator middleman अच्छा है। शुरू से ही erb/haml और ActiveSupport के साथ लिख सकते हैं
अगर आप HTML और CSS हाथ से लिखने की simplicity बनाए रखते हुए सिर्फ include, partial templates, link helpers जैसी convenience features चाहते हैं, तो nanoc एक incremental static site generator के रूप में ठीक है। plain HTML/CSS से शुरू करें और जरूरत पड़ने पर ही features जोड़ें
कभी-कभी behavior customize करने के लिए code लिखता हूँ, लेकिन ऐसा कुछ सालों में एक बार ही होता है। simple है और बस अच्छे से काम करता है
dynamic sites की कुछ चीज़ें याद आती हैं, लेकिन simple HTML files का folder किस तरह Pelican से बेहतर है, यह मुझे स्पष्ट नहीं है
website में feature bloat रोकने के लिए मेरा basic rule था कि मैं अपनी desired identity तय करूँ। मैं इसे अपने किए गए कामों का archive रखना चाहता था, और archive है तो उसे समय के साथ बहुत लंबे समय तक टिकना चाहिए। इसलिए static files सही हैं जिन्हें copy करना, mirror करना और किसी भी hosting platform पर चलाना आसान हो
multilingual site को ठीक से set करने में थोड़ा समय लगा, लेकिन कम से कम यह एक बार की cost है
अगर style changes HTML files में hardcoded हों तो वे भी problem बन सकते हैं
ज्यादा advanced काम Django में लिखता हूँ। मेरे लिए features जोड़ना बहुत आसान है
.md→.htmlstep जोड़ने के बारे में सोचा था, लेकिन अभी तक जरूरत नहीं पड़ीlocal server से site आसानी से देख पाना भी अच्छा है। सबसे अच्छा तो यह होगा कि file:// से भी देख सकें, लेकिन structure पूरी तरह solve नहीं कर पाया, इसलिए file-based viewing के लिए अलग copy बनाने वाले
make localstep पर ही खत्म कियाweb developer की personal website में एक चीज़ complexity बढ़ाती है: resume-driven development
कुछ professionals अपने personal side projects को resume-driven development के लिए इस्तेमाल करना चाहते हैं, और सोचते हैं कि ऐसा करने से employer के projects बिगाड़ने की संभावना कम होगी
उदाहरण के लिए, आज सुबह ही एक independent website थी जिसे जल्द publish करना था, और मुख्य रूप से resume reasons से एक popular modern web framework इस्तेमाल किया जा रहा था, लेकिन अब website update नहीं हो पा रही थी
एक NPM package में critical security issue था, और update करने की कोशिश की तो NPM ऐसे mutual dependency conflicts में फँस गया जिन्हें automatically resolve नहीं किया जा सकता था। विडंबना यह है कि इसी वजह से production site पर security update push नहीं कर पाए
उस site के लिए हाथ से लिखी 5 HTML files, थोड़ा inline JS, और 2 छोटे Perl CGI scripts काफी हो सकते थे। तब वह 25 साल बाद भी perfectly काम करती
इसके बजाय सिर्फ NodeJS part में ही 129 NPM packages, बार-बार जरूरी security updates, template fragments और TS config, handlers से बना एक उलझा हुआ source file tree है
लेकिन professionals के पास absurdly complex तरीके से न करने की गुंजाइश नहीं होती। उदाहरण के लिए resume में Perl हो तो employability पर घातक असर पड़ता है। age discrimination के कारण resume न फेंकने वाले लोग भी आपको resume-driven development न करने के लिए मूर्ख समझेंगे
मेरे मामले में resume या proposals में बिल्कुल interest नहीं है, लेकिन फिर भी मैं JS/Python templates से HTML उगलवाने से ज्यादा ergonomic कुछ चाहता हूँ। इसलिए मेरी sites TypeScript, Mithril, Express और कुछ utility libraries का मिश्रण हैं
packages कितने हैं, यह मुझे नहीं पता और परवाह भी नहीं। बस जो चीज़ें import करता हूँ वे mature हों और हर कुछ मिनट में कोई नया feature-vulnerability न पैदा करती हों
आपने stack नहीं बताया, लेकिन लगता है कि यह शायद React और उसका “हमेशा improve हो रहा है लेकिन कभी खत्म नहीं होता” ecosystem होगा। बिना माँगी सलाह दूँ तो false dichotomy पर भरोसा न करना बेहतर है। pure HTML और सबसे खराब कीचड़ के बीच बहुत बड़ा space है, और React world की स्थिति React-specific है, बाहर की दुनिया का प्रतिनिधित्व नहीं करती
WordPress का killer app comments हैं। Static site generators लगभग अपनी परिभाषा से ही comments की अनुमति नहीं देते, लेकिन WordPress blogs में वे लगभग हमेशा built-in होते हैं
अगर Hugo जैसी चीज़ सच में blogging space में लोकप्रिय होना चाहती है, तो बस comments वाला एक अच्छा दिखने वाला theme बनाना होगा। इसे scale पर solve कर दें। उदाहरण के लिए, blog-wise sharded SQLite का इस्तेमाल करके कोई third party इसे बहुत सस्ते में host भी कर सकती है। तब यह एक छोटी सोने के अंडे देने वाली मुर्गी बन जाएगा
Posts पर comments और discussions Reddit, HN, Facebook जैसे third-party communities में होते हैं। Substack post के नीचे comments list खंगालने वालों और उसी post पर HN comments के एक-दो pages पढ़ने वालों में कौन ज्यादा होगा?
अगर लेख tech से जुड़ा है, तो मुझे लगता है HN discussion की quality किसी खास article की comment chain से बेहतर होना लगभग तय है। क्योंकि HN पहले ही कुल blogs के 99.9% से बड़ा readership खींच चुका है
Blog post पर सीधे comment करने का मुख्य फायदा सिर्फ यह है कि author के देखने की संभावना कहीं ज्यादा होती है। HN front page पर कुछ देर के लिए रहना क्षणिक होता है
WordPress ecosystem इसका ठीक उलटा है। यह अरबों डॉलर के businesses का समूह है, जो गहराई से समझते हैं कि CMS और websites चलाने वाले लोगों को अपने-अपने छोटे market niches में क्या चाहिए, और इस market का आकार लगभग 50 करोड़ websites है
इस article का author भले ही smart हो, लेकिन CMS के practical uses के मामले में वह निश्चित रूप से smart नहीं है। “Static HTML sites बेहतर हैं, लेकिन evil companies की वजह से लोकप्रिय नहीं हैं” वाला worldview, अगर आप पैसे लेकर एक-दो websites बना लें, तो लगभग गलत साबित हो जाता है
Static HTML site generators से customer की चाही हुई हर चीज़ कर पाने की संभावना बहुत कम है। WordPress ने बहुत पहले समझ लिया था कि यह market कितना व्यापक और विविध है, और इसलिए उसने plugin support implement किया
मैं 100% सहमत हूं कि comments उन मूल use cases में से एक हैं जिनके लिए web पर static site generator के बजाय CMS जैसी किसी चीज़ का इस्तेमाल होता है। लेकिन इसके अलावा भी लाखों use cases हैं
सिर्फ static HTML documents से आप बहुत दूर नहीं जा सकते। Minimal developer blog से बाहर निकलते ही, असली users और customers जो चाहते हैं उसे करने के लिए बहुत program logic चाहिए। इसलिए जरूरत के हिसाब से CMS इस्तेमाल करें, और ज्यादा traffic सहना हो तो aggressive caching करें। वह भी काम का हिस्सा है
मुझे बिल्कुल समझ नहीं आता कि खुद को बड़ा समझने वाले developers caching कैसे काम करती है यह थोड़ा सीखकर लागू करने के बजाय पहिया फिर से invent करने की कोशिश क्यों करते हैं। क्या यह भी इतनी boring “solved problem” है?
मैं भी Hugo इस्तेमाल करता हूं, लेकिन engineering perspective से footprint अनावश्यक रूप से बड़ा हो तब भी user experience के मामले में WordPress कहीं ज्यादा friendly है
हर business site comments नहीं चाहती, लेकिन शायद contact form जरूर चाहती होगी। Email address public करना भी एक alternative है, लेकिन input pipeline handle करना बेहतर है
Static site में submissions handle करने के लिए भरोसेमंद service ढूंढनी होती है और उसे site से ठीक से जोड़ना होता है। एक और moving part जुड़ जाता है, वह अलग bill बन सकता है, और industry consolidate होने पर handle करने के लिए एक और चीज़ बढ़ जाती है
https://hn.algolia.com/?q=%22disqus%22
Facebook ने भी एक comment system दिया था जिसे कई sites इस्तेमाल करती थीं, लेकिन कई scandals की वजह से उसने trust और reach खो दी
मैं भी उस paradox में फिट बैठता हूं। मैंने अपनी personal website को framework या database के बिना modern PHP में फिर से लिखा
यह ज्यादातर static site है, लेकिन PHP से header जोड़ता हूं और blog posts की list जैसी चीज़ें handle करता हूं। पूरी तरह static न होना थोड़ा ज्यादा convenient लगा। Post लिखता हूं, commit और push करता हूं, और वह तुरंत online आ जाता है। ज्यादातर static site generators मुझे बहुत complex लगे
Single page code लगभग
title = "Blog Article Title";,$this->shortTitle = "Title";,$this->date = mktime(0,0,0,1,27,2024);,if ($this->mode == PageMode::Meta) return;के बाद raw HTML content आने जैसा हैRouter site header और footer अपने आप जोड़ देता है, और किसी folder में
_layout.phpfile जोड़ें तो sub-pages पर layout का एक और level लगाया जा सकता है। Blog list page folder के अंदर individual post files को scan करके index बनाता हैयहां
$this->mode == PageMode::Metaइस्तेमाल होता है। हर file का code execute करके metadata लिया जाता है, और बाकी render करने से पहले बाहर निकल जाता है। Content ज्यादा हो जाए तो scalability अच्छी नहीं होगी, लेकिन अगर समस्या बनी तो adjust कर दूंगामेरे “framework” का पूरा PHP code सिर्फ चार files में है:
init.php,functions.php,Layout.php,Page.phpDeveloper का फायदा यह है कि आप configuration या data के बजाय code लिख सकते हैं। Content को ज्यादा efficiently लिखने के लिए भी code इस्तेमाल कर सकते हैं
Result अभी काफी अधूरा है, लेकिन यहां है: https://www.codaris.com/
include()इस्तेमाल करता हूंवेबसाइट मालिक के नजरिए से user experience के बारे में सोचें तो यह कोई खास paradox नहीं है। WordPress में overhead कहीं ज्यादा होता है, फिर भी वह काम को अविश्वसनीय रूप से आसान बना देता है
यह तभी paradox जैसा लगता है जब इसे समय लगाकर तरह-तरह की settings करने के trade-off के रूप में सोचें। ज्यादातर लोगों के लिए विकल्प यही होता है कि किसी को पैसे देकर वेबसाइट बनवा ली जाए
अगर Hugo के लिए WYSIWYG editor बनाया जाए और domain registration से लेकर site publish करने तक सब कुछ कुछ clicks में पूरा हो जाए, तो इससे अच्छी-खासी कमाई हो सकती है
आपकी बात समझ रहा हूँ। भले ही ये companies कही गई बात के काफी करीब हों, अगर बीच के छोटे-छोटे steps संभाले जा सकें तो यह किसी के लिए बड़ा फायदा होगा
[1] https://micro.blog
“जब SuperHTML को सार्वजनिक किया, तो पता चला कि यह HTML के लिए पहला language server है जो users को diagnostics report करता है। मैंने एक blog post लिखा और वह Hacker News के front page पर आ गया, और किसी ने correction नहीं किया, इसलिए यह सच है” वाला हिस्सा शायद इसलिए है कि Microsoft द्वारा LSP लाने से पहले भी ज्यादातर IDEs कई सालों से यही काम कर रहे थे
Vim, Neovim, Helix, Zed, VSCode—सभी diagnostics support के बिना वही basic implementation share करते थे
Helix अगले release से SuperHTML को default रूप से enable करने वाला है: https://github.com/helix-editor/helix/pull/11609