خب مرسی بابت شرکت در پاسخ این سوال بحث بر انگیز ، بریم که جواب من رو داشته باشیم :
من خودم دو تا راه به ذهنم رسید. یکیش این که در این موقعیت هر بار دوباره یک کانکشن جدید داشته باشیم تا توکن جدید رو در auth پاس بدیم، که خب اصلا منطقی نیست.

دوم اینکه یک فانکشن بنویسم و هر موقع نیاز به emit شد از سمت فرانت ، با اون emit بزنم.
و در payload توکن جدید رو اون گوشه موشه ها جاش بدیم و ارسال کنیم.
‏webSocket هم که بر پایه TCP هست و رمزنگاری هم لازم انجام میشه ، پس فکر نکنم مشکلی پیش بیاد.

من خودم از این روش استفاده کردم و داره کار می‌کنه.

یه چندتا جا در آگهی استخدامی دیدم که اشاره کرده بودن تسلط به معماری ماژولار.
یاد این پستم افتادم .
گفتم بذار یه اشاره ای بهش بکنم بچه هایی که تازه وارد چنل شدن ببیننش.

چقدر این دنیای لامصب سریع داره پیشرفت می‌کنه تا میای با یه چیز انس بگیری یه چیز دیگه میاد.
آنقدر هم دارن ابزار ها زیاد و زیاد میشن که باید با همشون بتونی کار کنی.

درسته که اگه یک سری موارد پایه رو بلد باشی با اکثر اینا میتونی کار کنی ، ولی این سرعت بالای پیشرفت به من حس خوبی نمی‌ده حقیقتا.

بزار رو راست باشم ، حس عقب موندن از قافله رو میده.

من خودم دوست دارم تو یه چیز دیپ بشم ، زمان بذارم ، ولی این دنیا می‌ذاره مگه.
(البته تو ایران که باید همه فن حریف باشی)

بابا لامصبا یکم آروم برید برید جلو جایزه تیتاپ گذاشتن مگه.

اصلا هدف این دنیا رو فراموش کردیم والا
نیومدیم که مسابقه بدیم.

چطور دلتون میاد به بهانه پیشرفت ، اینهمه استرس و فشار کاری رو تحمل کنید که تهش چی؟
همه چیز اتوماسیون بشه بشینی تو خونه چه غلطی کنی 😒

پ.ن:‌ روی صحبتم با این سرعت رشد خیلی بالای تکنولوژیه. نه کسایی که یادش می‌گیرن.

خب دوستان این روش رو پیشنهاد نمیکنم بزنید.
من بعد دو روز فکرم موند پیشش برگشتم یه حرکت دیگه زدم 😂

حالا این رو چرا پیشنهاد نمی‌کنم؟
اولا که هیچ تضمینی نیست تایمر درست کار کنه!
یعنی ممکنه به هر دلیلی این تایمر استاپ بشه و یا یک مدتی فریز بشه و یک سری مشکلات پیش بیاد. بعد کاربر یهو وسط کار می‌بینه سر از صفحه لاگین در اومده.
و اینکه در این صورت ما وقتی این تایمر رو ست می‌کنیم باید مطمین باشیم که این تایمر با اکسس توکن ما یکیه! یعنی دقیقا مطمین باشیم که آقا اکسس توکن مثلا ازش 15 دقیقه مونده، ما از هر 13 دقیقه عوضش می‌کنیم.
که خب نمی‌تونیم این رو مطمین باشیم به چندین دلیل.

پس چه روشی خوبه؟ اینکه به دنبال یک روش استیل و درست درمون باشیم نه اینکه بیام اینطوری سوسکی ردش کنیم 😂
یکی از روش هایی که به ذهنم اومد این بود که برای سوکت یک توکن جدید بسازیم در حین کانکشن. مثلا کاربر متصل میشه ، ما یک توکن 2 یا 3 ساعته می‌سازیم ، و تا زمانی که ارتباط وصله از این استفاده می‌کنیم!
(به نظرم بهترین روش همینه)

