دنیای توسعه وب بخش عمده‌ای از یک دهه را صرف این باور کرد که مرورگر باید وظایف سنگین را بر عهده بگیرد

دنیای توسعه وب بخش بزرگی از یک دهه را صرف این باور کرد که مرورگر باید کارهای سنگین را انجام دهد. ما با اسناد و فرم‌ها شروع کردیم، سپس به تدریج هر عملیات قابل تصوری را به سمت کلاینت سوق دادیم. مسیریابی (Routing)، مدیریت وضعیت (state management)، واکشی داده‌ها (data fetching)، منطق رندرینگ (rendering logic) و حتی هماهنگ‌سازی پرس‌وجوهای پایگاه داده از طریق GraphQL؛ همه این‌ها به باندل‌های JavaScript منتقل شدند که با هر نسخه سنگین‌تر می‌شدند. فریم‌ورک‌ها تکثیر شدند، خط لوله‌های ساخت (build pipelines) پیچیده‌تر شدند و آنچه در ابتدا راهی برای سریع و روان کردن اپلیکیشن‌ها بود، به معماری‌ای تبدیل شد که در آن یک صفحه نمی‌تواند حتی یک پیکسل معنادار را رندر کند، مگر اینکه مگابایت‌ها کد دانلود، تجزیه (parse) و اجرا شده باشند.

این تغییر، مشکلات واقعی را حل کرد. صفحات رندر شده در سمت سرور با مقدار کمی jQuery در ارائه انتقال‌های نرم و اپلیکیشن‌مانند که کاربران انتظار داشتند، با مشکل مواجه بودند. اپلیکیشن‌های تک‌صفحه‌ای (Single Page Applications) به ما ناوبری آنی، وضعیت پایدار و تعاملات غنی را gift دادند. اما هزینه این کار نیز انباشته شد. تیم‌ها اکنون باید با ذخیره‌سازهای پیچیده وضعیت در سمت کلاینت دست و پنجه نرم کنند، باندل‌های عظیم JavaScript را مدیریت کنند، لایه‌های حساس همگام‌سازی داده‌ها را حفظ کنند و خط لوله‌های ساخت را دیباگ کنند که گاهی خود به یک شغل تمام‌وقت تبدیل می‌شوند. ما مجموعه‌ای از مشکلات را با مجموعه‌ای دیگر معامله کردیم و اکنون بسیاری از توسعه‌دهندگان می‌پرسند که آیا هر اپلیکیشنی واقعاً نیاز دارد این هزینه را بپردازد یا خیر.

دو تحول جدید، پاسخ به این سوال را آسان‌تر کرده‌اند.

HTMX و بازگشت هایپرمدیا (Hypermedia)

اولین مورد HTMX است. در ظاهر، این یک کتابخانه کوچک به نظر می‌رسد، اما پیامدهای معماری آن بسیار بزرگ است. HTMX با HTML به عنوان فرمت بومی برای منطق اپلیکیشن برخورد می‌کند، به جای اینکه با آن مانند یک پوسته استاتیک که باید توسط JavaScript پر شود، رفتار کند.

تغییرات در عمل به این صورت است: به طور سنتی، وقتی کاربر برای بارگذاری نظرات بیشتر روی یک دکمه کلیک می‌کند، فرانت‌اند یک درخواست fetch ارسال می‌کند، یک محتوای JSON دریافت می‌کند، آن را در یک ذخیره‌ساز سمت کلاینت نرمال‌سازی می‌کند، آن را از طریق یک قالب کامپوننت عبور می‌دهد، تفاوت‌های Virtual DOM را محاسبه می‌کند و در نهایت صفحه را اصلاح (patch) می‌کند. HTMX این زنجیره را میان‌بر می‌زند. خودِ دکمه حاوی ویژگی‌هایی (attributes) است که به مرورگر می‌گوید درخواست را به کجا بفرستد و کدام عنصر صفحه را جایگزین کند. سرور یک قطعه HTML (HTML fragment) برمی‌گرداند — فقط همان نظرات جدید که در یک div بسته‌بندی شده‌اند. مرورگر آن را جایگزین می‌کند. دیگر خبری از JSON، درخت وضعیت فرانت‌اند، الگوریتم تطبیق (reconciliation) و جاوااسکریپت امری (imperative) برای همگام نگه داشتن رابط کاربری با سرور نیست.

این به معنای رد کردن توسعه مدرن نیست؛ بلکه رد کردن انتزاع‌های غیرضروری است. HTMX ثابت می‌کند که هایپرمدیا (Hypermedia) — همان سبک معماری که قدرت بخش اول وب بود — همچنان می‌تواند در کنار ارگونومی مدرن، از رابط‌های کاربری پیچیده پشتیبانی کند. هر عنصری می‌تواند درخواست صادر کند، نه فقط فرم‌ها و لینک‌ها. هر رویدادی می‌تواند یک به‌روزرسانی را تحریک کند. سرور همچنان منبع اصلی حقیقت (source of truth) هم برای داده‌ها و هم برای نمایش باقی می‌ماند.

به‌روزرسانی‌های جزئیِ اعلامی (Declarative) در Chrome

