جاوا اسکریپت واکنشی: تکامل معماری front-end

بهبود تجربه وب سمت مشتری به معنای غلبه بر چالش های «هیدراتاسیون» است، یک مشکل مهندسی جذاب که به طرق مختلف با آن مقابله می شود. شیرجه بزنیم

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

به لطف تعدادی از پروژه های جاوا اسکریپت منبع باز، مانند SvelteKit، Solid، React، Qwik، و Astro، ما جایگاهی در ردیف اول برای تکامل آینده وب داریم. در اینجا راهنمایی برای درک عمل آمده است.

هیدراتاسیون چیست؟

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

جنبه های سطح بالای واکنش پذیری.

پیام اصلی در نمودار این است که فریم ورک مسئول قاب بندی نمای، نگه داشتن حالت و مدیریت تعامل بین آنها است. (اگر با الگوی MVC آشنایی دارید ، در اینجا خواهید شنید.)

هنگامی که این سه قطعه در جای خود قرار گرفتند، می‌توانید بروید. کاربر می تواند صفحه را ببیند و با آن ارتباط برقرار کند.

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

این رویکرد دارای مزیت شگفت انگیز سادگی است، هم برای کد در کار و هم برای ذهن انسان که سعی در درک آن دارد. همچنین یک نقطه ضعف بزرگ دارد: رندر صفحه اولیه باید منتظر همه چیز باشد و کاربر باید تمام آن شبکه و مرورگر را پشت سر بگذارد. همچنین، مگر اینکه دقت شود، صفحه نمایش داده می‌شود و سپس به طرز شرم‌آوری خود را در طرح‌بندی نهایی تغییر می‌دهد. ظاهر خوبی نیست.

این الهام بخش توسعه دهندگان شد تا ابتدا صفحه اولیه را در سرور رندر کنند (رندر سمت سرور یا SSR) و آن را ارسال کنند. سپس، کاربر یک صفحه مناسب برای نگاه کردن دارد در حالی که بقیه کد و وضعیت ارسال شده و بوت استرپ می شود. این یک ساده‌سازی عالی است اما ایده اصلی این است.

زمانی که طول می کشد تا چیدمان اصلی در جای خود قرار گیرد نخستین رنگ محتوا (FCP) نامیده می شود. نقطه عطف بعدی که صفحه باید به آن برسد با time to interactive (TTI) اندازه‌گیری می‌شود، یعنی زمانی که کاربر قادر به استفاده واقعی از صفحه باشد.

فرآیند گرفتن صفحه اولیه و تعاملی کردن آن — که هیدراتاسیون است.

محدودیت های رندر سمت سرور

خط اصلی این است که SSR تمایل به بهبود FCP دارد اما TTI را بدتر می کند. بنابراین هدف ایجاد تعادل بین این دو و در عین حال به حداکثر رساندن هر دو، در حالی که امیدواریم یک تجربه خوشایند توسعه دهنده (DX) حفظ شود، شده است.

روش‌های مختلفی در این تلاش برای بهبود هیدراتاسیون پیشنهاد، اتخاذ، رها، اصلاح و ترکیب شده‌اند. هنگامی که شخص شروع به بررسی جزئیات پیاده سازی می کند، از پیچیده شدن آن شگفت زده می شود. بهبود متعادل FCP و TTI با DX مناسب؟ آسان به نظر می رسد اما اینطور نیست.

یکی از دلایل پیچیدگی این است که ما در وسط مرتب سازی همه معاوضه ها هستیم. این یک صحنه آشکار است با این حال، هنگامی که راه رو به جلو متبلور شد، باید منتظر دو نتیجه از معماری مشتری باشیم که ظاهر می شود. اول، باید برنامه‌های وب ایجاد کند که حس «نسل بعدی» داشته باشند، به همان شیوه‌ای که اپلیکیشن‌های خوش‌ساخت امروزی تجربه بهتری را نسبت به چند سال پیش ارائه می‌دهند.

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

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

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

رویکردهایی برای بهبود هیدراتاسیون

ترفند اساسی برای بهبود وضعیت هیدراتاسیون این است که به مسائل با دقت بیشتری نگاه کنید. با تقسیم نمای، تعامل و حالت به قطعات کوچکتر، می‌توانیم آنها را به‌صورت مرحله‌ای بارگذاری و فعال کنیم، بهینه‌سازی شده برای FCP و TTI. در اینجا یک تور از برخی از رویکردها است.

اجتناب از جاوا اسکریپت به طور کامل

یکی از رویکردهایی که در بهترین عمل جذب شده است، تجزیه و تحلیل سایت‌ها برای آن دسته از صفحاتی است که اصلاً به جاوا اسکریپت نیاز ندارند. این به مفهوم جدیدتر برنامه های چند صفحه ای (MPA) مربوط می شود. این نوعی حد وسط بین برنامه های تک صفحه ای (SPA) و ناوبری مستقیم در هر صفحه (رفتار پیش فرض وب) است. ایده در اینجا یافتن بخش‌هایی از برنامه است که می‌توانند فوراً به‌عنوان دارایی‌های HTML بعلاوه ارسال شوند و در نتیجه بهترین زمان ممکن سئو و بارگذاری را داشته باشند.