روش بعدی که یکم سم هستش و به ذهنم رسید این بود که زحمت تولید این رو هم به خودمون ندیم ، و هنگام ارتباط با سوکت از رفرش توکن استفاده کنیم 😂
قشنگ ماهیت رفرش توکن رو می‌‌بریم سوال ولی توی بعضی پروژه ها جوابه.

می‌خوام راجع به یک موضوع باحال صحبت کنم.

‏Embedding چیست؟🤔

‌‏Embedding در هوش مصنوعی راهی است برای تبدیل داده ها ( مثل عکس ، متن ، صدا ) به یک نمایش عددی. ( یعنی اعداد در داخل یک بردار ) که کامپیوتر بتونه اون رو پردازش و مقایسه کنه.
و این مقایسه مفهومی هستش. یعنی چی؟

مثلا من یک متن دارم به این شکل : "سلام ، امروز تولد دوستمه!" این متن تبدیل میشه به برداری از اعداد . مثلا :

[0.060749103,0.04511056,0.03989463,0.036276204 و ....]

خب حالا این اعداد به چه دردی می‌خورن؟
به درد های فرآواااان.

چندتا از کاربرد هاش رو می‌نویسم و بعد یک توضیح میدم.

‏1-جستوجوی هوشمند
2-پیشنهاد محتوا
3-تشخیص شباهت و خوشه‌بندی
4-ترجمه و پردازش زبان طبیعی
5-شناسایی تصاویر و صدا

مثلا فرض کنیم من درون دیتابیسم کلی مقاله دارم.
یکی از مقاله‌ها عنوانش هست: "بهترین اتوموبیل‌های جهان".
حالا وقتی یک شخص بیاد و در نوار جستجو بنویسه: "بهترین خودروهای جهان"، به نظرتون به نتیجه‌ای می‌رسه؟
خیر. اگر بخواهیم عادی با مقایسه کلمات پیداشون کنیم، پیدا نمیشه.

اما وقتی تایتل مقاله را به برداری از اعداد (embedding) تبدیل کنیم، می‌تونیم نزدیک‌ترین نتایج از نظر معنی و مفهوم را پیدا کنیم. یعنی کامپیوتر می‌تونه بفهمه که "خودرو" و "اتوموبیل" تقریبا همان چیز هستند و نتیجه درست رو بیاره!

حالا چطور نزدیک‌ترین embeddingها پیدا می‌شوند؟

وقتی می‌خواهیم یک embedding را با بقیه مقایسه کنیم، از معیار شباهت برداری استفاده می‌کنیم، مثلا فاصله کسینوسی (Cosine Similarity) یا فاصله اقلیدسی (Euclidean Distance).

این الگوریتم‌ها خیلی سریع میگن: «کدام بردارها به بردار من نزدیک‌ترند؟»

به همین دلیل وقتی کاربر چیزی جستجو می‌کنه سیستم می‌تونه نتایج مرتبط و شبیه به هم را پیدا کنه. حتی اگر کلمات دقیقا یکی نباشند.

(همه این الگوریتم ها هم از قبل نوشته شده و آماده در اختیار ما هستند ، کافیه هر موقع خواستیم از این روش استفاده کنیم ، به سراغشون بریم.)

خب حالا که تا اینجا اومدیم و راجع بهش حرف زدیم، درباره‌ی بردار (Vector) یکم بیشتر بگم.

ما وقتی بخوایم این بردار رو توی دیتابیس ذخیره کنیم، باید یه راه درست انتخاب کنیم. چون بردار در واقع فقط یه لیست عددیه، پس چندتا روش داریم:

1️⃣ ذخیره به صورت JSON یا Array
ساده‌ترین راه اینه که کل بردار رو به شکل JSON بریزیم توی دیتابیس.
مثلاً:

[0.0607, 0.0451, 0.0398, 0.0362]

این روش برای دیتای کم خوبه، ولی برای جستجوهای سنگین خیلی بهینه نیست.

