هزینه هوش مصنوعی چارچوب های جاوا اسکریپت

یکی از نگرانی‌های حیوان خانگی من با جامعه توسعه وب این است که بسیاری از تصمیم‌هایی که می‌گیریم مبتنی بر ویبر هستند. فریم‌ورک‌ها «سریع هستند»، ابزارها توسعه‌تان را «شارژ فوق‌العاده» می‌کنند، انتزاع درست هم به نفع شما و هم برای کاربرانتان خواهد بود (DX و UX همه در یک!). همه این لاف زدن های نفس گیر معمولا با هیچ مدرکی ارائه می شود. الکس راسل این را «دهه گمشده فرانتند» نامیده است، بالدور بیارناسون برنامه‌نویسی را فرهنگ پاپ نامیده است، و من سعی کرده‌ام با این روند در وبلاگم با حقایق و معیارها مقابله کنم (به هر حال در بهترین حالت ممکن).

برای مدت طولانی به نظر می رسید که حساسیت جامعه ما به شواهد ناشی از تمایل به DX بیشتر است. به عبارت دیگر، توسعه‌دهندگان از نوع تایپ JSX در React خوششان می‌آمد، و استدلال‌هایی که React یا ابزارهای مرتبط را ترویج می‌کردند («DOM مجازی سریع است!») تا حد زیادی منطقی‌سازی‌های پس‌هک برای توجیه آن احساسات اولیه بودند. (جاناتان هایت احتمالا با این ارزیابی موافق است.)

اما در عصر نمایندگی، زمانی که توسعه‌دهندگان دیگر کد را با دست تایپ نمی‌کنند و بنابراین کمتر توسط DX محدود می‌شوند، من هنوز هم می‌بینم که vibes بر آن روز حاکم است (و نه فقط به معنای «کدگذاری vibe»). فرانت‌اندها بازنویسی می‌شوند، زیرا برخی از چارچوب‌ها برای نمایندگان بهتر است. (آیا کسی فکر کرد از نمایندگان بپرسد؟) کد به دست آمده "سریعتر" است، ماموران "اشتباهات کمتری" می کنند و غیره. بار دیگر، این ادعاها اغلب بدون مدرک مطرح می شوند. هر زمان که یکی از این حساب ها را می خوانم، با خودم فکر می کنم، "معیارها کجا هستند؟"

خب من کنجکاو شدم، بنابراین یک معیار نوشتم. ساختار این معیار بسیار ساده است:

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

باید با چند نکته شروع کنم: این یک آزمایش کامل نیست. این برنامه تنها یک نوع هولوتایپ را نشان می‌دهد – این یک سایت نسبتا مبتنی بر محتوا با تعامل کمی است، به ویکی‌پدیا نزدیک‌تر از Figma، GMail و غیره است. با این حال، من مجبور شدم برنامه‌ای را برای ساختن انتخاب کنم، و این یکی حداقل درک آن در سطح بالا آسان است، و مشخص کردن و آزمایش آن نسبتا ساده است.

برای تلاش برای یکنواخت کردن زمین بازی، هر فریم ورک/متا فریمورک از MCP رسمی یا مهارت‌های آن ابزار استفاده می‌کردم. من می‌خواستم از اتهاماتی مبنی بر اینکه «این چارچوب در داده‌های آموزشی به خوبی نمایش داده نمی‌شود، به همین دلیل MCP خود را ساخته‌ایم، انتظار داریم مردم از آن استفاده کنند» اجتناب کنم. همچنین معماری دقیق مورد استفاده را بیش از حد مشخص نکردم (به عنوان مثال SSR در مقابل CSR)، و همچنین مشخص نکردم که برنامه باید تا حد امکان کارآمد باشد. من به سادگی با تلاش زیاد مشخصات را به Opus 5.5 دادم و گفتم از آخرین نسخه فریمورک داده شده استفاده کند.

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

