前言

uni-app是一个开放的、支持多种开发工具的多端开发框架。

目前前端界，主流开发工具有4个，vscode、HBuilderX、webstorm、sublime text。其中前2个市占率更高。（vscode公布的全球月活是500万，没有单独公布中国区数字。HBuilder只服务中国开发者，月活是100万+，在中国的市占率应该相近）

HBuilderX和uni-app，同属一个公司，即DCloud出品。HBuilderX团队为uni-app做了大量的优化和定制。

当然uni-app团队也为其他开发工具提供了良好的支持，尤其是对vscode，比其他多端框架做的更多。

也就是说：

如果你选择了uni-app，在此基础上，希望得到最大化的效率工具支持，那么HBuilderX是你的首选。
如果你坚持使用vscode，以此为原则选择开发框架，那uni-app仍然是你首选，因为它为vscode做的优化，比其他小程序或多端框架（wepy、mpvue、taro）做的更多，比如组件的语法提示。有些开发者误以为使用vscode的话，不如选其他开发框架，这是错误的。
HBuilderX菜单-工具里，可以切换vscode、sublime text、webstorm的快捷键方案。以减少新用户的陌生感。

本文重点是HBuilderX为uni-app做了具体什么优化。至于uni-app为其他ide做的优化，另见：

HBuilderX为uni-app做了什么优化?

uni-app支持cli模式，可以用npm命令安装和构建。
其实HBuilderX中的uni-app插件，也是调用了uni-app的cli。

1. App的真机运行、日志显示、云打包只能在HBuilderX中使用
也就是使用其他ide，只能做uni-app的h5和各端小程序开发。做app开发还得使用HBuilderX。
尤其是云打包，涉及需要注册DCloud账户，必须登录HBuilderX才能使用。
当然，你也可以同时开多个编辑器，在其他编辑器里写代码，在HBuilderX里运行和打包App。

2. 代码提示
HBuilder系列是以代码提示强大著称的。自然uni-app里的代码提示是很强的。
uni-app是vue语法+小程序api。

首先在vue支持方面，HBuilderX是最好的。抛开uni-app不谈，即便开发普通的vue项目，其他开发工具也远不如HBuilderX，详见：https://ask.dcloud.net.cn/article/19601
然后在小程序api的提示方面，不管是组件、属性、方法、参数...HBuilderX都提供了完善的提示。由于这是中国特色的api，其他开发工具都没有良好支持。
最后在pages.json里，开发者要高频编辑，但其他任何工具都没有语法提示，而HBuilderX可以无死角提示pages.json。
小程序的api真的很多，如果你不想一边切文档一边敲代码，如果你不想把大小写拼错，那么一定要用HBuilderX。
好的代码助手能极大提高开发效率，敲几下键盘就能写出大段代码且不会出错，不让手速拖了脑速的后腿。

3. 条件编译的支持
多端开发中，条件编译至关重要，在组件、js、css、json中都大量用到条件编译。
条件编译其实本来是c语言里面的概念，在其他前端开发工具里，uni-app的条件编译无法高亮、无法提示，甚至可能报json语法错误。
在HBuilderX的工具里，一切自然使用，敲ifdef代码块，或者选中一段代码按ctrl+alt+/，都能方便输入条件编译，还支持条件编译的语法提示、折叠、智能双击选中整段......
详见uni-app的条件编译

注意如果一定要用其他开发工具写uni-app，那么编辑pages.json和manifest.json时请使用jsonc编辑器打开，使用json编辑器会报错。
json的条件编译，如不同平台的key名称相同，cli项目下开发者自己安装的校验器会报错，需自行关闭这些校验器对json相同key的校验规则。如果使用HBuilderX的校验器，无需在意此问题，HBuilderX的语法校验器为此优化过。