2️⃣ استفاده از ابزار مخصوص در دیتابیس‌ها
مثلاً PostgreSQL یه افزونه داره به اسم pgvector که بردار رو مستقیم به عنوان نوع داده ذخیره می‌کنه.
اینجوری می‌تونیم راحت توی همون دیتابیس روی بردارها جستجوی شباهت انجام بدیم (Cosine, Euclidean و …).

3️⃣ دیتابیس‌های مخصوص برداری (Vector Database)
وقتی دیتا خیلی زیاد باشه (مثلاً میلیون‌ها بردار)، باید بریم سراغ دیتابیس‌هایی مثل Pinecone، Weaviate یا Milvus.
این‌ها دقیقاً برای همین ساخته شدن.
جستجوی خیلی سریع و بهینه روی بردار ها.

من توی پروژه ای که داشتم از pgvector استفاده کردم که یک چالش خیلی کوچیک با typeorm داشت که حلش کردم و اگه دوستان خواستن میتونم شرحش بدم.

دشمن درجه یک ایرانی ها فقط گوگل!
لامصب بعضی از سرویس هات با VPN هم دیگه بالا نمیاد چیکار داری می‌کنی با خودت؟

Calm down bro!

سایت grow.google/career-dreamer ساخته شده توسط گوگل ، با اطلاعاتی که از علاقه و تجربه کاریتون می‌گیره، شغل های مناسب شما رو بهتون پیشنهاد می‌کنه.
نتایجش برای من خیلی جالب بود، پیشنهاد می‌کنم شما هم حتما امتحان کنید 👌

❗️با IP آمریکا وارد بشید.

🔺 برنامه‌نویسی کوانتومی (Quantum Programming)

برنامه‌نویسی کوانتومی بر پایه قوانین مکانیک کوانتوم ساخته شده. به جای بیت‌های کلاسیک (۰ و ۱)، در اینجا با کیوبیت سروکار داریم؛ کیوبیت می‌تونه همزمان در چند حالت باشه (به این می‌گن Superposition) و حتی با کیوبیت‌های دیگه Entanglement پیدا کنه. همین ویژگی‌ها باعث می‌شه بعضی محاسبات خیلی سریع‌تر از کامپیوترهای معمولی انجام بشه.

نکته مهم اینه که برنامه‌های کوانتومی قطعی (Deterministic) نیستن، بلکه احتمالی (Probabilistic) هستن. یعنی خروجی از طریق چندین بار اندازه‌گیری کیوبیت‌ها به‌دست میاد و هر بار بعد از اندازه‌گیری، حالتشون به یک مقدار مشخص فرو می‌ریزه.

🔺 برای نوشتن برنامه‌های کوانتومی، زبان‌ها و فریم‌ورک‌های مخصوصی وجود داره:

- Qiskit (مبتنی بر پایتون)
- Quipper (مبتنی بر Haskell)
- Cirq (از گوگل)

و این برنامه‌ها روی پردازنده‌های کوانتومی مثل IBM Quantum یا Google Sycamore اجرا می‌شن.

تو این دنیا به جای دستورهای کلاسیک، از گیت‌های کوانتومی (مثل Hadamard, CNOT, Pauli-X و...) استفاده می‌کنیم. همین ابزارها پایه‌ی کاربردهای بزرگی مثل رمزنگاری نسل بعدی، بهینه‌سازی، شبیه‌سازی سیستم‌های فیزیکی و شیمیایی هستن. البته تکنولوژی هنوز در مراحل اولیه رشدشه.

🔺 برنامه‌نویسی کوانتومی در خانه: واقعاً ممکنه؟

شرکت BlueQubit این امکان رو فراهم کرده که بدون نیاز به سخت‌افزار عجیب و غریب، بتونید برنامه‌های کوانتومی رو روی کامپیوتر خودتون و حتی روی سخت‌افزار واقعی اجرا کنید.
از طریق پلتفرم ابری BlueQubit می‌تونید: الگوریتم‌های کوانتومی بنویسید. روی شبیه‌سازهای پرسرعت اجراشون کنید. حتی روی پردازنده‌های کوانتومی واقعی تست بگیرید.

