PowerBuilder Authors: Chris Pollach, Yeshim Deniz, Jayaram Krishnaswamy, Kevin Benedict, Avi Rosenthal

Related Topics: PowerBuilder, Microsoft Cloud

PowerBuilder: Article

The Evolution of PowerBuilder .NET

We may need to look at different technology approaches for development for the web & native applications on non-Windows device

Somebody was asking in the Sybase newsgroups "should I make the commitment to PB.NET?" and wanted non-marketing types to respond. I started to respond in the forums, but the eventual length of the response and its applicability to many other people resulted in my responding here.

What PowerBuilder has always been good at - its differentiating factor - is allowing developers to rapidly build Windows client applications that are open with respect to the data source they work with. You can use other tools to do Windows client applications (e.g., C#, C++, etc.), but the primary advantage that PowerBuilder offers is that it accelerates the development effort. My gut feeling is that I can be an order of magnitude more productive using PowerBuilder to develop a Windows client than any other tool.

The Windows application development environment is changing though. We used to only worry about connecting directly to databases. More recently, services are another common data source and many of the features added to PB.NET (i.e., WCF client and service development) are designed to support that. The Windows architecture is changing as well, with .NET essentially becoming the API used to work with it. To that end, the .NET improvements in PB.NET were designed to allow PowerBuilder to evolve with the evolution of the Windows operating system.

The WPF target, as the Telerik Platform Guidance for .NET indicates, expands PowerBuilder's capabilities to support "Custom Windows Applications" that have a need for a more advanced graphics capability or support for multi-core processors. With the most recent maintenance release, it also adds support for 64-bit (or more specifically, any target) applications.

The argument is that what PB.NET is supposed to do is allow you to create applications that take advantage of all these new opportunities and still have that same accelerated development capability that PowerBuilder provided for client/server applications.

That being said, the client application development environment is going through some more recent major changes. Windows 8 offers not only .NET as an API for working with the operating system, but adds another API called WinRT. WinRT is a set of native COM objects that use .NET/ECMA-335 compatible metadata. As a result, they can not only be accessed by C++ and .NET, but by JavaScript as well.

Meanwhile, HTML5 has been proposed not only as a replacement for current methods of generating web applications, but for use in replacing native client applications as well. The argument is that by writing an application in HTML5, a developer could write the application once and make it available on any platform that supported an HTML5 capable browser.

The question that's raised is a broader one, but one we must answer in order to address the original question. This new question is "What is the significance of .NET in general in the future?" Does the introduction of WinRT render it just one of many ways of writing Windows applications? Does the recent interest in HTML5 mean that writing native client applications at all is going to become obsolete? If .NET is expected to lose relevance in the future, then PB.NET will suffer as well and we might as well wait to see if PowerBuilder 15 incorporates functionality to support these new approaches to application development.

For a number of reasons, I think that the relevance of .NET is safe for the immediate future. That's because I don't think WinRT or HTML5 are going to be displacing most Windows client application development for some time. As I noted in an earlier article, "the real test [for HTML5] will come when Facebook releases their new HTML5-based interface." Well, apparently the jury is in, because Facebook appears to be abandoning their HTML5 implementation and instead paid $1 billion dollars to acquire a competitor based on a native implementation.

As for WinRT, you have to first consider that Windows 8 still supports WPF-based applications under the "traditional Windows apps and services" portion of the architecture. As Andrew Binstock noted in a recent Dr. Dobbs article, such applications can not only run on desktops, but on properly powered tablets as well.[5] He goes on to argue that "It also means that insofar as tablets are concerned, the current model of downloading mobile apps will be supplanted in favor of using regular desktop apps. Mobile apps will return to their original venue, the smartphone, which due to its form factor, cannot push into the same domain as the PC."

If he's correct, then WinRT only really comes into play for smartphones. And even then, .NET is still available to develop applications for it (beginning with .NET 4.5). About all PowerBuilder would require to support it would be to adopt the approach used currently to support WPF applications to generate "Metro XAML Apps". Microsoft even gives some guidance on how to port WPF and Silverlight applications to Metro XAML.[6]

We may need to look at different technology approaches for development for the web and native applications on non-Windows devices. But .NET seems to have a strong future for generating Window client applications for the foreseeable future, and efforts to learn that technology will still pay off for some time.

More Stories By Bruce Armstrong

Bruce Armstrong is a development lead with Integrated Data Services (www.get-integrated.com). A charter member of TeamSybase, he has been using PowerBuilder since version 1.0.B. He was a contributing author to SYS-CON's PowerBuilder 4.0 Secrets of the Masters and the editor of SAMs' PowerBuilder 9: Advanced Client/Server Development.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.