The Future Of Frontend Build Tools – Smashing Magazine

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

ابزار ساخت Frontend به دلایل متعددی که تحت تجارب توسعه‌دهنده و کاربر بهبود یافته طبقه‌بندی می‌شوند، برای گردش کار توسعه‌دهنده جلویی مدرن بسیار مهم است. از دیدگاه توسعه‌دهنده، ابزار frontend به ما می‌دهد: توانایی ایجاد ماژول‌ها، سرور توسعه‌دهنده برای توسعه محلی، جایگزینی ماژول داغ (HMR) برای یک حلقه بازخورد کوتاه‌تر در حالت توسعه، توانایی هدف‌گیری مرورگرهای قدیمی با polyfills، پردازش یک میزبان. از انواع فایل جدا از جاوا اسکریپت، لیست ادامه دارد.

در نتیجه، کاربران می‌توانند از برنامه‌های توانمندتر و غنی‌تر لذت ببرند که از طریق تکنیک‌هایی مانند تقسیم کد، کش کردن، واکشی اولیه و سایر تکنیک‌های بهینه‌سازی منابع – با برخی از برنامه‌هایی که حتی قادر به کار آفلاین هستند، عملکرد خود را حفظ می‌کنند.

امروزه ابزار Frontend به قدری به ما می دهد که تصور اینکه زمانی وجود داشت که اصلاً به آن نیازی نداشتیم سخت است. یک سفر به پایین حافظه می تواند به ما کمک کند بفهمیم چگونه به اینجا رسیدیم.

گذشته

قبل از اینکه اپلیکیشن های فرانت اند مانند امروز پیچیده شوند، تمام کاری که جاوا اسکریپت مورد استفاده قرار می گرفت اضافه کردن تعامل اولیه به اسناد HTML ساده بود – شبیه به روشی که Adobe’s Flash استفاده می شد.

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

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

دو راه اصلی برای بارگیری جاوا اسکریپت در مرورگر وجود دارد. یکی با یک تگ اسکریپت است که به یک فایل جاوا اسکریپت ارجاع می دهد، و دیگری این است که جاوا اسکریپت خود را مستقیماً در HTML داخل تگ های اسکریپت بنویسید.

<script src="https://smashingmagazine.com/2022/06/future-frontend-build-tools/my-javascript-file.js"></script>

<script>
    var a = 1;
    var b = 2;

    var result = a + b;
</script>

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

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

حال حاضر

از آنجایی که می‌توانستیم جاوا اسکریپت خود را به فایل‌های مختلف با IIFE تقسیم کنیم، به نظر می‌رسید که تنها چیزی که نیاز داشتیم راهی برای به هم پیوستن این فایل‌ها و ارسال یک فایل به مرورگر بود. این نیاز شاهد ظهور ابزارهایی مانند Gulp، Grunt، Brocolli و غیره بود. با این حال، ما به زودی متوجه شدیم که تفکر ما ممکن است کمی بیش از حد ساده باشد.

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

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

برخی از محدودیت های عمده عبارتند از:

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

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

آینده

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

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

یک Replatform

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

به عنوان یک زبان سطح بالا، جاوا اسکریپت نمی تواند به سطوح عملکرد بومی برسد. این بدان معناست که ابزارهایی که در بالای این پلتفرم ساخته شده‌اند، دارای یک کلاهک در مورد عملکرد آنها هستند. بنابراین، برای رهایی از این محدودیت، ابزارهای ساخت جدیدتری بر روی زبان‌های سطح پایین‌تر و ذاتاً کارآمدتر مانند Rust ساخته می‌شوند.

زبان‌هایی مانند Rust و Go به گزینه‌های محبوبی برای نوشتن نسل بعدی ابزارهای ساخت با تأکید زیادی بر عملکرد تبدیل شده‌اند. Rust، به‌ویژه، نه تنها به دلیل عملکرد، بلکه به دلیل تجربه توسعه‌دهنده چشمگیرش محبوب است – شش سال متوالی به عنوان محبوب‌ترین زبان برنامه‌نویسی انتخاب شد. نظرسنجی توسعه دهندگان سرریز پشته.