محدودیت‌های سخت‌افزاری مثل تعداد کم کیوبیت‌ها یا ناپایداری هنوز وجود دارن، اما BlueQubit به شما کمک می‌کنه همین امروز وارد دنیای کوانتوم بشید، یاد بگیرید و آماده آینده‌ای بشید که کوانتوم داره تبدیل به بخش اصلی محاسبات می‌شه. با این ابزار می‌تونید بدون نیاز به زیرساخت‌های خاص، در خونه یا کسب‌وکار خودتون وارد ماجراجویی کوانتومی بشید.

🔺 زبان‌های برنامه‌نویسی کوانتومی

برای نوشتن الگوریتم‌های کوانتومی، فقط سخت‌افزار کافی نیست؛ به زبان‌های مخصوص هم نیاز داریم. زبان‌های کوانتومی طوری طراحی شدن که بتونن با کیوبیت‌ها، گیت‌های کوانتومی و عمل اندازه‌گیری کار کنن و در عین حال ابستراکشن‌های سطح بالا به برنامه‌نویس بدن.

برخلاف زبان‌های کلاسیک، این زبان‌ها از مفاهیم ویژه کوانتوم مثل Superposition (هم‌زمان بودن در چند حالت)، Entanglement (درهم‌تنیدگی) و Quantum Parallelism (محاسبات موازی کوانتومی) پشتیبانی می‌کنن.

این زبان‌ها به پژوهشگرها و توسعه‌دهنده‌ها کمک می‌کنن برنامه‌های کوانتومی واقعی بنویسن و حتی بتونن اون‌ها رو با کدهای کلاسیک ترکیب کنن. نتیجه این ترکیب، سیستم‌های هیبریدی (کوانتوم + کلاسیک) هستن که فعلاً اصلی‌ترین مسیر توسعه کاربردهای کوانتومی به حساب میان.

https://www.bluequbit.io/quantum-programming-languages

https://learn.microsoft.com/en-us/azure/quantum/qsharp-overview

اینجا quickstart با #Q وجود داره و پیشنهاد میکنم حتمی یک نگاهی بهش بندازید‌:

https://learn.microsoft.com/en-us/azure/quantum/qsharp-quickstart

در رابطه با پستمون درباره Embedding که قبلا نوشته بودم.

حس میکنم محتوای فنی دیگه مخاطب نداره.
و باید مثل بعضی از کانال فقط تو حاشیه باشی.
چون هر بار که محتوای فنی پست میشه، تعداد زیادی از کاربرا لفت میدن.

دقیقا حرف دل من بود که می‌خواستم در این چنل اشاره کنم.
زمانی که محتوای تخصصی تر و مفید تری می‌ذارم ، می‌بینم استقبال خاصی ازش نمیشه و چه بسا که چنل ریزش هم می‌کنه.

ولی خب هدف من از همون ابتدا جذب مخاطب نبوده و سعی می‌کنم مطالب تخصصی تر و بیشتری بذارم.
محتوای چنل هم از همون ابتدا در بایو مشخص شده که حول محور چه خواهد بود.

‏TCP چیست و چطور کار می‌کنه؟


تو دنیای شبکه‌های کامپیوتری، اگه بخوایم داده‌ای رو از دستگاهی به دستگاه دیگه‌ای بفرستیم، نیاز به یه سیستم مطمئن داریم که خیالمون رو راحت کنه.
اینجاست که TCP وارد عمل میشه. این بزرگوار مخفف "Transmission Control Protocol" هست (پروتکل کنترل انتقال) که یکی از مهمترین پروتکل‌های لایه انتقال (Transport Layer) توی مدل OSI و TCP/IP هست. این پروتکل برای انتقال داده بین دو دستگاه (مثلا کلاینت و سرور) طراحی شده و یک سری ویژگی خاص داره که باعث میشه قابل اعتماد، منظم، و کارآمد باشه.

