4GLs were quite the thing in the 80s and 90s. Everybody either had one, sold one, or was talking about getting one. For a while, it seemed like actually writing code was going to be obsolete any minute now. Who needs programmers when you can drag and drop UI elements, set properties, and go to town?
Easy peasy.
Except for various reasons the whole idea of 4GLs stalled out as we entered the new century. No serious person starts a project with PowerBuilder, Visual Basic 6.0, or Informix 4GL today. Today people are writing in Java, C#, Python, JavaScript, ObjectiveC, or you-name-it but not those old 4GLs.
But...while they were The Thing, a lot of code was written. And much of that code is still around. Here at Mobilize, we think a lot about automated migration and application modernization - especially the productivity gains vs manual rewrites.
I was on the Visual C++ team when PowerBuilder (PB) was kicking some serious butt with enterprise developers back in the day. We heard about it constantly. For some reason, it dodged the "not a serious tool" bullet that frequently wounded Visual Basic projects and proponents (this is not a knock on VB--it's just that the same snobbishness that made ASM programmers sneer at C programmers in the 80s was inherited by the C++ community when they contemplated the mere mortals that used VB).
PowerBuilder has gone through a lot of ownership since its inception, first to Sybase then SAP when they bought Sybase and now Appeon. It's not technically out of support but realistically it's not something I would invest a lot of resources in. Like VB6 or Delphi it's an architectural cul-de-sac, not a road to somewhere.
When I talk to people with PB apps, universally I hear they want to move those apps to HTML with either a Java or C# back end. Fundamentally this isn't that different from migrating a VB6 app to HTML. Many of the issues are identical; some are unique to PB. Let's tackle a few.
A large PB app we reviewed recently had the following requirements for migrating to the web:
PB was a one-trick pony: it could create a client app that ran on a Windows desktop. You laid out controls on windows and expected those controls would look correct when the client ran, regardless of the desktop. Control layout was two-dimensional (left to right and up to down) and tab order settings established a standard workflow for data entry.
Ideally you want to bring a web version of this app to users without serious disruption to their familiar usage patterns. That means duplicating as much as possible the familiarity of that user interface.
For some time now we've turned to Kendo from Progress (or Telerik before the acquisition) for UI elements in an HTML application. In the past we used KendoUI Professional with AngularJS but now we're moving to Kendo for Angular. In both cases, the libraries offer a rich assortment of familiar Windows-style controls, duplicating most of what PowerBuilder offered in design mode. You have grids, drop-downs, up-down controls, buttons tree views, tab strips, and more.
Is it responsive? Perhaps a better question for a desktop-to-web app transformation is: what form factor makes sense for users of this app? Would anyone ever use this on an iPhone? A Samsung 9" tablet? Or will it remain captive to a desktop/laptop full HD display?
What we have heard from our customers is the latter: the reasoning behind moving from a desktop architecture to a browser-based client is not so the app will work on a smartphone, but so that it will work nicely on a variety of "full-size" devices, regardless of underlying OS, and so that deployment is simplified and compatibility is assured.
We use an MVVM architecture on the client side to bind controls to events and track changes. Angular (not AngularJS) is our framework of choice for managing the client side of the application. Views are created with HTML5 and cascading style sheets (CSS) for styling. Every control on a form gets its own HTML element with associated CSS style. This simplifies modifying the look & feel of the application at a later date.
What do you want on the back end? You have two popular choices: Microsoft or Java. Here are one of each:
You can see that, whether ASP.NET or Java, the structure of both is similar. The helper classes are a by-product of our automated migration solution--if you were building these from scratch you probably wouldn't have those. On the other hand, they hide some of the necessary messiness required when moving a desktop app to the web. More about that later.
Years ago, I had a carpenter buddy named Don: he was about 6 foot 8 (203 cm for our friends elsewhere), had shoulder length blond hair, and a huge blond beard. Total Viking kind of dude. While I liked swinging a Vaughn 20 oz framing hammer, Don favored a roofing hatchet.
I'm not sure why Don preferred the hatchet over a hammer--watching the blade whistle past his ear with every back swing was interesting, to say the least. He believed in the one-hit approach--tap a sinker to start it, then drive it home with one furious blow from the hammer side.
The thing is, Don was no different from other carpenters, software developers, and even users, which is to say folks get used to a tool, comfortable with it, and don't want to change. And that's how we get whaddaboutism--whenever you try to do something new you will hear What about this? What about that?
PowerBuilder makes it easy to create reports in their DataWindow views, and just sending them to the printer gets you nicely formatted reports. Getting the same kind of functionality in a web version of a PB app is certainly possible, if you make some concessions. Here are three ways to do reporting from a migrated PB app:
On the desktop it's SO easy to read and write to local resources: the file system--local hard drive, thumb drives, network shares. or the registry. Not so in a web app--browsers don't want to break the sandbox model.
The business logic is going to reside on a web server running the application as a shared (ie multi-session) process. It can store some kinds of local data (private to the session) as in-memory objects; longer persistence might require it to write those objects out to some kind of database. Other objects might time out.
If the app is connected to a network share on the desktop, the web server can still (theoretically) connect to the same share and access it in the same way. Some work might need to be done depending on the topology of the network after moving to a web server.
Temporary files can be converted to in-memory objects. Other local files can be converted to use upload/download functionality that the browser supports.
Well, it's a beginning. But there are lots more issues to talk about: authentication, user roles and permissions, UI elements like drag & drop, cascading windows, keyboard shortcuts, printing. Yadda yadda yadda. Stay tuned for more on moving PowerBuilder to HTML.
Me writing this post (via GIPHY)