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

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

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

इस लेख की कमी यह है कि

1. SPA के असली उद्देश्य की संकीर्ण व्याख्या की गई है
   View Transitions API वाकई शानदार है, लेकिन केवल उससे SPA की ज़रूरत खत्म नहीं हो जाती।

2. सभी वेबसाइटों को एक ही मानदंड से देखा गया है
   मार्केटिंग साइट ≠ डैशबोर्ड ≠ कॉमर्स ऐप ≠ रियल-टाइम collaboration tool
   इन सभी की संरचनात्मक ज़रूरतें अलग होती हैं।

3. वास्तविक उपयोग में SPA + SSR + MPA साथ-साथ मौजूद हैं
   Next.js जैसे hybrid framework इसे अच्छी तरह दिखाते हैं।
   स्टैटिक assets के लिए SSG, लॉगिन के बाद डैश के लिए CSR/SPA, search engine के लिए SSR जैसे लचीले संयोजन की ज़रूरत होती है।

मेरा मानना है कि SPA केवल user experience ही नहीं, बल्कि structural improvement का भी परिणाम है।
जिन पेजों में SPA की ज़रूरत नहीं है, वहाँ MPA + modern CSS एक अच्छा विकल्प हो सकता है, लेकिन संरचना, state, scalability और maintenance के लिहाज़ से SPA अब भी ज़रूरी है। मेरा मानना है कि modern CSS, SPA को "पूरक" कर सकता है, लेकिन "प्रतिस्थापित" नहीं कर सकता।

सच कहूँ तो, यह वैसा ही लगता है जैसे Rust या Haskell को छुए बिना ही कहना, 'उसकी ज़रूरत नहीं, आजकल C++ से सब हो जाता है।'

मौजूदा SPA frameworks और उन पर आधारित frontend trends के बारे में यह सच है कि उन्हें लगातार non-standardization से सावधान रहने की ज़रूरत है, और वे over-engineering तथा अनावश्यक resource consumption को बढ़ावा देने में भी आसान हो सकते हैं, लेकिन…

SPA की अवधारणा को भी बहुत संकुचित तरीके से देखा जा रहा है, लेकिन उससे भी बढ़कर मुझे संदेह है कि लोग यह समझते हैं या नहीं कि SPA frameworks पूरे development पर किस तरह का प्रभाव डालते हैं।

यह कहना कि सिर्फ View Transition API और CSS से सब कुछ हो जाएगा, दूसरे शब्दों में यह कहने जैसा है कि उससे असंबंधित बाकी सभी features, और उन्हें हासिल करने के paradigms, सब पूरी तरह निरर्थक हैं — मुझे यह कुछ ज़्यादा ही अहंकारी दृष्टिकोण लगता है.

यह उस over-engineering से अलग मुद्दा है जो brochure की जगह लेने भर वाली site को React से बनाने पर होता है।

मैं इस बात से सहमत हूँ कि ज़्यादातर छोटे projects में बेवजह SPA framework की ज़रूरत नहीं होती, लेकिन जिन services में complex interaction, continuous user experience, और उसके अनुरूप maintenance तथा निरंतर improvement की requirements होती हैं, वहाँ CSS के विकास के बावजूद ऐसा नहीं मानता।

Vector search पर काम करते हुए जिन बातों पर सोचा गया है, वे काफ़ी दिलचस्प हैं।

जहाँ तक मुझे पता है, Kotlin में इसका इस्तेमाल करने पर primitive को wrapper में लपेटना पड़ सकता है, जिससे वह stack की बजाय heap में store होता है और performance issue हो सकता है। बेशक, ज़्यादातर use case में maintainability को प्राथमिकता दी जाती है। साथ ही, value class का उपयोग करके performance समस्या को न्यूनतम किया जा सकता है।

संदर्भ के लिए rust सपोर्ट टिकट: https://github.com/android/ndk/issues/1742

उम्मीद है कि C++ में भी ऐसा कुछ आएगा!

हम्म, पता नहीं। क्या SPA framework इस्तेमाल करने का मकसद smooth transition से ज़्यादा user के साथ complex interaction के लिए नहीं होता?

यह लोकल पर चलता है, इसलिए शायद किसी शुल्क की ज़रूरत नहीं होगी।

उसके लिए हर महीने $20 ~ $200 खर्च करना थोड़ा ज़्यादा है…

इस बीच Pass:

हम्म...^^;;; मुझसे गलती हो गई.. अगली बार थोड़ा और रिव्यू करके पोस्ट करूंगा..

LLM में कमियाँ नहीं हैं ऐसा तो नहीं है, लेकिन यह मानना मुश्किल लगता है कि सभी AI services लाभदायक नहीं हैं। मुझे लगता है कि आने वाले 5 सालों में मौजूदा लगभग सभी platform services का ज़्यादातर हिस्सा AI agents से replace हो जाएगा।

क्या मैं इस सारांश को PDF सारांश रिपोर्ट फ़ॉर्मैट (सारांश रूपरेखा-परिचय-मुख्य भाग-निष्कर्ष) में अलग दस्तावेज़ के रूप में भी तैयार कर दूँ?

क्योंकि यह लिखने वाले आम तौर पर भी बहुत पोस्ट करते हैं, लगता है इसे जानबूझकर डाला गया है lol
काफ़ी दिलचस्प लेख था। पहले खुद दिमाग लगाकर देखना और फिर llm का इस्तेमाल करना बेहतर रहेगा।

लगता है कि accuracy और ownership की भावना कम होना सच था।

सारांश तक भी llm..

समझ गया, धन्यवाद