## Waarom ik koos voor Alpine.js en afstand nam van HTMX {#sec-a4901ce975c0} Hallo. Vandaag wil ik als Django-ontwikkelaar die voornamelijk op de backend gericht is, praten over de twee hoofdrolspelers die de 'minder [[JavaScript]] gebruiken'-trend in het recente frontend-ecosysteem aanvoeren: **[[Alpine.js]]** en **[[HTMX]]**. Voor mensen zoals ik, die bekend zijn met Django en Python, zijn deze tools een zegen. Ze stellen je in staat om zonder complexe React- of Vue-instellingen toch behoorlijk indrukwekkende moderne websites te bouwen. Deze twee vrienden verschillen echter sterk in hun gebruiksdoel en karakter. HTMX is gespecialiseerd in communicatie met de server, terwijl Alpine.js gespecialiseerd is in UI-operaties binnen de browser. Om met de deur in huis te vallen: ik ben een grote fan geworden van **Alpine.js** en heb wat afstand genomen van **HTMX**. Ik zal de redenen daarvoor eerlijk delen. ![Vergelijkingsafbeelding van htmx en Alpine.js](/media/whitedec/blog_img/f0fd0eabe37b4dfdba84c4413b0ed893.webp) --- ## 1. Voorkennis: [[HTMX]] vs [[Alpine.js]] in één oogopslag {#sec-588a3f69cb07} Voordat we dieper ingaan op de materie, heb ik voor degenen die minder bekend zijn met deze twee concepten een korte vergelijkingstabel opgesteld. | Categorie | HTMX | Alpine.js | | :--- | :--- | :--- | | **Kern doel** | **Servercommunicatie** (AJAX-verzoek gevolgd door HTML-vervanging) | **Client-side statusbeheer** (UI-interactie) | | **Filosofie** | Uitbreiding van HTML (servergericht) | Lichtgewicht versie van Vue/React (browsergericht) | | **Gegevensformaat** | **HTML-fragment (Snippet)** | **JSON-gegevens** | | **Belangrijkste voordelen** | Oneindig scrollen, real-time zoeken (SSR-methode) | Modals, dropdowns, tabbladen wisselen (CSR-methode) | --- ## 2. Vier redenen waarom ik HTMX steeds meer begon te vermijden {#sec-cbf50b3543fc} HTMX lijkt op het eerste gezicht erg handig. Maar hoe dieper ik het in projecten toepaste, des te meer punten van conflict ontstonden met mijn ontwikkelingsaanpak. ### ① "Moet ik per se HTML-fragmenten op de server genereren?" (Het onderhoudsdilemma) {#sec-ccc17a7c9816} Om HTMX te gebruiken, moet de server (Django) **HTML-fragmenten** retourneren in plaats van JSON. Dit paste niet helemaal bij mijn voorkeur. * **Mijn perspectief:** "Is het niet duidelijker in taakverdeling als de server alleen nette gegevens levert en de client de rendering doet?" * **Standpunt van HTMX:** "Het ontvangen van JSON en opnieuw renderen is verspilling. De server die het uiteindelijke resultaat levert, is de Single Source of Truth (SSOT)." Wanneer ik in Django-templates conditionele logica zoals `if request.htmx:` toevoegde, kon ik het gevoel niet van me afschudden dat de view-logica gefragmenteerd en rommelig werd. ### ② Is AJAX-logica niet al eenvoudig genoeg? {#sec-3d93df5c1f47} De `hx-get` en `hx-target` van HTMX zijn uitstekende 'syntactische suiker'. Maar voor iemand die AJAX al heeft geïmplementeerd met Vanilla JS of eigen utility-functies, zijn ze niet essentieel. De **fetch API** van moderne browsers is ongelooflijk krachtig. Een enkele regel `fetch` binnen `x-init` van Alpine.js levert al voldoende declaratieve en nette code op, waardoor ik minder de noodzaak voelde om de regels van weer een andere bibliotheek te volgen. ### ③ De fatale onderbreking van "Locality of Behavior (LoB)" {#sec-2cd75954bdb6} Ik ben een groot fan van Alpine.js. Dat komt omdat je **direct kunt zien** wat de code doet. Maar HTMX is anders. * **Alpine.js:** Het gedrag bevindt zich in de HTML, en het resultaat vindt direct plaats in het browsermemory. * **HTMX:** Het gedrag is gedefinieerd in de HTML, maar om **het resultaat (HTML-fragment) te zien, moet je de servercode (`views.py`) doorzoeken.** Ik vond het zeer inefficiënt dat de context in dit proces werd verbroken. De irritatie van het steeds weer moeten openen van backend-bestanden tijdens het lezen van code was een van de doorslaggevende redenen waarom ik htmx begon te vermijden. ### ④ Het ongemak van subtiele latentie {#sec-c2deaaea82da} HTMX gaat ervan uit dat elke interactie een netwerk-roundtrip vereist. Hoe snel de server ook is, het kan de snelheid van Alpine.js, dat direct in de browser reageert, niet evenaren. Die subtiele vertraging van 0,1 tot 0,2 seconden die je voelt bij een klik, was voor mij een behoorlijk storende factor vanuit het oogpunt van gebruikerservaring. --- ## Tot slot: Wat zijn jullie gedachten? {#sec-fbc8664e9292} Samenvattend, ik geef de voorkeur aan een structuur waarin **gegevens via een API (JSON) stromen en de UI direct in de browser reageert**. Daarom is de combinatie van Alpine.js en DRF (Django REST Framework) mijn favoriet. Het grappige is dat ik op recente communities zoals Reddit veel meningen tegenkwam die precies het tegenovergestelde waren van de mijne. Veel mensen vinden [[Alpine.js]] complex en stappen over op HTMX of zelfs een combinatie van jQuery + HTMX. Hoe dan ook, het lijkt erop dat HTMX tegenwoordig zeker overweldigend populair is. Natuurlijk is [[HTMX]] een uitstekende tool. Het paste alleen niet bij mijn ontwikkelstijl en systeemontwerpaanpak. Ik denk dat er **"geen enkel juist antwoord is, alleen wat bij jou past."** Hoe zit het met jullie? Zijn jullie tevreden met de servergerichte filosofie van HTMX, of geven jullie net als ik de voorkeur aan JSON-responses en de directe reactiviteit van Alpine.js? Laat jullie mening achter in de reacties! Misschien heb ik HTMX te vroeg aan de kant gezet, voordat ik de ware kracht ervan volledig besefte?