3 minutes reading time (590 words)
Featured

The Future of PowerScript Desktop Apps

Now that PowerBuilder 2019 and its new C# development capabilities are in beta, we are starting to get questions about the future of PowerScript desktop apps.  Specifically, does Appeon recommend developers to move away from PowerScript desktop apps?  And related to this point, will Appeon be enhancing or just maintaining the features of PowerScript desktop apps?

A quick look at the PowerBuilder roadmap page and it is obvious we have put much focus on the C# language, open standards, and cloud architecture.  Increasingly, most new .NET projects have such high-level requirements.  Perhaps this is why the .NET framework is radically different these days – the .NET Core framework is open source, cross OS, and targeted for cloud deployment.  And unfortunately, we could not use any of the .NET stuff Sybase did because it didn’t meet these requirements.  So certainly, we had to put a lot of focus on non-client/server features. 

Now let’s assume for the sake of argument that the cloud is the future and focus on if and how a PowerScript desktop app fits into such future.  A native UI technology (e.g. PowerScript desktop app) has certain advantages over HTML (e.g. ASP.NET page) and vice versa.  However, for most line-of-business apps we believe a native UI technology offers the best set of tradeoffs.  Key industry players like Microsoft seem to be recognizing the shortcomings of HTML and trying to lessen this gap with Progressive Web Apps (PWAs).  At Appeon, we think it makes more sense to “cloudify” the PowerScript desktop app than replace it with some other technology. 

In fact, we began to “cloudify” the PowerScript desktop app the second we took over PowerBuilder, which we did on top of its existing C++ runtime and PowerScript language.  Starting with PowerBuilder 2017, we introduced an all-purpose HTTP client, a REST-specific client, an OAuth2 client (with support for tokens), and JSON handling (parsing, generating, packaging).  And in PowerBuilder 2019, we have significantly enhanced all of these features, especially how they integrate with the DataWindow to minimize the amount of coding you do. 

But of course, there is still more work for Appeon to do with the PowerScript desktop app to make it attractive for new projects, no matter they are client/server or cloud based.  This is exactly why in every single release for the foreseeable future we have planned to bring major new features to the desktop target.  For example, in PowerBuilder 2019 we will revamp the UI of desktop apps.  And in PowerBuilder 2021 we plan to revamp deployment of desktop apps (from the cloud).  Beyond that, it would be silly of us to say now, and most vendors wouldn’t even say this much. 

So to answer the main question of this blog: no, we do not think most customers should move away from PowerScript desktop apps.  In case it is not obvious, Appeon is bringing major new features to PowerScript desktop apps, which are aimed at modernizing them.  No matter you are looking to stay with a client/server architecture or “cloudify” your architecture, PowerBuilder 2019 can bring major change to your existing project without a rewrite.  For example, our approach to UI modernization is designed to be codeless (i.e. controlled through style sheets).  As another example, we invested to create an automated solution for “porting” valuable existing business logic to the cloud.  Lastly, in our experience, most rewrite projects are a failure to some degree… delayed, exceeding budget, and/or not impressing app users… so surely, we don’t want to recommend our customers to take more risk than absolutely necessary.

Comments (28)
Thursday, Mar 14 2019

Thanks for this. It is brilliant to get some certainty about the future especially as I am developing completely new applications.

1

Friday, Mar 15 2019

Thanks for the update. It is great to have this article as it provides clarity and helps me greatly as I have just revived a great application which was about to be terminated, and I am now moving forward with new development.

1

Friday, Mar 15 2019

Does this mean that we must become C # programmers and forget Powerscript to get the most out of the new versions of Powerbuilder?

1
Friday, Mar 15 2019

Quite the opposite Miguel! We are saying to get the most productivity out of PowerBuilder consider using PowerScript together with C#. PowerScript is the native UI programming language and C# is the server-side programming language for PowerBuilder 2019. Of course if your next project is pure client/server rather than cloud architecture then it would be 100% client app with no middle tier therefore it would be just pure PowerScript and no C#.

Comment was last edited 5 years ago by Armeen Mazda @Appeon
0
Friday, Mar 15 2019

Well. So, to get the most out of the server-side features of Powerbuilder 2019 and to be the most productive PB developers as possible, must we become expert C# programmers? Another learning steep slope to climb?

0
Saturday, Mar 16 2019

Since PowerBuilder's C# implementation is open architecture it is a blank canvas. So if you are a C# expert then you can go way beyond the features that PowerBuilder 2019 provides.

But if you are just using the C# features of PowerBuilder's framework then I don't see such steep learning curve. Just compare the PowerScript code to the C# code in this example: https://www.appeon.com/sites/default/files//pictures/developer/PS_to_Csharp_Porting.png

So to answer your question, the answer is no. The server-side features that PowerBuilder's framework provides do not require you to be a C# expert. Perhaps the issue is that you have not downloaded the PowerBuilder 2019 beta and tried out the various C# tutorials so you are imagining the worst?

Comment was last edited 5 years ago by Armeen Mazda @Appeon
0
Saturday, Mar 16 2019