مقاله کامل در :
https://vrgl.ir/V097m

تفاوت هاست، سرور مجازی، اختصاصی و ابری

وقتی می‌خوایم یک وب‌سایت یا اپلیکیشن راه‌اندازی کنیم، مهم‌ترین انتخاب ما نوع زیرساخت میزبانی هست. اینجا ساده و دقیق توضیح می‌دم که هرکدوم چی هستن و چه زمانی استفاده می‌شن:

🔹 هاست اشتراکی (Shared Hosting)
در هاست اشتراکی یک سرور فیزیکی بین صدها وب‌سایت تقسیم می‌شود.
شما کنترل محدودی دارید و منابع (CPU، RAM) بین همه‌ی سایت‌ها مشترک است.

مثال: مثل این است که در یک خوابگاه زندگی می‌کنید. اتاق دارید ولی آشپزخانه و حمام را با بقیه شریک هستید.

مناسب: وب‌سایت‌های ساده مثل وبلاگ، سایت شخصی یا شرکتی کوچک.

🔹 سرور مجازی (VPS – Virtual Private Server)
یک سرور فیزیکی با نرم‌افزار مجازی‌سازی به چند ماشین مجازی تقسیم می‌شود و هر کدام منابع مشخص و جداگانه دارند.

مثال: مثل یک آپارتمان در یک برج. هرکسی واحد خودش را دارد و می‌تواند داخل آن هر طور خواست تغییر بدهد.

مزیت مهم: دسترسی کامل (Root Access)، امکان نصب نرم‌افزار دلخواه، منابع تضمین‌شده.

مناسب: فروشگاه اینترنتی، پروژه‌های نیمه‌حرفه‌ای و استارتاپ‌های کوچک.

🔹 سرور اختصاصی (Dedicated Server)
در این حالت کل سرور فیزیکی فقط برای شماست.

مثال: مثل این است که کل ساختمان مال شماست. هیچ همسایه‌ای ندارید و کنترل کامل دارید.

مزایا: حداکثر قدرت، امنیت و آزادی در پیکربندی.

مناسب: پروژه‌های بسیار بزرگ، اپلیکیشن‌های پرترافیک، سرویس‌های حساس.


🔹 سرور ابری (Cloud Server / Cloud Hosting)
سرور شما روی یک زیرساخت توزیع‌شده (چندین سرور در دیتاسنترهای مختلف) اجرا می‌شود. اگر یک سرور از کار بیفتد، سرور دیگری جایگزین می‌شود و سایت شما همیشه آنلاین می‌ماند.

مثال: مثل این است که به جای داشتن یک خانه، چند خانه در چند شهر دارید؛ اگر یکی خراب شود، سریع می‌روید سراغ بعدی.

مزیت مهم: مقیاس‌پذیری سریع (می‌توانید منابع را در لحظه کم و زیاد کنید)، پایداری بسیار بالا.

مناسب: استارتاپ‌هایی که رشد سریع دارند، اپلیکیشن‌های جهانی و پروژه‌هایی که قطعی نباید داشته باشند.

داشتم به این فکر می‌کردم که این نظرات درون سایت هایی که می‌تونی داخلش راجع به سرویس ها ، شرکت ها و .. امتیاز بدی و نظرت رو بنویسی چقدر معتبرن؟
اگه دقت کرده باشید متوجه میشید که همه شرکت ها و سرویس ها منفی‌اند.

و خب منطقی هم هست نه؟
مثلا اگه من از کیفیت یک اینترنت پروایدر راضی باشم ، نمی‌رم بدو بدو یه سایت پیدا کنم نظرم رو بنویسم بگم عاااالیه 😂

ولی کافیه اذیتم کنه. همه جا ازش شکایت می‌کنم و نظر منفی راجع بهش میدم.

هستن آدم هایی که مخصوصاً برن نظر مثبت بدن؟

