导语 时光回到38年前，就是1982年，HTML诞生，从此开辟了计算机领域的前端时代，13年后，第一个前端可视化IDE诞生，他就是Frontpage，又两年后，大名鼎鼎的Dreamweaver诞生，垄断了前端可视化IDE许多年。此后，前端可视化这片江湖可谓风起云涌，一茬又一茬的斗士奋起直追，与此同时，一茬又一茬的背影也在悄然离去，能活下来的，都是英雄。

可视化IDE的探索之路

能活下来的，都是英雄

时光回到38年前，就是1982年，HTML诞生，从此开辟了计算机领域的前端时代，13年后，第一个前端可视化IDE诞生，他就是Frontpage，又两年后，大名鼎鼎的Dreamweaver诞生，垄断了前端可视化IDE许多年。此后，前端可视化这片江湖可谓风起云涌，一茬又一茬的斗士奋起直追，与此同时，一茬又一茬的背影也在悄然离去，能活下来的，都是英雄。

有的人站起来了，有的人倒下去了，在来与往上与下之间，究竟是什么在吸引着人们前仆后继，又究竟是什么原因让一个个壮士轰然倒下？笔者有幸误入了前端这片广袤的沃土，亲身体会到其中的深远与浑噩，简单与繁杂，刀光剑影，山海沉浮。感概万分，于是就有了这些许文字。

光明顶有屠龙刀

天下熙熙，皆为利来，天下攘攘，皆为利往。若没有“屠龙宝刀”，谁特么在意那究竟是光明顶还是小皮坡。虽然我们总喜欢高高在上做道德审判，但内心深处哪个又不是鬼精鬼精的，若不是“屠龙在手，天下我有”，谁还整天吵着嚷着不遗余力的干着“搞前端可视化IDE”的勾当。对的，因为它有需求，有场景，在某些情况下，确实能帮上我们大忙。看，黑压压的爬在半山腰上的那些人，有谷歌、微软、阿里、京东……，还有一些在家筹备干粮，蓄势待发。

我是杠精，我要上线

上面我们信誓旦旦的说到需求及场景，落到细节，都是些什么牛鬼蛇神？它们当真存在吗？好吧，作为一个大部分系统及语言都玩了个遍的大叔，是时候秀一下杠精本色了。

01、样式无所不能，就是不会用

• 比如，在某个时候，你想给一个按钮上个草绿色 我上来就告诉你我不用谷歌不用百度，我就直接知道这样写！

  background-color: lawngreen;

      好了，不用说了，我估计你要约我停车场见了。但我想，大部分人还是不知道的，这个时候，如果有一个界面弹出来，颜色都在那，让我们选，不觉得很hi吗？

• 比如，在某个场景，你想给一个元素加上阴影

我告诉你我不用谷歌不用MDN，上来就这么一套语法规则教你怎么做人！

box-shadow: h-shadow v-shadow blur spread color inset;

好吧，别说了，我知道了，不管如何，医药费你得付一下。

• 比如，我在某些地方，我希望文字限定宽度，超长自动打点 就这么简单的诉求，不用可视化的话，哥都得经常谷歌或MDN一下，但你说你就是记得，你啥都记得，你怎么不上天？

  display: block; text-overflow: ellipsis; text-align: center; white-space: nowrap; overflow: hidden;

• 是的，如果有一个可视化界面，我们选一下就好，不香吗？

• （这里省略了剩下的一万个场景）

 02、布局很高端，但真心很糟心

我们经常在一些网站上看到这种炫酷的排版，什么顶部菜单导航、左侧菜单导航、顶部固定排版、横向胶片排版、图文排版、瀑布流……

我们也经常看到内容上的各种对齐方式，什么上对齐、下对齐、上下居中、左对齐、右对齐、左右居中、横向均分、纵向均分……

好了，出于需要，我们也想这样做，可是当我们开动的时候才发现，看起来就那样，一撸撸半年。此时此刻，笔者就不信，难道我们就不想有个工具给指引指引？

03、视觉效果滞后

曾几何时，我们还在纯HTML年代，手撸的代码，直接拖到浏览器里面，是可以实时看视觉效果的。滞后？不存在的。

后来， PHP来了，ASP也来了，JSP也来了，都没提前打个招呼。想实时看效果？想多了，不老老实实跑个服务器实例，你都别想知道标题是啥，何况效果。

再后来，NG来了，React也来了，VUE也来了，小程序也来了，来的更高端，把前端页面提高到了APP的高度，大部分时候，我们不跑个“npm run dev”或相应的模拟器实例出来，都不知道我们自己撸的代码最终长什么鬼样。

这些时候，我们提供可视化编辑，让咋们知道自己究竟在搞啥，是不是心里会更踏实一些？

我是杠精，我不服：“ 既然有了npm run dev或模拟器，那滞后就不存在啦，那IDE上所谓的实时效果还有个鬼用？ ”