توجه داشته باشید که من هیچ متدولوژی CSS را اجباری نکردم، به جز اجتناب از استفاده از Tailwind، Bootstrap، یا هر فریم ورک جزء دیگر، و طراحی بر اساس مجموعه‌ای از توکن‌های مشخصات برای اعمال یکپارچگی بصری. من نمی‌خواستم این آزمایش را تماما در مورد CSS انجام دهم، اما در عوض در مورد چارچوب‌های JS، CSR در مقابل SSR، SPAs در مقابل MPA، و غیره. برنامه به‌دست‌آمده بر اساس یک مجموعه انطباق بر اساس درخت دسترس‌پذیری به جای DOM خام آزمایش می‌شود تا از اجبار هر ساختار HTML خاصی جلوگیری شود - یک چارچوب از مؤلفه‌های وب استفاده می‌کند که به DOM سایه‌ای وابسته است.

چیزی که از این آزمایش آموختم این است که همه چیزهایی که اندازه می‌گیرم بسیار تصادفی است. LLM ها تولید کننده کلمات تصادفی هستند، بنابراین گاهی اوقات شما یک تاس کم می خورید و یک عامل بدون تقصیر چارچوب یا ابزارهای آن، با یک تانژانت عجیب و غریب به هدر دادن دسته ای از نشانه ها می پردازد. خود لایت‌هاوس نیز می‌تواند نتایج متناقضی بدهد: Largest Contentful Paint (LCP) ممکن است تصمیم بگیرد که یک تصویر «بزرگ‌ترین» عنصر است، سپس تصویر دیگری را در اجرای بعدی انتخاب کند. داشتن یک آزمایش کاملا منصفانه دشوار است، اما اجرای چندین تکرار کمک کرد، و من سعی کردم در مورد واریانس صادق باشم.

با تمام این مشکلاتی که در راه است، بیایید به نتایج برسیم.

من قصد دارم این را با ابعاد مختلف تقسیم کنم: هزینه ساخت، کیفیت و قابلیت نگهداری. برای هر فریم ورک/متا فریم ورک، میانه 5 اجرا را گرفتم: به عبارت دیگر، همان برنامه را 5 بار در یک فریمورک ساختم. (بله، این همان چیز مسخره ای است که این روزها می توانید با عوامل برنامه نویسی انجام دهید.)

استثنا Angular بود که دو بار نتوانست یک برنامه کاربردی ایجاد کند، بنابراین من به جای آن 3 بار تکرار کردم. (در زیر توضیح داده شده است.)

واضح تر از همه، SvelteKit، Gracile+Lit و Angular نسبت به سایر فریم ورک ها گران تر هستند. برای SvelteKit، این ممکن است به این دلیل باشد که عامل ها راهنمای مهاجرت SvelteKit v3 را در هر اجرا می خوانند، احتمالا به این دلیل که برای قرار گرفتن در داده های آموزشی Opus 5.5 بسیار جدید است. به طور مشابه برای Gracile، عوامل به خوبی چارچوب را نمی‌شناختند و یا مخزن Gracile را شبیه‌سازی کردند یا منبع کامپایل‌شده آن را از node_modules مطالعه کردند. برای Angular به نظر می رسد که تابعی از اندازه کل کد باشد (به زیر مراجعه کنید).

همچنین باید اشاره کنم که نه هر عاملی از پلاگین MCP/skill/Claude Code استفاده کرده است و نه هر فریم ورکی یکی از این افزونه ها را دارد:

به عنوان مثال، عامل TanStack Start فقط فایل های مهارت خود را در 2/5 اجرا کشف کرد (آنها در node_modules پروژه ارسال می شوند). برای Nuxt، MCP هرگز توسط عوامل استفاده نشد. برای Next.js، عوامل فقط فایل مهارت را در 1/5 اجرا و AGENTS.md را در 2/5 اجرا می‌خوانند. این طیف وسیعی از نتایج است که به ماهیت تصادفی LLM ها اشاره دارد. با این حال، من هنوز این را یک آزمایش معتبر می‌دانم، زیرا شک دارم که بسیاری از کدنویس‌های vibe با تمام حروف به نمایندگان خود فریاد می‌زنند تا از MCP استفاده کنند (و احتمالا بسیاری از آنها کاملا از آن صرفنظر می‌کنند).

همچنین، اگر تعجب می‌کنید که چگونه Hono+htmx را پیدا کردم: اساسا می‌خواستم htmx به نحوی نمایش داده شود، و Hono یک جفت خوب به نظر می‌رسید (یعنی به عنوان جایگزین جاوا اسکریپت برای Rails/Django/و غیره). در مورد Gracile+Lit، من می‌خواستم کامپوننت‌های وب از طریق چارچوب استاندارد (Lit) نمایش داده شوند و فقط از Gracile به عنوان یک متا چارچوب آگاه بودم. اگر نامزدهای بهتری وجود داشته باشد، آن‌ها برای یک آزمایش بعدی عالی خواهند بود.

