Svelte یا SolidJS؟ مقایسه Svelte ۵ و SolidStart

اگر فقط یک Benchmark یا اندازه «Hello World» را ببینید، انتخاب Svelte یا SolidJS ساده به نظر می‌رسد؛ اما پروژه واقعی با Routing، Form، Auth، SSR، Deployment، Test، Accessibility و تیم نگهدارنده ساخته می‌شود. برنده عمومی وجود ندارد. Svelte ۵ و SolidJS هر دو از Virtual DOM سنتی فاصله می‌گیرند، ولی زبان مؤلفه، مدل Reactivity و بلوغ Meta-framework آن‌ها مسیر متفاوتی برای تیم می‌سازد.

پاسخ کوتاه: Svelte ۵ را زمانی Shortlist کنید که سینتکس نزدیک‌تر به HTML، Runes و یک مسیر رسمی و یکپارچه با SvelteKit برای SSR/SSG/Adapters برای تیم مهم است. SolidJS را زمانی Shortlist کنید که JSX، Signalهای صریح و Fine-grained reactivity با کنترل دقیق Dependencyها مناسب ذهنیت تیم و بار تعاملی پروژه است. تصمیم نهایی را با PoC دو‌هفته‌ای روی همان Route، Deployment و Integrationهای واقعی بگیرید.

جدول تصمیم سریع Svelte و SolidJS

این جدول برنده تعیین نمی‌کند؛ سؤالات PoC را تعیین می‌کند.

Svelte ۵ چگونه کار می‌کند؟

Svelte یک Compiler برای Componentهای .svelte است. Template، Style و Script را در Build تحلیل و کد لازم برای ایجاد و به‌روزرسانی DOM تولید می‌کند. عبارت «هیچ Runtimeای ندارد» توصیف دقیقی برای هر خروجی نیست؛ Helper و کد Runtime بر اساس Feature و Build می‌تواند وجود داشته باشد. مزیت را با Bundle واقعی Route بسنجید، نه شعار.

Runes در Svelte ۵

در Svelte ۵، Runes بخشی از Syntax زبان‌اند و بدون Import استفاده می‌شوند:

<script lang="ts">
  let count = $state(0);
  let doubled = $derived(count * 2);
</script>

<button onclick={() => count++}>
  {count} / {doubled}
</button>

$state State، $derived مقدار مشتق و $effect Side effect را بیان می‌کند. Svelte از Legacy mode نیز برای کد قدیمی پشتیبانی می‌کند، اما ترکیب Patternهای قدیم و جدید بدون Migration policy می‌تواند Review را دشوار کند.

SolidJS چگونه کار می‌کند؟

SolidJS از JSX استفاده می‌کند اما مدل Update آن با React یکی نیست. Signalها Dependency را هنگام خواندن ثبت می‌کنند و Observer وابسته با تغییر مقدار دوباره اجرا می‌شود. هدف Fine-grained reactivity این است که بخش مرتبط به‌صورت هدفمند Update شود.

import { createSignal, createMemo } from "solid-js";

const [count, setCount] = createSignal(0);
const doubled = createMemo(() => count() * 2);

<button onClick={() => setCount(c => c + 1)}>
  {count()} / {doubled()}
</button>

Component در Solid معمولاً مرحله Setup را اجرا و Graph واکنشی می‌سازد؛ Expressionهای Reactive در Owner/Observer مناسب به‌روز می‌شوند. شباهت JSX با React نباید باعث کپی Hook mental model شود. Destructuring نابجا، خواندن Signal خارج از Tracking scope و Effect بی‌هدف از خطاهای رایج مهاجرت‌اند.

تفاوت بنیادی Reactivity

هر دو مدل می‌توانند کد قابل پیش‌بینی یا پیچیده بسازند. Discipline در derived state، Async cancellation و ownership مهم‌تر از نام Primitive است.

SvelteKit در Snapshot فعلی

