Ein Logistikkunde erzählte uns letztes Quartal, er habe 18 Monate und rund 1,4 Millionen Euro in ein Mendix-Projekt investiert, bevor er es aufgab. Die Plattform bewältigte die ersten 20 Bildschirme hervorragend. Bildschirm 21 brauchte ein nicht standardmäßiges Daten-Grid, und der Workaround dauerte länger, als das gesamte Modul in Angular neu zu bauen.
Diese Geschichte ist der Grund, warum wir bei der Bezeichnung von DEX Elements vorsichtig sind. Es ist kein Low-Code.
Die Low-Code-Falle
Low-Code-Plattformen machten ein überzeugendes Versprechen. Enterprise-Anwendungen bauen, ohne viel Code zu schreiben. Drag, Drop, ausliefern. Citizen Developer. Das Versprechen liefert — bis zu einem Punkt.
Der Punkt ist der Moment, in dem Sie eine komplexe Validierungsregel, ein nicht standardmäßiges Layout, ein performancekritisches Daten-Grid oder eine Integration mit einer Enterprise-API brauchen, die nicht in das Denkmodell der Plattform passt. Dann kommt die Wand, und die Wand ist brutal. Sie schreiben Logik in einer proprietären Ausdruckssprache, debuggen ohne richtige Tools und deployen in einer Runtime, die Sie nicht inspizieren können.
Wir haben beobachtet, wie Unternehmen Mendix oder OutSystems für ein Projekt einführen und dann mehr Ingenieurstunden damit verbringen, die Plattform zu umgehen, als sie gebraucht hätten, um die Anwendung richtig zu bauen.
Was wir stattdessen gebaut haben
DEX Elements verwendet JSON-Deskriptoren, um zu definieren, was Anwendungen tun. Das klingt nach Low-Code, aber die Mechanik weicht in vier relevanten Punkten ab.
Low-Code versteckt Komplexität. DEX macht sie inspizierbar. Der Deskriptor ist eine transparente Spezifikation. Lesen Sie ihn, versionieren Sie ihn, vergleichen Sie ihn, reviewen Sie ihn mit denselben Tools, die das Team bereits für TypeScript nutzt.
Low-Code sperrt Sie ein. DEX generiert Standard-TypeScript. Wenn ein Kunde uns morgen nicht mehr nutzt, besitzt er trotzdem eine normale Anwendung, die jeder Entwickler warten kann. Es gibt keine Runtime-Abhängigkeit von unserer Infrastruktur.
Low-Code begrenzt Erweiterbarkeit. DEX hat explizite Escape Hatches. Jeder Bildschirm kann benutzerdefinierte Komponenten in reinem TypeScript einbinden. Das Framework deckt rund 90 % der Fälle ab. Benutzerdefinierter Code deckt den Rest ab — ohne Strafaufschlag.
Low-Code berechnet pro Benutzer. DEX berechnet für die Plattform. Die Preisgestaltung hat nichts damit zu tun, wie viele Personen das nutzen, was darauf aufgebaut wurde.
Der eigentliche Unterschied
Low-Code ist eine Runtime. Sie bauen darauf, deployen darauf, skalieren darauf. Die Anwendung existiert nicht ohne sie.
DEX ist ein Generator. Er erzeugt Anwendungen, die unabhängig laufen. Das Framework bietet Struktur während der Entwicklung. Die Ausgabe ist nach dem Deployment autonom.
Dieser Unterschied ist enorm wichtig für Unternehmen, die keine Plattformabhängigkeit für missionskritische Systeme akzeptieren können. Sie haben die Lektion einmal mit Oracle Forms gelernt. Sie werden denselben Fehler nicht mit einem Low-Code-Anbieter machen.
Für wen das gedacht ist
DEX ist nicht das richtige Tool für jemanden, der ein Kontaktformular oder einen einfachen Genehmigungsworkflow baut. Dafür gibt es genug andere Tools.
DEX ist für das Team, das ein 50-Bildschirm-ERP-Modul mit komplexen Validierungsregeln, rollenbasiertem Zugriff, Audit-Logging und Echtzeit-API-Integration baut, es in Monaten ausgeliefert haben will und sich weigert, Vendor Lock-In als Preis der Geschwindigkeit zu akzeptieren.
Das ist ein spezifischer Kunde. Wir wissen genau, wer das ist. Sie sind es leid, gesagt zu bekommen, ihre einzigen Optionen seien langsam und sicher oder schnell und eingesperrt. Wir denken, es gibt eine dritte Option — und sie beginnt damit, die Ausgabe zu ihrer zu machen.