میں غیر ارادی طور پر Vue.js کا انتخاب کرتا تھا۔ ہر پروجیکٹ ایک ہی طرح سے شروع ہوتا تھا: CLI انسٹال کریں، router سیٹ اپ کریں، store کنفیگر کریں، اور اس پوری چیز کو single-page application shell میں لپیٹ دیں۔ اس سے کوئی فرق نہیں پڑتا تھا کہ میں ایک real-time dashboard بنا رہا ہوں یا ایک سادہ contact form۔ Vue میرا ڈیفالٹ انتخاب تھا، اور میں سمجھتا تھا کہ اس سے ہلکا کوئی بھی دوسرا انتخاب پیچھے کی طرف ایک قدم ہے۔
یہ عادت عام ہے۔ اگر آپ نے برسوں React یا Vue ecosystem کے اندر گزارے ہیں، تو SPA ماڈل ناگزیر محسوس ہونے لگتا ہے۔ آپ یہ پوچھنا چھوڑ دیتے ہیں کہ کیا آپ کو واقعی اتنی مشینری کی ضرورت ہے۔ آپ بس اسے استعمال کر لیتے ہیں۔ وقت کے ساتھ، میں نے ایک پریشان کن چیز محسوس کی۔ میں ان admin screens کے لیے Vuex stores تیار کر رہا تھا جنہیں صرف ایک اسٹیٹس تبدیل کرنے اور ایک ٹیبل کو ریفریش کرنے کی ضرورت تھی۔ میں ان landing pages کے لیے fetch logic تیار کر رہا تھا جنہیں صرف ایک ای میل ایڈریس جمع کروانے کی ضرورت تھی۔ پیچیدگی مسائل سے نہیں آ رہی تھی۔ وہ میرے ٹول کے انتخاب سے آ رہی تھی۔
پھر میں نے HTMX استعمال کرنا شروع کیا۔ یہ تبدیلی میری توقع سے زیادہ خاموش تھی، لیکن اس نے میرے ٹیکنالوجی اسٹیک (stack) کے انتخاب کے طریقے کو بدل دیا۔
HTMX اصل میں کیا کرتا ہے
زیادہ تر آن لائن بحثیں اس معاملے میں غلطی کرتی ہیں۔ لوگ اسے Vue بمقابلہ React بمقابلہ HTMX کی جنگ کے طور پر پیش کرتے ہیں۔ یہ موازنہ اصل مقصد سے بالکل ہٹ جاتا ہے۔ HTMX کوئی SPA framework نہیں ہے۔ یہ Vue کو تبدیل نہیں کرنا چاہتا۔ یہ ایک ایسی لائبریری ہے جو HTML کو اس سے کہیں زیادہ کرنے کے قابل بناتی ہے جتنا براؤزر اسے پہلے سے فراہم کرتا ہے۔
ایک ایسا component لکھنے کے بجائے جو mount ہو، JSON fetch کرے، اسے local state میں parse کرے، اور ایک فہرست کو دوبارہ render کرے، آپ ایک بٹن میں ایک attribute شامل کر دیتے ہیں۔ سرور ڈیٹا کے بجائے HTML fragments واپس کرتا ہے۔ براؤزر اس مواد کو اپنی جگہ پر تبدیل (swap) کر دیتا ہے۔ آپ اب بھی server-rendered صفحات کے ساتھ کام کر رہے ہوتے ہیں، لیکن آپ کو وہ انٹراکیٹیویٹی (interactivity) ملتی ہے جس کا لوگ عام طور پر بھاری JavaScript front ends سے تعلق جوڑتے ہیں۔
یہ کوئی تنزلی (downgrade) نہیں ہے۔ یہ ایک مختلف ماڈل ہے۔ Vue آپ سے ایک client-side application بنانے اور براؤزر میں state کو مینیج کرنے کا کہتا ہے۔ HTMX آپ سے کہتا ہے کہ state کو سرور پر رکھیں اور HTML کو نیٹ ورک کے ذریعے بھیجیں۔ چونکہ وہ مختلف قسم کے مسائل حل کرتے ہیں، اس لیے دونوں ایک ہی پروجیکٹ میں بغیر کسی تنازع کے ساتھ رہ سکتے ہیں۔
جب Vue اب بھی صحیح انتخاب ہے
پیچیدہ انٹرفیسز کو Vue کی ضرورت ہوتی ہے۔ اگر آپ drag-and-drop widgets، nested filtering، اور live charts کے ساتھ ایک real-time analytics dashboard بنا رہے ہیں جو متعدد ویوز میں ڈیٹا شیئر کرتے ہیں، تو آپ کو ایک reactive framework کی ضرورت ہے۔ اس state کا مالک براؤزر کو ہونا چاہیے۔ آپ نہیں چاہیں گے کہ ہر بار جب صارف کسی چارٹ کو ڈریگ کرے یا فلٹر گروپ کو تبدیل کرے تو سرور تک رابطہ (round-trip) کرنا پڑے۔ Vue کا component model، reactivity system، اور ecosystem بالکل اسی کے لیے بنائے گئے ہیں۔
یہی بات انتہائی انٹرایکٹو صارف ایپلی کیشنز (consumer applications) کے لیے بھی صادق آتی ہے۔ ایک ڈیزائن ٹول، ایک collaborative whiteboard، یا ایک music sequencer کے بارے میں سوچیں۔ یہ صرف بٹنوں والے دستاویزات نہیں ہیں۔ یہ ایسی ایپلی کیشنز ہیں جو براؤزر میں چلتی ہیں۔ اس کام کے لیے، Vue اب بھی میرا پہلا انتخاب ہے۔
جہاں HTMX کام سنبھال لیتا ہے
سب سے واضح کامیابی تب ملی جب میں نے اپنے پروجیکٹس کے بورنگ حصوں پر نظر ڈالی۔ Admin panels وہ پہلے حصے تھے جو تبدیل ہوئے۔ ایک admin backend کو عام طور پر ریکارڈز کی ایک ٹیبل، چند ایکشن بٹنز، paginated filters، اور ایک یا دو فارمز کی ضرورت ہوتی ہے۔ ان میں سے کسی کو بھی virtual DOM کی ضرورت نہیں ہوتی۔ اسے جس چیز کی ضرورت ہے وہ ہے تیز رفتار جزوی اپ ڈیٹس (partial updates)۔
HTMX کے ساتھ، ایک delete بٹن hx-delete اور hx-target attributes کے ساتھ ایک ٹیگ بن جاتا ہے۔ اس پر کلک کریں، براؤزر درخواست بھیجتا ہے، اور سرور ایک ریفریش شدہ ٹیبل رو (row) کے ساتھ جواب دیتا ہے۔