SvelteKit Meta-framework رسمی Svelte است. مستندات رسمی Page optionها توضیح می‌دهند که Component به‌طور پیش‌فرض روی Server Render یا Prerender و سپس در Browser Hydrate می‌شود. می‌توان prerender، ssr و csr را per-route ترکیب کرد: صفحه Marketing استاتیک، صفحه Dynamic با SSR و Admin به‌صورت SPA.

• File-based routing و Layout؛
• Server/Universal load و Form actions؛
• Endpointهای HTTP؛
• SSR، Prerender و CSR قابل ترکیب؛
• Adapter برای Node، Static و Providerهای مشخص؛
• Environment boundary و Server-only module؛
• Service worker، Hooks و Observability hookهای مستند.

Adapter بخشی از معماری است. قابلیت Runtime، Streaming، Region، Cache و Node API را روی Target واقعی بررسی کنید.

SolidStart در Snapshot فعلی

SolidStart Meta-framework فول‌استک Solid است و Renderingهای CSR، SSR و SSG، Routing فایل‌محور، Server function و API route ارائه می‌کند. مستندات رسمی SolidStart ۱.۰ را اعلام کرده‌اند و هم‌زمان مسیر v2 را با انتقال Configuration به Vite و تغییر Deployment plugin/Runtime مستند کرده‌اند.

این وضعیت الزاماً بد نیست؛ اما پروژه باید دقیقاً بگوید روی کدام نسل است. Copy کردن Example بین v1 و v2 می‌تواند Config، Import یا Runtime requirement ناسازگار بسازد.

• نسخه @solidjs/start و Solid Router را Pin کنید؛
• مستندات همان نسخه را Bookmark کنید؛
• Node/Vite/Deployment requirement را در CI Assert کنید؛
• Server-only/client-only boundary را Test کنید؛
• Migration guide و Rollback branch داشته باشید.

Routing و Data loading

Demo «Todo» آبشار داده، Session expiry و Mutation هم‌زمان را نشان نمی‌دهد. PoC باید Failure و Refresh مستقیم را نیز بسنجد.

SSR، SSG و CSR: چارچوب مهم‌تر از Component library

برای سایت Public، Rendering و URL بیشتر از سرعت Update یک Button بر SEO و First load اثر دارند. هر دو Stack می‌توانند SSR/SSG و Client interaction بسازند، اما تنظیم، Adapter و Error path متفاوت است.

• HTML اولیه Routeهای Search-driven را بررسی کنید؛
• Status واقعی ۴۰۴/Redirect و Canonical را Test کنید؛
• Hydration mismatch و Empty shell را در Log بگیرید؛
• Page data را دوبار Fetch نکنید؛
• Secret و DB client به Bundle مرورگر نروند؛
• Cache header با Personalization سازگار باشد.

جزئیات Crawl، Render، History API، Service Worker و Index را در راهنمای سئو JavaScript و PWA ببینید.

Performance: «سریع‌ترین» بدون Workload معنا ندارد

Benchmark micro-operation می‌تواند هزینه Update DOM را نشان دهد، اما تجربه محصول از Network، Server، Data، Asset، Hydration، Long task و Third-party script می‌آید. هیچ‌کدام را برنده قطعی همه پروژه‌ها ننامید.

یک Build production، بدون Devtools، با داده و Componentهای واقعی مقایسه کنید. نتیجه را بر صدک و دستگاه گزارش دهید، نه فقط میانگین Laptop توسعه‌دهنده.

Bundle size: افسانه «Runtime صفر»

اندازه خروجی به Compiler، Runtime helper، Router، Component library، i18n، Analytics و کد شما وابسته است. Svelte بسیاری از تصمیم‌های Update را Compile می‌کند؛ Solid یک Runtime واکنشی کوچک دارد. اما در پروژه بزرگ، App code و Dependencyها می‌توانند اختلاف Core را بی‌اهمیت کنند.

