اگه امروز بخوای یه پروژه‌ی فرانت‌اند جدی بسازی، احتمالاً دیگه مستقیم سراغ React یا Vue خام نمی‌ری؛ سراغ یه meta-framework می‌ری که routing، server-side rendering، و بهینه‌سازی‌ها رو از قبل برات حل کرده. مشکل اینجاست که الان پنج تا گزینه‌ی جدی داری، هر کدوم با فلسفه‌ی متفاوت. تو این مقاله هر پنج تا رو از نظر کاربرد، مزیت، و محدودیت بررسی می‌کنیم.

Next.js (روی React)

Next.js امروز استاندارد de facto دنیای React است؛ توسعه‌ش رو Vercel هدایت می‌کنه و از App Router (مبتنی بر React Server Components) به‌عنوان معماری اصلیش استفاده می‌کنه.

مزیت‌ها: اکوسیستم و کامیونیتیش بزرگ‌تر از هر meta-framework دیگه‌ست؛ تقریباً هر مشکلی که باهاش مواجه بشی، قبلاً یه نفر دیگه هم باهاش مواجه شده و جواب رو جایی نوشته. React Server Components به‌طور واقعی حجم جاوااسکریپتی که به مرورگر می‌فرسته رو کم می‌کنه، چون بخشی از کامپوننت‌ها فقط رو سرور اجرا می‌شن. یکپارچگی خیلی خوبی با Vercel داره (deploy تقریباً بدون تنظیم اضافه)، و از static generation، server-side rendering، و incremental static regeneration به‌صورت هم‌زمان و قابل‌انتخاب پشتیبانی می‌کنه.

معایب: منحنی یادگیری App Router (مخصوصاً تفاوت Server Component و Client Component، و قوانین مربوط به این‌که کجا می‌شه از useState یا event handler استفاده کرد) برای تازه‌کارها گیج‌کننده‌ست. وابستگی معنوی و عملی به Vercel هم یه نگرانیه؛ هرچند می‌شه رو زیرساخت‌های دیگه هم deploy کرد، ولی بعضی ویژگی‌ها (مثل ISR بهینه) بهترین تجربه رو رو خود Vercel می‌دن. build time هم برای پروژه‌های بزرگ می‌تونه کند بشه.

کجا مناسبه: پروژه‌های تجاری بزرگ، محصولاتی که نیاز به SEO قوی دارن، تیم‌هایی که از قبل با React راحتن و می‌خوان بیشترین منابع آموزشی و کامیونیتی رو در اختیار داشته باشن.

Nuxt (روی Vue)

Nuxt همون نقشی که Next.js برای React بازی می‌کنه رو برای Vue بازی می‌کنه، با همون تیم اصلی Vue پشتش (Evan You هم مستقیم درگیرشه).

مزیت‌ها: تجربه‌ی توسعه‌ی خیلی هماهنگ و «batteries-included»؛ auto-import برای کامپوننت‌ها و composable ها، file-based routing، و Nitro (لایه‌ی سرور خودش) که به تنهایی deploy رو رو تقریباً هر پلتفرمی (Vercel، Netlify، Cloudflare Workers، یا حتی یه سرور Node ساده) بدون تغییر کد ممکن می‌کنه. مستندات و پیام‌های خطاش معمولاً واضح‌تر و کاربرپسندتر از Next.js هستن. Vue's Composition API هم به‌طور طبیعی با معماری Nuxt جفت می‌شه.

معایب: اکوسیستم کوچیک‌تر از Next.js، یعنی احتمال این‌که به یه مشکل خیلی خاص برخوردی که کسی قبلاً حلش نکرده، بیشتره. بعضی ویژگی‌های پیشرفته (مثل معادل دقیق React Server Components) هنوز به بلوغ Next.js نرسیدن. تقاضای بازار کار هم به‌طور کلی از React و Next.js کمتره.

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

SvelteKit (روی Svelte)

SvelteKit فرق بنیادی‌تری با بقیه داره، چون خود Svelte هم یه فلسفه‌ی متفاوت داره: به‌جای virtual DOM، Svelte موقع build کد رو به جاوااسکریپت خالص و بهینه compile می‌کنه.

