Bei traditionellen CGI- oder eingebetteten Skripten (asp, php) fällt eine Trennung der Applikationslogik von der Oberfläche relativ schwer. Dies führt nicht nur zu schwer verständlichem Spaghetti-Code, in dem Programmanweisungen und HTML gemischt sind, sondern macht die HTML-Vorlagen für Tools wie Dreamweaver oder GoLive praktisch nutzlos. Zusätzlich wird das Zusammenspiel von Programmierern und Designern erschwert. In IOWA besteht eine klare Trennung zwischen Editor-freundlichem HTML-Code und einem einzigen Block aus reinem Ruby-Code.
Das Anfrage-Antwort-Verfahren sorgt dafür, dass traditionelle Skripte die
Eingaben einer Seite auf einer zweiten Seite auswerten. Spätestens bei
nachträglichen Änderungen kann dies zu Albträumen führen. IOWA
![[*]](footnote.png)
belässt den
Kontrollfluss auf der gleichen Seite, selbst mehrere Links oder Submits können
auf einer Seite verbleiben. Dadurch bleibt die Logik da, wo sie hingehört: auf
der gleichen Seite wie das Formular.
CGI-Anwendungen speichern Zustandsinformationen auf der Clientseite entweder in Form von Cookies oder kryptischen URL- Anforderungstrings. IOWA-Seiten sind Objekte, die alle Zustände einer Session serverseitig speichern und verwalten können.
Anwendungsentwickler, die von modernen objektorientierten Frameworks verwöhnt sind, fühlen sich in die Steinzeit zurück katapultiert, wenn sie sich mit den Low-Level-Details des Web-developments herumplagen müssen. Ruby und IOWA bieten eine dynamische Entwicklungsumgebung, wie sie für Smalltalk- und Objective-C-Anhänger gewohnt ist.
Das von IOWA benutzte Verfahren ist denkbar einfach. Ein Ruby-CGI-Programm oder das mod_iowa-C-Modul eines Apache-Servers schickt die URL und die Request-Parameter über einen Socket an einen laufenden IOWA-Server, der dann über denselben Socket seine Antwort zurückschickt.