• Initial JS هر Route و Chunk مشترک را اندازه بگیرید؛
• Tree-shaking و Duplicate package را Audit کنید؛
• Source map analyzer و Import cost داشته باشید؛
• Lazy route را با Waterfall معامله نکنید؛
• Component library کامل را برای دو Button وارد نکنید؛
• Budget را در CI Fail کنید.

Developer experience و منحنی یادگیری

«Svelte آسان» و «Solid برای React developer آسان» فقط فرض اولیه‌اند.

Svelte 5

• Template و Scoped style برای بسیاری خواناست؛
• Runes State/Derived/Effect را صریح‌تر کرده‌اند؛
• فایل‌های Legacy و Runes نیاز به Style guide دارند؛
• رفتار SSR و Browser-only code باید آموخته شود؛
• SvelteKit Convention سرعت می‌دهد ولی Framework knowledge می‌خواهد.

SolidJS

• JSX و TypeScript برای تیم React آشناست؛
• Signal getter/setter و Fine-grained tracking ذهنیت جدا می‌خواهد؛
• Component rerender assumption می‌تواند Bug بسازد؛
• Control flow componentها و Async primitiveها باید درست استفاده شوند؛
• نسخه SolidStart/Router/Toolchain اهمیت بیشتری دارد.

به‌جای نظرخواهی، یک Pairing session دو‌ساعته، Review و تغییر Requirement را روی هر دو PoC اجرا کنید.

TypeScript و API design

هر دو از TypeScript پشتیبانی می‌کنند، اما Type inference در Template/JSX، Generated type Route و Server boundary را در IDE تیم آزمایش کنید.

• Type از DB/API تا Component چگونه جریان دارد؟
• Validation Runtime جدا از Type compile-time هست؟
• Form error و Action result type-safe است؟
• Library Component generic و Event type چگونه است؟
• Generated type در Monorepo و CI پایدار است؟
• Version upgrade چند Type error واقعی می‌سازد؟

Forms و Progressive enhancement

برای CRUD و Commerce، Form از Counter مهم‌تر است. SvelteKit Form actions و Enhancement رسمی دارد. SolidStart Action/Server function دارد؛ UX و Failure را روی نسخه انتخابی بررسی کنید.

Accessibility و کیفیت Component

Framework دسترسی‌پذیری محصول را تضمین نمی‌کند. Svelte Compiler برخی Warningها می‌دهد و JSX نیز Semantic HTML را ممکن می‌کند؛ اما Modal، Menu، Focus trap و Form به تست واقعی نیاز دارند.

• Keyboard-only و Screen reader؛
• Focus پس از Route/Modal/Validation؛
• Reduced motion و Contrast؛
• RTL و ترتیب خواندن؛
• SSR/Hydration و ID پایدار؛
• Component library با تست و Maintenance روشن.

برای سنجش Task و خطای واقعی، راهنمای تست کاربردپذیری را وارد PoC کنید.

Ecosystem را با فهرست نیاز بسنجید

عبارت «اکوسیستم بزرگ‌تر» بدون Requirement کمکی نمی‌کند. برای پروژه خود Matrix بسازید:

آخرین Release، Issue پاسخ‌داده‌شده، License، Bus factor، Migration note و Compatibility را ثبت کنید. Download count به‌تنهایی کیفیت نیست.

Deployment و Adapter risk

انتخاب Meta-framework بدون Target deploy ناقص است. یک Adapter می‌تواند روی Demo کار کند اما Streaming، Cookie، WebSocket، File system یا Edge API مورد نیاز را نداشته باشد.

• Node version و Build image؛
• Serverless/Edge limits و Cold start؛
• Streaming و Compression؛
• Cookie/Session و Header behavior؛
• Image optimization و Cache invalidation؛
• Scheduled job/Queue/WebSocket؛
• Log/Metric/Trace export؛
• Preview، Canary و Rollback.

SvelteKit Adapter و SolidStart Deployment plugin/preset را در محیط واقعی Deploy کنید؛ جدول Feature بازاریابی کافی نیست.