مزیت‌ها: چون Svelte خیلی از کار رو موقع build انجام می‌ده (نه runtime)، باندل خروجی معمولاً خیلی کوچیک‌تر و اجرا سریع‌تره؛ برای اپ‌هایی که performance رو سخت اندازه می‌گیرن این مزیت محسوسه. سینتکس Svelte هم به‌طور کلی مختصرتر و به HTML/CSS/JS استاندارد نزدیک‌تره، پس برای خیلی‌ها یادگیریش سریع‌تره. SvelteKit خودش هم adapter های رسمی برای deploy رو پلتفرم‌های مختلف داره.

معایب: اکوسیستم به‌طور قابل‌توجهی کوچیک‌تر از React و Vue است؛ تعداد کتابخونه‌های آماده، مثال‌ها، و متخصصینی که بشه استخدام کرد کمتره. بازار کار هم برای Svelte محدودتره، پس اگه هدفت جذب نیرو یا پیدا کردن شغله، این یه ریسکه. بعضی ابزارهای شخص ثالث (مخصوصاً کتابخونه‌های UI بزرگ) دیرتر یا هیچ‌وقت پشتیبانی از Svelte اضافه نمی‌کنن.

کجا مناسبه: پروژه‌هایی که performance و سایز باندل واقعاً حیاتیه (مثل اپ‌های موبایل-محور یا با شبکه‌ی ضعیف)، تیم‌های کوچیک که می‌خوان سریع یاد بگیرن و بسازن، و کسایی که از پیچیدگی اضافه‌ی اکوسیستم‌های بزرگ‌تر خسته شدن.

Remix (روی React)

Remix هم رو React ساخته شده، ولی فلسفه‌ش با Next.js فرق داره؛ Remix تمرکز خیلی زیادی روی استانداردهای وب (مثل Web Fetch API) و مدل قدیمی‌تر ولی قوی‌ترِ «فرم‌های HTML به‌عنوان روش اصلی mutation» داره. از سال ۲۰۲۴ به بعد، Remix و React Router به هم نزدیک‌تر شدن و تیمشون هم زیر چتر Shopify فعالیت می‌کنه.

مزیت‌ها: مدل data loading و mutation ش (با loader و action) خیلی ساده و قابل‌پیش‌بینیه، و به‌شدت رو progressive enhancement تمرکز داره؛ یعنی اپلیکیشن حتی بدون جاوااسکریپت هم (تا حد زیادی) کار می‌کنه، چون از فرم‌های HTML استاندارد استفاده می‌کنه. برای اپلیکیشن‌هایی با فرم‌های زیاد و تعامل سرور-محور، این مدل خیلی طبیعی‌تر از حالت‌های پیچیده‌ی client-side state حس می‌شه. نزدیکی به استانداردهای وب هم یعنی دانشی که یاد می‌گیری قابل‌انتقال‌تره.

معایب: اکوسیستمش نسبت به Next.js کوچیک‌تره، و بعد از ادغام با React Router، مسیر و آینده‌ی پروژه یه‌کم برای بعضی توسعه‌دهنده‌ها مبهم به نظر رسیده. پشتیبانی از React Server Components هم هنوز به بلوغ Next.js نرسیده.

کجا مناسبه: اپلیکیشن‌های فرم‌محور و data-heavy (مثل داشبورد ادمین یا پنل‌های مدیریتی)، تیم‌هایی که به progressive enhancement و استانداردهای وب اهمیت می‌دن، و پروژه‌هایی که می‌خوان از پیچیدگی مدل Server/Client Component فاصله بگیرن.

TanStack Start (روی React)

TanStack Start جدیدترین بازیگر این میدونه، از همون تیمی که TanStack Query و TanStack Router رو ساختن (Tanner Linsley). برخلاف بقیه که از یه framework بزرگ شروع کردن، TanStack Start از یه router کاملاً type-safe شروع شده و بهش قابلیت‌های full-stack اضافه کرده.

مزیت‌ها: type-safety فوق‌العاده‌ای داره؛ چون بر پایه‌ی TanStack Router ساخته شده، پارامترهای URL، search params، و حتی loader ها به‌طور کامل با TypeScript type-check می‌شن، چیزی که تو بقیه‌ی framework ها معمولاً باید دستی یا با ابزار جدا مدیریت بشه. ادغام native و روون با TanStack Query هم برای مدیریت state سرور یه مزیت بزرگه، مخصوصاً برای کسایی که از قبل با TanStack Query کار کردن.

