把IDE这样庞大的黑盒掀开一角,妄图进行深度定制,看起来那可真蠢,写写插件不好吗?之所以这样做,主要有2个原因:
实际上,灵活性收益的多少取决于扩展机制的限制程度,如果插件机制是完全开放的,二次开发带来的灵活性提升就显得不那么必要了,例如Atom的扩展机制,几乎没什么限制,依靠插件机制完全可以造出来一个全新的IDE,比如Nuclide
控制粒度则侧重于可定制能力,例如主题风格、UI布局、语法扩展等等,二次开发能够支持定制那些插件机制不允许定制的部分,小到应用名称/图标,大到UI布局/交互操作
另一方面,从需求场景来看,专用的IDE有几个优势:
这也是ReactNative、Weex、微信小程序、支付宝小程序等特殊场景要提供专用IDE的原因,其一希望开发起来更方便,体验更好;其二希望在一定程度上规范写法,统一风格
一款可用的定制化IDE应该具备哪些能力:
其中,各个能力的地位分别是:
空间/发展 可扩展性
-------
种子/成长 集成能力
-------
水/生存 基础功能
集成能力和基础功能缺一不可,可扩展性是想象空间。因为没有种子一切都是空谈,没有水就会迅速失去生命力,有了种子和水之后,是草还是树取决于空间。发芽之后,水要持续不断地满足,所以基础功能才是赖以生存的根本(码的不爽,再怎么方便我也不用)
另外,基础功能有其特殊性,前端IDE的选择一直是个口味问题,重如IntelliJ IDEA/WebStorm,轻如Sublime Text/VS Code,快如NotePad/Vim,想要用一块糖果解决这个众口难调的事情几乎不太可能,所以基于开源IDE进行二次开发似乎成了唯一的选择,除非有个高可用的IDE Core包含绝大多数IDE基础功能,很遗憾,暂时还没有这种东西(Monaco比较接近了,但还差一些关键的东西,比如可扩展性)
定制化的IDE似乎突然之间就冒出来很多,例如:
对应选型方案如下:
名称 | 跨平台 | 基础功能 | 实现方案 |
---|---|---|---|
微信开发者工具 | NWjs | monaco-editor | NWjs手搓,IDE Core用Monaco |
支付宝小程序开发工具 | Electron | vscode editor | Electron手搓,IDE Core用扒来的VS Code editor部分 |
React Native IDE | Electron | Atom | Atom插件合集,IDE Core就用Atom |
最初用微信开发者工具搞过事情(见上不了线的小程序),那种码起来束手束脚的感觉很不舒服(怎么连个xx功能都没有啊),这就是上面提到的水(当然,因为没得选,他们不用考虑水的问题),经过这么久的迭代,在代码编辑、文件管理等方面似乎改进了不少,再没有深度体验
支付宝小程序可能同样考虑了水的问题,所以选择了从VS Code扒一个editor的方案,应该是费了一番功夫的
RN IDE就粗暴得多了,拿了一堆Atom package(插件)过来,堆出了强依赖Flow的IDE,还号称:
A unified developer experience for software development
实际情况是,项目不用Flow的话,连个跳转到定义都不支持
可行方案无非两种:
技术上需要抉择的有3个关键点:
如果是基于开源IDE二次开发,只需要关心用哪个IDE,如果是手搓的方案,则需要选择跨平台方案和IDE Core
相同点:
区别和限制:
其中,比较重要的是平台支持与源码保护方面的差异
选用NWjs的原因:
选用Electron的原因:
开源,且高可用的IDE Core似乎只有Monaco,但存在一些难以克服的问题:
JSX语法高亮有多难支持呢?
可以查看Does monaco support JSX ?,16年底的问题,现在(18年3月)还open着。因为是来自底层正则引擎的限制,无法从.tmLanguage
低成本地迁移过来,详细见Colorization Clarification
P.S.那么TSX是怎么支持的,不都差不多嘛?因为TypeScript也是MS自家维护的,不支持说不过去,没有足够的理由的话,没人会去做巨量的正则转换工作
扩展机制更重要的是生态,毕竟资源有限,我们需要“拥抱”开源,而Monaco恰恰缺少这个,见Integrate VS Code extensions in the Monaco editor
P.S.幸好微信小程序没有造出全新的东西(只是XML,CSS,JS),否则IDE团队可能会面临巨大的工作量
开源IDE | 技术实现 | 维护者 | 受欢迎程度 | 插件生态 |
---|---|---|---|---|
Atom | Electron | Github | 43K star | 插件多,但不活跃 |
VS Code | Electron | Microsoft | 42.6K star | 插件多,且活跃 |
Brackets | Chrome Embedded Framework(在Chromium之上的定制化方案) | Adobe | 28.6K star | 插件多,且活跃 |
单从上面的对比来看,VS Code最具优势。但为什么RN要基于Atom扩展而不是VS Code呢?
因为,VS Code对扩展能力限制很大,比如:
而Atom恰恰相反,没有进程隔离,允许深度UI定制,插件API都是相对底层的,不像VS Code只提供高度封装的,从扩展成本来看,Atom相当有优势
P.S.Atom刚推出时,性能为人诟病,给大家留下了不太好的印象,但日常使用貌似也足够,没那么慢
决策树如下:
定制化IDE方案决策树
5种可行方案优缺点对比如下:
方案 | 简述 | 缺陷 | 优势 |
---|---|---|---|
A)基于VS Code二次开发 | VS Code插件开发 + 尽量小修改源码 | UI定制成本高插件能力受到严格限制UI定制型插件极少 | 插件市场活跃度高代码编辑体验好启动性能高,插件按需加载容易扩展,如Vue或更新的前端生态产物支持 |
B)基于Atom做二次开发 | Atom插件开发 + 尽量小修改源码 | 核心API薄弱插件能力不受限,质量没有保证插件市场活跃度低,后期维护成本大代码编辑体验略差 | UI定制容易插件能力不受限UI定制型插件很多,前期开发快容易扩展,如Vue或更新的前端生态产物支持 |
C)修改RN IDE | 纯Atom插件开发 | 强依赖TypeScript、FlowJSX支持度不高,增强成本低启动性能略差 | 应用场景类似,实现细节都可借鉴,无技术风险现成的UI/交互,不用专门投入 |
D)Monaco + N | VS Code IDE core + Electron开发 | 手动实现,稳定程度没有保障不支持JSX,增强成本很高TSX支持程度不高,增强成本很高 | 去中心,灵活性高开发成本比ABC高 |
E)alm + N | VS Code IDE core增强 + Electron开发 | 手动实现,稳定程度没有保障JSX支持程度不高,增强成本很高 | 去中心,灵活性高开发成本比ABC高,比D低 |
综合来看,真正可行的只有A和B,进一步的选择就要考虑工作量与可用资源了:
假设只有1人月,那么选B,没什么风险,因为B是大前期,能迅速出东西,但将面临后期打酱油的问题
如果有2人月,可以尝试选A,低风险,因为UI定制成本是个不确定因素,影响前期进度,可能导致Alpha等靠前的时间节点压力较大,但大后期有绝对的发展优势
把大象装进冰箱需要3步:
种子与水缺一不可,极端条件下,种子 > 水 > 空间
过程中犯了2个错误:
面对权威压力,不应该动摇理性的判断力,tell me why,我们摆事实讲道理。对战斗力的判断应该基于此刻事实,而不是以往经历,只有真真切切地面对问题时,真实的战斗力才会展现出来
这一套东西,NB在哪里?
反向推动能力 他们的电脑上可是什么都没有
结果之外的东西,有些时候与结果本身一样重要