Security و مرز Server/Client

Full-stack convenience می‌تواند Import ناخواسته Secret یا Trust نابجا به Server function ایجاد کند.

• Authorization را داخل هر عملیات Server اعمال کنید؛
• Validation را روی Server تکرار کنید؛
• Server-only module را با Guard و Build test محافظت کنید؛
• CSRF، Origin و SameSite را بر معماری Form/API بررسی کنید؛
• Serialized data نباید Secret/PII اضافی داشته باشد؛
• CSP را با Hydration/Serializer نسخه انتخابی آزمایش کنید؛
• Dependency و Lockfile را Scan و Update کنید.

Testing strategy

Mock زیاد می‌تواند Framework integration را پنهان کند. حداقل یک Test با Build production و Runtime واقعی داشته باشید.

Observability و Debuggability

Framework سریع ولی غیرقابل تشخیص در Incident هزینه‌ساز است. در PoC این‌ها را وصل کنید:

• Server/client error با Release و Route؛
• Source map خصوصی و symbolication؛
• Trace از Request تا DB/API؛
• Hydration mismatch و unhandled rejection؛
• RUM برای INP/LCP/CLS؛
• Log بدون Secret و PII؛
• SLO و Alert بر Journey، نه فقط Process up.

راهنمای Observability وب‌سایت معیارهای PoC را به عملیات Production وصل می‌کند.

تیم، استخدام و Ownership

Framework باید با تیمی که دو سال بعد آن را نگه می‌دارد سنجیده شود.

• چند نفر تجربه Production دارند؟
• Onboarding یک Developer جدید چند روز است؟
• چه کسی Adapter و Upgrade را مالک است؟
• در بازار استخدام هدف، مهارت مستقیم یا قابلیت آموزش وجود دارد؟
• اگر Champion پروژه رفت، Runbook و ADR باقی می‌ماند؟
• Vendor/Community support برای Incident چگونه است؟

کمبود نیروی مستقیم همیشه مانع نیست، اما باید هزینه آموزش، Review و Bus factor در TCO بیاید.

Lock-in و Migration surface

Framework abstraction را حذف نمی‌کنید؛ محل وابستگی را کنترل می‌کنید. ADR بنویسید و دلیل انتخاب را با Trigger بازنگری ثبت کنید.

برای محاسبه Principal/Interest و تصمیم Refactor/Rewrite از راهنمای مدیریت بدهی فنی استفاده کنید.

PoC دو‌هفته‌ای پیشنهادی

Scope مشترک

• سه Route: Public، Dynamic و Admin؛
• Auth/Session و یک Role؛
• List با Filter و ۱۰۰۰ Row؛
• Form با Validation و Mutation؛
• SSR/SEO و Error route؛
• i18n فارسی/RTL؛
• Deploy، Log، Trace و E2E؛
• Upgrade یک Minor و Rollback.

Scorecard وزنی

وزن را قبل از دیدن نتیجه تعیین کنید تا علاقه شخصی معیارها را جابه‌جا نکند.

سناریوهای انتخاب

سایت محتوایی + Dashboard کوچک

SvelteKit با Prerender/SSR per route و مسیر رسمی Adapter معمولاً Shortlist طبیعی است؛ اما SolidStart نیز باید با SSG/SSR واقعی آزموده شود. Content tool و Markdown/CMS integration تعیین‌کننده است.

رابط تعاملی با Updateهای پرتکرار

Solid Fine-grained model می‌تواند جذاب باشد، اما Svelte نیز Compiler-generated update دارد. با Workload واقعی، Memory و Debuggability تصمیم بگیرید.

Widget قابل Embed

Bundle، CSS isolation، Custom element، چند Instance و Host compatibility را بسنجید. ادعای «Svelte همیشه کوچک‌تر» را بدون Build رد یا قبول نکنید.

تیم React/JSX باتجربه