همیشه ما همه تلاش داریم کد با Performance خوب توسعه بدیم بدون این که این موضوع رو تصور کنیم که داخل کدبیس های #JavaScript معمولا Performance شوخیه.
ولی امروز قراره درمورد یک ویژگی جدید که در آپدیت ES2025 به #JavaScript اضافه شده صحبت کنیم که بهمون کمک میکنه که Performance بهتری داشته باشیم. سمت #NodeJS در بیزینس لاجیک های پیچیده میتونه معجزه کنه. برای #FrontEnd هم کاربردی هست ولی باتوجه به این که مرورگر های قدیمی ساپورت نمیکنن خب قطعا به این زودی استفاده ازش رو نمیبینیم.
ویژگی جدید ما اضاف شدن یک static method جدید به Iterator هست.

Iterator.from()

حالا سوال پیش میاد که چطور این به ما کمک میکنه. فرض کنید یک array بزرگ دارید و میخواید data رو map کنید به یک شکل دیگه و برای این کار یک pipeline از map ها رو ایجاد کردید:

const data = [1, 2, 3, 4, 5];

const final = data
  .map((item) => item.toString())
  .map((item) => `- ${item} -`)
  .map((item) => `${item} ${new Date()}`);

در نگاه اول مشکلی نداره ولی اگر با عینک Performance ببینیم دوتا مشکل میبینیم.
1. برای هر map مجبوریم یکبار کامل loop بزنیم خب 3 بار loop میزنیم پس داریم O(3n)
2. هربار که یک loop کامل میزنیم هربار داریم یک Array جدید بعد از map ایجاد میکنیم. به صورت خلاصه هر .map برابر هست با یک Array allocation جدید. خب اینجا یک array اورجینال داریم و 3 تا map پس 4 تا array allocation داریم.
ممکنه برای تازه کارترها سوال های زیر پیش بیاد:
1. خب چرا اصلا این استایل کد میزنیم؟
2. چرا همه رو داخل یک map انجام نمیدیم؟

پاسخ سوال اول:
- میتونیم با for ... of کار رو بهتر با یک loop در بیاریم ولی مسئله این هست که معمولا برنامه نویس های #JavaScript در اینجور مواقع حتی بدون این که خودشون بدونن دیدگاه Functional Programming دارن و خب از اونجایی که به صورت فلسفی FP ذات Declarative داره و به صورت فلسفی کار کردن با API ها Declarative خیلی راحت تر و لذت بخش تر از Imperative هست همچین چیزی رو میبینیم.
- اگر هم خیلی کنجکاوید بیشتر بدونید وقتش هست نگاهی به #Elixir #Scala یا حتی Lambda ها در #Java اونجا قشنگ متوجه میشید. یا اصلا مسیر رو برعکس برید و نگاهی به رویکرد #Golang کنید و فرق زمین تا آسمونی رو ببینید.
پاسخ سوال دوم:
- در بزینس لاجیک های پیچیده برای خوانایی کد داشتن map های بیشتر خیلی بهتر از این هست که یک map بزرگ داشته باشیم. منطقی هم هست چون خیلی بهمون God Object ها رو یادآوری میکنه.

خب حالا سوال پیش میاد چیکار کنیم؟ خیلی ساده هست کافیه فقط خط اول رو به این شکل عوض کنیم و array رو تبدیل کنیم به Iterator.

const data = [1, 2, 3, 4, 5, 6]; ❌
const data = Iterator.from([1, 2, 3, 4, 5, 6]); ✅

خب دوباره الان سوال پیش میاد که WTF الان چی شد؟ سادس.
ما دیتا رو تبدیل کردیم به یک Iterator که ذات Iterator ها به صورت Lazy هست یعنی تا وقتی که نیاز به consume شدن data نباشه هیچ پردازشی انجام نمیشه و اگر هم نیاز به map کردن باشه دقیقا در runtime به صورت on-demand برای هر index تبدیل انجام میشه و ما نیازی به alloc کردن حافظه اضافه برای Array نداریم و هیچ loop اضافه ای هم درکار نیست.

