Wer heute noch mit MS Access und VBA arbeitet, kennt das Gefühl: Die Sprache funktioniert, die Lösungen laufen – aber irgendwie wirkt alles wie ein Überbleibsel aus einer anderen Zeit. Microsoft selbst hat VBA seit Jahren nicht mehr weiterentwickelt. Kein modernes Tooling, keine 64-Bit-Unterstützung ohne Frickelei, keine echte Zukunftsperspektive. In diese Lücke stößt seit einigen Jahren ein Projekt, das in der Access-Community gerade wieder Aufmerksamkeit bekommt: twinBASIC.
Was ist twinBASIC überhaupt?
twinBASIC ist eine neue Programmiersprache und Entwicklungsumgebung, die zu 100 Prozent abwärtskompatibel mit VBA sein soll. Das klingt zunächst unspektakulär – ist es aber nicht. Der Ansatz ist: Vorhandener VBA-Code soll ohne Anpassungen lauffähig sein, während man gleichzeitig von modernen Sprachfeatures profitieren kann, die VBA nie hatte.
Dazu gehören unter anderem echte Multithreading-Unterstützung, ein modernes IDE-Erlebnis im Browser beziehungsweise als Desktop-App, verbesserte 64-Bit-Unterstützung, und die Möglichkeit, COM-DLLs und ActiveX-Komponenten zu erstellen – also genau die Art von Bibliotheken, die in Access-Projekten häufig zum Einsatz kommen. Das Projekt wird von einem einzelnen Entwickler namens Wayne Phillips vorangetrieben und ist bisher als Freeware verfügbar, mit einem optionalen Sponsor-Modell.
Das jüngste Update hat vor allem unter Access-Entwicklern wieder für Gesprächsstoff gesorgt, weil Stabilität und Funktionsumfang spürbar gewachsen sind.
Was twinBASIC gut kann
Der größte Vorteil liegt auf der Hand: VBA-Code läuft ohne Umschreiben. Wer also eine gewachsene Access-Anwendung mit tausenden Zeilen VBA hat, muss nicht von vorne anfangen. Das ist kein Kleinigkeit – es ist für viele KMU-Projekte der entscheidende Punkt.
Darüber hinaus bietet twinBASIC einige Dinge, die VBA schlicht nie hatte:
- Echte Namespaces für sauberere Codestruktur
- Generics und moderne Sprachkonstrukte, die den Code lesbarer machen
- Multithreading, das in komplexen Auswertungsszenarien relevant werden kann
- Eine zeitgemäße IDE, die sich nicht anfühlt wie ein Werkzeug aus dem Jahr 2003
Für Entwickler, die COM-DLLs für Access-Anwendungen bauen, ist twinBASIC besonders interessant: Es kann diese Komponenten erzeugen, ohne dass man auf Visual Basic 6 oder umständliche Workarounds angewiesen ist.
Was twinBASIC (noch) nicht kann
Hier muss ich ehrlich sein, denn das gehört zur Abwägung dazu.
twinBASIC ist kein Microsoft-Produkt. Es gibt keine Garantien für langfristigen Support, und das Projekt hängt im Wesentlichen an einer Einzelperson. Für produktive KMU-Umgebungen ist das ein echter Risikofaktor, den man nicht kleinreden sollte.
Die Sprache ist außerdem noch nicht fertig. Es gibt Funktionen, die noch nicht vollständig implementiert sind, und die Dokumentation ist – freundlich formuliert – ausbaufähig. Wer heute eine neue Access-Lösung für einen Kunden baut und dabei auf twinBASIC setzt, geht ein Wette auf die Zukunft eines Community-Projekts ein.
Auch die Integration in bestehende Access-Projekte ist nicht so nahtlos wie manchmal suggeriert: twinBASIC ist eine eigene Entwicklungsumgebung, kein direktes Plug-in für Access. Der Code muss kompiliert und als COM-Komponente eingebunden werden – das ist machbar, aber kein Selbstläufer.
Kurzfassung der Vor- und Nachteile:
- 100% VBA-Abwärtskompatibilität, aber Einzelentwickler-Projekt, kein Enterprise-Support
- Moderne Sprachfeatures, aber noch nicht feature-complete
- COM-DLL-Erstellung möglich, aber Integration in Access erfordert Zusatzaufwand
- Kostenlos nutzbar, aber Dokumentation noch lückenhaft
- Aktive Community, aber noch kein offizielles Microsoft-Backing
Für wen lohnt sich ein Blick jetzt?
Meine ehrliche Einschätzung: twinBASIC ist für den produktiven KMU-Einsatz heute noch kein vollständiger VBA-Ersatz. Dafür ist das Projekt zu jung und die Abhängigkeit von einem einzelnen Entwickler zu groß.
Aber – und das ist ein wichtiges Aber – es ist das vielversprechendste Projekt, das es in diesem Bereich seit Jahren gibt. Wer als Access- oder VBA-Entwickler arbeitet, sollte es kennen und beobachten. Besonders interessant ist es für alle, die eigene COM-Komponenten für Access-Projekte entwickeln: Hier kann twinBASIC schon heute eine sinnvolle Alternative zu VB6 sein.
Ich werde das Projekt weiter verfolgen und bei relevantem Stand auch erste praktische Erfahrungen aus eigenen Tests teilen. Die Access-Community ist klein genug, dass man solche Entwicklungen nicht verschlafen sollte – auch wenn man sie nicht blind übernimmt.
PS:
Wenn du viel mit Access arbeitest, ist twinBASIC kein Ersatz – sondern ein Werkzeug zum Aufräumen.
Schwere Berechnungen gehören nicht ins Formular-Ereignis. Zieh sie raus in eine DLL. Access bleibt schnell, die Logik läuft stabil im Hintergrund. Der Unterschied ist sofort spürbar.
Alles rund um API, HTTP und JSON ist in VBA oft ein wackeliger Kompromiss. In twinBASIC kannst du das sauber und wiederverwendbar bauen – einmal richtig, statt in jeder Datenbank neu improvisiert.
Wenn du mehrere Kundenprojekte hast, hör auf, Code zu kopieren. Bau dir zentrale DLLs für wiederkehrende Funktionen. Das spart Zeit, vermeidet Fehler und macht dich unabhängig von einzelnen Dateien.
Der größte Hebel liegt im alten VBA. Nicht wegwerfen – entkoppeln. Kritische Logik rausziehen, stabilisieren, versionieren. Access darf weiter Oberfläche sein, aber nicht mehr Single Point of Failure.
Kurz gesagt: Lass Access das tun, was es gut kann. Und alles andere ziehst du raus. Genau da wird twinBASIC interessant.
