Zamani nilikuwa nikitumia Vue.js kwa mazoea. Kila mradi ulianza kwa njia ile ile: install CLI, weka upangaji wa router, sanidi store, na kufunika kila kitu kwenye shell ya single-page application. Haikujali kama nilikuwa nikitengeneza real-time dashboard au fomu rahisi ya mawasiliano. Vue ilikuwa chaguo langu la kwanza, na nilidhani kuwa kitu chochote chepesi zaidi kilikuwa hatua ya nyuma.
Tabia hii ni ya kawaida. Ikiwa umetumia miaka mingi ndani ya mfumo wa React au Vue, mfumo wa SPA unaanza kuonekana kama jambo lisiloepukika. Unaacha kuuliza ikiwa kweli unahitaji mashine nyingi kiasi hicho. Unazitumia tu. Baada ya muda, niligundua kitu chenye kusumbua. Nilikuwa nikitengeneza Vuex stores kwa ajili ya skrini za admin ambazo zilikuwa zinahitaji tu kubadilisha hali (toggle a status) na kuonyesha upya jedwali (refresh a table). Nilikuwa nikitengeneza logic ya fetch kwa ajili ya landing pages ambazo zilikuwa zinahitaji tu kutuma anwani ya barua pepe. Ugumu haukutokana na matatizo yenyewe. Ulitokana na chaguo langu la kifaa.
Kisha nikaanza kutumia HTMX. Mabadiliko yalikuwa tulivu kuliko nilivyotarajia, lakini yalibadilisha jinsi ninavyochagua stack yangu.
Kile HTMX Kinachofanya Haswa
Majadiliano mengi ya mtandaoni yanafanya makosa hapa. Watu wanaiweka kama vita kati ya Vue dhidi ya React dhidi ya HTMX. Ulinganishi huo unakosa hoja kabisa. HTMX si framework ya SPA. Haitaki kuchukua nafasi ya Vue. Ni library inayofanya HTML ifanye zaidi ya kile kivinjari (browser) kinachotoa kiasili.
Badala ya kuandika component inayomount, inachukua JSON, inaitafsiri kuwa local state, na kuirudisha upya orodha (re-renders a list), unaongeza attribute kwenye kitufe. Seva inarudisha HTML fragments, siyo payloads za data. Kivinjari kinabadilisha maudhui na kuyaweka mahali husika. Bado unafanya kazi na kurasa zinazotengenezwa na seva (server-rendered pages), lakini unapata mwingiliano (interactivity) ambao watu kawaida huuhusisha na JavaScript front ends nzito.
Huu si upungufu wa ubora. Ni mfumo tofauti. Vue inakuomba ujenge application ya upande wa mteja (client-side) na usimamie state kwenye kivinjari. HTMX inakuomba uweke state kwenye seva na kutuma HTML kupitia mtandao. Kwa sababu zinatatua aina tofauti za matatizo, zote zinaweza kuwepo kwenye mradi mmoja bila mgongano.
Wakati Vue Bado Ni Chaguo Sahihi
Interface tata zinahitaji Vue. Ikiwa unajenga real-time analytics dashboard yenye widgets za drag-and-drop, vichujio vilivyofungamana (nested filtering), na chati za moja kwa moja (live charts) zinazoshiriki data kwenye mitazamo (views) mingi, unahitaji reactive framework. Kivinjari kinapaswa kumiliki state hiyo. Hutaki kufanya mzunguko kwenda kwenye seva (round-trip to the server) kila wakati mtumiaji anapovuta chati au kubadilisha kikundi cha kichujio. Mfumo wa component wa Vue, mfumo wake wa reactivity, na mfumo wake (ecosystem) umeundwa haswa kwa ajili ya hili.
Hali kadhalika kwa programu za watumiaji zinazohitaji mwingiliano mkubwa. Fikiria kifaa cha usanifu (design tool), ubao wa ushirikiano (collaborative whiteboard), au music sequencer. Hizi si nyaraka zenye vitufe. Ni application zinazoishi kwenye kivinjari. Kwa kazi hiyo, Vue bado ni chaguo langu la kwanza.
Pale HTMX Inapochukua Nafasi
Ushindi wa wazi zaidi ulikuja nilipoangalia sehemu zisizovutia za miradi yangu. Paneli za admin ndizo zilizoanza kubadilika kwanza. Backend ya admin kwa kawaida inahitaji jedwali la rekodi, vitufe vichache vya hatua (action buttons), vichujio vya kurasa (paginated filters), na fomu moja au mbili. Hakuna katika hayo kinachohitaji virtual DOM. Kinachohitaji ni updates za haraka za sehemu fulani (partial updates).
Kwa kutumia HTMX, kitufe cha kufuta kinakuwa tag yenye attributes za hx-delete na hx-target. Ukibonyeza, kivinjari kinatuma ombi, seva inajibu kwa kurudisha mstari wa jedwali uliosasishwa