حالا به این نکات توجه کنید:
- هر iterator رو فقط یکبار میشه consume کرد و اگر نیاز باشه باید دوباره ازش بسازی. در حقیقت با .toArray داریم consume کردن رو شبیه سازی میکنیم و دومی مقدار خالی به ما میده به خاطر iterator بودن.

const data = Iterator.from([1, 2, 3, 4, 5, 6]);

data.toArray()
data.toArray()

- در این قسمت به map ها باید توجه کرد که با هر بار call شدن یک Array جدید نمیسازن بلکه یک Iterator جدید که روی Iterator قبلی سوار هست رو به ما میده! پس در نتیجه با توجه به تعریف Iterator که بالاتر گفتم نه loop اضافه ای داریم و نه alloc اضافه.

const data = Iterator.from([1, 2, 3, 4, 5, 6]);

const final = data
  .map((item) => item.toString())
  .map((item) => `- ${item} -`)
  .map((item) => `${item} ${new Date()}`);

حالا اگر یکم بیشتر دقت کنی میبینیم خیلی شبیه به stream ها هست. اصلا این دوتا api به شدت باهم سازگار هستن. در این حد که استریم ها رو میشه تبدیل کرد به iterator و برعکس. بقیه کد هم دقیقا به صورت مشابهه کار میکنه.

import { Readable } from "node:stream";
const data = Iterator.from([1, 2, 3, 4, 5, 6]);
const streamData = Readable.from(data);

دل نوشته:
حقیقتا دیگ نمیشه تفاوت بین stream, iterator, generator, rxjs, web stream, رو تشخیص داد😂. همشون رو میتونی جایگزین هم استفاده کنی. ( دلایل مختلفی برای وجود این همه api برای یک کار هست )

🧠 تفاوت SSR و CSR و تأثیرش روی سئو

توی CSR (Client Side Rendering)، سرور یه فایل HTML ساده (معمولاً خالی) می‌فرسته. مرورگر بعدش باید کلی فایل JavaScript رو دانلود و اجرا کنه تا محتوای صفحه ساخته بشه. این یعنی محتوای واقعی دیرتر به دست ربات‌های موتور جستجو می‌رسه و ممکنه ایندکس شدن صفحه عقب بیفته.

ولی توی SSR (Server Side Rendering)، سرور همون اول محتوای صفحه رو رندر می‌کنه و یه HTML کامل می‌فرسته.
در این صورت:

محتوای صفحه همون اول تو پاسخ رندر میشه.

ربات جستجو لازم نیست صبر کنه تا JS اجرا بشه، همون اول محتوا رو می‌خونه.

ایندکس شدن و رتبه گرفتن سریع‌تر انجام می‌شه.


نمونه تکنولوژی‌ها و فریم‌ورک‌هایی که SSR دارن:

‏ Next.js برای React

‏ Nuxt.js برای Vue

‏ Angular Universal برای Angular

‏ Sapper / SvelteKit برای Svelte

به همین دلیله که SSR برای سایت‌هایی مثل فروشگاه، بلاگ یا هر جایی که محتوای عمومی داره و می‌خوایم تو گوگل دیده بشه خیلی به درد می‌خوره. ولی برای اپلیکیشن‌های داخلی یا داشبوردها که ایندکس شدن مهم نیست، همون CSR کافی هست.

یه جاهایی دیدم بعضی از دوستان سر اینکه از چه لایبرری برای UI پروژه استفاده کنند خوبه بحث می‌کردن.

موردی که هست اینه که اگه شما پروژتون UI داره و دارین طبق اون پیش میرین ، اصلا منطقی نیست از هیچ لایبرری استفاده کنین! و خودتون باید کامپوننت هاش رو بنویسین.

مگر اینکه UI پروژه طبق همون لایبرری طراحی شده باشه.

وگرنه از نظر من کاستومایز کردن کامپوننت های یک لایبرری برای یک UI اختصاصی نه تنها منطقی نیست ، بله غیر حرفه ای هم هست.