برای "Vanilla"، توجه داشته باشید که به عامل گفته شده است که از "vanilla JavaScript یا TypeScript با Vite، بدون چارچوب UI استفاده کند." به‌طور شگفت‌انگیزی، این چند فریم‌ورک عملکرد ضعیفی دارد، که به نظر می‌رسد نشان می‌دهد که داشتن برخی چارچوب‌ها می‌تواند بهتر از هیچ باشد (یا به هر حال بهتر از Vite خام). Vite به این دلیل انتخاب شد که دارای چارچوب های زیادی است و زیرساخت جاوا اسکریپت نسبتا استاندارد و آگنوستیک را نشان می دهد.

کل زمان و نشانه‌ها با هزینه بسیار نزدیک است:

ساعت دیواری دقیقه از دید نماینده میانه 3-5 ران.

کش می خواند، ورودی و خروجی ذخیره نشده. میانه 3-5 ران.

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

البته، چون فکر می‌کنم نتایج مهم هستند، عوامل را با Lighthouse هم تست کردم. به‌عنوان توسعه‌دهندگان نرم‌افزار، من فکر می‌کنم مهم است که ما نه تنها چیزها را ارزان بسازیم، بلکه با عملکرد و در دسترس بودن هم بسازیم.

ابتدا باید به دو نکته در مورد معیارم توجه کنم:

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

به طور خلاصه: امتیازات Lighthouse برای عملکرد، دسترسی و CLS (تغییر چیدمان تجمعی) تقریبا اشباع شده است و بر اساس چارچوب تفاوت چندانی ندارد:

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

همانطور که توسط Lighthouse گزارش شده است. میانه 3-5 برنامه.

زمان مسدود کردن کل (TBT) از این جهت جالب است که صرفا تابعی از بایت‌های جاوا اسکریپت نیست. برخی از برنامه‌ها زمان بیشتری را نسبت به سایرین روی رشته اصلی صرف می‌کنند. گفته می شود، اعداد همه بسیار کم است:

همانطور که توسط Lighthouse گزارش شده است، شبیه سازی دریچه گاز موبایل. میانه 5 اجرای Lighthouse در هر برنامه، سپس میانه 3-5 برنامه بعد از آن.

بزرگترین رنگ محتوایی (LCP) به دلیل مشکلات ذکر شده در خود متریک بسیار متغیر است. همانطور که انتظار می رود، اما به طور کلی SPA ها را مجازات می کند و به MPA ها پاداش می دهد:

توجه داشته باشید که واریانس وحشی در اعداد Next.js را می توان با این واقعیت توضیح داد که یک برنامه از بارگذاری تنبل تصاویر اجتناب کرد و چهار برنامه دیگر این کار را نکردند. Astro و Vanilla نوسانات مشابهی دارند که به نظر می رسد ناشی از اولویت بندی یا خصلت های LCP باشد.

با این حال، به طور کلی، جای تعجب نیست که این معیار به MPA هایی که به سرعت با HTML نقاشی می کنند، به جای SPA هایی که پس از اجرای جاوا اسکریپت در سمت کلاینت نقاشی می کنند، پاداش می دهد (همراه با احتمالا چندین سفر رفت و برگشتی برای گرفتن داده های پوکمون). با نادیده گرفتن واریانس، LCP در اینجا بیشتر تابعی از اندازه بسته نرم افزاری جاوا اسکریپت است. (Qwik در اینجا یک استثنا قابل توجه است: از نظر فنی یک SPA است که از مسیریابی سمت مشتری استفاده می کند، اما در میان چارچوب های MPA امتیاز می گیرد.)

البته توجه داشته باشید که برخی از فریم‌ورک‌ها در این که آیا بیشتر بر روی مشتری یا سرور تمرکز می‌کنند یا حتی از چارچوب سمت کلاینت استفاده می‌کنند، متفاوت هستند. به عنوان مثال، عامل Gracile حتی از Lit در دو اجرا استفاده نکرد. برای «وانیل»، نماینده عرض جغرافیایی کامل داشت (به غیر از اینکه به او گفته شد از Vite استفاده کند)، اما همچنان تصمیم گرفت هر 5 بار یک SPA بسازد.