در صحبت در مورد تصمیم برای ساخت رم (ابزار ساخت و نه شهر) با Rust، جیمی کایل می گوید:

«بسیاری از افراد دیگر قبل از ما عملکرد، حافظه و مزایای ایمنی Rust را بیان کرده‌اند – بیایید بگوییم همه کسانی که گفته‌اند Rust خوب هستند، درست می‌گویند. با این حال، بزرگترین نگرانی ما بهره وری خودمان بود.
[…]
با این حال، پس از چند نمونه اولیه، ما به سرعت متوجه شدیم که ممکن است در Rust سازنده‌تر باشیم.

– جیمی کایل که در رم در زنگ نوشته خواهد شد

پروژه SWC در خط مقدم این ایده استفاده از Rust برای ابزارهای ساخت frontend است. اکنون پروژه هایی مانند کامپایلر جدید Next.js، Deno، Parcel و دیگران را تقویت می کند – با عملکردی که بسیار بالاتر از سایر ابزارهای ساخت موجود است.

پروژه هایی مانند SWC ثابت می کنند که با تغییر پلت فرم زیربنایی، عملکرد ابزارهای ساخت به طور قابل توجهی بهبود می یابد.

یک تغییر پارادایم

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

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

فرآیند بسته‌بندی هنوز مدتی طول می‌کشد، اگرچه و با رشد پروژه، زمان ساخت (حتی در حال توسعه) تنها و طولانی‌تر می‌شود. آیا عالی نخواهد بود اگر بتوانیم به‌طور کلی از بسته‌بندی صرف نظر کنیم و در عین حال بتوانیم طبق معمول ماژول‌ها را بنویسیم و مرورگر بداند که چگونه با آنها کار کند؟ مجموعه جدیدی از ابزارهای ساخت این رویکرد را در پیش گرفته اند که به نام Unbundled Development شناخته می شود.

توسعه بدون بسته عالی است. این یک مشکل عمده با ابزارهای ساخت موجود را حل می کند: آنها اغلب نیاز دارند تا کل بخش های برنامه شما را حتی برای تغییرات جزئی کد بازسازی کنند، و زمان ساخت با رشد برنامه طولانی تر می شود. ما بازخورد سریع را از دست می دهیم – برای یک تجربه توسعه دلپذیر ضروری است.

ممکن است کسی تعجب کند که اگر توسعه بدون بسته بسیار عالی است، چرا امروزه عادی نیست؟ دو دلیل عمده وجود دارد که چرا توسعه unbundled تنها شروع به جلب توجه می کند: سازگاری مرورگر برای ویژگی های پیشرفته و پردازش واردات ماژول گره.

1. سازگاری مرورگر برای ویژگی های لبه برش

توسعه Unbundled توسط ماژول‌های ES (ESM) ارائه می‌شود، که یک سیستم ماژول استاندارد شده را به جاوا اسکریپت می‌آورد – به‌طور بومی در چندین زمان اجرا، از جمله مرورگر، پشتیبانی می‌شود. با این قابلیت جدید، می توانیم تگ های اسکریپت خود را به عنوان ماژول علامت گذاری کنیم و در نتیجه می توانیم از آن استفاده کنیم import و export کلمات کلیدی که همه ما با آنها آشنا هستیم.

<script type="module" src="https://smashingmagazine.com/2022/06/future-frontend-build-tools/main.js"></script>

<script type="module">
  /** JavaScript module code goes here */
</script>

ماژول‌های ES مدتی است که وجود داشته‌اند. با این حال، ما فقط می‌توانیم از مزایای آن برای مواردی مانند توسعه unbundled استفاده کنیم، بیشتر به دلیل مدت زمانی که استانداردسازی آن در تمام بازیکنان در اکوسیستم وب طول کشیده است.

