نقشهٔ راه فرانت‌اند: از HTML تا رابط آمادهٔ تولید

نقشهٔ راه فرانت‌اند اغلب به فهرست ابزارها تبدیل می‌شود: React، Vue، Tailwind، Vite و ده‌ها مورد دیگر. این مقاله ترتیب را از «چه چیزی را باید بتوانم بسازم» شروع می‌کند، نه از «کدام ابزار محبوب است». چارچوب شش‌مرحله‌ای زیر پیشنهاد نویسنده است؛ مستندات MDN، W3C (WCAG)، Playwright و web.dev (خوانده‌شده ۱۹ اکتبر ۲۰۲۶) فقط برای ادعاهای مشخص به‌کار رفته‌اند. زمان قطعی یا وعدهٔ شغلی نمی‌دهیم. برای زمینهٔ محصول آماده تولید نرم‌افزار آمادهٔ تولید و برای انتخاب فناوری انتخاب تکنولوژی را ببینید.

اصل: از تسلط پایه شروع کنید

MDN Learn خودش را منبعی برای مهارت‌های ضروری یک توسعه‌دهندهٔ فرانت‌اند معرفی می‌کند که از روی MDN Curriculum ساخته شده و می‌خواهد خواننده را از «مبتدی» به «راحت» (نه «خبره») برساند؛ ماژول‌های آن سه دسته‌اند: Getting started، Core و Extension. این طرح نشان می‌دهد ترتیب درست یعنی ابتدا مفاهیم پایه (HTML، CSS، JavaScript)، بعد عمق‌دادن. مقالات «Test your skills» و «Challenges» در همان منبع برای سنجش پیشرفت طراحی شده‌اند؛ از آن‌ها به‌عنوان آزمون استفاده کنید نه فقط خواندن.

مرحلهٔ ۱: HTML و CSS معنادار

HTML معنایی، فرم‌ها، لینک‌ها و CSS (مدل جعبه، layout، responsive). پروژه: یک صفحهٔ معرفی شرکت که روی موبایل و دسکتاپ درست دیده شود. مهارت سنجش‌پذیر: بدون فریم‌ورک، layout دو ستونی را که روی موبایل تک‌ستونی می‌شود پیاده کنم و صفحه با کیبورد قابل پیمایش باشد.

مرحلهٔ ۲: JavaScript و کار با داده

تابع، آرایه، DOM، رویداد، fetch و async. پروژه: برنامهٔ فهرست کارها که داده را از یک API ساختگی می‌گیرد، خطا را نمایش می‌دهد و حالت بارگذاری دارد. مهارت: وضعیت بارگذاری، خطا و خالی را برای یک درخواست شبکه به‌طور کامل مدیریت کنم.

مرحلهٔ ۳: یک فریم‌ورک و مدیریت وضعیت

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

مرحلهٔ ۴: دسترس‌پذیری

W3C می‌گوید WCAG 2.2 سیزده راهنما زیر چهار اصل perceivable، operable، understandable و robust دارد و هر راهنما معیارهای موفقیت قابل‌آزمون در سطح A، AA یا AAA دارد؛ مطابقت بر پایهٔ همین معیارها تعیین می‌شود. همچنین W3C تذکر می‌دهد WCAG مقدمهٔ دسترس‌پذیری نیست و برای شروع باید به منابع مقدماتی مراجعه کرد، و استفاده از آخرین نسخه را توصیه می‌کند. هر مرحلهٔ پروژه‌ها را با چند بررسی ساده همراه کنید: ناوبری با کیبورد، متن جایگزین تصویر، برچسب فرم، تضاد رنگ. مهارت: یک صفحه را با کیبورد کامل ناوبری کنم و فهرستی از مشکلات پیدا کنم.

مرحلهٔ ۵: عملکرد و تجربهٔ کاربر

web.dev LCP را زمان رندر بزرگ‌ترین تصویر، بلوک متن یا ویدیوی قابل‌دیدن در viewport نسبت به شروع ناوبری و یکی از معیارهای پایدار Core Web Vitals برای سرعت بارگذاری ادراک‌شده می‌داند. مفهوم را بشناسید و روی پروژهٔ خودتان اندازه بگیرید: چه عنصری LCP است؟ چه چیزی آن را کند می‌کند؟ بدون اندازه‌گیری، بهینه‌سازی حدس است. مهارت: LCP یک صفحه را شناسایی و یک عامل کندی را رفع کنم و اثر را اندازه بگیرم.

مرحلهٔ ۶: تست و استقرار

