من قبلاً به طور ناخودآگاه سراغ Vue.js می‌رفتم. هر پروژه‌ای به یک شکل شروع می‌شد: نصب CLI، راه‌اندازی router، پیکربندی store و قرار دادن کل آن در یک قالب single-page application. فرقی نمی‌کرد که در حال ساخت یک داشبورد بلادرنگ (real-time) باشم یا یک فرم تماس ساده. Vue انتخاب پیش‌فرض من بود و تصور می‌کردم هر چیز سبک‌تر از آن، یک قدم رو به عقب است.

این عادت رایج است. اگر سال‌ها را در اکوسیستم React یا Vue گذرانده باشید، مدل SPA اجتناب‌ناپذیر به نظر می‌رسد. دیگر از خود نمی‌پرسید که آیا واقعاً به این همه ابزار و پیچیدگی نیاز دارید یا خیر؛ فقط سراغش می‌روید. با گذشت زمان، متوجه چیز نگران‌کننده‌ای شدم. من داشبوردهای Vuex را برای صفحات مدیریت (admin) راه‌اندازی می‌کردم که فقط نیاز داشتند یک وضعیت را تغییر دهند و یک جدول را به‌روزرسانی کنند. من منطق fetch را برای صفحات فرود (landing pages) می‌نوشتم که فقط نیاز داشتند یک آدرس ایمیل را ارسال کنند. پیچیدگی از خودِ مسائل نبود، بلکه از انتخاب ابزار من نشأت می‌گرفت.

سپس شروع به استفاده از HTMX کردم. این تغییر آرام‌تر از آن چیزی بود که انتظار داشتم، اما نحوه انتخاب stack من را تغییر داد.

HTMX واقعاً چه کاری انجام می‌دهد

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

به جای نوشتن کامپوننتی که mount شود، JSON را fetch کند، آن را در local state تجزیه (parse) کند و یک لیست را دوباره رندر کند، فقط یک ویژگی (attribute) به یک دکمه اضافه می‌کنید. سرور قطعات HTML را برمی‌گرداند، نه داده‌های خام (payloads). مرورگر محتوا را در جای مناسب جایگزین می‌کند. شما همچنان با صفحات رندر شده در سمت سرور (server-rendered) کار می‌کنید، اما همان تعاملی را تجربه می‌کنید که مردم معمولاً با فرانت‌اندهای سنگین JavaScript مرتبط می‌دانند.

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

چه زمانی Vue همچنان انتخاب درستی است

رابط‌های کاربری پیچیده به Vue نیاز دارند. اگر در حال ساخت یک داشبورد تحلیل داده‌های بلادرنگ با ویجت‌های drag-and-drop، فیلترهای تو در تو و نمودارهای زنده هستید که داده‌ها را در چندین نما (view) به اشتراک می‌گذارند، به یک فریم‌ورک reactive نیاز دارید. مرورگر باید مالک آن state باشد. شما نمی‌خواهید هر بار که کاربر نموداری را جابه‌جا می‌کند یا یک گروه فیلتر را تغییر می‌دهد، یک رفت و برگشت (round-trip) به سرور داشته باشید. مدل کامپوننت، سیستم reactivity و اکوسیستم Vue دقیقاً برای همین کار ساخته شده‌اند.

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

جایی که HTMX برتری می‌یابد

واضح‌ترین پیروزی زمانی حاصل شد که به بخش‌های خسته‌کننده پروژه‌هایم نگاه کردم. پنل‌های مدیریت اولین بخش‌هایی بودند که تغییر کردند. یک بک‌اند مدیریت معمولاً به جدولی از رکوردها، چند دکمه عملیاتی، فیلترهای صفحه‌بندی شده و یک یا دو فرم نیاز دارد. هیچ‌کدام از این‌ها به virtual DOM نیاز ندارند؛ آنچه نیاز دارند، به‌روزرسانی‌های جزئی و سریع است.

با HTMX، یک دکمه حذف به تگی با ویژگی‌های hx-delete و hx-target تبدیل می‌شود. با کلیک روی آن، مرورگر درخواست را ارسال می‌کند و سرور با یک ردیف جدول به‌روزرسانی شده پاسخ می‌دهد