4. rpx的支持
rpx是全端通用的动态宽度。但这个中国人发明的宽度单位，在老外的编辑器里都无法正常。
其他编辑器无法高亮rpx的单位着色。
如果你的设计稿宽度不是750px，HBuilderX还提供px转rpx的单位换算神器，详见：https://ask.dcloud.net.cn/article/35445

5. 新建页面优化
在HBuilderX里新建页面，可以选择是否在pages.json里注册，选择注册的分包，自动创建页面目录和目录下的vue文件。而其他工具则需要大量手工操作。

6. manifest可视化配置
编辑json配置很容易出错且不友好，可视化的配置轻松而不会出错。

7. 免命令行开发
有人觉得在cli下敲命令很酷，也有很多人不习惯cli。但从客观效率来看，cli确实没有可视化界面搭配快捷键更高效、易掌握。
比如vue官方cli也做了可视化界面，不然复杂操作会很难用。
HBuilderX里开发uni-app可以免命令行，ctrl+n新建项目、ctrl+r运行项目、ctrl+u发布项目...虽然底层仍调用了命令行，但便利性更高，比敲终端命令更快。

8. 转到定义
其他工具只能简单跳转js变量的定义，HBuilderX的转到定义(alt+鼠标单击，或F12)可以精准跳转到每个环节，css的定义、组件中对变量引用的定义、还能在文件和pages.json之间方便切换。

9. 插件市场便捷导入
uni-app插件市场有数千款丰富插件，如果使用HBuilderX，则可以快捷的导入到项目下。如下图：

如果不用HBuilderX，只能下载zip包自行解压使用。当然如果插件作者提供了npm使用方式，那么用终端安装也可以。

10. easycom组件支持
传统vue组件需要先import引用、然后在components下注册才能使用。
uni-app支持easycom，只要工程下有这个组件文件，就可以随时在任何页面里直接用，不用引用也不用注册。打包时还会自动过滤未使用的组件。
HBuilderX完好的支持了easycom，可以对组件进行良好提示、转到定义、及查看vuedoc里的帮助。
在HBuilderX新建项目时选择uni ui模板的话，在任意页面里敲u，会拉出大量组件，比如ulist，回车就可生成一个列表组件。开发效率提升数倍。
easycom详见：https://uniapp.dcloud.io/collocation/pages?id=easycom

11. 使用uniCloud只能用HBuilderX
uniCloud是DCloud提供的serverless云开发服务，用js完成服务器开发，内置云端资源管理。它对安全性要求极高，只能在HBuilderX的使用。

除了uni-app优化，HBuilderX本身也有非常多优点，比如：

代码块：HBuilderX预置了大量uni-app的代码，敲个u，会列出大量代码块，可方便的完成开发。
中文输入法免干扰：国人经常会把半角符号敲成全角符号导致报错。HBuilderX会自动识别，在你敲下全角符号时，识别当前位置语法区，根据情况自动把全角转半角。
json提示优化：vue的js开发，小程序的api方法参数，几乎都是json，多个逗号少个逗号经常出错。HBuilderX可以在回车时自动补齐上一行漏敲的逗号，也会在保存时自动清除末尾多余的逗号。开发json更轻松。
F1直接查语法文档：按下F1，光标所处位置的语法会被自动识别，然后自动在右侧打开该api对应的语法帮助，包括vue的语法和uni-app的api，非常方便。
重构或选择相同语法词，详见https://ask.dcloud.net.cn/article/35732

更多高效极客操作见：https://ask.dcloud.net.cn/docs/#//ask.dcloud.net.cn/article/13191

当然HBuilderX相对其他工具也有它的缺点：

对react、angular框架的支持不如其他工具，因为HBuilderX的重心在于把vue开发体验做到极致。
插件总数没有vscode多。但在vue、uni-app相关领域，不会因为缺少什么插件而影响开发效率。HBuilderX也提供了插件API，基本兼容vscode插件API。HBuilderX还有用户开放平台，这是vscode也没有的功能，非常有利于为开发者服务的公司使用。插件API详见：https://hx.dcloud.net.cn/，开放平台详见：http://open.dcloud.net.cn/

