Review: Tools for rapid Web development

With WYSIWYG prototyping environments and preconfigured graphical components, rapid Web development tools can help you build applications faster -- but with less flexibility

When it's time to develop your Web application, you have choices: You could roll up your sleeves, select your programming languages, pile references manuals on your desk, and begin the time-consuming task of building your application from scratch. You might take a shortcut and grab one of the many open source frameworks available, such as symfony or Zend for PHP programmers, Django for Python users, Ruby on Rails, and so forth. Or you might consider one of the many rapid development tools now available to the Web world.

I had a chance to test-drive five Web development systems that claim to significantly cut application development time: Alpha Software's Alpha Five 10; Iron Speed Designer 6.2.1; LANSA's LANSA for the Web 11.5; OutSystem's Agile Platform 5.0; and MLState's OPA (One Pot Application) 2.0 Beta.

[ Show your support for InfoWorld's peace plan between Apple and Flash. | Keep up with app dev issues and trends with InfoWorld's Fatal Exception and Strategic Developer blogs. ]

Based on my testing, I can say that these tools provide a speed boost to development with features such as WYSIWYG prototyping environments, loads of prebuilt graphical components, and easy deployment. Importantly, some of the tools are specialized, designed primarily for constructing database-centric Web applications, but even those tools offer enough flexibility to create more generic apps.

Find out how the Web development tools fared in InfoWorld Test Center's review. (Please note that we did not score OPA 2.0, as it's still in beta.)

Read the first review: Alpha Five 10

Alpha Five 10First released way back in 1982, Alpha Five at first blush appears to be just a database management tool, capable of talking to MySQL, Oracle, SQL Server, or any RDBMs with an ODBC or ADO interface. Were those its only functions, it would still be an admirable product. Although building database applications -- desktop and Web-based -- are Alpha Five's forte, it is nevertheless flexible enough for developing general Web applications. However, there's likely no advantage to using Alpha Five for the latter as opposed to, say, ASP.Net.

Alpha Five includes its own Web application server, referred to as WAS (Web Application Server). Neither an IIS nor Apache variant, WAS recognizes A5W pages -- files that include HTML with embedded Xbasic, the company's proprietary language that is in no way related to the open source language of the same name. Other than the ability to run A5W pages, WAS behaves much like other Web servers. It has its own root directory (C:\A5Webroot on a development system) from which applications are deployed.

Xbasic powers the behavior of most controls in desktop applications and executes an Alpha Five Web application's server-side code. Alpha Five's Xbasic has everything you'd find in any complete BASIC-language implementation, with additional system objects and functions for manipulating databases.

Web development in Alpha Five draws upon a massive collection of UI components, reinforced by an extensive event model with server- and client-side hooks. Alpha Five strikes a good balance between shielding developers from writing code, while permitting them to do so when necessary. Its codeless AJAX feature helps you build AJAX-enabled controls without having to write AJAX. Its event hooks mean you can easily incorporate third-party JavaScript libraries such as Dojo or jQuery.

You build Web applications in Alpha Five one page at a time. First, you select the components you'll be using on a Web page, then you work with the WYSIWYG HTML editor to stitch the components together into a final form. Double-click on any component within this editor, and a component editor opens, where you can modify the component's properties.

Alpha Five's supply of Web components include grids, forms, dialogs, navigation components (such as toolbars and menus), login components, and others. There are countless variations on these themes. Each component is awash with configurable properties and comes with plenty of event hooks for attaching custom code. Select a control and choose an event from the list recognized by the control; you're taken to the stub Xbasic function that responds to that event. If you've used any popular component-based IDE GUI-building environment, you'll be right at home here.

Many of the more complex controls include intelligently predefined actions. For example, when a user has entered data into a form control and clicks the Submit button, the values within the form are validated. If they all "pass," the system executes the Xbasic routine identified by the form's AfterValidate event.

Alpha Five's component editor lets you select the fields that will be displayed in a grid control.

