दिलचस्प है

वाह, सच में कमाल का प्रोग्राम है। लगता है इसके निर्माता नॉर्वे के हैं। सिर्फ मज़े के लिए ऐसा high-quality प्रोग्राम बनाकर उसे सार्वजनिक कर देना—यह तो सम्मान करने लायक बात है। फिर से महसूस होता है कि दुनिया बहुत बड़ी है और जीनियस लोगों की कमी नहीं। कोरियाई डेवलपर्स भी और मेहनत करें और ऐसा कुछ शानदार बनाकर एक बार सार्वजनिक करें।

उधर भी लोगों की संख्या ही ज़्यादा है, काम-धाम तो यहाँ और वहाँ सब एक जैसा ही है हाहा

यह तो उस परिचित किसी देश की रोज़मर्रा की ज़िंदगी लगती है, जो 'हान' से शुरू होकर 'गुक' पर खत्म होता है।

यह कॉन्सेप्ट अपने-आप में कभी-कभी देखा हुआ था, लेकिन वेब पेज इतना दिलचस्प था और इस तरह अच्छी तरह बनाया गया था कि उसकी खूबियां एक नज़र में आज़माई जा सकें, यह देखकर मैं हैरान रह गया।
नींद-भरे वक्त में यह ऐसा मजेदार अनुभव था जिसने आँखें चमका दीं।

शुरू से ही अगर सिर्फ़ "smoothness" की वजह से SPA पर विचार करने की स्थिति होती, तो मैं वैसे भी बस smoothness छोड़कर MPA में ही लिखता, इसलिए इससे ख़ास सहमति नहीं बनती...

सच कहूँ तो कुछ लोग ऐसे भी थे जिनके पास खास काम नहीं था, फिर भी जबरन पूरा पैसा वसूलने के लिए multi चलाते थे...

आपके दिए गए उदाहरणों में SPA को View Transition वगैरह से प्रतिस्थापित न कर पाने वाला मामला वास्तव में सिर्फ real-time collaboration tool का है, और अधिकांश वेबसाइटें real-time collaboration tool नहीं होतीं। मार्केटिंग साइट, डैशबोर्ड, commerce app—इन सबको SPA framework के बिना भी server rendering, full page, CSS-आधारित animation, जानबूझकर preloading, और न्यूनतम JS अपनाने जैसी शर्तें रखते हुए बनाया जा सकता है। इस दिशा को लक्ष्य बनाने वाला Rails ecosystem का Hotwire भी है, और इसके production उदाहरण के तौर पर Basecamp और HEY भी मौजूद हैं। State management? जब तक वह real-time collaboration tool जैसा कुछ न हो, URL parameter, server session जैसी server-side विधियाँ या local storage ही काफी हैं। Page transition देखकर SPA अपनाने के मामले भी निश्चित रूप से हैं (जैसे AGF की official site; वहाँ Astro से भी पर्याप्त काम चल सकता था, फिर भी React अपनाया गया), और SPA के प्रतिनिधि फायदों में page transition का अक्सर उल्लेख होना इस बात से इनकार नहीं किया जा सकता।

सिर्फ एक smooth interaction के लिए भी SPA framework अपनाने के मामले वाकई मौजूद हैं। लेकिन SPA लागू की गई बहुत-सी साइटों को जटिल interactions की ज़रूरत ही नहीं होती।

हर चीज़ endofunctor नहीं होती। Result<T, E> की तरह जिनमें कई type parameter होते हैं, वे 𝒞 → 𝒞 नहीं होते, बल्कि Result : 𝒞 × 𝒞 → 𝒞 होते हैं, इसलिए ऐसे मामले BiFunctor होते हैं।

बिलकुल सही बात है!
लगता है कि दूसरी भाषाओं में लिखी गई सामग्री को Rust के संदर्भ में लागू करने की प्रक्रिया में गलतफहमी हुई थी।
चूंकि Rust का type system एक single category बनाता है, इसलिए endofunctor और सामान्य functor के बीच का अंतर शायद अर्थहीन हो जाता है।
अफसोस है कि ब्लॉग में comment की सुविधा नहीं है, लेकिन मुझे पूछना पड़ेगा कि क्या इसमें संशोधन का अनुरोध किया जा सकता है।

अच्छा लेख है! हालांकि, endo functor से जुड़ी व्याख्या में एक त्रुटि है, इसलिए अच्छा होगा अगर उसे सुधार दिया जाए https://x.com/simnalamburt/status/1950074970647761168?s=46

king - man + woman = queen

लगता है इसमें वे सारे फीचर हैं जिनके होने की उम्मीद होती है। यह अकेला ही पूरा NAS बन जाता है।

सिर्फ demo साइट देखकर भी यह काफ़ी प्रभावशाली लगता है। बहुत कम कोड में वाकई कई तरह के फ़ीचर सपोर्ट किए गए हैं।

Namuwiki...

उम्र सत्यापन और privacy protection एक साथ कैसे काम कर सकते हैं, यह मुझे ठीक से समझ नहीं आता..

सत्यापन करने के क्षण कम-से-कम एक बार तो वहाँ मेरा signature छोड़ने जैसा ही नहीं है क्या?

अगर सच में privacy protection करनी है, तो उसे anonymous तरीके से इस्तेमाल कर पाना चाहिए

बहुत बढ़िया। मुझे ऐसा दृष्टिकोण बहुत पसंद है।

यह non-ML आधारित optimization methodology वाकई स्वागतयोग्य है।

लगता है कि ये व्यक्ति IDE subscription cost की बात कर रहे हैं। FLCC free version में उपलब्ध नहीं है।
लेकिन लोग सिर्फ उसी की उम्मीद में पैसे नहीं देते।