综合来看，HBuilderX优势多于劣势，是更值得陪伴你的优秀开发工具。
而且HBuilder系列有900多万开发者，月活百万级，一直是国人骄傲。
让中国人的开发工具，拥有更多用户，支持它做的比国外工具更好，甚至反向对外输出，这对发展中国人的技术，预防无可避免的中美争端影响，有更大的帮助。

vscode用户常见不适应的地方

快捷键其实可以选择vscode方案，主题也有雅蓝、酷黑等暗系风格。
HBuilderX默认是多项目，vscode默认是单项目。但HBuilderX其实也支持单窗体单项目，对项目点右键选在新窗体打开，详见：https://hx.dcloud.net.cn/Tutorial/UserGuide/multi-window

后记：
很多开发者仍然提希望uni-app为vscode做插件，其实DCloud已经做了https://ask.dcloud.net.cn/article/36286，在vscode里开发uni-app，体验绝对超过在vscode里开发其他小程序或跨端框架。只不过，还是没有HBuilderX用的那么顺。

对HBuilderX有任何需求，欢迎到需求墙投票：http://dev.dcloud.net.cn/wish/

程序小菜鸟

回复 DCloud_heavensoft ：

其他的不说了，我们看看你的回复点赞多还是我的回复点赞多。

2022-06-10 14:17

1. 我知道HBuilderX支持CLI。但是请不要改目录结构，node_modules, src, package.json 这些请勿更改，或者隐藏。多一个src目录，我不觉得会对开发者造成负担，何况这些结构是共识，起码是node编程的共识。你改动目录结构，隐藏文件，不是你所说的透明掉无用文件，而是让本来已经习惯了vue编程的人重新搞清楚如何才能引入一个npm。隐藏这些文件能让开发者专注于自己的业务逻辑？难道你见过哪个开发者不会点开src文件夹进行开发？

2. 我确实没有用过云端一体的插件。node_modules不支持云端的库放在一起？？既然都是云端了，为何放在本地？云端不是通过api通讯的吗？如果你非要搞个uni_modules，起码你得做到和node_modules一样的版本管理，并且第三方库不需要提交到本项目的git吧？

上面这两点，你们做成了本该和项目有关的依赖，完全在项目里剔除了。不该提交到项目里的第三方库，却要提交到项目里的git。这。。你们觉得没问题？

国内开发者，特别是前端的水平参齐不齐，很多都是从jQuery时代过来的人，而uniapp恰恰又是jQuery时代的风格，所以吸引到大部分是不喜欢用终端的用户一点也不奇怪。但，请你们把目光望远一点，看看技术主流是怎么做的。并想清楚你们要引领主流，还是迎合菜鸟。

npm国外生态不可控这话，只能说很无趣。npm是可以自建私有库的。再不济，起码先抄一下它的功能，自己重建一个类似的，先抄袭，后超越。但你们却将目光锁定在了jQuery时代。。。

回到 Hbuilder：
1. 布局你保留你的意见吧，我不做评论。
2. Vuter和Volar做的太烂？我估计是你没配置好。template、js、css交织引用的部分没遇到过你所说的问题。 "eslint和prettier在HBuilder里都直接支持"，实测使用起来很差，格式化不完美。何况，你所说的eslint和prettier在HBuilder里直接支持，不过也是一个插件。但是鉴于你们的风格，迎合jQuery时代的用户，他们才不会去用eslint和prettier，用户群体少的插件，能做完美才怪。
3. 如果你所说的快，仅仅是启动，打开文件的话，那么notepad++无疑是最大的赢家。作为一个用户，快慢不仅仅是打开的速度，而是使用过程中的各种及时响应。
4. 主题颜色，我说了无意和你争论哪个主题更科学。如果硬要扯的话，你可以去看一下对于键盘布局的讨论，现在的QWERT键盘其实是非常不科学的。但是你觉得如果有一家键盘生产商硬要推他们觉得科学的布局的话，你觉得他能赢得市场吗？虽然你们提供了3个主题，但是第一主题往往代表了用户使用它的第一感受。更不用说其实你们另外2个深色主题也很拉胯。

