Ik bouwde jTorm: een CSS-achtige, out-of-band template-transformatietaal (TSS), een Node.js UI-engine en een Magento-module met thema. Een parser, een domeinspecifieke taal en een plugin-engine — in productie gedraaid op een echte webshop. Dit is het eerlijke verhaal: wat het doet, waarom het kernidee echt goed is, en de eerlijke afweging waar het wél en niet zinvol is in het AI-tijdperk.
Het ene echte idee: fork de template nooit
Een platform-template aanpassen betekent meestal: de template kopiëren en de kopie bewerken — een fork die je vervolgens bij elke upstream-upgrade met de hand moet bijwerken. jTorm draait dat om. De template blijft ongewijzigd; je aanpassing leeft als een aparte, declaratieve regelset (TSS) die nodes selecteert en op rendertijd transformeert — text, attr, swap, move, wrap, each, if, insert, ui, en meer. Omdat de fork nooit bestaat, bestaat de upgrade-samenvoegstap ook nooit.
Wat ik daadwerkelijk bouwde
Onder het CSS-achtige oppervlak zit een echte engine zonder runtime-dependencies:
- een handgeschreven parser voor de TSS-taal;
- een transformatie-vocabulaire dat de markup out-of-band herschrijft;
- een data-binding-minitaal — dot-paths, concatenatie, literals en type-coercion;
- een method-plugin-architectuur (validate / handle / params / alias) zodat de taal uitbreidbaar blijft;
- een isomorfe pipeline — dezelfde template + regels + data rendert server-side én in de browser;
- event-hooks en caching;
- een schema.org-getypeerde component-mapper die getypeerde componenten naar HTML rendert — met de aanzet om later andere UI-frameworks te targeten (vandaag bestaat alleen de HTML-backend).
En het draait in productie op een omzetgenererende webshop: een Node.js-engine doet het renderen, aangestuurd door een custom Magento (PHP) module met thema die hem data voeren en zijn output terug in de pagina plaatsen. De engine is niet herschreven in PHP — de Magento-kant is een dunne host die het werk delegeert naar Node. Eén engine, geïntegreerd in een platform dat niet zijn moedertaal is. De code is openbaar:
- jtorm-framework — de kern: TSS-parser, transformatie-vocabulaire, method-plugin-systeem en schema.org-componentlaag
- nodejs-jtorm-ui-engine — de Node.js-host die het framework bedraadt en rendering via een API aanbiedt
- magento-module-jtorm — de Magento (PHP) integratie die de engine in productie aanstuurt
- magento-module-jtorm-theme — het bijbehorende Magento-thema
Maakt AI het overbodig? Nee — maar het verkleint de voorsprong
Het is verleidelijk om te zeggen "AI doet dat nu toch gewoon." Maar dan worden twee verschillende dingen op één hoop gegooid. jTorm geeft je een architecturale eigenschap op rendertijd: de aanpassing leeft buiten het kernbestand, dus de fork bestaat nooit en de upgradekost is vrijwel nul. AI geeft je een versnelling tijdens het ontwikkelen: het schrijft de override en voegt je geforkte template bij een upgrade opnieuw samen — goedkoper dan vroeger, maar nog steeds een samenvoeging die je moet uitvoeren, controleren en testen, en AI-samenvoegingen kunnen stil fout gaan. AI verlaagt dus de kost van het alternatief dat jTorm wilde vermijden; het vervangt niet het voordeel van "er is helemaal geen samenvoegstap."
De eerlijke tegenwind (grotendeels niet over AI)
Het AI-samenvoegverhaal is misschien een derde van het plaatje. De rest is lastiger, en vooral structureel:
- De economie van een eigen DSL werd slechter. Modellen kunnen een taal van één auteur niet aanvullen, uitleggen of debuggen — er is geen trainingsdata voor. jTorm nu adopteren betekent tegen de AI-rugwind in roeien, een adoptiekost die er niet was toen ik begon.
- Het ecosysteem verkleinde het probleem bij de bron. Componenten, slots en hooks vervingen transformatie-achteraf als aanpassingsmodel; in Magento specifiek maakten Hyvä en headless-storefronts de override-drift kleiner en vriendelijker.
- De markt heeft al gestemd. Transphporm — hetzelfde idee, volwassener en PHP-native, dat jTorm als inspiratie crediteert — haalde de doorbraak nooit.
- Bus-factor van één. Een handgeschreven parser en compacte code zijn prima voor "ik onderhoud het zelf" en een muur voor "laat het uitgroeien tot een framework."
Waar is het dan voor?
Ik behandel jTorm als precies wat het eerlijk gezien is: een scherp intern gereedschap waar de upgrade-veiligheid zich terugbetaalt op de shops die ik draai, en een portfolio-artefact dat de engineering-diepte erachter laat zien. Ik jaag het niet na als publiek framework — "niet alles wat je bouwt hoeft een product te worden" is een prima technische beslissing, en dat hardop zeggen is dezelfde eerlijkheid die ik in klantwerk breng.
Dat oordeel — bouw het moeilijke ding als het zich terugbetaalt, en zeg "tot hier en niet verder" als dat niet zo is — is hetzelfde oordeel dat ik meebreng naar maatwerk-webontwikkeling en elk project dat ik aanneem.