رویکرد no-JS برای مثال در SvelteKit دیده می‌شود. البته این برای آن دسته از صفحاتی که نیاز به تعامل واکنشی دارند، کاری انجام نمی دهد. چارچوب‌ها همچنان باید به هیدراتاسیون در صفحاتی که به عنوان SPA عمل می‌کنند بپردازد.

معماری جزیره

Astro از ایده معماری جزیره‌ای دفاع کرده است. ایده این است که تعیین کنیم کدام قسمت‌ها صفحه ثابت هستند و کدام قسمت ها نیاز به واکنش دارند. با این دانش، می‌توانید بارگذاری صفحه را با نادیده گرفتن کامل محتوای کادربندی که هرگز تغییر نمی‌کند، تنظیم کنید و سپس قسمت‌های دیگر (جزایر) را فقط در صورت نیاز بارگیری کنید.

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

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

مرزهای لود شده تنبل

ویژگی‌هایی مانند کامپوننت Suspense React رویکردی را ارائه می‌کند که مدل پایه هیدراتاسیون را در جای خود نگه می‌دارد، اما آن را در امتداد مرزهایی تجزیه می‌کند که سپس بارگذاری تنبلی می‌شوند. این مزیت این است که بسیاری از فرآیندهای آشنا را در جای خود نگه می دارد، اما جنبه منفی آن این است که برای دستیابی به نتایج خوب نیاز به تفکر و تنظیم زیاد از سوی توسعه دهنده است. از نظر ذهنی، توسعه‌دهنده در موقعیتی قرار دارد که دنیای چیدمان اجزا و تقسیم کد در زمان ساخت را پل می‌کند.

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

قابلیت ادامه مجدد

Resumability ایده ای است که توسط چارچوب Qwik معرفی شده است. Qwik عمیق تر در عناصر برنامه فرو می رود و مرزهای تنبلی را در سراسر آنها ایجاد می کند. (به نوعی، می‌توانید آن را به‌عنوان شکل بسیار پیچیده‌ای از محدودیت‌های بارگذاری تنبل ببینید.) Resumability به این معنی است که مشتری می‌تواند از جایی که سرور متوقف شده است ادامه دهد و همه چیز را به روشی دقیق همگام نگه دارد.

اجزای سرور

React در حال ارائه ایده اجزای سرور و بهبود عملکرد مرتبط به نام استریم است. در اینجا توضیحی درباره نحوه عملکرد اجزای سرور آمده است. در اصل، اجزای سرور به شما این امکان را می دهند که تشخیص دهید کدام بخش از برنامه می تواند به طور کامل بر روی سرور اجرا شود، در نتیجه از هرگونه جریمه رندر سمت کلاینت جلوگیری می شود.

در حال پخش

جریان‌گذاری یکی دیگر از تکنیک‌های در حال تکامل React مربوط به Suspense است. ایده در اینجا این است که اجازه دهیم محتوای فریم مانند HTML قبل از اینکه تمام داده‌های مورد نیاز روی سرور آماده شود، به مشتری ارسال شود. سپس می‌توان این را به عنوان تعامل مؤلفه اعمال کرد.

هیدراتاسیون جزئی یا هیدراتاسیون پیشرونده

با این اصطلاحات اوضاع کمی گل آلود می شود. Astro معماری جزیره ای خود را به عنوان هیدراتاسیون جزئی توصیف می کند. به این معناست که در هر زمان فقط عناصر خاصی از صفحه هیدراته می شوند. گاهی اوقات به این هیدراتاسیون پیشرونده نیز گفته می شود. هر دوی این اصطلاحات گاهی اوقات برای تکنیک های دیگر به کار می روند.

ما در اینجا واقعاً سه اصطلاح داریم که روی انگشتان یکدیگر قرار می گیرند: جزایر، جزئی، مترقی. مهم نیست، ایده اصلی یکسان است: ما باید ساختار برنامه را به قطعات کوچکتر تجزیه کنیم تا بتوانیم آن را هوشمندانه تر بارگیری کنیم.

هیدراتاسیون پارتیشن بندی شده؟

بیایید سعی کنیم اصطلاحات را کمی تفکیک کنیم. بیایید بگوییم معماری جزیره به قطعاتی از تعامل مستقل به سبک Astro در یک قاب ایستا اشاره دارد.

با حرکت به سمت بالا، می توانید بگویید که کل ایده تجزیه رابط کاربری هیدراتاسیون جزئی است و جزایر Astro نمونه ای از آن هستند. با این حال، ما نمی‌توانیم این کار را بدون خطر انجام دهیم، زیرا Astro == جزیره == جزئی در حال حاضر در آنجا شناور است. همچنین، به نظر می‌رسد جزئی وضعیت ناقص هیدراتاسیون را نشان می‌دهد که گمراه‌کننده است.

سپس دوباره، پیشرو باعث سردرگمی با برنامه‌های وب پیشرو (PWA) می‌شود. شاید هیدراتاسیون پارتیشن بندی شده اصطلاح خوبی برای ایده کلی باشد.

تکامل معماری جلویی

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

از جمله این افراد رایان کارنیاتو (Solid) و Misko Hevery (Qwik) هستند. هر دو در حال پیشرفت هستند و کد و اطلاعات را در حال انتشار در بقیه جهان هستند. دو مکان خوب برای شروع کار Carnatio اینجا و اینجا، و دو مورد برای Hevery’s اینجا و اینجا.