HBuilder做为中国唯一成功ide，这话我先打个问号吧。现实中，很多人都是为了uniapp才被迫下载并使用它。uniapp是一个很好的产品，但HBuilder不是。HBuilder完全可以用uniapp开发，并利用同样使用uniapp，并熟悉uniapp的用户去使用它，完善它，做成一个和uniapp相互成长的产品。而不是用C++，单靠DCloud官方去维护它，这样的话，HBuilder和vscode的差距将会越来越大。

习惯是一个非常重要的东西，最好应该跟顺着大家的习惯去做产品，而不是逆向，否则只会导致用户不爽。除非你们能够引领前沿，大家以你马首是瞻，就像腾讯，无论大家对微信有多少不满，也得老老实实得使用它。不对。。HBuilder也有这效果，大家不就是为了用uniapp必须下载Hbuilder，对HBuilder敢怒不敢言吗？捂脸逃~~

2022-06-10 13:58

DCloud_heavensoft (作者)

回复程序小菜鸟：

感谢你愿意打这么多字反馈你的意见。

1. HBuilder支持cli，但会提供更易用的内置方式
首先HBuilder支持cli模式，cli创建的项目拖到HBuilder里一样可以用。
但大多数开发者根本不关心vue2或3的底层，大家用的是被修改过的uni-app。
把这些事透明掉，开发者专注于自己的业务逻辑，更方便、更有效率。

2. 关于uni_modules和node_modules
我们对node_modules的态度是支持，但它不够好，所以我们要搞uni_modules。
开发者在HBuilderX里使用node_modules，不会感受到与其他ide有什么不同。
但使用uni_modules，会更方便。

你可能没用过云端一体的插件，包括收费插件，所以你不知道npm不能同时支持云和端的库放在一起，也不知道npm无法实现我们的版权保护策略。

然后从易用性来讲，node_modules要比uni_modules差很多。HBuilder有900万开发者，大多数不喜欢用终端。uni_modules还提供了版本更新的代码差异对比和合并，可以更方便的更新库，减少开发者锁死版本不更新的冲动。

最后，npm作为一个国外生态，有太多不可控性。

综上，HBuilder支持node_modules，但会提供更好用的包管理工具。

然后回到ide本身的问题：
1. vscode在左边拉了一排，HBuilder是在顶部拉了一排，没有很本质的区别。至于运行，在顶部toolbar有快捷入口。ctrl+r更是比vscode方便
左侧文件区字体，是和电脑的资源管理器字体一样大的。这个有调节的必要的吗？如果需求较多，可以增加。

2. 恰恰是HBuilder的优势啊，Vuter和Volar都做的太烂的，很多代码提示都做不好，尤其是template、js、css交织引用的部分。eslint和prettier在HBuilder里都直接支持。

3. HBuilder快于vscode，有技术底层的原因，也同时是大量测试的结果。启动、打开各种大文件，我们都仔细对比测试过，都快于vscode。你提到的有些情况不稳定、卡，是质量问题，不是HBuilder比vscode慢的问题。质量问题我们是承认的，遇到相关问题，请给我们报bug，我们来解决。

4. 主题颜色。HBuilder预置了3个主题，两个是深色的。开发者可以自己换主题。但科学就是科学，我们不能在已经做过科学实验的基础上昧着良心给开发者推荐不健康的主题。所以默认主题是浅色，有人喜欢深色可以自己换。