معایب: جدیدترین گزینه‌ی این لیسته، یعنی هنوز اکوسیستم، مستندات کامل، و تعداد پروژه‌های production که باهاش ساخته شدن به‌اندازه‌ی بقیه نیست. برای تیم‌هایی که ریسک‌گریزن یا نیاز به یه framework کاملاً جاافتاده دارن، فعلاً انتخاب پرریسک‌تریه.

کجا مناسبه: پروژه‌هایی که TypeScript و type-safety براشون اولویت بالاییه، تیم‌هایی که از قبل با TanStack Query راحتن و می‌خوان همون فلسفه رو تو routing و SSR هم ادامه بدن، و کسایی که راحتن با یه ابزار نسبتاً جدیدتر کار کنن.

جدول مقایسه‌ی سریع

مقایسه‌ی سرعت: واقعیت پشت ادعاهای بازاریابی

یه سؤال رایج اینه: «مگه Vue همیشه از React سریع‌تر تبلیغ نمی‌شد؟» جواب کوتاه اینه که این ادعا برای زمان خودش درست بود، ولی چشم‌انداز از اون موقع عوض شده. ارزش داره این موضوع رو جدا و دقیق‌تر بررسی کنیم.

چرا Vue اول خودش رو «سبک‌تر و سریع‌تر» معرفی کرد

Vue (مخصوصاً نسخه‌های ۱ و ۲) از همون ابتدا مستقیم رو سایز باندل کوچیک‌تر و overhead کمتر نسبت به Angular و React اون دوره تمرکز کرد؛ و این ادعا واقعی بود. بخش زیادیش هم به همون مدل fine-grained reactivity برمی‌گشت که قبلاً توضیح دادیم: چون Vue دقیقاً می‌دونه کدوم بخش از UI به کدوم داده وابسته‌ست، لازم نیست مثل React یه virtual DOM کامل رو diff کنه؛ همین یعنی overhead کمتر بدون نیاز به بهینه‌سازی دستی.

چیزی که از اون موقع تغییر کرده

React فاصله رو کم کرده: React مدرن، با tree-shaking بهتر، و مخصوصاً با React Server Components (که بخشی از کامپوننت‌ها اصلاً جاوااسکریپتی به مرورگر نمی‌فرستن)، دیگه همون داستان باندل سنگین ۲۰۱۵ نیست.

Svelte وارد بازی شد و جلوتر افتاد: رو بنچمارک‌های معروف framework (مثل js-framework-benchmark)، این روزها معمولاً Svelte/SvelteKit جلوتر از هر دوی React و Vue قرار می‌گیره؛ نه Vue. دلیلش اینه که Svelte حتی از فلسفه‌ی Vue هم یه قدم جلوتر رفته: به‌جای این‌که یه reactivity engine رو runtime داشته باشه (حتی fine-grained)، خود Svelte موقع build کد رو مستقیم به جاوااسکریپت خام کامپایل می‌کنه و کل runtime رو حذف می‌کنه.

تفاوت React و Vue امروز خیلی کوچیکه: رو بیشتر بنچمارک‌های امروزی، React و Vue تو یه سطح قرار می‌گیرن؛ اختلافشون معمولاً چند درصده و بین نسخه‌های مختلف بنچمارک هم جابه‌جا می‌شه. چیزی که واقعاً فرق می‌کنه، رفتار پیش‌فرضه نه سقف عملکرد: React می‌تونه به همون سرعت Vue برسه، ولی نیاز به بهینه‌سازی دستی داره (useMemo، useCallback، React.memo)، در حالی که Vue این کار رو به‌صورت خودکار انجام می‌ده. یعنی داستان دقیق‌تر اینه که «Vue به‌سختی می‌شه به‌طور تصادفی کندش کرد»، نه این‌که «Vue همیشه سریع‌تره».

چرا تو دنیای واقعی این تفاوت‌ها کمتر اهمیت دارن

نکته‌ی مهم اینه که تو اکثر پروژه‌های واقعی، خود runtime engine (چه React، چه Vue، چه Svelte) به‌ندرت گلوگاه اصلی performance است. چیزهایی مثل سایز باندل کلی، استراتژی server-side rendering، بهینه‌سازی تصویر و فونت، و مقدار جاوااسکریپتی که واقعاً به کلاینت فرستاده می‌شه (دقیقاً همون چیزی که Next.js با Server Components و SvelteKit با کامپایل‌کردن موقع build سعی می‌کنن حلش کنن) معمولاً تأثیر خیلی بیشتری رو تجربه‌ی واقعی کاربر می‌ذارن تا میکروبنچمارک‌های خود reactivity engine.