Thank you very much for your guidance, Armeen. I shall download the Powerbuilder 2019 beta to understand the subject more clearly.

1
Thursday, May 09 2019

We are offering a service to help fast track PB developers into the C# PB hybrid world. I would be happy to discuss this with anyone interested

1

Hi guys ... I am interested !!! ... What do I have to do ??? ...

0

Thursday, Mar 28 2019

Thank you for this post, it is very important for companies like the one where I work, having very big PB C/S apps with many users, to hear that Appeon is not going to abandon PowerScript and PB Classic as a C/S dev tool.

Since we still write all the business logic in PowerScript, it would be very important for us to enhance the language and the PB IDE: for the language the support of Java-C#-PHP-like interfaces would be enough (https://en.wikipedia.org/wiki/Interface_(Java)), and for the IDE the most important feature would be to allow the programmer to open an object/function just by ctrl+clicking on its name in a script.

I don't see any enhancements to the PowerScript language or the IDE in the Roadmap. Do you think there is room for such features? Thank you so much.

0
Friday, Mar 29 2019

Appeon roadmap covers the revisions of the current version and the next major version. There are no changes to the PowerScript language itself planned for the next major version, but beyond the next major version we really cannot say.

However, if you find the PowerScript language is not adequate for your business logic coding, you really should consider using the new C# Web API features of PB 2019. Using this feature doesn't mean you have to run your app over the Internet or deploy to the cloud. You can run this all on-premise with traditional client/server architecture. Our C# Web API includes Kestrel so you don't even have to install or configure a Microsoft IIS server.

0
Monday, Apr 01 2019

Thank you Armeen for your answer. I didn't know about Kestrel since I'm not a .net expert, I'll take a look at it. I have been coding in PowerScript for the last 23 years, so I'd love to continue with it; but since it's still basically as it was in PB4 (I mean the language itself), it's time to switch to a more powerful one. C# + Kestrel can be an option.

1

Thursday, Apr 11 2019

Hello, all
From everything I wrote and from everything I tried in 2019 Beta so far I still cannot answer the most basic and critical question: will I be able to access .NET DLL public classes and functions from PB 2019 IDE?
We are currently using PB12.6 NET to create console applications in PB script, which use NET DLLs. We do not want to create Web APIs for them, we would like to leave them as .NET DLLs and consume them from PB IDE.

Is this at all possible with PB 2019? we are lost here

Thank you
Arcady

0
Sunday, May 05 2019

Hi Arcady,

PB 2017/2019 does not contain PB 12.6 .Net any more. Thus, if you want to call .Net DLL, you need to expose the .NET DLL as a COM library, then PowerBuilder can consume it. You will need to register the DLL in the system where the program will run on or use Registery-less COM.
Please refer to the below for more details:
https://www.brucearmstrong.org/2007/07/calling-dot-net-components-from.html
http://brucearmstrong.sys-con.com/node/1668463/mobile

BTW, Appeon plans to add a new object CSharpObject in PB 2019 R2/R3. With this new object, you can call .Net DLL public classes and functions directly.

Regards,
Ken

2

Tuesday, Jul 09 2019

Hi, Friends
When you said:

"PowerBuilder 2021 we plan to revamp deployment of desktop apps ( from the cloud)"

This means that to take advantage of the improvements that come in the future; I have to pass my apps that are C / S to the cloud (using model store pg) or not necessarily?; I am using PFC with my apps ;
the migration would be complicated


Regards

0
Friday, Jul 12 2019

Hi Milton,

Regarding the desktop cloud app, I suggest you take a look at this link first:
Https://www.appeon.com/developers/roadmap/desktop-cloud-app.html

Even if you use PFC, you will still be able to deploy your app to the Cloud via the PB IDE.

Regards,
Ken

0

Adding to what Ken said, since the Desktop Cloud App uses same PBVM as C/S you can benefit from the new PowerScript features we add to PB without having to move your apps from C/S to the cloud (besides obviously the Desktop Cloud App deployment feature itself).

0

Wednesday, Jul 17 2019

Armeen and Ken Thanks for the reply:
Where can I review complete migration examples to the cloud using datastore.net and embedded sql

There may be lib. PFCs oriented towards the cloud (it would be great)

thanks

0
Thursday, Jul 25 2019

Hi Milton,

I'm so sorry that we couldn't offer you this kind of information yet, as it's still under development.

Regards,
Ken

0

Wednesday, Sep 25 2019

Maybe a stupid question but, in the case of a Client/Server app, how does adding a middle tier in the cloud add any benefit? Seems like it's just adding one more hoop to jump through on the way to/from the database. I don't see the advantage of that.... if anything, seems like it would slow things down and add unneeded complexity. What am I missing?

0
Wednesday, Sep 25 2019

One of the advantages is the access speed using model store or datastore (.neT); you separate the business logic from the data layer;
You can also consume and create microservices in the cloud which is what is technologically in vogue
REgards

0
Wednesday, Oct 02 2019

Datawindows only transfer data to/from the database... I don't see how adding a middle tier makes that go any faster.... even if the middle tier and the database servers were physically in the same room, it's still another hop over a network that adds more latency.

