Vroeger greep ik uit reflex naar Vue.js. Elk project begon op dezelfde manier: de CLI installeren, de router instellen, de store configureren en het geheel verpakken in een single-page application shell. Het maakte niet uit of ik een real-time dashboard bouwde of een simpel contactformulier. Vue was mijn standaard, en ik ging ervan uit dat alles wat lichter was een stap terug was.
Deze gewoonte komt veel voor. Als je jarenlang in het React- of Vue-ecosysteem hebt gezeten, begint het SPA-model onvermijdelijk te voelen. Je stopt met jezelf de vraag te stellen of je die hoeveelheid mechanica eigenlijk wel nodig hebt. Je grijpt er gewoon naar. Na verloop van tijd merkte ik iets verontrustends op. Ik was Vuex-stores aan het koppelen voor beheerschermen die alleen een status hoefden om te zetten en een tabel hoefden te verversen. Ik was fetch-logica aan het samenstellen voor landingspagina's die alleen een e-mailadres hoefden te verzenden. De complexiteit kwam niet voort uit de problemen. Het kwam voort uit mijn keuze voor de tool.
Toen begon ik HTMX te gebruiken. De verschuiving was stiller dan ik verwachtte, maar het veranderde hoe ik mijn stack kies.
Wat HTMX eigenlijk doet
De meeste online discussies begrijpen dit verkeerd. Mensen presenteren het als een strijd tussen Vue versus React versus HTMX. Die vergelijking mist volledig het punt. HTMX is geen SPA-framework. Het wil Vue niet vervangen. Het is een bibliotheek die HTML meer laat doen dan de browser standaard biedt.
In plaats van een component te schrijven die wordt gemount, JSON ophaalt, deze parseert naar een lokale state en een lijst opnieuw rendert, voeg je een attribuut toe aan een knop. De server stuurt HTML-fragmenten terug, geen payloads van data. De browser vervangt de inhoud op de juiste plek. Je werkt nog steeds met server-rendered pagina's, maar je krijgt de interactiviteit die mensen meestal associëren met zware JavaScript front-ends.
Dit is geen downgrade. Het is een ander model. Vue vraagt je om een client-side applicatie te bouwen en de state in de browser te beheren. HTMX vraagt je om de state op de server te houden en HTML over de lijn te sturen. Omdat ze verschillende soorten problemen oplossen, kunnen ze beide zonder conflict in hetzelfde project naast elkaar bestaan.
Wanneer Vue nog steeds de juiste keuze is
Complexe interfaces hebben Vue nodig. Als je een real-time analytics dashboard bouwt met drag-and-drop widgets, geneste filters en live grafieken die gegevens delen over meerdere weergaven, dan wil je een reactief framework. De browser moet die state beheren. Je wilt niet voor elke actie waarbij een gebruiker een grafiek versleept of een filtergroep omzet, een round-trip naar de server maken. Het componentmodel, het reactiviteitssysteem en het ecosysteem van Vue zijn precies hiervoor gebouwd.
Hetzelfde geldt voor zeer interactieve consumententoepassingen. Denk aan een designtool, een collaboratief whiteboard of een muzieksequencer. Dit zijn geen documenten met knoppen. Het zijn applicaties die in de browser leven. Voor dat werk is Vue nog steeds mijn eerste keuze.
Waar HTMX het overneemt
De duidelijkste winst kwam toen ik naar de saaie onderdelen van mijn projecten keek. Admin-panels waren de eersten die veranderden. Een admin-backend heeft meestal een tabel met records nodig, een paar actieknoppen, gepagineerde filters en een formulier of twee. Geen van dat heeft een virtual DOM nodig. Wat het wel nodig heeft, zijn snelle gedeeltelijke updates.
Met HTMX wordt een verwijderknop een tag met hx-delete en hx-target attributen. Klik erop, de browser stuurt de aanvraag, de server reageert met een verversde tabelrij