جمع‌بندی سریع

رتبه‌بندی صادقانه برای سرعت خام runtime، امروز چیزی شبیه این است: SvelteKit معمولاً جلوتره (چون overhead رو موقع build حذف می‌کنه، نه runtime)، و React و Vue تقریباً هم‌سطح هستن، جایی که تجربه‌ی تیم و تصمیمات معماری بیشتر از خود engine رو نتیجه‌ی نهایی تأثیر می‌ذارن.

اگه دنبال امن‌ترین انتخاب با بیشترین منابع و کامیونیتی هستی، Next.js همچنان انتخاب پیش‌فرضه، مخصوصاً برای پروژه‌های تجاری بزرگ. اگه تیمت Vue رو ترجیح می‌ده یا می‌خواد انعطاف بیشتری تو deploy داشته باشه، Nuxt گزینه‌ی طبیعیه. اگه performance و سایز باندل برات حیاتیه و حاضری اکوسیستم کوچیک‌تر رو تحمل کنی، SvelteKit ارزش امتحان کردن داره. اگه پروژه‌ت پر از فرمه و به progressive enhancement اهمیت می‌دی، Remix فلسفه‌ی مناسب‌تری داره. و اگه TypeScript و type-safety اولویت اصلیته و راحتی با یه ابزار نسبتاً جدید مشکلی نداری، TanStack Start رو جدی بگیر.

نکته‌ی آخر اینه که هیچ‌کدوم از این‌ها انتخاب «اشتباه» نیستن؛ هر پنج‌تاشون production-ready هستن و شرکت‌های واقعی باهاشون محصولات واقعی می‌سازن. تفاوت واقعی بیشتر به این برمی‌گرده که تیمت با کدوم فلسفه راحت‌تره و پروژه‌ت به کدوم مزیت بیشتر نیاز داره، نه این‌که کدوم «بهتره».

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

ایده‌ی اصلی

این معماری که اولین بار توسط Alistair Cockburn معرفی شد، می‌گه منطق اصلی کسب‌وکار (business logic یا domain) باید کاملاً مستقل از هر چیز بیرونی باشه؛ چه دیتابیس، چه فریم‌ورک وب، چه API خارجی، چه message queue. این جداسازی از طریق دو مفهوم اصلی اتفاق می‌افته: port و adapter.

Port یه interface است که مشخص می‌کنه domain چه چیزی از دنیای بیرون نیاز داره یا چه چیزی به دنیای بیرون ارائه می‌ده؛ ولی هیچ جزئیات پیاده‌سازی توش نیست. مثلاً یه port می‌تونه بگه «من به یه راه برای پیدا کردن کاربر با ایمیل نیاز دارم»، بدون این‌که بگه این کار با SQL انجام می‌شه یا با یه فایل JSON.

Adapter پیاده‌سازی واقعی اون portه؛ کدی که واقعاً می‌دونه چطور به PostgreSQL وصل بشه، یا چطور یه HTTP request به یه API خارجی بفرسته.

چرا اسمش «هگزاگونال»ه

اسم این معماری از یه شکل شش‌ضلعی میاد که Cockburn برای نشون دادن domain استفاده کرد؛ نه به این خاطر که دقیقاً شش تا port لازمه، بلکه چون شکل شش‌ضلعی جا برای چندین ضلع (port) مختلف می‌ده، بدون این‌که مثل یه مربع محدود به بالا/پایین/چپ/راست باشه. نکته‌ی اصلی این شکل صرفاً بصریه: نشون می‌ده domain می‌تونه از چند جهت مختلف با دنیای بیرون در ارتباط باشه، و هر جهت از طریق یه port مشخص کنترل می‌شه.

دو نوع port: driving و driven

معمولاً port ها به دو دسته تقسیم می‌شن:

Driving port (یا primary/inbound): چیزی که دنیای بیرون رو قادر می‌کنه با domain حرف بزنه. مثلاً یه interface که می‌گه «چطور می‌شه یه سفارش جدید ثبت کرد». یه controller وب یا یه CLI command، از طریق این port به domain دستور می‌ده.