Alpha Five has special "component builders" that act like wizards for constructing grids and dialogs. Perhaps no control has more variations than the grid control; it is the quintessential means of displaying and managing databases, and therefore receives special treatment. You can select numerous grid geometries for displaying either single or multiple records simultaneously. You can go pretty crazy, linking grids to other grids; as long as there is a relationship in the database between one table and another, that relationship can be used to set up parent/child grid connections. These can be nested to virtually any depth.

Some controls are stunningly elaborate. The latest version of Alpha Five includes Supercontrols, which are controls that have been subclassed for specific applications. For example, the Google Maps Supercontrol lets you access Google Maps through that service's REST interface. You can use this control to, say, call up a map within a grid control, based on an address fetched from a database field.

Alpha Five uses the term genie rather than wizard to describe automated screens that guide you through gnarlier construction activities. Most grid controls populate their contents based on database queries, and the Query Genie helps you build those queries. The Query Genie is unusual in that it lets you build queries in an additive fashion, a final query being the sum of multiple smaller queries. Alpha Five even has a query by example (QBE) feature. With QBE, you enter representative values for attributes and specify the matching criteria; the QBE control will fetch rows that match the representative example.

To deploy an application, you first define a profile. This not only tells Alpha Five the destination of the deployment, but describes the mechanism whereby the code is delivered: FTP, a remote disk share, and so on. You can create multiple profiles, which enable you to deploy a single application to a variety of destinations.

Alpha Five's documentation is as good as it gets. Its help system goes on for miles and is the proper mixture of how-to and reference information.

Read the next review: Iron Speed Designer 6.2.1

Iron Speed Designer 6.2.1Iron Speed Designer, like Alpha Five, can build both desktop and Web applications, and it excels at creating database-centric applications. Unlike Alpha Five, however, Iron Speed does not use a proprietary runtime. Peek under the hood, and you'll see that Iron Speed Designer is really a development front end for .Net and ASP.Net applications. The Designer emits either C# or VB.Net (your choice).

Iron Speed Designer's principal function is to create database access and management applications, but an application's complete source code is available. Thus, a skilled developer could extend that code to produce most any conceivable Web application. More precisely, Iron Speed builds CRUD (create, read, update, and delete) interfaces for databases. It won't create your application's "business logic" -- that is, code beyond the fundamental CRUD operations. Iron Speed's documentation claims that about 80% of a database-centric application's development is spent building the CRUD code.

Building an application in Iron Speed follows a series of defined steps. It's like cooking from a recipe. Of course, the first step is to create (or connect to) whatever database your application will use. Next, you select your application's display theme. This sets a standard look and feel for all the generated code. The number of available styles depends on the edition of the package you choose. Although there are plenty in the free edition, the Enterprise Edition lets you create custom styles.

Once you've chosen your application's theme, select which sorts of pages you want the designer to create. Most of the generated pages are grid-style layouts of one form or another. You can choose pages that provide view-only data access or pages that provide editing functions. Plus, there are master-detail layout styles. Overall, Iron Speed offers close to 30 different page layouts.

Iron Speed Designer offers a fine example of "automated coding." Point it to a database, and it does the rest. Here, Iron Speed Designer has constructed a database search screen for an orders table.

Extending the generated application with your own code is relatively easy. You can access the generated source at any time. For example, select a button on a generated page, and a properties window lists all of the button's methods (methods triggered by events the button recognizes). Navigate to a chosen method's entry point and fill in your code.

Because one of the first development steps is choosing the database behind the application, Iron Speed development occurs using live data. You'll see that data via the Live Preview screen.

Iron Speed provides a variety of mechanisms to build security into your applications. You can draw on the access-control features built into the back-end database (users and roles), as well as use Active Directory-based security or Windows authentication. If you enable Iron Speed's role-based security, you can control user access down to the level of individual pages or even individual controls.

Designer's built-in MSI installer makes deployment ridiculously simple. One click is all it takes to produce an *.MSI file that you can copy to the target machine and execute in the same way you would a setup.exe file. What's more, because the application is an ASP.Net application, you can alter the target database on the production system by simply changing the connection string in the Web.config file.

Perhaps Iron Speed's best feature is the fact that generated source code is always available, and is standard C# or VB.Net. Consequently, you are not bound to any proprietary language or runtime. You can modify the source to your heart's content -- which, of course, is a sword that cuts both ways.