لین کلارک در مقاله خود در مورد ماژول های ES در مورد هک های موزیلا می گوید:

ماژول‌های ES یک سیستم رسمی و استاندارد ماژول را به جاوا اسکریپت می‌آورند. مدتی طول کشید تا به اینجا رسیدیم – تقریباً 10 سال کار استانداردسازی.

– لین کلارک که در ماژول های ES: شیرجه عمیق کارتونی

موضوع پشتیبانی مرورگر یا عدم وجود آن برای مدت طولانی توسعه frontend را با مشکل مواجه کرده است. به همین دلیل است که ما CSS خود را از فروشنده پیشوند داریم، گاهی اوقات دلیل پلی پرها، چرا ما برای اطمینان از پشتیبانی چند پلتفرمی برای برنامه های وب خود وقت صرف می کنیم، و چرا گاهی اوقات زمان زیادی طول می کشد تا بتوانیم از جدیدترین و بهترین ویژگی های وب استفاده کنیم. در کار روزمره ما

سعی کنید از یک بازدید کنید StackBlitz پروژه با استفاده از Safari، و با صفحه زیر مواجه خواهید شد که عدم پشتیبانی از WebContainers در مرورگرهای غیر مبتنی بر Chromium را نشان می دهد.

سرعت پذیرش ویژگی در ارائه دهندگان مرورگر یکسان نیست، و اغلب در نحوه اجرای برخی ویژگی‌ها توسط فروشندگان مختلف، تغییراتی وجود دارد. با این حال، آینده با ابتکاراتی مانند اینتروپ 2022.

2. پردازش واردات ماژول گره

اکثر، اگر نگوییم همه، برنامه های frontend که امروز می نویسیم به کتابخانه های خارجی NPM وابسته هستند. برای یک برنامه react معمولی، ما React را در بالای فایل های جزء خود وارد می کنیم مانند:

import React from 'react'

/** The rest of your component code */

تلاش برای بارگیری مستقیم این مورد در مرورگر، همانطور که برای توسعه unbundled باید انجام دهیم، به دو مشکل منجر می شود. اول، مرورگر نمی داند که چگونه مسیر پیدا کردن را حل کند react و ثانیاً، کتابخانه react به عنوان یک ماژول مشترک JS (CJS) منتشر می شود – که نمی تواند به صورت بومی در مرورگر بدون پیش پردازش اجرا شود.

مورد دوم در اینجا مسئله بزرگتر است، زیرا ممکن است و حتی پیش پا افتاده است که به سادگی وارد کردن ماژول گره خود را با مسیرهای نسبی به فایل های خاص جایگزین کنیم. با این حال، این واقعیت که اکثر بسته‌های NPM در قالب ماژولی نوشته شده‌اند که برای Node JS مناسب‌تر از مرورگر است، مستلزم این است که وابستگی‌های NPM ما به‌طور ویژه برای تسهیل توسعه unbundled درمان شوند.

کوله برفبه ویژه، با پردازش وابستگی های برنامه به فایل های جاوا اسکریپت مجزا که می توانند مستقیماً در مرورگر استفاده شوند، این کار را انجام می دهد. اطلاعات بیشتر در مورد نحوه انجام این کار Snowpack را می توانید پیدا کنید اینجا.

با توجه به اینکه ماژول‌های ES اکنون در اکثر مرورگرهای مدرن رایج هستند، و راه‌حل‌های هوشمندانه برای وابستگی‌های NPM، ابزارهایی مانند وایت و کوله برف می تواند گزینه توسعه unbundled با عملکرد بسیار بهبود یافته، ساخت های سریع، علاوه بر HMR فوق العاده سریع را ارائه دهد.

افکار نهایی

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

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

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

مطالعه بیشتر در مجله Smashing