Driven port (یا secondary/outbound): چیزی که domain برای انجام کارش به دنیای بیرون نیاز داره. مثلاً یه interface برای ذخیره‌ی سفارش تو دیتابیس، یا فرستادن ایمیل تأیید.

# Driven port: domain فقط این interface رو می‌شناسه
from abc import ABC, abstractmethod

class OrderRepository(ABC):
    @abstractmethod
    def save(self, order: 'Order') -> None:
        pass

    @abstractmethod
    def find_by_id(self, order_id: str) -> 'Order | None':
        pass


class NotificationSender(ABC):
    @abstractmethod
    def send_order_confirmation(self, order: 'Order') -> None:
        pass

پیاده‌سازی: هسته‌ی domain

هسته‌ی domain فقط به این port ها وابسته‌ست، نه به هیچ پیاده‌سازی خاصی:

class Order:
    def __init__(self, order_id: str, customer_email: str, total: float):
        self.order_id = order_id
        self.customer_email = customer_email
        self.total = total
        self.status = "pending"


class PlaceOrderService:
    def __init__(self, repository: OrderRepository, notifier: NotificationSender):
        self.repository = repository
        self.notifier = notifier

    def place_order(self, order_id: str, customer_email: str, total: float) -> Order:
        if total <= 0:
            raise ValueError("مبلغ سفارش باید مثبت باشه")

        order = Order(order_id, customer_email, total)
        self.repository.save(order)
        self.notifier.send_order_confirmation(order)
        return order

این کلاس PlaceOrderService هیچ ایده‌ای نداره که آیا OrderRepository واقعاً یه دیتابیس PostgreSQL رو صدا می‌زنه یا فقط یه dictionary تو حافظه‌ست. برای همینه که تست کردنش خیلی ساده‌ست:

class InMemoryOrderRepository(OrderRepository):
    def __init__(self):
        self.orders = {}

    def save(self, order):
        self.orders[order.order_id] = order

    def find_by_id(self, order_id):
        return self.orders.get(order_id)


class FakeNotifier(NotificationSender):
    def __init__(self):
        self.sent = []

    def send_order_confirmation(self, order):
        self.sent.append(order)


def test_place_order_saves_and_notifies():
    repo = InMemoryOrderRepository()
    notifier = FakeNotifier()
    service = PlaceOrderService(repo, notifier)

    order = service.place_order("ord_1", "ali@example.com", 150.0)

    assert repo.find_by_id("ord_1") == order
    assert len(notifier.sent) == 1

آداپترهای واقعی

حالا وقتی زمان استفاده‌ی واقعی می‌رسه، همون port ها رو با پیاده‌سازی واقعی adapt می‌کنیم:

import psycopg2

class PostgresOrderRepository(OrderRepository):
    def __init__(self, connection):
        self.connection = connection

    def save(self, order):
        with self.connection.cursor() as cursor:
            cursor.execute(
                "INSERT INTO orders (id, email, total, status) VALUES (%s, %s, %s, %s)",
                (order.order_id, order.customer_email, order.total, order.status)
            )
        self.connection.commit()

    def find_by_id(self, order_id):
        with self.connection.cursor() as cursor:
            cursor.execute("SELECT * FROM orders WHERE id = %s", (order_id,))
            row = cursor.fetchone()
            return Order(*row) if row else None


class EmailNotifier(NotificationSender):
    def __init__(self, smtp_client):
        self.smtp_client = smtp_client

    def send_order_confirmation(self, order):
        self.smtp_client.send(
            to=order.customer_email,
            subject="تأیید سفارش",
            body=f"سفارش {order.order_id} با موفقیت ثبت شد."
        )

خود PlaceOrderService بدون هیچ تغییری، هم با نسخه‌ی تستی کار می‌کنه و هم با نسخه‌ی واقعی؛ فقط adapter ای که موقع wiring کردن اپلیکیشن بهش تزریق می‌شه فرق می‌کنه.

این معماری با Dependency Inversion Principle چه ربطی داره

اگه مقاله‌ی SOLID رو خونده باشی، احتمالاً این الگو برات آشناست؛ معماری هگزاگونال عملاً یه اعمال سیستماتیک از Dependency Inversion Principle تو سطح کل اپلیکیشنه. به‌جای این‌که domain به یه پیاده‌سازی خاص (مثل PostgreSQL) وابسته باشه، هم domain و هم پیاده‌سازی، به یه abstraction مشترک (port) وابسته‌ن. جهت وابستگی همیشه به سمت داخل (به سمت domain) است؛ هیچ‌وقت برعکس.

