Over the years we've been offered, either by Sybase or by third-party companies, a number of "move PowerBuilder to the Web" offerings. Focusing specifically on those offered by Sybase, we were first offered Web.pb. It was provided as a set of libraries with PowerBuilder 6 that was built on the Distributed PowerBuilder (DPB) technology introduced with PowerBuilder 5. It actually worked fairly well for developing Web front-ends to non-visual components in an n-tier environment. However, its dependence on DPB spelled its doom once DPB was de-supported in favor of EAServer.

Sybase also provided us with a few other technologies in PowerBuilder 6 in an attempt to bridge traditional PowerBuilder development with the Web. Those included the Window ActiveX, the DataWindow plug-in and ActiveX, and (most importantly) the ability of the DataWindow to generate HTML. The plug-ins and ActiveX controls required deploying a runtime file to the clients, which has limited their popularity. The ability of the DataWindow to generate HTML, however, was instrumental in developing the WebDataWindow, as well as paving the way towards the DataWindow generating other formats (e.g., XHTML, XML, etc.). PowerBuilder 7 brought us EAServer integration and the WebDataWindow. PowerBuilder 8 introduced Web Targets based on PowerDynamo. JSP Targets arrived in PowerBuilder 9 and PowerBuilder 10 gave us the XML WebDatawindow.

There are a couple of things many of those approaches (excluding the Web DataWindow) have in common:

1. They focus on deploying the PowerBuilder code as objects in the middle tier and handcrafting Web pages to call them.
2. Each technology introduced was incongruous with the previous technology. Those approaches also showed a trend away from proprietary technologies towards more standards-based approaches.

More recent product offerings, namely Appeon and PowerBuilder 11, take a somewhat different tack. They attempt to render the GUI as well as the non-GUI code, but they do it by rendering the existing client/server style application pretty much "as is" into the browser. The application is rendered as a Web application, but it still looks and behaves like the original client/server application.

I believe that's certainly a step in the right direction. I can think of three main reasons I use PowerBuilder:

1. Object-orientation - The development benefits deriving from using a tool that supports object-oriented development.
2. The DataWindow - Automatic generation of insert, update, and delete statements so I don't have to do a lot of low-level SQL development
3. RAD GUI - The ability to put a GUI application together quickly without having to do a lot of low-level GUI development.

Item 1 has become pretty much mainstream among development tools nowadays. With regard to item 2, the DataWindow is loosing ground to advances in ADO.Net and ORMs that also do a good job of isolating the developer from low-level SQL coding. However, the DataWindow still has some advantages with regard to data display capabilities.

Where I really see a large potential for PowerBuilder is in item 3: RAD GUI development. PowerBuilder continues to do a good job in this regard for Windows development. The approaches taken through Appeon and PB11 are a move towards providing that same RAD GUI development for Web forms. However, I think the approach of simply redeploying an application that was designed to be client/server as a Web application is only a partial solution.

What I would prefer to see is the ability to create Web applications from scratch using the existing PowerBuilder painters modified slightly to accommodate some Web development specific requirements. Of course, a lot more would have to happen under the hood, but the point is the painters would be almost identical between Windows and Web development.

Perhaps an illustration would help here. Figure 1 is a screen shot from a typical Visual Studio Web form. Note that I have two command buttons on the form. The first is a "standard" button, one that if clicked will fire a postback for processing on the server in C# (or whatever .Net language I'm using). The second is an HTML button that if clicked will be processed client side in JavaScript (or whatever client-side scripting language I'm using). A couple of things drive me nuts here:

1. If I originally coded the form with an HTML button for client-side processing and then decide later that I need to do server-side processing in response to a click (or visa versa) I have to remove the control in question, replace it with another, and then re-script it. (I would have to re-script, because I'm going to have to use a different language. It's having to delete and replace the control to do it that seems a bit odd).
2. If I'm scripting a standard button, I'm taken to a separate pane (the code behind .cs file), but if I'm scripting an HTML button I'm toggled between the design and code views of the aspx file. It seems rather inconsistent.

Imagine instead that I create a Web form "window" using the PB window painter, drop a command button on that, and then go to the scripting editor (Figure 2). Note that I've added a couple of additional dropdowns to my "ideal" PB script editor. The first, which is only applicable for Web forms (but who knows, perhaps somehow expanded to n-tier development later), is where the code gets processed: on the server or in the client (i.e., browser). The second (whose options are actually filtered based on the first selection) is the scripting language that will be used for this particular script. Note that I've included C# on the list. I don't think it's that difficult. Under the hood, I'm imagining that the Sybase engineers could simply wrap the entire script in an IF DEFINED PBDONET THEN block for me when I select that option. I'm also thinking that giving PowerBuilder more of a .NET scripting tool feel may assuage the concerns that many corporations have with using a proprietary scripting language (i.e., PowerScript).

The point is that if I now need to change the processing from the client to the server, I simply change an attribute of the script. Under the hood, I'm thinking that the Sybase engineers could maintain a couple of separate script areas for each event/method, depending on which options are selected. That is, I could code up a client-side script, code a server-side script for the same event, and the one that's actually used depending on which was selected when the object was compiled (obviously you can't use both).

That is, the IDE becomes responsible at compile time to separate out what needs to be in the server-side file and what needs to be in the client-side file. As a developer, I don't have to keep switching back and forth between the script for the form and a separate code behind the file. That's an implementation detail that I want abstracted so I don't have to deal with it.

Of course, I'd be way off base here too. Sybase thought the market was ready for a RAD GUI Java tool, and so it produced PowerJ. The most impressive thing about it was the loud thud it made in the market as it fell flat on its face. Marketing may have helped, but it does seem that the Java community loathes the concept. Perhaps the Web development community does as well. That's where I need to hear from you. Am I the only one who thinks that the time is right for tool that could do for RAD GUI Web development work what PowerBuilder did for Windows development?