Playwright Test چارچوب تست end-to-end است که Chromium، WebKit و Firefox را پشتیبانی می‌کند، می‌تواند محلی یا در CI اجرا شود و در نصب گزینهٔ ساخت workflow برای GitHub Actions دارد. یک تست سرتاسری برای مهم‌ترین مسیر (مثلاً ثبت‌نام یا فرم تماس) بنویسید و آن را در CI اجرا کنید. سپس پروژه را روی یک میزبان مستقر کنید. مهارت: با یک دستور تست‌ها را اجرا کنم و استقرار بعد از موفقیت تست خودکار شود.

پروژهٔ نهایی و نمونهٔ کار

یک پروژهٔ واقعی (مثلاً سایت یا اپلیکیشن کوچک برای یک کسب‌وکار فرضی) که مراحل ۱ تا ۶ را شامل شود: صفحهٔ responsive، منطق JS، فریم‌ورک، دسترس‌پذیری، سنجش LCP و تست سرتاسری. مخزن را با README و دستور اجرا بگذارید. پروژهٔ خوب را با «ساخته شد» نمی‌سنجند بلکه با «در دستگاه دیگری هم کار می‌کند، با کیبورد قابل استفاده است و تست دارد».

مثال ساختگی

یادگیرندهٔ فرضی ابتدا یک صفحهٔ معرفی خالص HTML/CSS می‌سازد و با کیبورد آن را می‌پیماید و دو مشکل دسترس‌پذیری پیدا می‌کند. سپس همان صفحه را به یک برنامهٔ فهرست‌کارها با JavaScript و بعد با فریم‌ورک تبدیل می‌کند. در پایان یک تست Playwright برای مسیر اصلی می‌نویسد. این مثال ساختگی است و نشان‌دهنده یک مسیر یادگیری نمونه است نه زمان‌بندی.

اشتباهات رایج

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

چطور بفهمیم مرحله تمام شده

پایان هر مرحله را با آزمون عملی تعیین کنید، نه با تعداد ساعت یا تعداد دوره. برای مرحلهٔ HTML و CSS: صفحه را بدون ابزار آماده بازسازی کنید و روی دو اندازهٔ صفحه آزمایش کنید. برای JavaScript: بدون نگاه‌کردن به راه‌حل، همان برنامه را از نو بنویسید. برای فریم‌ورک: یک ویژگی جدید (مثلاً فیلتر) را بدون کپی‌کردن از آموزش اضافه کنید. برای دسترس‌پذیری: ماوس را کنار بگذارید و کل صفحه را با کیبورد طی کنید؛ هر جا گیر کردید یک مورد برای رفع است. برای عملکرد: عدد LCP را قبل و بعد از یک تغییر ثبت کنید. برای تست: یک تغییر عمدی بشکنید و ببینید تست آن را می‌گیرد.

اگر منبعی مثل MDN آزمون‌های «Test your skills» دارد، از آن‌ها استفاده کنید؛ این آزمون‌ها برای سنجش درک یک مفهوم مجزا طراحی شده‌اند و «Challenges» توانایی ترکیب چند مهارت را می‌سنجند. اما نتیجهٔ نهایی همان پروژه‌ای است که می‌سازید. به یاد داشته باشید که MDN خودش هدف را رساندن به سطح «راحت» می‌داند، نه تسلط کامل؛ پس نگران نباشید اگر پس از مرحلهٔ ۶ هنوز چیزهای زیادی برای یادگیری دارید.

یک رویهٔ مفید: پروژه‌های هر مرحله را در یک مخزن یا پوشهٔ مجزا نگه دارید و در README بنویسید چه مهارتی را نشان می‌دهد و چگونه اجرا می‌شود. این مجموعه، هم راهنمای یادگیری خودتان است و هم مدرک عملی برای کسی که کارتان را می‌بیند، بدون اینکه مدعی تخصصی شوید که هنوز ندارید.

چک‌لیست

1. HTML/CSS/JS پایه با پروژهٔ بدون فریم‌ورک تمرین شده است.
2. هر پروژه حالت بارگذاری، خطا و خالی را دارد.
3. صفحه‌ها با کیبورد و بررسی دسترس‌پذیری آزموده شده‌اند.
4. LCP صفحهٔ اصلی اندازه‌گیری شده است.
5. یک تست سرتاسری در CI اجرا می‌شود.
6. پروژه‌ای با README و دستور اجرا در مخزن هست.

منابع و مراجع

• Learn web development — MDN Web Docs، 2026-10-19.
• WCAG 2 Overview — W3C Web Accessibility Initiative، 2026-10-19.
• Largest Contentful Paint (LCP) — web.dev (Google)، 2026-10-19.
• Installation (Playwright) — Playwright Docs، 2026-10-19.