کجا این معماری واقعاً ارزش داره

این معماری برای اپلیکیشن‌هایی معنی داره که منطق کسب‌وکار پیچیده و قابل‌تغییری دارن، یا احتمال داره زیرساخت‌هاشون (دیتابیس، پیام‌رسان، API های خارجی) تو طول زمان عوض بشه. سیستم‌های مالی، پلتفرم‌های e-commerce با قوانین قیمت‌گذاری پیچیده، یا هر جایی که تیم می‌خواد تست‌های سریع و ایزوله داشته باشه، از این جداسازی سود می‌بره.

در مقابل، برای یه CRUD ساده که فقط داره داده رو از دیتابیس می‌خونه و نمایش می‌ده، بدون منطق کسب‌وکار پیچیده‌ای، اضافه کردن لایه‌های port و adapter فقط پیچیدگی اضافه می‌کنه بدون فایده‌ی متناسب. مثل خیلی از الگوهای معماری دیگه، سؤال درست این نیست که «آیا این الگو خوبه؟»، بلکه اینه که «آیا پیچیدگی پروژه‌م این سرمایه‌گذاری رو توجیه می‌کنه؟»

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

فلسفه‌ی طراحی: کتابخونه در برابر فریم‌ورک

React خودش رو یه «کتابخونه برای ساخت UI» معرفی می‌کنه، نه یه فریم‌ورک کامل. یعنی چیزهایی مثل routing، مدیریت state سراسری، یا فرم‌ها جزو خود React نیستن؛ باید یا خودت پیاده‌شون کنی، یا از کتابخونه‌های جدا مثل React Router یا Redux استفاده کنی. این طراحی یعنی انعطاف بیشتر، ولی هم‌زمان یعنی برای هر پروژه باید یه سری تصمیم معماری بگیری که تو تیم‌های مختلف می‌تونه نتیجه‌ی خیلی متفاوتی بده.

Vue برعکس، خودش رو یه فریم‌ورک progressive معرفی می‌کنه؛ یعنی ابزارهای رسمی برای routing (Vue Router)، مدیریت state (Pinia)، و build (Vite، که خودش هم پروژه‌ی همون سازنده‌ی Vueه) از قبل با هم هماهنگ شدن و به‌عنوان بخشی از اکوسیستم رسمی معرفی می‌شن. این یعنی تصمیم‌گیری معماری کمتری لازمه، مخصوصاً برای تیم‌های کوچیک‌تر یا پروژه‌های جدید.

مدل reactivity: مقایسه به‌جای اثبات وابستگی

اختلاف فنی اصلی این دو، تو نحوه‌ی تشخیص تغییرات و رندر مجدده.

React از یه مدل declarative استفاده می‌کنه: هر بار که state عوض بشه، کل تابع کامپوننت دوباره اجرا می‌شه و یه virtual DOM جدید می‌سازه، بعد این virtual DOM جدید رو با نسخه‌ی قبلی مقایسه می‌کنه (diffing) تا فقط تغییرات واقعی رو به DOM اصلی اعمال کنه:

function Counter() {
  const [count, setCount] = useState(0);

  return (
    <button onClick={() => setCount(count + 1)}>
      تعداد: {count}
    </button>
  );
}

هر بار که setCount صدا زده بشه، کل تابع Counter دوباره اجرا می‌شه. React باهوشیه که فقط تغییرات واقعی DOM رو اعمال کنه، ولی محاسبه‌ی خود diff هنوز باید انجام بشه.

Vue از یه مدل fine-grained reactivity استفاده می‌کنه؛ سیستم دقیقاً می‌دونه کدوم بخش از template به کدوم متغیر وابسته‌ست، پس وقتی یه مقدار عوض می‌شه، فقط همون بخش خاص آپدیت می‌شه، بدون نیاز به اجرای دوباره‌ی کل تابع یا محاسبه‌ی diff:

<script setup>
import { ref } from 'vue';
const count = ref(0);
</script>

<template>
  <button @click="count++">تعداد: {{ count }}</button>
</template>