تغییر دوم جدیدتر است و درون خودِ مرورگر جریان دارد. Chrome در حال معرفی به‌روزرسانی‌های جزئی اعلامی یا DPU است. این ویژگی به مرورگر اجازه می‌دهد تا HTML را استریم کرده و همزمان با رسیدن بایت‌ها، آن‌ها را مستقیماً در بخش‌های هدف در یک صفحه درج کند.

قبل از DPU، اگر می‌خواستید داده‌های زنده را در یک صفحه وب استریم کنید، معمولاً سراغ WebSockets، Server-Sent Events یا long-polling به همراه دستکاری دستی DOM می‌رفتید. فرانت‌اند باید اتصال را مدیریت می‌کرد، محتوا را تجزیه می‌کرد و دقیقاً تصمیم می‌گرفت که مارک‌آپ را چگونه و کجا تزریق کند. DPU با اعلامی (declarative) کردن این فرآیند، معادله را تغییر می‌دهد. توسعه‌دهنده یک کانتینر هدف را مشخص می‌کند و مرورگر بقیه کارها را انجام می‌دهد: دریافت استریم، تجزیه قطعه کد و قرار دادن آن دقیقاً در جایی که متعلق به آن است، حتی قبل از اینکه پاسخ کامل بسته شود.

یک داشبورد مانیتورینگ که لاگ‌های سرور را نشان می‌دهد یا یک صف پشتیبانی که در لحظه به‌روز می‌شود را تصور کنید. با DPU، بک‌اند تکه‌های ساده HTML را به محض تولید شدن ارسال می‌کند. مرورگر آن‌ها را بدون حتی یک خط کد استریمینگ در سمت کلاینت، مستقیماً در بدنه یک جدول یا یک کانتینر فید استریم می‌کند. این مونتاژ به صورت بومی (native) انجام می‌شود.

مدل سرور-محور (Server-First)

اگر HTMX و DPU را در کنار هم قرار دهید، به یک معماری منسجم می‌رسید که در آن سرور مالک وضعیت است و رابط کاربری را تولید می‌کند، در حالی که مرورگر وظیفه نمایش و ورودی‌های کاربر را بر عهده دارد. فریم‌ورک‌های بک‌اند مانند Rails، Laravel، Django، قالب‌های Go یا ASP.NET دوباره به لایه اصلی رابط کاربری تبدیل می‌شوند. فرانت‌اند دیگر یک اپلیکیشن مجزا نیست که یک API را مصرف کند؛ بلکه همان رابط هایپرمدیا است که سرور تولید می‌کند.

This model fits a surprisingly wide slice of software. Consider the typical SaaS application. It is dashboards with sortable tables. It is admin panels with forms and filters. It is internal tools that move records from one state to another. It is CRUD workflows that show a list, expose a detail view, and let the user edit fields. It is even AI interfaces where a language model streams tokens back to the user, and each token or paragraph can be wrapped in HTML and appended to the conversation thread. For all of these, a thick JavaScript client is often overkill.

The benefits are immediate and practical. Initial page loads are faster because the first meaningful paint arrives as HTML, not after a hydration cycle completes. JavaScript payloads shrink because there is no virtual DOM, no client-side router, and no state management library to ship. Search engines see complete content without executing bundles, so SEO works by default. Complexity drops because one codebase handles routing, business logic, and rendering. Debugging gets easier. When something looks wrong, you inspect the Network tab and see exactly what HTML the server sent. There is no opaque client-side state object to reverse-engineer.

What About React and Heavy Clients?

None of this means React is dead, or that SPAs are a mistake. Complex, editor-grade applications still need a thick client. Figma runs a C++ engine compiled to WebAssembly inside the browser because server round-trips would make drawing impossible. Canva manipulates the canvas at sixty frames per second with client-side geometry. Google Docs uses operational transforms to resolve editing conflicts in milliseconds. These tools are essentially desktop applications delivered through a browser tab. They are not going back to server-rendered forms.

But most software is not Figma. Most software is not a real-time graphics editor. Most software is a reporting screen, a configuration panel, a booking flow, or a content management form. For that long tail of applications, shipping hundreds of kilobytes of JavaScript framework just to toggle a modal or fetch a list of records never made much sense. The economics of the stack are shifting. We are rediscovering that the server can be close to the user thanks to the edge, and that the browser itself has grown capable enough to update fragments without a framework intermediating every byte.

The Pendulum Finds a Balance

The arc of web architecture is swinging back toward simplicity, but it is not a naive return to the nineties. The browser is becoming smarter. Features like DPU do not replace developer ingenuity; they absorb the patterns we used to implement by hand — streaming, partial updates, targeted DOM insertion — into the platform itself. HTMX gives us the vocabulary to express those behaviors without reconstructing a miniature operating system in the frontend.

You no longer have to choose between a simple architecture and a responsive user experience. You can have both. The server can drive the interface, the browser can assemble it, and the JavaScript you write can focus on genuine interactivity rather than plumbing.

For the next generation of dashboards, admin tools, and AI-powered interfaces, the smartest client might be the one that does less.