Read the next review: LANSA for the Web 11.5

LANSA for the Web 11.5LANSA was originally built for IBM System/36 AS/400 systems, but its applications can be compiled to run on Windows or Linux systems, as well as System/38, AS/400, iSeries, and IBM i Systems. Nevertheless, it retains the ability to produce code that uses IBM 5250 terminals as the UI device. LANSA reckons this is a feature and claims that code built to run in its earliest versions can still execute in the current version. Given that the company has been around since the late 1980s, that's impressive. (There are numerous products in LANSA's portfolio. I only examined those used for developing applications.)

LANSA can be used to build applications for the desktop, the Web, and mobile devices. You use LANSA for the Web to create Web applications; it also employs the Visual LANSA development environment and component builder to build WAMs (Web Application Modules).

WAMs are files that correspond roughly to a set of related pages in a Web application. Each is composed of both RDMLX code (LANSA's server-side language) and associated XML/XSL code (that determines client-side appearance and behavior). RDMLX is a descendant of IBM CL (Command Language), the scripting language of the OS/400 operating system. Its scripting roots show: Most commands appear to have the form of an action followed by parameters. It isn't particularly complex, but anyone unused to the language will need time to pick it up.

LANSA keeps the RDMLX and XML/XSL sides separate in the IDE, which helps divide business logic from UI logic. Inside a WAM, code is grouped into Webroutines, each of which defines the behavior of a Web page in an application. It's important to point out that LANSA for the Web can also be used to build Web services -- in which case each Webroutine would correspond to a SOAP function.

When you create an application with LANSA, you're laboring inside the meta-data repository, a database that holds everything the development environment needs to know about all of the objects used to build an application. These objects include source code and back-end database meta-information about tables (referred to as files in LANSA) and attributes (fields). The meta-data repository is roughly analogous to a project file in other IDEs, though it is something more than just a project container. Because it carries information about database fields, it also holds validation information, database triggers, referential integrity information, and even help text.

Web Application Modules, or WAMs, are composed of both RDMLX, LANSA's server-side language, and associated XML/XSL code.

When you place a particular field on a form, LANSA knows (thanks to the repository) the field's data type, how many characters it includes, what security properties are attached to it, and more. In addition, when you deploy a file/table within an application, LANSA not only deploys the fields of the table (thus defining its structure) and builds any required indexes, but also deploys the database business rules that ensure data integrity.

WebLets are the visual components of LANSA Web design. A WebLet encapsulates display properties and functionality, and it can be dragged and dropped onto a Web page in the development environment. For example, WebLets include primitive components such as check boxes, radio buttons, and text areas, as well as composite components such as a grid or a calendar. LANSA's collection of WebLets are highly parameterized, allowing wide latitude in customization.

From the IDE, you can construct WAMs, their Webroutines, and WebLets. WebLets can be dragged from a palette and dropped onto the Web Designer's WYSIWYG canvas. You can also view the source behind a Web page under construction. The IDE also includes a visual debugger. You can set breakpoints on Webroutines, launch your WAM in the debugger, and single-step through the executing RDMLX code. Other panes in the debugger provide views of current field values.

LANSA requires no special server on the back end. Its runtime system is a plug-in that works on Apache on Linux and iSystem machines, and IIS on Windows systems. It's happy with all the popular RDBMS systems: DB2, Microsoft SQL Server, Oracle, Sybase, and MySQL. Architecturally, LANSA for the Web sits on top of the LANSA runtime, which provides the execution environment for LANSA applications, as well as integrity rules for databases with which LANSA applications interact, and interfaces with a Web server (Apache or IIS).

LANSA's help is extensive. The tool is awash with CHM files, which, in turn, are full of tutorials. There's also context-sensitive help in all the tools and plenty of online tutorials. RDMLX may be off-putting, but there's lots of assistance for neophytes.

Read the next review: OutSystem Agile Platform 5.0

OutSystem Agile Platform 5.0With a name like OutSystem Agile Platform, the intent is obvious: agile development. Agi attempts this goal via a truly visual development environment. OutSystem's claim is that you can create full-featured Web applications without writing any code (though, you can do that, too, if you prefer).

The output of Agile Platform -- the code that actually executes your application -- is (depending on the edition) either .Net or Java. Therefore, applications built by the Agile Platform can execute on Windows and Linux. To choose the flavor of the generated application, you simply select the back-end server on which the application will execute, and Platform generates the proper code.

The Agile Platform consists of four components: the Platform Server, Service Studio, Integration Studio, and the Service Center Management Tool.

The Platform Server is a collection of services that execute alongside .Net or Java application servers. Platform Server creates and maintains a meta-data repository that stores all versions of applications and application components. The repository also acts as a source control system and retains the source code of previous versions. The meta-data and application repository exists within an RDBMS system, which can be either SQL Server or Oracle. However, deployed applications can use any database for which an ODBC driver exists. You can also create "integration extensions" (described later) to talk to specialized databases.

The Service Studio is a visual modeling tool used to build applications; it is the Agile Platform's IDE. It is here that you define an application's user interface, business logic, database structure, security and authentication logic -- all by dragging, dropping, and wiring together visual components. Also within the Service Studio, you define attributes of your database table, and the Platform creates the database (tables and attributes) when the application is deployed. Of course, if the database already exists, you supply that info to Agile Platform, and the application will simply connect when executed.

Integration Studio works with Microsoft Visual Studio or Eclipse to create and bring components into the Service Studio's repository. As delivered, the Agile Platform has built-in components that can do things like talk to the database, read and write Excel files, and so on. But for technologies for which the Platform has no interface -- say, a .Net-based object database -- you call on the Integration Studio to build an integration extension to provide the connectivity.

Here, Agile Platform's Service Studio builds a query for a contacts list Web action.

Integration Studio works with Visual Studio and Eclipse to help you migrate into the Agile platform. Integration Studio includes built-in wizards for reverse-engineering non-Agile-Platform code to create these extensions. For example, one such wizard will translate a .Net assembly into an extension. Integration Studio also includes a verifier that lets you check to see if an extension is "correct" and can be safely used in Service Studio.

Finally, the Service Center Management Tool is the Agile Platform's control and management center. It provides functions for creating and configuring user accounts, such as deciding which developers have access to which applications and which integration components. It can also fetch and display usage statistics for a deployed application.

A project within Agile Studio is referred to as an eSpace, and it holds a Web application's Web pages, business logic, database table definitions, and security settings. Within a Web application, the overarching control structure -- which guides how user activity moves from one page to the next -- is the Web flow. It begins at a starting point represented by an anchoring node affixed to a directed arc on the Service Studio's design canvas that serves the same purpose as the main() function in a C program. It also corresponds to a Web page (such as an .ASPX page) that is the "entry point" to your application.

Nodes that you deposit along an arc's path can either perform control operations (if-then decisions) or execute processes, and some processes can transition to other Web pages. At runtime, an application begins execution in the starting Web flow. As the user interacts with onscreen controls, such as click buttons, the runtime will execute screen actions -- event handlers triggered by the user-generated event -- and these screen actions shepherd application execution into new Web flows.

You construct the HTML that will be displayed on a Web page via a Web screen editor. This editor works in WYSIWYG fashion: You type into the Web screen and Agile Platform generates the appropriate HTML code. The process of creating individual Web pages is similar to building ASP.Net pages in Visual Studio: You freely mingle HTML with controls that you drag and drop onto the Web screen editor's canvas.

Controls trigger actions. Suppose you've created a button that saves data in a database. When you define the action triggered by the button's being pushed, you are taken to a development screen that shows another flow diagram consisting of a Start node connected to an End node. On the left, you have a hierarchical tree control filled with tools. Sublevels show categories such as User Actions, Entity Actions, Timer Actions, and so on. You can drag these actions onto the arc to define operations that are performed when the button is pushed and execution flows from start to finish.

Service Studio has plenty of controls and widgets to choose from, ranging from the simple (buttons) to the complex (form widgets). For example, the data edit widget will automatically build a form for editing data within a database table. Drag and drop it onto the screen, and it will construct its default appearance by reading the associated table, determining its field attributes, and constructing onscreen labels accordingly.

Service Studio can employ AJAX in its user-side components. If you add your own components to the Agile Environment, they can use any of the popular JavaScript libraries to handle AJAX request -- libraries such as jQuery, Prototype, Dojo, and so on.

An entity is Agile Platform's representation of a database table. Whenever you create an entity, the platform will automatically build associated actions: Create, CreateOrUpdate, Delete, Get, and so on. From there, the system already "knows" what activities you will likely perform on that entity and builds the necessary code for performing those actions. You can drag that code into your application whenever you wish.

Finally, Service Studio can create Web services and Web applications. You can expose any piece of an application's business logic as a standard Web service, and the Agile Platform will automatically create all the WSDL signatures and mappings so that the service can be used by other applications. Similarly, Service Studio can also consume Web services. Enter the WSDL address, and Service Studio will fetch the method definitions and data structures, and make them available as visual building blocks that you can drag and drop into your application.

There is a bit of a learning curve to Agile Platform. Developers accustomed to jumping directly into source code will need restraint. Although the environment doesn't prohibit that, you'll be thwarting its intent if you try to escape its paradigm too quickly. Code, in other words, should be your last resort.

Read the next review: MLState OPA 2.0 Beta

MLState OPA 2.0 BetaMLState's OPA is both a language and a development paradigm. The acronym OPA stands for One Pot Application, the implication being that everything you need to create a Web application is in a single place. With OPA, you don't need to create HTML and JavaScript pages on the client side, and PHP (or whatever server-side language you choose) and SQL on the server side. OPA serves it up all in one spot.

Actually, this claim is only partly true. Although there are no separate client and server modules in an OPA application, you have to include HTML and JavaScript code. It's sort of like building a Java servlet: You aren't completely insulated from other technologies. OPA won't select which JavaScript calls to make where; you have to express that in the code explicitly.

One thing is true: With OPA, you don't have to deal with a separate Web application server. When you compile an OPA application, it creates a single executable that contains the Web server, the business logic of the application itself, and a database runtime.

As a language, OPA is a statically and strongly typed language. In fact, the current version is so strongly typed, there are different mathematical operators for integer and floating point numbers. Documentation promises that future releases will allow overloaded operators in this case.

OPA recognizes simple data types -- integers, floats, and strings --  as well as more complex structured types such as Lists, Maps, Sets, and Iterators. OPA supports a "record" datatype, which is analogous to the C-language struct. It also has the notion of "sum," which is a way of handling variants by informing the compiler that a given variable might hold one of several data types and to execute code based on its current type.

OPA has special syntax elements for manipulating an application's HTML and JavaScript. For example, you can define an action -- code that executes in response to a user event (say, a button click). Also, you can identify elements in OPA source that are bound to elements in the HTML page. Putting those two together, you can have some OPA code like this:

action() = [ #result <- jQuery.getText(#("text")) ]

And couple it with HTML like this:

<textarea id="text" rows={1} cols={10}></textarea>

<p onclick={action()}>Click here</p>

<p id="result"></p>

The above allows the user to enter text into a text area, hit the "Click here" label, and see the entered text poured into the page element marked by id="result". Of course, the HTML shown in the latter snippet would be emitted by another OPA command.

OPA can use some AJAX libraries out of the box. (The preceding example uses jQuery.) You cannot yet, however, import new AJAX libraries into the OPA environment. The OPA engineers explained that they are working on a safe way to integrate other AJAX libraries.

OPA functions can be embedded in HTML in much the same way one might embed Java in a JSP. For example, the following code produces a simple Web application that displays the current time:

server = one_page_server("Time", -> <>The current time is


The function one_page_server() is a sort of main() function that defines the runtime entry point to application plus Web server whose title is Time. Note the embedded function call to the OPA-provided

Just a few lines of OPA code are enough to create a primitive, but functioning, wiki site. The code on the right compiles to produce the wiki open on the left.

One of OPA's more important functions is parser(), which works something like a switch() (or select) statement. When passed the URI (handed to the server by the Web browser), the parser function moves the URI through a series of regular expressions, which you can line up, one after another. Each regular expression can be mapped to a function, such that if a given expression returns a match, the associated function is executed. This permits a single OPA executable to serve up multiple Web pages.

OPA's fundamental idea is sound: OPA's blending the stew of Web development -- server side, client side, and persistent storage -- into a single executable is enticing. Also, it's refreshing to not have to wrestle with Web servers, making sure that all the various configuration variables are set properly, shared libraries are where they must be, subdirectories in their proper place and set with their proper permissions. All those niggling details are dealt with by OPA.

But for anyone versed in the likes of VB.Net, C#, or even Ruby, Python, PHP, or JavaScript, the language of OPA will take some time. Also missing is complete documentation. At the time of this writing, there was no API documentation, and the language documentation stopped at the "Polymorphism" section. This implies that OPA supports object-oriented features, but it's difficult to know without documentation available.

Faster, but less flexibleIf you choose one of these tools to accelerate your Web development, keep in mind that your gain in development speed will be paid for by a loss in flexibility. Alpha Five and Iron Speed Designer, for example, are geared to very specific kinds of applications. Along with Agile Platform and LANSA, they also pre-impose a structure on your code. Your application will have to live with that structure throughout its lifetime -- and you may have to as well. In addition, many of the products here require proprietary components.

It's important to remember that Iron Speed doesn't do it all, nor does it try to. Iron Speed builds fundamental database access code -- which, if you're building a database management application, gets you a long way there. As with Alpha Five, Iron Speed's runtime is Windows based. But if you're building database-centric Web applications running atop ASP.Net, it doesn't get much better than this.

LANSA is also a well-established company, and its tools span more platforms than any other products in this roundup. But the total number of tools available can be daunting; just figuring out which tool you need for a particular development project could take some time. Also, learning RDMLX will require effort, but if you need to build Web applications that run on a wide range of platforms, LANSA might be just the ticket.

The Agile Platform strikes a fine balance between visual development and hands-on coding. Because the platform generates standard .Net and Java code, you can take the source out of your application and continue working on it with your favorite development tools. Agile Platform's free community edition lets you build applications supporting up to five simultaneous users. However, it can only create Windows (.Net-based) applications. Only the paid editions of Agile Platform can be used to build Java-based Linux applications.

Finally, OPA is still a work in progress. Even elements of the language are in a state of flux. For example, documentation accompanying the parser function tells us that the syntax is experimental and may change in future versions of OPA. This isn't the sort of thing you want to read if you're building an application that your business is going to depend on. Anyone embracing OPA is susceptible to the problems attendant with adopting any new technology: Will it still be there next year or the year after that in the future? If not, what happens to all my applications? This is not a trivial matter.

  • Wonderful user interface
  • Extensive help system
  • Company is well established
  • Server runs on Windows only
  • Xbasic is proprietary language
  • Point it to a database, and it does the rest
  • Source code can be "peeled away" from the application
  • No proprietary back end
  • Server runs on Windows only
  • Only builds CRUD database interfaces
  • Runs on IBM midrange systems, Linux, and Windows
  • Excellent and extensive help system
  • Server runs with Apache or IIS
  • Proprietary server-side language
  • Development system is complex
  • Significant learning curve
  • Runs on Linux and Windows
  • No proprietary back end
  • Easy to extend environment with external source
  • Free edition can only create Windows applications
  • Current version requires all entities to be in one database
  • A bit of a learning curve
  • Everything goes in one file
  • Simplified deployment
  • Executable includes Web server and database
  • Product is still being developed
  • Language is in a state of flux
  • Documentation is incomplete

This article, "InfoWorld review: Tools for rapid Web development," was originally published at Follow the latest news in software development at, and get a digest of the key stories each day in the InfoWorld Daily newsletter and on your mobile device at

Read more about developer world in InfoWorld's Developer World Channel.

This story, "Review: Tools for rapid Web development" was originally published by InfoWorld.

Top 10 Hot Internet of Things Startups
You Might Like
Join the discussion
Be the first to comment on this article. Our Commenting Policies