این تفاوت معماری یعنی Vue معمولاً بدون نیاز به optimization دستی (مثل useMemo یا useCallback تو React) عملکرد خوبی می‌ده، در حالی که تو اپ‌های React بزرگ، مدیریت re-render های غیرضروری خودش به یه مهارت جدا تبدیل می‌شه.

سینتکس و ساختار فایل

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

Vue از Single-File Component ها (فایل‌های .vue) استفاده می‌کنه که سه بخش جدا داره: <template> برای HTML، <script> برای منطق، و <style> برای CSS، همه تو یه فایل ولی از هم مجزا. این ساختار برای کسایی که از پس‌زمینه‌ی HTML/CSS سنتی میان، معمولاً آشناتر و راحت‌تر برای شروعه.

منحنی یادگیری

Vue معمولاً به‌عنوان فریم‌ورک ساده‌تر برای شروع شناخته می‌شه؛ مستندات رسمیش هم به همین دلیل معروفه که خیلی واضح و گام‌به‌گامه. مفاهیم پایه (directive هایی مثل v-if، v-for، v-model) خیلی شبیه HTML گسترش‌یافته هستن و برای کسی که تازه شروع کرده، ورودی نرم‌تری فراهم می‌کنن.

React برای شروع هم سخت نیست، ولی چون خودش فقط کتابخونه‌ی UI است، رسیدن به یه استک کامل (routing، state management، فرم‌ها، styling) یعنی باید چند تا کتابخونه‌ی جدا رو هم یاد بگیری، و هر کدوم فلسفه‌ی خودشون رو دارن. همین‌طور مفاهیمی مثل closure، dependency array تو useEffect، و re-render logic، برای تازه‌کارها معمولاً چالش‌برانگیزترن.

اکوسیستم و بازار کار

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

Vue تو کشورهایی مثل چین و بعضی جاهای اروپا و آسیا محبوبیت بالایی داره، و اکوسیستمش هم به‌طور پیوسته در حال رشده (مخصوصاً بعد از معرفی Vue 3 و Composition API)، ولی از نظر حجم موقعیت شغلی جهانی، هنوز از React عقب‌تره.

Next.js و Nuxt: وقتی فریم‌ورک‌های بالادستی وارد می‌شن

امروز خیلی از پروژه‌های واقعی مستقیم از React یا Vue خام استفاده نمی‌کنن، بلکه از یه meta-framework روی همون پایه استفاده می‌کنن. برای React، Next.js استاندارد de facto شده؛ server-side rendering، routing فایل-محور، و بهینه‌سازی‌های image/font رو به‌صورت آماده می‌ده. برای Vue، معادلش Nuxt است که همون فلسفه رو دنبال می‌کنه. اگه داری یه پروژه‌ی جدید شروع می‌کنی، احتمالاً سؤال واقعی‌ت نه «React یا Vue»، بلکه «Next.js یا Nuxt» است، چون این‌ها تصمیمات معماری بیشتری رو از قبل برات گرفتن.

کدوم رو انتخاب کنیم

اگه تیمت از قبل با جاوااسکریپت راحته و می‌خواد از یه اکوسیستم بزرگ، فرصت شغلی بیشتر، و قابلیت اشتراک کد با موبایل (از طریق React Native) بهره ببره، React انتخاب امن‌تریه؛ مخصوصاً برای پروژه‌های بزرگ و تیم‌های بزرگ که به انعطاف معماری نیاز دارن.

اگه دنبال یه منحنی یادگیری ملایم‌تر، مستندات واضح، و یه استک هماهنگ و رسمی (بدون نیاز به تصمیم‌گیری‌های زیاد درباره‌ی کتابخونه‌ها) هستی، یا تیمت کوچیک‌تره و می‌خوای سریع‌تر به نتیجه برسی، Vue گزینه‌ی راحت‌تریه.

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

شرکت چینی Zhipu AI (که با اسم تجاری Z.ai هم شناخته می‌شه) چهاردهم آگوست مدل جدیدش، GLM-5.3، رو منتشر کرد. طبق ادعای خود شرکت، این مدل الان قوی‌ترین مدل کدنویسی open-weights دنیاست؛ ادعایی که هنوز به‌طور مستقل تأیید نشده، ولی جزئیات فنی پشتش قابل توجهه.

بدون تغییر مدل پایه، فقط با post-training