SSR در مقابل CSR نیز تا حدی از جایی است که مشکل با Angular از آن سرچشمه می‌گیرد: در 2 اجرا، عامل یک برنامه SSR ساخت که غیر محلی‌هاست را رد می‌کرد (حتی اگر دستورالعمل‌ها به صراحت گفته بودند که برنامه در پشت پراکسی معکوس قرار دارد). من این را یک شکست معتبر برای رعایت مشخصات دانستم و تصمیم گرفتم که 2 تکرار ناموفق را دوباره اجرا نکنم.

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

تعداد خطوط فایل منبع غیر خالی. میانه 3-5 برنامه.

برای من این یکی از جالب ترین نمودارهاست. به یک معنا، تمام هدف یک فریم ورک کاهش مقدار کدی است که باید حفظ کنید. به قول به یاد ماندنی ریچ هریس:

«فریم‌ورک‌ها ابزاری برای سازماندهی کد شما نیستند، بلکه ابزارهایی برای سازماندهی ذهن شما هستند.»

در دوره نمایندگی، این امر حتی سخت‌تر می‌شود، زیرا اندازه کد در نهایت بر تعداد توکن‌ها، از جمله در ویرایش‌های آینده، تأثیر می‌گذارد، به این معنی که بر هزینه واقعی نگهداری یک پایگاه کد در طول زمان تأثیر می‌گذارد. این بدان معنا نیست که مختصر بودن تنها مقداری است که اهمیت دارد، اما مطمئنا جالب است که ببینید Hono+htmx می‌تواند تقریبا همان کاری را که Angular با 70% کد (و سریع‌تر برای بوت کردن) انجام می‌دهد، انجام دهد.

راه های زیادی برای بهبود این معیار وجود دارد. به عنوان مثال، می‌توانید مامور را موظف کنید که از Service Workers برای ذخیره‌سازی آفلاین استفاده کند، یا فایل‌های تصویری پوکمون را بهینه‌سازی کند، یا از بارگذاری تنبل، اولویت واکشی، Speculation Rules API و غیره استفاده کند. حتی با وجود اینکه من تعداد زیادی از این هک‌های عملکردی را می‌دانم، عمدا عامل‌ها را به سمت هیچ یک از آنها هدایت نکردم، زیرا این کار معمولی نیست.

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

همچنین می‌توانید با اجرای تکرارهای بیشتر، استفاده از عوامل کدنویسی مختلف، تلاش سطوح مختلف تلاش، استفاده از چارچوب‌های مختلف یا نسخه‌های مختلف چارچوب‌ها، تلاش با و بدون MCP/مهارت‌ها، آزمایش در مرورگرهای بیشتر از Chromium، ساخت انواع مختلف برنامه‌ها، و غیره، نحوه اجرای معیار را بهبود بخشید. با این حال، اگر کسی بخواهد خودش این معیار را اجرا کند یا آن را جدا کند، در GitHub است، بنابراین من شما را تشویق می‌کنم که دیوانه شوید. من با خوشحالی نتایج شما را در اینجا گزارش خواهم کرد (همراه با هر اشتباه یا نقصی که ممکن است پیدا کنید).

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

من همچنین سعی نمی‌کنم چارچوب خاصی را تحقیر کنم. قبل از اجرای معیار نمی‌دانستم کدام یک «برنده» می‌شود، اگرچه گمان می‌کردم که MPAها از SPAها بهتر عمل می‌کنند (که با خوشحالی در این پست اعتراف کرده‌ام). مطمئنا می‌توانید با ساختن برنامه به یک داشبورد پیچیده، یک بازی ویدیویی، یک برنامه بهره‌وری و غیره، معیارهای مورد علاقه SPA را بنویسید. همچنین می‌توانید معیارهای مختلفی را انتخاب کنید: Lighthouse و Core Web Vitals برای SPAها بسیار سخت هستند، بنابراین می‌توانید تعامل درون برنامه‌ای را به جای آن اندازه‌گیری کنید.

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

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

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

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

نسخه‌های چارچوب مورد استفاده در آزمایش (توجه داشته باشید که Qwik یک وصله انتشار بخشی از آزمایش داشت):