不误会我的意思，我仍然是QT的粉丝，这是我搬到其他选择之前的第一选择。当时，大约在2013年，当我开始开发桌面应用程序时，QT是最成熟的选项。尽管电子大约在同一时间被引入，但我可能会错过它，或者也许我没有看到它的潜力。无论如何，我选择了QT，而且效果很好，大约一年。

我所指的应用程序最初是用VB6+C ++编写的。我选择QT的原因之一是我需要一个跨平台解决方案。 VB6正在推广迁移到.NET框架，但是即使我是那段时间的C＃开发人员，我也对这种方法感到不满意。

随着时间的流逝，我发现在QT中创建GUI变得更加具有挑战性和耗时，即使是为了一项简单的任务。因此，我开始寻找替代选择。此外，我需要将我的应用程序视为Web API，这不是QT可以帮助的领域。但是，我仍然认为，如果您需要为嵌入式系统开发GUI应用程序，QT是最好的选择之一。

我采取的第一步是在普通的C ++中重写我的核心代码，而不是依靠QT框架。随着C ++ 14和C ++ 17中引入的新功能，这很简单。我认为，除非有充分的理由这样做，否则没有人应该编写核心应用程序QT代码。
为了使事情变得简单，我将以点形式列出我的迁移路径：

• 我将核心业务逻辑移至普通C ++。
• 我创建了一个node.js n-api模块，该模块包裹了我写的核心功能（参考：https://nodejs.org/api/n-api.html）。
• 我将node.js包装器编译成电子支持的普通天然节点。

电子应用：

在C ++中编写了核心逻辑并将其作为JS库将其导入到电子+角度设置中后，开发相对容易。现在，我不仅限于QT小部件提供的组件。你们中有些人可能认为QT快速（QML）有此目的。我还尝试了QML，然后才搬到电子，但对我来说，这仍然是很多工作。

Web API：

我编写了一个Nestjs包装器以授权，并将其部署为lambda函数。我遇到的一个困难是必须在Lambda使用的核版本中编译我的C ++ node.js模块。

我面临的挑战：

并非全部阳光和彩虹。我不喜欢电子 +节点插件方法。

电子有局限性

有人可能会争辩说，电子只是具有一些扩展能力的光荣铬。这个论点有一些真相。在继续前进之前，您可能必须寻找电子限制。电子有时对于简单应用来说太重了。对于我的个人项目，最大的缺点之一是Electron缺乏开箱即用的印刷预览的能力。我使用了解决方法。

我所做的是在内存中创建PDF打印，然后将字节流传递到pdf.js，并将其显示在新的电子窗口中作为打印预览。我知道你们中有些人可能会觉得这太骇客了。不过，我喜欢结果。最好的部分是，与使用qtwidget，qprintpreviewdialog等相比，使用HTML和CSS设计打印输出太容易了。

为什么我不在plainjs中重写我的代码？

在核心业务逻辑方面，我的应用程序有点密集。但是，您的特定申请可能并非如此。另外，您可以考虑使用WebAssembly而不是编写本机插件。如果您从头开始，这将为您节省所有平台的节点插件的麻烦。
除这些考虑因素外，我已经有C ++编写的现有代码，因此我要做的就是删除所有与QT相关的库。

我希望这种个人经历对您有帮助。重要的是要记住，对每个问题都没有一定大小的解决方案，每个问题都有其独特的观点。您仍然可以选择使用QT而不是其他选项进行桌面应用程序开发。