You can refactor business logic out of the client/powerbuilder environment by simply putting it in stored procedures in the database where it also has immediate access to the data..... accessing and processing of data doesn't get any faster than that.

I get the idea of microservices and can see the benefit of being able to consume them, and maybe even create some.

"which is what is technologically in vogue"
I think that's the bottom line answer right there, which is one reason why I've resisted moving to Web environments. It's all about chasing the "flavor of the month". Your applications end up looking like a hodgepodge of 20 different technologies written by 10 different developers (Developer get's hired for one technology, introduces a new one to gain experience in the latest trend, and then bails out when he finds a better paying job in that new technology).

But for an internal business app written for corporate use (which is all I've worked on in my 20 year career), I still don't see how that justifies rewriting/porting such an app to the cloud and adding a middle tier. Deploying from the cloud is cool maybe, but our current method of deploying a compressed file from a file server works perfectly fine and takes literally a few seconds. Deploying from a database would probably be even better.

Personally, I think one reason why Powerbuilder is still around is BECAUSE it hasn't changed that much. It's a solid, stable platform which has allowed those apps to just keep on running without having to be re-written every few years. The biggest downside for businesses is finding developers that still know how to do it and the salaries those developers are able to command.

That said, I do like Appeon's direction in providing a way to write Web/Mobile applications in Powerbuilder and the ability to leverage the datawindow to do so. And though I'm not a fan of the syntactical limitations of C# (namely, case sensitivity... Yuck!!), I think the language does open a lot of possibilities and more efficient ways of doing things (LinQ!!!) than even powerscript. And opening the door to all the .NET capabilities out there is going to make many things much easier since we won't have to reinvent the wheel as much.

Personally, we are still on SAP Powerbuilder 12.6 which we can use for free till the end of time. I'm waiting for the roadmap to be completed before deciding to make the jump to Appeon Powerbuilder though. I've seen too many people get burned when they jumped on the Powerbuilder flavors of the Java bandwagon (Jaguar) or the .NET bandwagon (Powerbuilder .NET). When Appeon has gotten to where I can port the language from powerscript to C# and still build a Desktop app using the datawindow, that's when I'll consider making the switch. From what I understand, that should be by 2020 or 2021. When C# developers find out how much faster/easier it is to build apps in Powerbuilder, thanks to the datawindow, businesses shouldn't have a problem finding developers willing to do it.

0
Wednesday, Oct 02 2019

hi, friend; the performance using datastore o modelstore
check it out in : https://demopb.appeon.com/performance_1_102.html

It is very efficient in memory and response time; If you take into consideration that the main objective is the cloud;

0
Thursday, Oct 10 2019

I don't see how this example is relative. I'm talking about the performance of running a client/server app where the client connects directly to a database vs an app where the client connects to a web server and then to a database.

Anyway, the issue is moot now. My company is not willing to wait another year for Appeon to deliver the final piece of the roadmap to enable the migration from Powerscript to C# for desktop applications. They are going to instead offshore development in .NET/APEX to India and do a complete rewrite of the application. Guess who will probably be out of a job soon? Ping me if you have a job available for a 20 year PB/Oracle developer in the Central Florida area (or remote).

0
Sunday, Nov 17 2019

Sorry to hear that! Our PowerScript-to-C# converter is currently in beta, and it can probably automate half of the migration project to .NET. Here is a conversion demo using the beta version: https://youtu.be/PXyiDb4Znn4?t=795

We had number of early adopters present their success stories at our annual user conference:
https://youtu.be/rUqEBFcaseY
https://youtu.be/iHMAMcmpqIo

0
Monday, Sep 14 2020

That comparison got me tricked too:
It's faster but only compared to the old PB .Net, not to classic PB C/S.

0

Tuesday, Oct 29 2019

"As another example, we invested to create an automated solution for “porting” valuable existing business logic to the cloud."

Is this the same as what is on the Powerbuilder Roadmap...

"PowerScript-to-C# syntax converter(additional license) "

Can someone explain what this is going to do for us?

One of the main complaints my company has is the lack of resources (developers) available that can still code in Powerbuilder/Powerscript and of course the salaries we command. I see the moving of business logic and such to C# Web API's, but what about the front end GUI? Are we ever going to be able to write Powerbuilder Desktop applications in C# and have the datawindow (not just a datastore) available for rapid development of the front end? I thought this was what PB2021 was going to deliver, but I'm not so sure now.

0
Sunday, Nov 17 2019

The PowerScript-to-C# converter is included in the $1,595/year subscription of PowerBuilder. There is no additional license fee.

It only migrates business logic, but that is like automating half of your project. There isn't going to be something that's 100%... not possible to do and have maintaintable code.

We are working on introducing an HTML DataWindow to help with the UI migration as well, but that is far out. What is currently in beta is the PowerScript-to-C# converter.

Just to clarify, when using the PowerScript-to-C# converter your UI technology can be anything. You can use vanilla ASP.NET pages, continue using traditional PowerBuilder client, or the new UI technologies we are working on (e.g. HTML DataWindow).

0