مقایسه فریمورک‌های جاوااسکریپت در کدنویسی با هوش مصنوعی؛ ابزارهای سبک و سرورمحور برنده شدند

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

نولان لاسن (Nolan Lawson)، توسعه‌دهنده شرکت امنیت هوش مصنوعی Socket، در یادداشتی می‌نویسد: «یکی از دغدغه‌های اصلی من در جامعه توسعه وب این است که بسیاری از تصمیمات ما صرفاً بر اساس حس و حال شخصی گرفته می‌شوند.» این موضوع واقعیت دارد؛ جنگ میان فریمورک‌های جاوااسکریپت بیش از یک دهه است که با شدت ادامه دارد و هر فریمورک تازه وعده می‌دهد که کاستی‌های ابزارهای نسل قبل را برطرف کند.

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

نتایج این بنچمارک حاوی نکات آموزنده‌ای است. به‌طور کلی، ایجنت‌های هوش مصنوعی با فریمورک‌های سرورمحور بازدهی بسیار بالاتری نشان می‌دهند تا فریمورک‌های سنگین «برنامه تک‌صفحه‌ای» یا همان SPA در سمت کلاینت؛ موضوعی که احتمالاً برای منتقدان React جالب‌توجه خواهد بود.

اما مهم‌ترین نتیجه این آزمون پیامی شفاف دارد: ایجنت‌های هوش مصنوعی بیشترین بهره‌وری را از فریمورک‌هایی به دست می‌آورند که از ساختارهای استاندارد، ثبات در رابط برنامه‌نویسی (API) و اختصار در کدنویسی بهره می‌برند.

نحوه مقایسه فریمورک‌های جاوااسکریپت

لاسن در این آزمایش، مجموعه‌ای از دستورالعمل‌ها را برای ابزار Claude Code تدوین کرد تا یک وب‌اپلیکیشن پایه برای پوکمون با استفاده از رابط برنامه‌نویسی PokéAPI بسازد. این مدل از دستوراتی کاملاً یکسان در ۱۲ فریمورک و پشته مختلف جاوااسکریپت استفاده کرد: Angular، Astro، Gracile همراه با Lit، ترکیب Hono و htmx، جاوااسکریپت خالص همراه با Vite، Next.js، Nuxt، Qwik، React Router، TanStack Start، SolidStart و SvelteKit.

لاسن هر یک از این پشته‌ها را در پنج دور مستقل در محیط سندباکس مورد ارزیابی قرار داد؛ تکرار چندباره این آزمون‌ها باعث شد نوسانات احتمالی در عملکرد مدل تعدیل شده و نتایج دقیقی حاصل شود.

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

چنانچه فریمورک‌ها دارای سرورهای رسمی پروتکل زمینه مدل (MCP)، پلاگین‌های Claude یا فایل‌های مهارت ایجنت بودند، لاسن آن‌ها را به‌عنوان منابع کمکی در اختیار ایجنت قرار می‌داد؛ اگرچه مدل همواره به آن‌ها رجوع نمی‌کرد. به جز این مورد، او هیچ معماری خاصی را برای رندر برنامه به ایجنت تحمیل نکرد.

مقایسه عملکرد ۱۲ فریمورک جاوااسکریپت

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

اگر به دنبال ساخت یک برنامه با کمترین هزینه هستید، مناسب‌ترین انتخاب ترکیب فریمورک Hono با htmx است. این زوج فناوری اقتصادی‌ترین فرایند اجرا را رقم زدند و میانگین هزینه توسعه هر برنامه با آن‌ها تنها ۲٫۶۷ دلار شد.

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

فریمورک Astro با هزینه ۲٫۷۶ دلار عملکردی بسیار نزدیک به صدرنشین ثبت کرد. فریمورک Astro نیز مانند ترکیب Hono و htmx، پردازش‌ها را به‌شکل سمت سرور انجام می‌دهد. پردازش اطلاعات در سرور هم‌چنین به Astro کمک کرد تا با ثبت زمان ۸٫۲ دقیقه، سریع‌ترین میانگین زمان ساخت و آزمایش برنامه را از آن خود کند.

