導語時光回到38年前，就是1982年，HTML誕生，今後開闢了計算機領域的前端時代，13年後，第一個前端可視化IDE誕生，他就是Frontpage，又兩年後，大名鼎鼎的Dreamweaver誕生，壟斷了前端可視化IDE許多年。此後，前端可視化這片江湖可謂風起雲涌，一茬又一茬的鬥士奮起直追，與此同時，一茬又一茬的背影也在悄然離去，能活下來的，都是英雄。html

可視化IDE的探索之路

能活下來的，都是英雄

時光回到38年前，就是1982年，HTML誕生，今後開闢了計算機領域的前端時代，13年後，第一個前端可視化IDE誕生，他就是Frontpage，又兩年後，大名鼎鼎的Dreamweaver誕生，壟斷了前端可視化IDE許多年。此後，前端可視化這片江湖可謂風起雲涌，一茬又一茬的鬥士奮起直追，與此同時，一茬又一茬的背影也在悄然離去，能活下來的，都是英雄。前端

有的人站起來了，有的人倒下去了，在來與往上與下之間，到底是什麼在吸引着人們前仆後繼，又到底是什麼緣由讓一個個壯士轟然倒下？筆者有幸誤入了前端這片廣袤的沃土，親身體會到其中的深遠與渾噩，簡單與繁雜，刀光劍影，山海沉浮。感概萬分，因而就有了這些許文字。jquery

光明頂有屠龍刀

天下熙熙，皆爲利來，天下攘攘，皆爲利往。若沒有「屠龍寶刀」，誰特麼在乎那到底是光明頂仍是小皮坡。雖然咱們總喜歡高高在上作道德審判，但心裏深處哪一個又不是鬼精鬼精的，若不是「屠龍在手，天下我有」，誰還成天吵着嚷着竭盡全力的幹着「搞前端可視化IDE」的勾當。對的，由於它有需求，有場景，在某些狀況下，確實能幫上咱們大忙。看，黑壓壓的爬在半山腰上的那些人，有谷歌、微軟、阿里、京東……，還有一些在家籌備乾糧，蓄勢待發。git

我是槓精，我要上線

上面咱們信誓旦旦的說到需求及場景，落到細節，都是些什麼牛鬼蛇神？它們當真存在嗎？好吧，做爲一個大部分系統及語言都玩了個遍的大叔，是時候秀一下槓精本色了。github

0一、樣式無所不能，就是不會用

好比，在某個時候，你想給一個按鈕上個草綠色npm

我上來就告訴你我不用谷歌不用百度，我就直接知道這樣寫！小程序
```
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;
複製代碼
```
是的，若是有一個可視化界面，咱們選一下就好，不香嗎？
（這裏省略了剩下的一萬個場景）

0二、佈局很高端，但真心很糟心

咱們常常在一些網站上看到這種炫酷的排版，什麼頂部菜單導航、左側菜單導航、頂部固定排版、橫向膠片排版、圖文排版、瀑布流……

咱們也常常看到內容上的各類對齊方式，什麼上對齊、下對齊、上下居中、左對齊、右對齊、左右居中、橫向均分、縱向均分……

好了，出於須要，咱們也想這樣作，但是當咱們開動的時候才發現，看起來就那樣，一擼擼半年。此時此刻，筆者就不信，難道咱們就不想有個工具給指引指引？

0三、視覺效果滯後

曾幾什麼時候，咱們還在純HTML年代，手擼的代碼，直接拖到瀏覽器裏面，是能夠實時看視覺效果的。滯後？不存在的。

後來， PHP來了，ASP也來了，JSP也來了，都沒提早打個招呼。想實時看效果？想多了，不老老實實跑個服務器實例，你都別想知道標題是啥，況且效果。

再後來，NG來了，React也來了，VUE也來了，小程序也來了，來的更高端，把前端頁面提升到了APP的高度，大部分時候，咱們不跑個「npm run dev」或相應的模擬器實例出來，都不知道咱們本身擼的代碼最終長什麼鬼樣。

這些時候，咱們提供可視化編輯，讓咋們知道本身究竟在搞啥，是否是內心會更踏實一些？

我是槓精，我不服：「 既然有了npm run dev或模擬器，那滯後就不存在啦，那IDE上所謂的實時效果還有個鬼用？ 」

其實，「npm run dev」是須要跑個半天才能跑起來的，再者咱們的業務可能會有狀態這玩意，你跑起來還得切到正確狀態跳轉到你想要的頁面才能看到你想看的內容，可是在IDE裏，這些壓根兒不是事！

再說，若是咱們的業務邏輯是「我點擊一個刪除服務器文件的按鈕以後才展現出一個我想要的頁面」，難道你還真的點「刪除」按鈕以後再看不成？

0四、缺少直觀感覺