نکته‌ی جالب GLM-5.3 اینه که دقیقاً همون معماری و مدل پایه‌ی نسخه‌ی قبلی (GLM-5.2) رو داره؛ هیچ pretraining جدیدی انجام نشده. تمام بهبودها از یه دور گسترده‌ی post-training اومده؛ چیزی که Zhipu توضیح می‌ده با استفاده از ده‌ها برابر بیشتر محیط‌های task طولانی‌مدت، تنوع بیشتر تو نوع این محیط‌ها، و مدت زمان طولانی‌تر post-training به دست اومده. طبق ادعای خود شرکت، تو ارزیابی‌های داخلیشون، توانایی کدنویسی مدل ۵۰ درصد نسبت به GLM-5.2 بهبود پیدا کرده و تو بنچمارک‌های عمومی مثل Terminal-Bench 3.0 و Agents' Last Exam، رتبه‌ی اول رو بین مدل‌های متن‌باز گرفته؛ با توانایی کدنویسی و agent نزدیک به Claude Fable 5.

بعد رفتن سراغ امنیت سایبری

یکی از جاهایی که مدل‌های چینی مثل Kimi یا Qwen تا الان از مدل‌های frontier آمریکایی عقب بودن، امنیت سایبریه. Zhipu مستقیم رفته سراغ همین نقطه‌ضعف: GLM-5.3 رو با داده و محیط‌هایی آموزش داده که مخصوص پیدا کردن آسیب‌پذیری نرم‌افزار طراحی شده. طبق توضیح Z.ai، این مدل شروع کرده به استدلال کردن رو چند مرحله‌ی مختلف بهره‌برداری و ساختن برنامه‌های منسجم برای زنجیره‌ی کامل اکسپلویت.

با همکاری تیم‌های امنیتی تو چین، شرکت می‌گه این مدل ۲۴۳۶ آسیب‌پذیری رو تو ۲۶۹ پروژه پیدا کرده؛ بعضی از این آسیب‌پذیری‌ها تا ۴۰-۴۵ سال قدمت داشتن. تو بنچمارک CyberGym هم امتیاز ۸۴.۵ درصد گرفته که کمی از Claude Mythos 5 و GPT-5.6 Sol بهتره، هرچند تو تسک‌های عمیق‌تر بهره‌برداری مثل ExploitBench، هنوز فاصله‌ای با مدل‌های frontier بسته باقی مونده.

وزن‌ها هنوز باز نشدن

با این‌که Zhipu این مدل رو به‌عنوان open-weights معرفی می‌کنه، خود فایل‌های وزن هنوز قابل دانلود نیستن. طبق اعلام شرکت، این وزن‌ها حدود دو هفته بعد از انتشار، بعد از یه دور بررسی امنیتی، منتشر می‌شن. تا اون موقع، تنها راه دسترسی به مدل از طریق GLM Coding Plan خود Zhipu و integration هایی مثل ZCode، Claude Code، و OpenCode است.

همین تأخیر تو انتشار وزن‌ها یعنی فعلاً هیچ بنچمارک یا تست مستقلی از سمت جامعه‌ی خارج از Zhipu وجود نداره؛ تمام اعداد و ادعاهای بالا (بهبود ۵۰ درصدی، رتبه‌ی اول بین مدل‌های متن‌باز) صرفاً بر اساس ارزیابی‌های داخلی خود شرکته و باید تا انتشار واقعی وزن‌ها، با احتیاط بهشون نگاه کرد.

دسترسی برای کاربران فعلی

همزمان با انتشار، Zhipu اعلام کرد که quota مصرف همه‌ی کاربران GLM Coding Plan، ساعت ۱۳:۰۰ همون روز ریست شده و کاربرها می‌تونن سهمیه‌ی جدیدشون رو تو بخش «Usage Statistics» ببینن.

جمع‌بندی

اگه قبلاً از GLM-5.2 برای کارهای کدنویسی استفاده می‌کردی، GLM-5.3 همین الان از طریق GLM Coding Plan در دسترسه و طبق ادعای شرکت، جهش محسوسی تو agent-based task ها داره. ولی اگه دنبال self-host کردن یا استفاده‌ی offline از این مدل هستی، باید حدود دو هفته صبر کنی تا وزن‌ها منتشر بشن؛ و بعد از انتشارشون هم ارزش داره منتظر بنچمارک‌های مستقل بمونی تا ببینی ادعاهای Zhipu چقدر تو عمل هم صدق می‌کنه.