بیایید به تاریخچه شکل گیری فریمورک های تحت وب نگاه مختصری بیاندازیم.
در ابتدا که وب ایجاد شد، صفحات کاملا استاتیک بودن و به صورت خیلی ساده به هم وصل میشدند. اما مشکل اینجا بود که این ایستا بودن (استاتیک بودن) پاسخگوی نیاز کسب و کارها نبود. اگر میخواستیم چند صفحه عناصر مشترک داشته باشند مجبور بودیم آنها را تکرار کنیم و راهی نداشتیم که داده های دینامیک و پویا را از پایگاه داده گرفته و در صفحات نمایش دهیم.
به همین دلیل در زبان های برنامه نویسی رایج آن زمان، فریمورک هایی ایجاد شدند که قابلیت تولید صفحات دینامیک را به ما بدهند.
بسیاری از شما با این فریمورک ها آشنا هستید. مثلا PHP یا ASP.NET یا Django و غیره.
اما بازار ثابت کرده که همواره سرعت رشد نیازهایش از امکانات موجود بازار بیشتر است.
با گسترش وب سایت ها و دسترسی افراد بیشتر، سرعت مساله مهمی شد.
دیگر اینکه برای باز کردن یک وب سایت چند ثانیه صبر کنیم، و متحمل دانلود چند مگابایت داده شویم، قابل قبول نبود.
اینکه با زدن هر لینک یا دکمه منتظر بمانیم که صفحه به صورت مجدد بارگزاری شود چندان جذاب نبود.
برای حل این مشکلات راه حل هایی ارائه شد. مثلا فشرده سازی منابع لازم مثل اسکریپت ها و استایل ها یا بارگزاری کردن منابع از چند دامنه استاتیک. اما این راه حل ها در افزایش سرعت محدودیت هایی داشتند که چندان به ذائقه بازار خوش نمی آمد.
به همین دلیل زیرساخت هایی جدید تر شکل گرفتند. این زیرساخت ها در مرحله کامپایل کردن، منابعی که استفاده نشده بودند را حذف میکردند (tree shaking). و فایل های مختلف را با هم یکی میکردند (bundling) و با حذف فضای خالی آنها و تغییر نام اجزای سازنده آنها را کوچک میکردند (minification)
و شرایطی را فراهم می آوردند که تمام برنامه در ابتدا درون مرورگر بارگزاری شود، سپس اجرا شود. این باعث میشد که کاربر در تعامل با برنامه، بسیار سریع به صفحات مختلف برود و با فشردن کلید ها و لینک ها برنامه خیلی سریع واکنش نشان دهد، زیرا منابع لازم برای نمایش صفحه بعدی در حال حاضر بارگزاری شده بودند (SPA).
اما این تغییر الگو (paradigm shift) به همراه خود چالش های جدیدی آورد. مهم ترین این چالش ها این بود که موتورهای جستجو به راحتی انسان قابل به درک متحوای سایت های اینچنینی نبودند. به همین دلیل سایت ها و نرم افزارهایی که اینگونه تولید میشدند، اگرچه خیلی از لحاظ سرعت به مذاق کاربر خوش می آمدند، اما از عدم قابلیت بازاریابی در موتورهای جستجو که یکی از کلیدی ترین ستون های موفقیت مالی شرکت هاست، رنج میبردند.
به همین دلیل باز هم با تغییر دیگری مواجه شدیم. اینبار این فریمورک ها مثل فریمورک های قبلی صفحات را ابتدا بر روی سرور render میکردند و سپس این صفحات را به سمت کاربر میفرستادند. این باعث میشد که موتورهای جستجو به راحتی محتوای صفحات را درک کرده و انها را در لیست خود نمایش دهند (index). اما این به معنی عدم قابلیت تعامل کاربر با صفحات بود. صفحات تبدیل شده بودند به عناصری ایستا و صرفا نمایشی.
اگر برای دینامیک کردن آنها جداگانه جاوااسکریپت اضافه میکردیم، عملا به مشکلات گذشته برمیگشتیم. پس چاره کار چه بود؟
چاره کار این بود که این فریمورک ها دو کار را انجام دهند. هم در گام اول صفحات را بر روی سرور render بگیرند و به سمت کاربر بفرستند، هم آنقدر از این صفحات دیتای جانبی بفرستند که بتوانند در سمت کاربر (درون مرورگر) نسخه ای پویا از صفحات مجدد بسازند (virtual DOM).
به این تصمیم که در بسیاری از فریمورک ها گرفته شده بود، hydration گفته می شود.
هیدراسیون به معنی آبیاری است. مثل اینکه یک صفحه وب استاتیک یک زمین خشک و بی آب و علف است، و ما با جاوااسکریپت آن را آبیاری میکنیم (آن را دینامیک میکنیم) تا به باغ یا مزرعه ای سبز تبدیل شود.
اما این مشکل جدیدی را ایجاد کرده بود.
مشکل این بود که هیدراسیون زمان بر بود. صفحات در ابتدا خیلی سریع لود میشدند (SSR یا SSG)، اما وقتی کاربر بر روی دکمه ها کلیک میکرد یا انگشت میزد، واکنشی دریافت نمیکرد.
این عدم دریافت واکنش گاهی تا چندین ثانیه (حتی چند ده ثانیه) طول میکشید. موتورهای جستجو این را نپسندیدند. بنابراین در علائم حیاتی بنیادی صفحات وب (core web vitals) یک شاخص در نظر گرفتند به نام time to interactive یا زمان لازم برای فعال شدن یک صفحه اینترنتی.
فریمورک ها تلاش کردند که این زمان کاهش پیدا کند. اما محدودیت داشتند. پیچیدگی زمانی این کار (time complexity) از جنس O(n) بود. یعنی با افزایش حجم یک صفحه و حجم تعاملات یک صفحه، میزان کد لازم برای اجرا در سمت کاربر بیشتر میشد و به همین ترتیب زمان لازم برای پویا شدن یک صفحه افزایش می یافت.
کاملا مشخص بود که با افزایش نیاز کسب و کارها و افزایش تقاضای کاربران برای تعامل بیشتر با صفحات اینترنتی، این زمان قابل کاهش نبود.
اینجا بود که Qwik وارد صحنه شد.
کوئیک یک فریمورک بود که از همان ابتدا ماموریتش این بود:
با حفظ همه مزایای تمام فریم ورک های گذشته، زمان بر بودن تعامل را از O(n) به O(1) کاهش بدهیم.
کوئیک در زمان بیلد، تمامی کامپوننت های پروژه را بررسی میکند. در این فاز چند موضوع مشخص میشود:
- کدام کامپوننت ها هیچ تعاملی با کاربر ندارند
- کدام کامپوننت ها به هیچ وجه مسیری برای تغییر State ندارند
- کامپوننت هایی که State قابل تغییر دارند (شامل تعامل کاربر) کدامند
سپس تمامی کامپوننت هایی که State قابل تغییر ندارند را به طور کامل در سمت سرور render میگیرد که در این بخش شباهت دار به server components در ری اکت و نکست جی اس.
اما شاهکار کوئیک در بیلد کردن کامپوننت هایی است که قابلیت تغییر دارند. کوئیک کدهای مربوط به قسمت های مختلف این کامپوننت ها را در بسته های بسیار کوچک و مجزا استخراج میکند.
به قول میشکو هِوِری (خالق کوئیک که خالق انگولار هم بود)، کوئیک کد شما را به میلیون ها قسمت ریز تقسیم میکند.
و این تکنیک متفاوت در بیلد، باعث میشود که بتوان بدون نیاز به ارسال همه کدهای مربوط به کلاینت به سمت کاربر، سایت را بارگزاری نمود. در این صورت TTI سایت به طرز چشمگیری کاهش میابد. چون در زمان بارگزاری اولیه، تنها یک اسکریپت کوچک با حجم فشرده کمتر از یک کیلوبایت به سمت کاربر ارسال و در مرورگر اجرا میگردد.
سپس این اسکریپت اولیه که به آن Loader گفته میشود، به تمامی تعاملات کاربر و صفحه مرورگر گوش میدهد. هر گاه کاربر تعاملی را آغاز نماید (مثل فشردن یک دکمه، یا باز کردن یک منو) این Loader متوجه میشود و سریعا قطعه ریز مربوط به آن تعامل را از سمت سرور درخواست میکند.
این اسکریپت ریز به دلیل حجم پایین کد، و به دلیل استفاده از تکنیک prefetching خیلی سریع تر از قابلیت درک بصری کاربر در صفحه بارگزاری و اجرا، و درخواست کاربر برای تعامل با آن عنصر صفحه پاسخ داده میشود.
در واقع میتوان چنین گفت که پویا کردن صفحات اینترنتی در کوئیک در خردترین سطح صورت میگیرد. یعنی به جای اینکه یک اسکریپت حجیم و تمام و کمال در ابتدای بارگزاری صفحه از سمت سرور درخواست و اجرا گردد (مثلا ۲۰۰ کیلوبایت و ۴ ثانیه زمان لازم برای اجرا)، هر قسمت کوچک صفحه که نیاز به تعامل دارد جداگانه لود و اجرا میشود (مثلا ۲ کیلوبایت و ۵۰ میلی ثانیه صرفا برای همین دکمه که کلیک شد).
همین تکنیک ساده و بسیار هنرمندانه، کوئیک را قادر ساخته تا به عنوان اولین فریمورک شناخته شود که جدای از حجم و بزرگی پروژه شما، همواره صفحه ای سریع به کاربر نمایش خواهد داد.
پس با کوئیک چه شما چند تعامل ساده (معادل کمتر از ۵۰ کیلوبایت اسکریپت) و چه هزاران تعامل پیچیده (معادل چند مگابایت اسکریپت) طراحی کنید، سرعت بارگزاری صفحه در مرورگر یکسان خواهد بود.
