通过浏览器插件实现一个计算/编程工具

[nobodxbodon]

思路有些延续#33, 以及从人机交互角度看中文编程:'打开微信'.

主要目标应用领域是处理日常任务
例子(也是大致开发顺序):

• 单位转换(如英制/公制, 摄氏/华氏度转换)
• 计算器. 侧重一些常用计算器没有的功能, 如更复杂的数学公式, 如"求平均". 最好做到容易合作者扩展添加新公式, 并易于查询现有的公式(参考IDE的代码提示)
• 从剪贴板导入数据, 处理后导出到其他app/格式 <-- 需表格处理功能
• 与浏览器功能集成, 如保存网页内容到本地, 并提供历史内容搜索等
• API稳定后, 添加二次开发的支持, 以及一些简单语法, 如条件/循环

下面是一点初步技术分析:

采用浏览器插件	优势	劣势
通过插件平台发布	过程简单, 无需独立安装包	1) 受限于审核过程 2) 需要浏览器用户习惯使用插件
支持多系统平台	所有浏览器可安装的平台都能运行	需要设计能够兼容移动设备的界面
相同代码支持多浏览器	chrome和火狐插件已基本兼容, 相比以前易于用同一代码库同时支持	一些浏览器API仍有区别(范围需调研)
可集成的系统功能	可以集成浏览器本身功能	受限于浏览器API
计算主要靠本地	不需外部(网站)依赖	受限于(尤其是移动设备的)计算能力
HTML/CSS和(类)Javascript开发	上手较快	仍与一般前端开发有差异

API肯定会尽量用中文. 代码也尽量中文命名.

个人在火狐插件的经验稍多一点, 但对Chrome开发印象不错. 不知国内访问chrome webstore和火狐插件网站有无限制. 由于国内用Chrome的开发者肯定更多, 初步估计会用Chrome作为主要开发平台.

[4b5ent1]

个人在火狐插件的经验稍多一点, 但对Chrome开发印象不错. 不知国内访问chrome webstore和火狐插件网站有无限制. 由于国内用Chrome的开发者肯定更多, 初步估计会用Chrome作为主要开发平台.

我建议直接做chrome插件，因为现在，firefox也支持crx格式了，opera也用的webkit/blink，国产的大多都是chromium改，然后Vivaldi也是chromium+react，win10的edge也支持crx转制。也就是说，做chrome插件，除了不能满足safari和ie以外，都可以一步到位。

关于劣势的个人分析：

1. 受限于审核过程 2) 需要浏览器用户习惯使用插件 - 审核这个可以绕过，直接让有需要的用户下载crx，就跟安卓分发apk一样。习惯是必须要习惯的，ide上手也是需要一个习惯的过程，这一点，不能太照顾用户。
2. 需要设计能够兼容移动设备的界面 - 移动设备可以先不做，如果需要，可以考虑特定的wap站点，或者做微信小程序。
3. 一些浏览器API仍有区别(范围需调研) - 现在基本上统一了，兼容库应该是有人在做的。基于chromium的浏览器API基本一致。
4. 受限于浏览器API - 限制我看不是大问题，如果觉得受限，可以先做chrome+crx扩展，以后再做electron这样的独立程序，可以逐步按实际需求来过渡。总之一句话：typescript大法好
5. 受限于(尤其是移动设备的)计算能力 - 移动设备的算力不是问题，如果是问题，自己做个平台就好了，把复杂的东西扔到后端解决，没必要做一个纯粹的扩展。真正实用的扩展，应该只是一个entry，为了方便接入自己的网站而定制化的辅助helper。
6. 仍与一般前端开发有差异 - 这个没毛病，浏览器扩展的开发，属于客户端开发逻辑，可参考比较成熟的体系，如：Qt

然后是关于功能：

1. 单位转换(如英制/公制, 摄氏/华氏度转换)

• 这类工具箱的我看挺好，比如MD5校验，SQlite集成，都属于这类实用小工具类型。

2. 计算器. 如"求平均". 最好做到容易合作者扩展添加新公式, 并易于查询现有的公式(参考IDE的代码提示)

• 这个我觉得可以有，然后可以一点点一点点的加入中文编程的东西进去，函数定义全用中文

3. 从剪贴板导入数据, 处理后导出到其他app/格式 <-- 需表格处理功能

• 这个会稍微复杂一点，也可以有

4. 与浏览器功能集成, 如保存网页内容到本地, 并提供历史内容搜索等

• 本地IO现在基本不是问题了，还有worker可以用。历史搜索我觉得很有必要

5. API稳定后, 添加二次开发的支持, 以及一些简单语法, 如条件/循环

• 嗯这个思路是对的

[nobodxbodon]

由于优先级低于 #165 ，暂时关闭。