یک مهندس و یک مدل AI در یک هفته Next.js را از صفر بازسازی کردند و نتیجه پروژه یک جایگزین drop-in به نام vinext (تلفظ: vee-next) شد که روی Vite ساخته شده و با یک فرمان میتواند روی Cloudflare Workers دیپلوی شود. این پروژه در اولین بنچمارکها تا 4x سریعتر بیلد میکند و بستههای کلاینت تا 57% کوچکتر میشوند. 😊
هزینه کلی کار حدوداً 1,100 دلار بهصورت token بوده است.
مشکل deployment با Next.js
Next.js پراستفادهترین فریمورک React است و تجربه توسعهٔ بسیار خوبی ارائه میدهد، اما وقتی میخواهید آن را در اکوسیستم سرورلس گستردهتر مستقر کنید، با یک مشکل اساسی روبرو میشوید: ابزارها کاملاً bespoke هستند. Next.js سهم زیادی روی Turbopack گذاشته اما برای دیپلوی روی Cloudflare، Netlify یا AWS Lambda باید خروجی build را طوری تغییر دهید که پلتفرم هدف بتواند اجرا کند.
OpenNext تا حد زیادی برای حل همین مشکل ساخته شده اما این رویکرد—یعنی ساختن روی خروجی Next.js—پس از مدتی محدودیتها و شکنندگیهایی نشان میدهد. OpenNext مجبور است خروجی buildِ Next.js را reverse-engineer کند و تغییرات غیرقابلپیشبینی بین نسخهها کار زیادی برای اصلاح میخواهد.
علاوه بر این، در زمان توسعه next dev صرفاً در Node.js اجرا میشود و امکان قرار دادن runtime متفاوت وجود ندارد. اگر اپ شما از APIهای اختصاصی پلتفرم مثل Durable Objects، KV یا AI bindings استفاده کند، بدون راهحلهای جانبی نمیتوانید آن کد را در dev تست کنید.
معرفی vinext
ایده این بود: بهجای تطبیق دادن خروجی Next.js، آیا میتوانیم سطح APIِ Next.js را مستقیماً روی Vite پیادهسازی کنیم؟ Vite ابزاری است که بیشتر اکوسیستم front-end (مثل Astro، SvelteKit، Nuxt و Remix) از آن استفاده میکند. هدف یک بازپیادهسازی تمیز بود، نه فقط یک wrapper یا adapter. ما واقعاً انتظار نداشتیم این کار به این سرعت جواب بدهد، اما در 2026 هزینهٔ ساخت نرمافزار عوض شده است.
برای استفاده کافی است بسته را نصب کنید، next را در اسکریپتها با vinext عوض کنید و باقی چیزها معمولاً بدون تغییر کار میکنند: app/، pages/ و next.config.js همچنان کار خواهند کرد.
npm install vinext # Replace next with vinext in your scripts, then: vinext dev # Development server with HMR vinext build # Production build vinext deploy # Build and deploy to Cloudflare Workers
این پروژه یک wrapper روی Next.js و Turbopack نیست؛ بلکه یک پیادهسازی جایگزین از سطح API است: routing، server rendering، React Server Components، server actions، caching، middleware — همه بهعنوان یک پلاگین Vite. مهمتر اینکه خروجی Vite به کمک Vite Environment API روی هر پلتفرمی قابل اجراست.
نتایج اولیه بنچمارک
بنچمارکهای ابتدایی امیدوارکنندهاند. مقایسه بین vinext و Next.js 16 با یک اپ App Router شامل 33 مسیر انجام شد. هر دو فریمورک کار یکسانی انجام میدهند: compile، bundle و آمادهسازی مسیرهای server-rendered. برای انصاف، TypeScript type checking و ESLint در buildِ Next.js غیرفعال شد (Vite اینها را در build اجرا نمیکند) و از force-dynamic استفاده شد تا Next.js زمان اضافه برای pre-render ایستا را صرف نکند. بنچمارکها در GitHub CI روی هر merge به main اجرا میشوند.
Production build time (متوسط):
Next.js 16.1.6 (Turbopack): 7.38s baseline
vinext (Vite 7 / Rollup): 4.64s — حدود 1.6x سریعتر
vinext (Vite 8 / Rolldown): 1.67s — حدود 4.4x سریعتر
Client bundle size (gzipped):
Next.js 16.1.6: 168.9 KB baseline
vinext (Rollup): 74.0 KB — 56% کوچکتر
vinext (Rolldown): 72.9 KB — 57% کوچکتر
این بنچمارکها صرفاً سرعت compilation و bundling را اندازه میگیرند، نه عملکرد سروینگ در پرو덕شن. فیکسچر تست یک اپ 33-route است و نمایندهٔ همهٔ اپهای واقعی نیست؛ نتایج را بهعنوان جهتنما در نظر بگیرید. البته معماری Vite و خصوصاً Rolldown (Bundler مبتنی بر Rust در Vite 8) مزایای ساختاری دارد که در این اعداد بهخوبی دیده میشود.
دیپلوی روی Cloudflare Workers
vinext با Cloudflare Workers بهعنوان هدف اولیهٔ دیپلوی ساخته شده و یک فرمان همهچیز را از سورس تا Worker اجراشونده انجام میدهد:
vinext deploy
این فرمان کل فرایند را پوشش میدهد: بیلد برنامه، ایجاد خودکار پیکربندی Worker و دیپلوی. هم App Router و هم Pages Router روی Workers کار میکنند و client-side hydration، کامپوننتهای تعاملی، ناوبری سمت کلاینت و React state پشتیبانی میشوند.
برای کشینگ production، vinext یک Cloudflare KV cache handler ارائه میدهد که ISR را همانند Next.js از جعبه در اختیار میگذارد:
import { KVCacheHandler } from "vinext/cloudflare";
import { setCacheHandler } from "next/cache";
setCacheHandler(new KVCacheHandler(env.MY_KV_NAMESPACE));
KV برای اکثر اپها گزینهٔ خوبی است، اما لایهٔ کش طوری طراحی شده که قابل تعویض باشد. اگر payloadهای کششده بزرگ دارید یا الگوهای دسترسی متفاوت، R2 ممکن است مناسبتر باشد. در حال کار روی بهبود Cache API هستیم تا لایهٔ کش قویتری با پیکربندی کمتر ارائه شود. هدف انعطافپذیری است: استراتژی کشی را که مناسب اپ شماست انتخاب کنید.
مثالهای زندهای که هماکنون اجرا میشوند: App Router Playground، Hacker News clone، App Router minimal، Pages Router minimal. همچنین نمونهای از Cloudflare Agents که در یک اپ Next.js اجرا میشود وجود دارد؛ حالا نیازی به workarounds مثل getPlatformProxy نیست چون کل اپ هم در dev و هم در deploy در workerd اجرا میشود. این یعنی میتوانید از Durable Objects، AI bindings و سایر سرویسهای خاص Cloudflare بدون محدودیت استفاده کنید.
فریمورکها تیمی هستند
هدف اولیه Cloudflare Workers است اما تقریباً 95% vinext مبتنی بر Vite است و بخشهای مهم مثل routing، module shims، SSR pipeline و RSC integration اصلاً Cloudflare-specific نیستند. Cloudflare در حال تعامل با دیگر هاستینگهاست تا این toolchain توسط آنها هم پذیرفته شود (مثلاً یک proof-of-concept برای Vercel در کمتر از 30 دقیقه کار کرد). این پروژه open-source است و برای موفقیت بلندمدت نیاز به همکاری با شرکای مختلف داریم — PRها از سایر پلتفرمها خوشآمدید.
وضعیت: Experimental
میخواهیم شفاف باشیم: vinext هنوز experimental است. کمتر از یک هفته از عمر آن میگذرد و در مقیاسهای بزرگ بهصورت گسترده مورد آزمایش قرار نگرفته است، پس در صورت ارزیابی برای production با احتیاط جلو بروید.
از طرفی، مجموعه تستها گسترده است: بیش از 1,700 تست Vitest و 380 تست Playwright E2E، شامل تستهایی که مستقیماً از Next.js test suite و OpenNext’s Cloudflare conformance suite پورت شدهاند. پوشش API تا 94% از سطح APIِ Next.js 16 است. مشتریان اولیه نتایج امیدوارکنندهای دیدهاند؛ برای مثال National Design Studio در سایت CIO.gov از vinext در production استفاده کرده و بهبودهای معنیداری در زمان بیلد و اندازه bundle مشاهده کردهاند. README پروژه بهصراحت محدودیتها را توضیح میدهد تا وعدهٔ بیش از حد داده نشود.
حالت pre-rendering
vinext از ISR پشتیبانی میکند؛ بعد از اولین درخواست به یک صفحه، صفحه کش شده و در پسزمینه revalidate میشود، درست مثل Next.js. اما vinext هنوز از pre-rendering ایستا در زمان build پشتیبانی نمیکند: صفحات بدون دادهٔ داینامیک در Next.js در زمان next build رندر شده و بهصورت HTML ایستا ذخیره میشوند و اگر مسیرهای داینامیک دارید از generateStaticParams() برای فهرستبندی استفاده میشود — vinext این رفتار را هنوز ندارد. این تصمیم آگاهانه برای لانچ بوده و در roadmap قرار دارد. اگر سایت شما 100% ایستا است، امروز احتمالاً vinext برای شما بهترین انتخاب نیست و ابزارهایی مثل Astro که برای محتوای استاتیک طراحی شدهاند گزینهٔ مناسبتریاند.
پیشنهاد بهبود: Traffic-aware Pre-Rendering (TPR)
یکی از مشکلات Next.js این است که generateStaticParams() باعث میشود همهٔ صفحات تعیینشده در زمان build پیشریندر شوند؛ یک سایت با 10,000 محصول یعنی 10,000 رندر در build حتی اگر 99% از آن صفحات هرگز بازدید نشوند. به همین دلیل بیلدها بهصورت خطی با تعداد صفحات رشد میکنند و سایتهای بزرگ بیلدهای 30 دقیقهای دارند.
ایدهٔ TPR ساده است: چون Cloudflare بهعنوان reverse proxy ترافیک واقعی را میبیند، میتوانیم از دادههای ترافیک برای تصمیمگیری استفاده کنیم و تنها صفحات واقعیِ بازدیدشده را پیشریندر یا اولویتبندی کنیم. این رویکرد میتواند بهصورت قابلتوجهی زمان build را کاهش دهد و هزینهٔ منابع را به صفحات پرتقاضا متمرکز کند. این ویژگی هنوز experimental است و قرار است پس از دریافت بازخوردهای واقعی پیشفرض شود.
جمعبندی
vinext یک آزمایش جدی و امیدوارکننده است: با هزینهٔ نسبتاً کم و استفاده از مدلهای AI، یک بازپیادهسازی از سطح APIِ Next.js روی Vite ساخته شده که در بنچمارکهای اولیه مزایای قابلتوجهی نشان میدهد. اما هنوز راه زیادی تا بلوغ کامل وجود دارد و مخصوصاً برای Production باید با احتیاط و تستهای مناسب جلو رفت. اگر در حوزهٔ devops / SRE کار میکنید و علاقهمندید آن را امتحان کنید، به پروژه سر بزنید، تستهای خودتان را اجرا کنید و در صورت امکان با PR یا issue مشارکت کنید — تجربیات واقعی شما طلا هستند. 🚀