Solid Syntax آشناست، اما React mental model را مستقیم منتقل نکنید. یک Workshop Signal/Owner/Effect و Review اجباری بگذارید.

تیم با HTML/CSS قوی و Full-stack Convention

Svelte component و SvelteKit می‌تواند Onboarding روان‌تری بسازد؛ Runes و Server/client boundary همچنان آموزش می‌خواهد.

ملاحظات پروژه ایرانی

• شبکه و Bundle: JS per route را روی Mobile و شبکه واقعی بسنجید.
• Hosting: Node/Edge version، Streaming و Adapter را با سرویس مقصد اثبات کنید.
• Package access: Registry، Cache CI، Lockfile و Mirror امن/قانونی را برنامه‌ریزی کنید.
• فارسی/RTL: Font، Form، عدد، تاریخ، جدول و Keyboard را در PoC بگذارید.
• تیم: دسترسی به نیروی آموزش‌پذیر و مستندات داخلی از شهرت جهانی مهم‌تر است.
• مانیتورینگ: سرویس Error/Trace و Source map باید در زیرساخت قابل استفاده باشد.
• پرداخت: Callback، Cookie، CSRF و Idempotency را روی Runtime نهایی تست کنید.
• تداوم: Build reproducible و Deploy rollback مستقل از لپ‌تاپ یک نفر باشد.

ماتریس انتخاب نهایی

اگر برای طراحی PoC، ADR و Benchmark مستقل نیاز به همراهی دارید، درخواست مشاوره معماری Frontend ثبت کنید.

سوالات متداول Svelte و SolidJS

Svelte سریع‌تر است یا SolidJS؟

پاسخ عمومی ندارد. Solid در بسیاری از Updateهای Fine-grained قوی است و Svelte کد Update را Compile می‌کند؛ اما Route bundle، SSR، Data، Third-party و Workload واقعی نتیجه محصول را تعیین می‌کنند.

آیا Svelte ۵ هنوز از Syntax قدیمی پشتیبانی می‌کند؟

Legacy mode برای کد قدیمی وجود دارد، اما کد جدید معمولاً با Runes نوشته می‌شود. Migration را مرحله‌ای، با Style guide و Test انجام دهید و Patternها را بی‌قاعده مخلوط نکنید.

آیا SolidStart آماده Production است؟

SolidStart ۱.۰ در مستندات رسمی اعلام شده و مسیر v2 نیز فعال و متفاوت است. آمادگی پروژه به Version pin، Runtime/Deployment، Integration، Test و توان Upgrade شما بستگی دارد؛ PoC روی نسخه دقیق لازم است.

برای SEO کدام بهتر است؟

هر دو با Meta-framework می‌توانند SSR/SSG و HTML مناسب بدهند. Status، URL، Metadata، Canonical، Internal link و Adapter configuration مهم‌تر از Component syntax است.

برای تیم React کدام ساده‌تر است؟

JSX در Solid آشناست، اما React rerender/Hook mental model می‌تواند گمراه‌کننده باشد. Svelte Syntax متفاوت‌تر اما ساده‌خوان است. Pairing و تغییر Requirement در PoC پاسخ واقعی‌تری می‌دهد.

جمع‌بندی

Svelte یا SolidJS را با شعار Compiler، Signal یا Benchmark انتخاب نکنید. Svelte ۵ با Runes و SvelteKit یک مسیر رسمی و منسجم می‌دهد؛ SolidJS با Fine-grained reactivity و SolidStart کنترل واکنشی و Full-stack متفاوتی ارائه می‌کند. Requirement، نسخه، Deployment و Integration را Pin کنید، یک PoC مشترک بسازید، عملکرد و DX را با مدرک بسنجید و تصمیم را در ADR قابل بازنگری ثبت کنید.

منابع مرجع: مستندات رسمی Runes در Svelte ۵، Page options رسمی SvelteKit، Fine-grained reactivity در SolidJS و مستندات رسمی SolidStart v2.