HBuilder作为中国唯一一个成功ide，HBuilder团队作为华人最顶尖的ide开发团队，是正道，不是开倒车。
ide、端引擎、云引擎，这三者有效结合，才能切实改进数字世界的建设效率。
vscode是有很多用户，导致很多习惯不顺和抱怨，我们能理解。所以我们尽量兼容vscode的用户习惯，提供了主题和快捷键方案，兼容插件api写法，兼容大量插件。
但HBuilder+uni-app+uniCloud，才是面向未来的最佳解决方案，才是数字世界能够更高效、更普惠的关键。

2022-06-09 17:37

我简单说一下自己的感受。我多次尝试用HBuilderX开发，并多次放弃，改用vscode开发。

HBuilderX隐藏了package.json，舍弃了node_modules，将开发所需的包内含在编辑器内，这个是一个极其愚蠢的做法，百害而无一利，编辑器就应该做好编辑器的工作。这样做只会导致由于包更新而不得不做适配，以前用vue2，如今主流用vue3，再以后呢？出到vue10，难道要逐个都打包进HBuilderX？还要忍受来自这些不同包所带来的BUG？

舍弃了npm加载包，额外多加了一个uni_modules，直接将第三方包拷贝进项目，给我的感觉像是倒退回了20世纪。（别跟我说HBuilderX可以一键导入，原理上和自己拷贝进去一样，只不过HX自动化了而已）之前看过你的解释，说是由于npmjs上的包不全是可以在uniapp上用，并且有部分包是需要收费的。其实这个非常容易解决，npm支持加载第三方库，你们完全可以建立第三方库，使用需要登录，部分包需要付费才能使用。

如果你说 #ifdef 这些条件编译在node_modules下无法正常识别，这个更加不需要担心，无论是vue-cli，vite 还是webpack，都支持加载plugin，你只需要做一个编译的plugin即可。

跑题了，说回HBuilderX这个编辑器和Vscode的优劣。估计你也注意到，我一直叫HBuilderX是编辑器，而不是IDE，因为它给我的感觉就是一个 sublime text + 适配uniapp和模拟器。完全无法和vscode对比。更加不能和IDEA这些正牌IDE对比。简单列举一下vscode的优势：

1. 简单易用的界面。而HBuilderX的界面除去编辑区，文件区字体偏小，重点是基本所有功能都挤在菜单栏，完全可以参考vscode在左边栏加功能图标，甚至比如运行到虚拟机，真机可以弹出新窗口，而不是挤在下面的terminal区域。

2. 强大的插件。琳琅满目的插件是vscode的一大特色。想要开发vue2，装个Vuter。想要开发vue3，装个Volar。其他编程语言，同样大把插件。比如在vscode下开发vue3，配置好volar + eslint + prettier，开发效率杠杠的。然而HBuilderX？仅有为数不多的官方开发的插件。且可配置项少得可怜。

3. vscode运行速度比HbuilderX快。不好意思，虽然你们一直宣传比vscode快，你们的理由是C++开发的程序比electron开发的程序快。但是这个是个谬论，代码质量差异所造成的速度差异远比代码语言本身的差异大。我用hbuilderx的时候经常会有卡顿，不畅。用vscode则不会。这方便唯一HBuilderX比vscode好的地方仅仅是内存占用，但是现在内存便宜啊。。。

还有一些小细节，我就不列举了，比如说HbuilderX的默认配色，我也曾经看过你所谓的黑色更伤眼理论。是否正确暂且不讨论，但是，你要知道，黑色主题才是符合广大程序员喜好的主流。HBuilderX功能跟不上主流，起码使用习惯要跟上主流吧？都跟不上，所以才造就如今这样，不讲究的人直接用，讲究一点的人为了写uniapp，被迫在编译的时候用HBuilderX编译一下，其他时候用vscode写代码。

诚心是希望DCloud 回归正道，以uniapp为主，HBuilderX为辅，跟上时代的脚步，不要开倒车了。。。

还有很多吐槽，但奈何太多，还是不写了。。。

2022-06-08 22:04