其实，“npm run dev”是需要跑个半天才能跑起来的，再者我们的业务可能会有状态这玩意，你跑起来还得切到正确状态跳转到你想要的页面才能看到你想看的内容，但是在IDE里，这些压根儿不是事！

再说，如果我们的业务逻辑是“我点击一个删除服务器文件的按钮之后才展示出一个我想要的页面”，难道你还真的点“删除”按钮之后再看不成？

 04、缺乏直观感受

前端变化太快，昨天还在说jquery，今天就变了，当我们还在为自己封装的组件志得意满的时候，打开github，人家几万星的更专业的组件库早就站在那了，并且还是黑压压一片。

够精致、够专业，功能完备，确实省了我们不少麻烦。可是用多了，总感觉还有点不太顺，我们不可能每次都去人家官网上翻来翻去查看怎么使用，我们也不可能每个组件都能记住了，就算记住一些常用的，那也不可能每个使用方法都记住咯。但是，如果有这么一个IDE，把一些组件库都整合进来，给你最直观的入口，拖进去就能用，不hi吗？

除了方便整合优秀组件之外，可视化其实可以引入更多的便捷，比如可以提供一些页面模版，这不仅仅是一段代码，更是页面的直观感受。

05、相同或相似场景，更适合屏蔽细节，聚焦差异

以前的前端项目，十有八九是做门户，现在的前端项目，十有八九是网店，差别在哪里？别说笔者极端，最大的差别只是名称和联系方式而已。就这，给我丢一筐一筐的代码，意欲何为？秀智商？秀高大上？就这场景，让我填个名称和联系方式，都嫌多！

是的，在一个框定的规则里面，我们是可以屏蔽细节简化概念提高可复用度的，这个就是现在谷歌、微软和阿里都不惜花大血本进入的领域，低代码无代码开发领域。

都是披星戴月，何以九死一生

这么说来，需求很明确啊，场景很清晰啊，我们照着给解决方案就行啦。照着给解决方案，不就是嘛。好像是，也好像不是，总感觉哪里怪怪的。如果真那么简单，努力的人那么多，岂不是一入江湖，都能练就一身的绝世武功？到时拆迁队每个人衣服上印个“拆”字，然后所到之处，“呼呼哈嘿”一套“降龙十八掌”下来，一切尘埃落定，还需要挖掘机干嘛？没看到几十年来，也没哪个企业做到盟主这个位置上来，也没看哪个产品处于巅峰位置，都是各自坐各自的小山头。当然，能坐上山头做个寨主还是可以的，至少能强取豪夺抢个山寨夫人，但是更多的是连名字都没留下就“呵呵”了，那才是悲伤的故事。

每每想到这，笔者都一身冷汗，因为身处其中，说不定哪天也“呵呵”了，所以不止一次的思考在这个可怕的江湖里面，那些人都是怎么倒下的。思来想去，困惑之间，似乎也有一些考虑。

可视化并非灵丹妙药

上面这么大的篇幅，不就是吹可视化怎么怎么得了怎么怎么好吗？现在反转，这戏究竟唱哪出？可视化确实带来了很大的便利性，但是过度解读和夸大，真的不太合适。

你比如，像我们这种代码比汉语还熟悉的人群来讲，代码还是来得亲切一些，不单亲切，我在vscode里面直接撸代码，直接写变量、写函数、写样式，更方便不过，难道还有比这更高效的撸代码环境？除非代码都是根据简单规则自动生成的。除此之外，一切号称可视化写代码比直接撸代码效率还高的，都是忽悠你的。

优缺点都明显，怎么做就是一个度的问题，如何把握这个度？就得看场景：

• 纯视觉稿设计 这种场景，更适合纯视觉可视化编辑方案，用户就只关心最终界面长啥样，谁管你变量函数有的没的，跟他有关吗？ 视觉、原型设计基本属于此类。
• 后端接口相对固定或后端规则相对固定的应用开发 这种场景，更适合无代码或低代码方案，通过可视化配置或简单的可视化页面编辑来完整业务需求的开发，但凡多一点代码都有点多余。 广告运营，SAAS统一服务，纯数据运维平台，皆属于此类。
• 业务复杂度高的应用开发

     这种场景，更适合可视化+代码混编的方案，代码为主，视觉为辅，毕竟需         要码很多复杂交互逻辑代码和业务逻辑代码，定位不清，适得其反。

     中大型WEBAPP的开发基本属于此类，当然即使是小项目，如果业务繁杂，       也应归到此类。

乾坤大挪移还是降龙十八掌？

不同的技术，各有千秋，不同的产品思维，各有喜好，具体要选哪个场景，似乎问题并不太大，毕竟山头那么多，但凡占山为王，也足够丰衣足食了。不管如何，江湖那么大，我们一起去走走？