PowerBuilder现代编程方法X11：PB程序完全跨平台方案

PB可能要支持Windows、macOS、Linux、iOS、Android与鸿蒙操作系统和X86、ARM、RISC-V与国产龙芯CPU的原生应用了！

PowerBuilder现代编程方法X11：PB程序完全跨平台方案

前言

《PowerBuilder编程新思维》在写到了WebUI后，陷入了沉寂。

原因是我对PB发展的下一代技术方案不太满意，越是对未来的走向不清晰，就越是没有动力补全现有的方案，生怕一不小心走岔路。

这段时间，我反复思考可行的技术方案，也做了大量的尝试项目，但都废弃了，文章也写了有快二十篇没有发表。

终于有一天我读到了这一篇《Htmx意外走红，我们从React“退回去”后：代码行数减少 67％，JS 依赖项从 255 下降到 9》

我意识到，不是Web前端的发展有什么问题，而是已经到了抛弃Web前端的时候了。

抛弃Web前端

一直以来，我都认为PB的下一代是Web化，主要是DataWindow的Web化，后端主导的技术潮流已经不适应未来的发展。

但是事实上，Web技术虽然不断发展，但是Web本身的问题却层出不穷。生产力不断提升，生态不断完善，可是探索却总是碰壁。

Htmx给我提了个醒，应该重回后端主导的前端框架这个思路上来，抛弃前端框架。

我们知道，Web发展的初期，是没有前端应用的。Web2.0开始，前端不断发展。给了我们太多的选择，越是想偷懒，就越是被前端束缚。

特别是PB这样“古老”的工具，理念上同前端是天然对立的，放弃前端才是最好的出路。

前端主导的后端框架

本来PB下一代开发解决方案PbXds（neXt-generation Development Solution）是基于前端主导的思路。

修改前的方案参见《PowerBuilder编程新思维10.5：外传2（PowerPlume下一代解决方案）》

将PB程序编译为JS，使用React前端框架，部分使用本地接口的程序运行在后端，可以选择编译成Golang。

那么区分前端还是后端代码就成了一个有困难的任务，必须人工的参与，自动生成是不可靠的。

纠结完前后端的问题之后，又有了前端兼容性的纠结，特别是如果想跨平台，Sciter的兼容性就成了最恐怖的事情。

就算准备使用tauri之类的框架解决跨平台的问题，并且放弃掉许多平台的兼容性，但还是有个问题悬在心头——安全性。

安全一直以来都是PB的核心弱点问题，如果安全性得不到保障，又有几个人会来用你这个“下一代”？

Web天然没有什么秘密，如果要增强这个安全性，势必要加强后端的强度，人工的投入又是一个无底洞。

后端主导的前端框架

如果思路换成后端主导，将PbXds WebUI方案升级为PbXds Multiplatform多平台方案。

那么PbXds编译器只需输出Golang代码即可，无需输出js，相应的PbXmp运行时也只需Golang版本而无需js版本。

数据窗口暂定为后端输出，也就是PbXmp部分输出，而无需另行开发。PbXsf也会并入PbXmp。

最终只需PbXds原有内容的三分之一即可。

首先，逻辑代码全部采用后端Golang，安全性能得到很好保证。

然后，前端完全没有逻辑代码，所以也不存在源码前后端选择与环境适配的问题。

最后，仅有的前端代码由后端PbXmp产生，可以动态调整输出，兼容性完全不是问题。

这样，PbXds不仅没有原方案的三大主要问题，而且内容也精简到了三分之一，非常Nice。

新的技术方案

新的方案中，前端可以直接使用Htmx或者其定制版本。

后端直接使用桥接或者Web框架Iris和Gin。编译器由输出JS，换成输出Golang。

除了直接部署为Web服务，还可以编译为跨平台本地应用。

应用由内嵌浏览器显示界面，这样在打印，本地设备IO，读取UKey等等方面比纯Web应用有更好的使用体验。

内嵌浏览器框架可以采用 Webview（golang）

这个项目类似于Rust的tauri，不过更早，如果不是取名太过奇葩（搜都搜不到），说不定早火了。

另外可以采用Sciter

不过由于Sciter的兼容性堪忧，所以不会作为主要方案，只会作为跨平台应用的可选框架，应对支持XP之类的特殊需求。

跨平台技术方案：PbXds WebUI升级为PbXds Multiplatform

PbXds（golang）+PbXmp（golang） + Webview（golang）+ Htmx（JavaScript）

方案涉及的问题解答

一、这个PbXds Multiplatform方案不就是Web混合应用吗？值得吹吗？

Web混合应用过往表现并不优秀，主要的问题是界面卡顿，但Htmx方案不存在JS逻辑，JS大小不会随代码增大。

从而规避了前端框架的最大弊端——首屏显示问题，显示性能也会随之有非常大的提升。

安装包的太大的问题也被Webview解决，最后一些老旧系统问题也可以通过适配到Sciter解决。

二、这个Golang应用框架和PB有啥关系？

PB的用户这些年相对稳定，源码积累还是很深的，这些都是资产。

PB的特点在于快速开发，IDE和DW都是法宝，可以提升开发效率，尽可能的利用。

DataWindow实际上是早期的ORM，很优秀的机制，最好支持动态DW的功能，作为视图功能的补充。

与同享的EXTPB.NET类似，充分利用DataWindow控件的强大功能，与之不同的是采用自绘DataWindow。

三、为什么不选择Rust语言？

事实上，Golang和Rust是仅有的可以选择两种现代编程语言，不仅可以跨平台，而且生态也非常成熟。

Dart、Swift、Kotlin等语言都有弱点，不在选择之列。

Golang比Rust简单一点，更重要的是与Pb比较而言，更“原始”一些，沟通转换没有太大的代沟。

还有Golang已经支持大多数操作系统平台和大多数CPU架构，已在 1.19 版本原生支持龙芯 LoongArch 架构。

当然如果有可能，支持Rust也在考虑之列。

四、为什么不直接用DirectUI？

DirectUI库主要在国内流行，无论Duilib、DuiVision、Soui、REDM都不跨平台。

而国内的国产系统国产软件的替代大潮已经箭在弦上，不得不发了，跨平台是第一需求，国产CPU支持也是关键。

Dui的跨平台基础库也在研究中，毕竟还需时日，如果设计得当，直接替换PbXmp就可以了。

五、还有没有其它的UI方案？

有，但是都有一定的局限性，比如：

TCL/TK，这是最老牌的UI，应用非常广，但是由于TCL语言太过古老，选择的人不多；

LIBUI，这是一个C语言UI库，在各个平台选用原生控件，但界面不够现代；

QT，非常强大的跨平台UI，但是许可比较迷，一直广受诟病，另一个缺点是比较臃肿；

 

方案快速验证演示

虽然我的思路看起来没有什么问题，但是还是需要跑通整个链条来证明思路没有错误和大的障碍。

所以实现了一个《PbXds Multiplatform快速验证程序》，内容不多，仅供参考。

PbXds.go（Compiler from pb to golang）

PbXmp.go（Multiplatfrom Framework for golang）

• PbXmp application object （AdapterControllerServer/Client）
• PbXmp window object （AdapterPresenterWeb/Sciter/Dui）
• PbXmp database object （AdapterDatabaseMSSQL/MySQL/Oracle/PostgreSQL）

PB可能真的要支持Windows、macOS、Linux、iOS、Android与鸿蒙操作系统和X86、ARM、RISC-V与国产龙芯CPU的原生应用了！

（由于群里熊猫兄的催更，还没有完成就提前发布，所以暂时没有源码下载）

<本节完>