فریمورک Nuxt با هزینه ۲٫۸۲ دلار، اقتصادی‌ترین گزینه برای رویکردهای مشابه برنامه‌های تک‌صفحه‌ای بود. این فریمورک کدها را در سرور رندر می‌کند و سپس آن‌ها را در سمت کلاینت فعال می‌سازد. فریمورک Nuxt بر پایه Vue.js بنا شده، اما ساختار چارچوب‌مند و مشخصی دارد که حجم زیادی از کدهای تکراری و پیش‌نیاز را که ایجنت باید بنویسد، حذف می‌کند. هم‌چنین Nuxt انتقال داده‌ها و مسیریابی فایل‌ها را به‌صورت درونی مدیریت می‌کند که نیاز به کدنویسی اضافی را برطرف می‌سازد.

نکته شایان توجه این است که Nuxt با مصرف ۳٫۸۵ میلیون توکن، کمترین میزان توکن مصرفی را در میان تمام گزینه‌ها به نام خود ثبت کرد؛ هرچند به‌دلیل تفاوت نرخ محاسبه توکن‌های ورودی و خروجی در Claude، این موضوع آن را به ارزان‌ترین گزینه تبدیل نکرد. فریمورک Nuxt برنامه مورد نظر را در ۱٬۴۱۵ خط کد ایجاد کرد که پس از ترکیب Hono و htmx با ۱٬۳۷۰ خط، در رتبه دوم قرار گرفت.

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

با این حال، برخی از فریمورک‌های سنتی‌تر عملکرد بسیار ضعیف‌تری ثبت کردند و با فاصله زیادی عقب ماندند.

توسعه برنامه با فریمورک SvelteKit حدود ۴٫۲۸ دلار هزینه در بر داشت؛ چراکه ایجنت هوش مصنوعی برای تسلط بر شیوه کار نسخه به‌روزرسانی‌شده Svelte بارها به مستندات آن مراجعه کرد. فریمورک Angular نیز گران‌ترین گزینه برای ساخت برنامه توسط ایجنت بود که ۴٫۹۷ دلار هزینه به‌همراه داشت، ۱۷٫۲ دقیقه به طول انجامید و ۹٫۷۶ میلیون توکن مصرف کرد؛ جالب آنکه ایجنت در دو بار از پنج تلاش خود حتی نتوانست یک برنامه کاربردی را با Angular کامل کند.

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

برنامه ساخته‌شده با Astro با ثبت زمان بارگذاری ۸۱۰ میلی‌ثانیه برای شاخص مهم LCP سریع‌ترین سرعت لود را ارائه داد؛ در حالی که کندترین فریمورک‌های این گروه، یعنی Next.js با ۲٬۰۹۰ میلی‌ثانیه و TanStack Start با ۲٬۰۲۸ میلی‌ثانیه، بیش از دو برابر زمان بردند تا خروجی نهایی را نمایش دهند که احتمالاً به حجم کدهای جاوااسکریپت ارسال‌شده به سمت مرورگر مربوط می‌شود.

درس‌هایی برای توسعه آینده با هوش مصنوعی

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

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

یکی از برنامه‌نویسان در این زمینه نوشت: «پس از یک دهه کار با React، حاضر نیستم برای یک پروژه جدید سراغ یاد‌گیری htmx یا ابزارهای مشابه با مزایای جزئی بروم؛ مخصوصاً وقتی که این کار توانایی من را در بازبینی و خطایابی کدهای نوشته‌شده کاهش می‌دهد.»

در نهایت، ممکن است خود این فریمورک‌ها نیز با کمک هوش مصنوعی پیشرفت کنند و فاصله‌ها به‌مرور زمان کمتر شود. همان‌طور که یکی دیگر از توسعه‌دهندگان بیان کرد: «به جز بازنویسی پروژه در فریمورکی دیگر به کمک هوش مصنوعی، گزینه دیگر این است که خود فریمورک موجود را با تکیه بر هوش مصنوعی مدرن‌سازی کنیم.»