前端變化太快，昨天還在說jquery，今天就變了，當咱們還在爲本身封裝的組件志得意滿的時候，打開github，人家幾萬星的更專業的組件庫早就站在那了，而且仍是黑壓壓一片。

夠精緻、夠專業，功能完備，確實省了咱們很多麻煩。但是用多了，總感受還有點不太順，咱們不可能每次都去人家官網上翻來翻去查看怎麼使用，咱們也不可能每一個組件都能記住了，就算記住一些經常使用的，那也不可能每一個使用方法都記住咯。可是，若是有這麼一個IDE，把一些組件庫都整合進來，給你最直觀的入口，拖進去就能用，不hi嗎？

除了方便整合優秀組件以外，可視化其實能夠引入更多的便捷，好比能夠提供一些頁面模版，這不只僅是一段代碼，更是頁面的直觀感覺。

0五、相同或類似場景，更適合屏蔽細節，聚焦差別

之前的前端項目，十有八九是作門戶，如今的前端項目，十有八九是網店，差異在哪裏？別說筆者極端，最大的差異只是名稱和聯繫方式而已。就這，給我丟一筐一筐的代碼，意欲何爲？秀智商？秀高大上？就這場景，讓我填個名稱和聯繫方式，都嫌多！

是的，在一個框定的規則裏面，咱們是能夠屏蔽細節簡化概念提升可複用度的，這個就是如今谷歌、微軟和阿里都不惜花大血本進入的領域，低代碼無代碼開發領域。

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

這麼說來，需求很明確啊，場景很清晰啊，咱們照着給解決方案就行啦。照着給解決方案，不就是嘛。好像是，也好像不是，總感受哪裏怪怪的。若是真那麼簡單，努力的人那麼多，豈不是一入江湖，都能練就一身的絕世武功？到時拆遷隊每一個人衣服上印個「拆」字，而後所到之處，「呼呼哈嘿」一套「降龍十八掌」下來，一切塵埃落定，還須要挖掘機幹嗎？沒看到幾十年來，也沒哪一個企業作到盟主這個位置上來，也沒看哪一個產品處於巔峯位置，都是各自坐各自的小山頭。固然，能坐上山頭作個寨主仍是能夠的，至少能強取豪奪搶個山寨夫人，可是更多的是連名字都沒留下就「呵呵」了，那纔是悲傷的故事。

往往想到這，筆者都一身冷汗，由於身處其中，說不定哪天也「呵呵」了，因此不止一次的思考在這個可怕的江湖裏面，那些人都是怎麼倒下的。思來想去，困惑之間，彷佛也有一些考慮。

可視化並不是靈丹妙藥

上面這麼大的篇幅，不就是吹可視化怎麼怎麼得了怎麼怎麼好嗎？如今反轉，這戲究竟唱哪出？可視化確實帶來了很大的便利性，可是過分解讀和誇大，真的不太合適。

你好比，像咱們這種代碼比漢語還熟悉的人羣來說，代碼仍是來得親切一些，不單親切，我在vscode裏面直接擼代碼，直接寫變量、寫函數、寫樣式，更方便不過，難道還有比這更高效的擼代碼環境？除非代碼都是根據簡單規則自動生成的。除此以外，一切號稱可視化寫代碼比直接擼代碼效率還高的，都是忽悠你的。

優缺點都明顯，怎麼作就是一個度的問題，如何把握這個度？就得看場景：

純視覺稿設計

這種場景，更適合純視覺可視化編輯方案，用戶就只關心最終界面長啥樣，誰管你變量函數有的沒的，跟他有關嗎？

視覺、原型設計基本屬於此類。
後端接口相對固定或後端規則相對固定的應用開發

這種場景，更適合無代碼或低代碼方案，經過可視化配置或簡單的可視化頁面編輯來完整業務需求的開發，但凡多一點代碼都有點多餘。

廣告運營，SAAS統一服務，純數據運維平臺，皆屬於此類。
業務複雜度高的應用開發

這種場景，更適合可視化+代碼混編的方案，代碼爲主，視覺爲輔，畢竟須要碼不少複雜交互邏輯代碼和業務邏輯代碼，定位不清，拔苗助長。

中大型WEBAPP的開發基本屬於此類，固然即便是小項目，若是業務繁雜，也應歸到此類。

乾坤大挪移仍是降龍十八掌？

不一樣的技術，各有千秋，不一樣的產品思惟，各有喜愛，具體要選哪一個場景，彷佛問題並不太大，畢竟山頭那麼多，但凡佔山爲王，也足夠豐衣足食了。無論如何，江湖那麼大，咱們一塊兒去走走？

更多精彩內容，盡請關注騰訊VTeam技術團隊微信公衆號和視頻號

原做者：藍中第

未經贊成，禁止轉載！