关于公文排版助手未来开发计划

这是一个比较长远的开发路线，不代表以后一定会如此，还会视情况而定。

众所周知，Office 和 WPS 都支持插件。

微软 Office 自己的发展路线是 VBA/VSTO/COM –>Office JavaScript API 。

相较于使用 VBA、COM 或 VSTO 生成的加载项，Office 加载项提供以下优势。

• 跨平台支持。Office 加载项在 Office 网页版、Windows 版 Office、Mac 版 Office 和 iPad 版 Office中运行。
• 集中部署和分发：管理员可以在整个组织内集中部署 Office 加载项。
• 可通过 AppSource 轻松使用：可以将解决方案提交到 AppSource，供广大受众使用。
• 以标准 Web 技术为依据：可以使用所需的任何库来生成 Office 加载项。

而 WPS 走经历了3个阶段：自有API –> 兼容 VBA/VSTO/COM –> WPSJS API。

WPSJS API 的优势如下：

• WPS 加载项是一套基于 Web 技术用来扩展 WPS 应用程序的解决方案。
• 跨平台，目前已针对Windows/Linux操作系统进行适配。
• 底层是以 Chromium 开源浏览器项目为基础进行的优化扩展。

二者的开放 API 从不兼容到兼容，再到不兼容，但是他们又都选择了 JavaScript 语法规范。

毕竟 VBA 太老了，作为 VB（VB 2020年也停更了） 的子集，已经停更了20多年。

当然了，这并不意味着 VBA 会消失，最新的 Office 2021 也还可以使用 VBA和宏，只是不会继续发展了。

COM和VSTO加载项，尽管可以选择其他语言，但平台只能限定 Windows，所以之前很多人询问过我能否支持 Mac 系统，如果看到这里就明白了为什么不支持了。

所以公文排版助手未来一定是跨平台的。

但是由于 WPS 和 MSOffice 技术路线的不兼容，这也将导致公文排版助手需要做出抉择。在下定决心之前，我们需要先分析一下微软和金山的特点：

微软新一代加载项要支持 Word JS 1.3 需要 Office 2019，导致国内用户感知不强，加载项功能很弱导致实用性很差，运行效率也不高，而且免费的很少。对于开发者来说，加载项分发部署难度较大。

尽管 Office JS 迭代多年，我也一直关注它的进展，但目前来看，不论是功能性还是兼容性，都无法满足公文排版助手目标用户的需求（还有很多人在用Word2007你敢信）。

金山虽然高举民族软件的大旗，也是正版化进程和政府采购的主力，但是我并不太想支持它的原因有二：

第一，WPS 的技术路线多次摇摆，比如 WPS 全面放弃早期自有插件平台，缺乏长期兼容的表现，会很伤开发者。即使是微软这么庞大的公司，Windows Phone 系统的失败也跟缺乏长期兼容性，来回摇摆有关。

而 WPS 兼容 VBA的代码本身还存在很多BUG，公文排版助手兼容 WPS 时踩了不少坑。我跟金山产品经理反馈时，很明显能感受到金山由于开启 WPS JS，已经放弃了对VBA “屎山”的维护。

所以我很担心 WPS 的技术路线再次摇摆，或者缺乏长期支持。

第二，WPS 有自己的公文开发计划：

金山办公正式推出全球首个办公软件“公文模式”。据悉，WPS 公文模式主要面向党政机关用户，以国标版式、定制工具、集成 OFD、模板导入等功能为出发点，全面、集中、针对性地解决党政机关用户在公文写作过程中遇到的痛点，党政机关用户可以在 WPS 一个端内完成公文撰写、协作、排版等工作，并直接打印出符合国家公文标准的文件，从而极大地提升党政办公效率。

对于我来说，开发公文排版助手的初衷是找不到好用的公文软件，当时市面上最好的公文软件XX宝把用户操作限制的死死的它更适合完全不懂办公软件的人，而不是我这种有一定排版基础，但是想要提高效率的人。

如果 WPS 本身就提供了这样的功能，我是非常赞赏国产民族软件切合用户实际需求的行为。

可见，Word 用户更需要公文排版助手，在未来，我将会主要跟踪微软 Office Javascript API 的进度，在合适的情况下分支开发 JS版的公文排版助手。

目前来说，两家 JS API 的权限都太低，很多功能无法实现，大家还是不要着急，也不用心慌，我会继续开发和维护现在的 VSTO 版本。