Low-code en RAD

Onlangs heb ik me geregistreerd bij een van de vele crowdfunding-platforms die er inmiddels zijn, Collin Crowdfund. Inherent aan zulke platforms moet je een flow van formulieren door. Dat werkte redelijk gebruikersvriendelijk. De opmaak kwam me enigszins bekend voor. Het platform, of althans de front-end, is met behulp van Mendix gemaakt, een low (of no)-code platform.
Low-code wordt populairder, naast Mendix, BettyBlocks, Outsystems is er ook het Belgische Odoo en het, net door Google overgenomen, Appsheet.
Tientallen jaren geleden gebruikten we Delphi, Visual Basic, Access of dBase om snel software te maken – RAD (Rapid Application Development).

low-code, rad and application-development

Visual basic 1.0

Deze omgevingen boden allemaal een GUI-builder aan. De GUI-builder maakte mogelijk om vrij snel een database-gedreven, visuele, applicaties te maken, met formulieren, workflows, databasetoegang. Dit kon dus al begin jaren 90/!
Visual Basic 2.0 screenshot
Computers waren toen al ruimschoots snel genoeg om een GUI te tonen – je hoefde niet in omslachtige talen als C te programmeren, laat staan Assembly.

Ergens in de jaren 2000 werd het hip om software geschikt te maken voor de browser, zelfs als zo’n applicatie alleen intern gebruikt wordt. Helaas betekende dit het einde van applicatie-programmeren. Op eens moest iedere programmeur die een GUI ging maken, JavaScript, HTML, en CSS kennen en werd de-facto een system-programmer. Het gebruik van componenten, laat staan gebruik van een GUI-builders werd nauwelijks gedaan, en vaak op neergekeken. Browsers waren (en zijn) behoorlijk traag. Applicaties die ‘geschikt voor intranet of internet’ gemaakt werden waren traag, onhandig (geen sneltoetsen) en beperkt in functionaliteit. De ontwikkeling van nieuwe software duurde daarentegen heel lang en was duur.

Browsers zijn iets beter geworden, en computers zijn inmiddels nog sneller geworden. Toch verbaasd het me hoeveel tijd we (softwareontwikkelaars, ontwerpers) steken in het maken van formulier-gedreven applicaties.

Vergeleken met ontwikkeling met JavaScript, Java, HTML, CSS en wirwar van gratis open-source frameworks en libraries lijkt een low-code een grote stap vooruit. Wat we dan verliezen is vrijheid. Opeens moeten we veel geld per gebruiker betalen en zitten zowel de software als data vast in een platform.
Al die RAD tools uit de jaren 90 hadden dat probleem niet.

Kunnen we als ontwikkelaars en architecten voor een tussenstap kiezen? Misschien moeten we investeren in goede GUI-builders en makkelijke te gebruiken GUI-libraries? Misschien besluiten dat als we een formulierapplicatie gaan maken, het niet nodig eigen CSS-styling te gaan toepassen.
Moeten we zelf een Jenkins-server opzetten, scripts en uitgebreide wiki-pagina’s schrijven die een beginnend teamlid moet begrijpen voordat hij of zij kan bijdragen? In plaats daarvan zouden we ook kunnen uitzoeken hoe we onze software naar een PaaS kunnen verhuizen. In plaats van dagen verspillen aan het uitzoeken hoe we we fail-over en backup van onze database kunnen configureren, zouden we ook database-as-as-service kunnen overwegen.

Je hoeft niet over te stappen naar een low-code platform om naast een iemand te gaan zitten en samen met hem of haar een prototype te maken.