以下讨论的优缺点，都是基于几大OFFICE开发技术的相互比较结果，纯属个人见解。

一、WPSJS加载项优点

1. 用户量大

当前国内的WPS用户，不容忽视，WPS官方说已经月活4亿。

笔者在开发运营【Excel催化剂】、【EasyShu】、【EasyShuForPPT】等插件过程中，被无数次问到是否支持WPS。而真正使用WPS群体，也是更偏向于初级用户者，这个群体对插件的需求量是非常庞大的，有用户才有插件的生存空间。

2. 中美关系紧张的政治正确选择

中国崛起是不争的事实，中国企事业单位使用WPS用户越发增加也是不争的事实，在WPSJS还在蓝海阶段进入，是一个理性的最优选择。

3. WPSJS插件可跨平台运行

同样地，这个笔者以前不以为然，但面对国企政府等部门已经开始推行linux系统的背景，或许将来局面真的会改变。当然苹果Mac系统这个人群，能覆盖也是最好，此人群是高净值群体，最有希望转化付费的群体。

4. 依赖的核心技术语言JavaScript是成熟并持续成长的

笔者也不是技术背景出身，纯Excel用户的技术成长路线，在开发【EasyShu】图表插件时，才接触了JavaScript语言，当前水平也仅仅是入门级别。

待久了OFFICE的VBA社区的传统开发者们，可能真需要好好地权衡下，是否值得再努力一下，把JavaScript语言给入门一下，相对VBA来说（VBA已经停更20+年，在技术领域这个是很漫长的时间了），它太丰富的生态了，轮子一抓一大把，比起天天霸占朋友圈的洗脑python还要丰富得多。

当然作为传统VBA/VSTO开发者来说，不必太深入学习JavaScript，毕竟我们是以操作OFFICE对象模型为主的应用开发，后期再尝试分享更多的JavaScript学习经验供大家参考。

5. 插件安装部署有绝对性的优势

对比VB/.NET的COM加载项插件来说，WPSJS的加载项部署更有优势，安装成功率更高，用户只需打开某个网页，这个网页加载完就已经部署成功（此处是其publish的部署方式，笔者仍未测试成功，当前说的是理论层面，关于部署的详细教程，后面会展开分享）。

OFFICE插件作为OFFICE软件的附属，不是独立性软件，太多的坑，各种奇怪问题，永无止境。能够把部署体验做好，单纯这一点就非常有优势。

而且WPSJS这样的网页开发技术，对系统的依赖性极低，不受各种阉割系统、系统权限控制等问题干扰。当然对OFFICE宿主的依赖性也比传统的要弱得多。WPS也不像微软OFFICE那么多阉割版本和历史版本包袱。实在有问题，让用户去官网下载个200M不到的安装包重新安装，也是非常容易做到的（主要是还不用到处找激活码之类的骚操作）。

二、WPS加载项缺点

1. 新技术，到处是坑

当学习和使用一个新技术时，难免需要付上更大的代价，一路踩坑是再正常不过了。当然社区的帮助也少之又少，更多的是自己摸黑。

而相对微软OFFICE的WebAddins技术来说，WPSJS更不成熟，更少人关注（目前官方社群100人不到）。而且官方文档一个奇葩之处是：错误或已作更新的地方未同步更新仍然存在，就算读烂官方文档，也不能排除多少坑。

2. 网页技术开发和传统开发技术差异非常大

相信这一点是拦住大家进入WPSJS开发的最大的阻力，但没办法，学习技术就是要不断地突破自我。

现在很不幸的是WPS官方跑通的案例，竟然是集中在文档方面的，而不是在表格方面的，官方的案例是OA助手，主要是用来处理文档场景。但传统OFFICE开发，必然是以Excel表格开发占大部分。也徒增了不少学习成本。

3. 网页开发有其必然的局限性，对本地资源的调用权限极有限

对于开发个人市场的插件，这一点也是非常大的重伤，如果用户的数据不在云端，在自己本地电脑上，网页开发技术将变得非常无力，因为它不能碰触本地资源，没有这个权限。

例如一个很常见的场景：批量插件本地图片到表格上，因为图片是在本地的，只能让用户先上传图片的操作，才有可能让插件拿到图片，再做其他操作。对于搜索类场景就无望了，总不能为了要几滴水，把一个鱼塘给端到云端网站上。

对于微软的WebAddins（对权限要求更严格，合规性更强），读取本地资源这一块必然是无望的，但对于WPSJS，还可能有一线生机，这个也等笔者再深入探讨后，再作专题的分享。