|By Bruce Armstrong||
|October 8, 2012 11:00 AM EDT||
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.
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. 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.
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.
- Where Are RIA Technologies Headed in 2008?
- PowerBuilder History - How Did It Evolve?
- Creation and Consumption of Web Services with PowerBuilder
- Cloud People: A Who's Who of Cloud Computing
- DDDW Tips and Tricks
- Working with SOA & Web Services in PowerBuilder
- Cloud Expo 2011 East To Attract 10,000 Delegates and 200 Exhibitors
- Dynamically Creating DataWindow Objects
- OLE - Extending the Capabilities of PowerBuilder
- DataWindow.NET How To: Data Entry Form
- Custom Common Dialogs Using SetWindowsHookEx
- Cloud Expo and The End of Tech Recession
- Solutions for Optimizing ASP.NET Applications
- Dynamic SQL
- Office 2003 Toolbar: A New Look For Your Old PowerBuilder App