為什么不做JavaScript服務(wù)端開發(fā)
沒有合適的JavaScript Runtime(JSR ?)
現(xiàn)在JS之所以能夠流行,很大程度上取決于瀏覽器的普及.瀏覽網(wǎng)頁的時(shí)候需要計(jì)算一道簡單的四則混合運(yùn)算,你會(huì)怎么做?心算?打開計(jì)算器然后點(diǎn)幾個(gè)按鈕?我的方法是在瀏覽器地址欄輸入"javascrit:alert(1+2+4*5);".很方便不是么.
但是服務(wù)端的情況就不容樂觀,除了少數(shù)幾個(gè)解析器能夠勉強(qiáng)運(yùn)行單薄的JS語法,似乎很難讓他在服務(wù)端大展拳腳.V8?嗯,確實(shí)很快,不過還只是個(gè)跑在客戶端的小伙子.Node.js?嗯,的確提出了很多特性,不過就拿這些特性想征服服務(wù)端的開發(fā)還是不容樂觀.RingoJS?JVM的龐大,讓JS無法靈巧的伸展.IronJS?無案例,無圖,無真相.
沒有成熟的類庫
你愿意在一片荒蕪的土地上開荒,還是在肥沃的農(nóng)田揮鋤?
JS在客戶端確實(shí)意氣風(fēng)發(fā),jQuery,Prototype,YUI,Ext,Dojo等等.無數(shù)的框架,為我們的網(wǎng)頁動(dòng)態(tài)化提出了解決方案之道.在這百家爭鳴的日子里,眾多特性,理念,被提出來,鏈?zhǔn)讲僮?函數(shù)式編程....一片繁華.
反觀JS在服務(wù)端的表現(xiàn),集合操作停留在增刪改,沒有filter,沒有order.字符串只能拼接,沒有格式化.文件讀寫就一個(gè)CommonJS標(biāo)準(zhǔn).數(shù)據(jù)交互的確得益于JSON的流行,很方便,但是數(shù)據(jù)存儲(chǔ)似乎又回到了ASP/VBScript時(shí)代.
標(biāo)準(zhǔn)
就像客戶端瀏覽器對(duì)JS的支持參差不齊,服務(wù)端對(duì)于CommonJS標(biāo)準(zhǔn)也是有待加強(qiáng).所幸服務(wù)端JS沒有跨"瀏覽器"之憂.
效率
開發(fā)效率頂呱呱的JS在服務(wù)端由于缺少類庫的支持,使得服務(wù)端開發(fā)相比現(xiàn)存的幾個(gè)平臺(tái)(JVM,.NetFX),慢了不止幾個(gè)檔次.客戶端就備受詬病的執(zhí)行效率放到服務(wù)端仍舊是一個(gè)不可忽視的問題.
為什么要看好JavaScript服務(wù)端開發(fā)
靈巧
沒人否認(rèn)JS本身強(qiáng)大的靈活性,強(qiáng)大的自解析,原型鏈和弱類型衍生出的種樣繁多的開發(fā)方式.實(shí)在是讓人愛不釋手.
普及
JSON確實(shí)有XML不可比擬的潛質(zhì),體積瘦小,方便傳輸.眾多語言中都有支持.客戶端無需插件就能原生解析.還有什么比這更棒的么?
活躍的社區(qū)
一個(gè)籬笆三個(gè)樁,一個(gè)好漢三個(gè)幫.活躍的JS社區(qū)不會(huì)甘心JS止步與客戶端,必然會(huì)向服務(wù)端虎視眈眈.
js 在對(duì)文件操作,網(wǎng)絡(luò)傳輸?shù)确矫娑紱]有成熟的解決方案,我認(rèn)為,至少目前是 js 之所以流行是因?yàn)樗蚫om和瀏覽器結(jié)合的比較好,如果脫離了 瀏覽器這個(gè)運(yùn)行環(huán)境 ,js 和其它服務(wù)器端編程語言相比,基本沒有競爭性。
玩家完全可以選擇 IDE 更成熟,開發(fā)、執(zhí)行效率更高的語言來替代。但我看好 json數(shù)據(jù), 在具有一定可讀性,且體積較xml更小,關(guān)鍵是可直接當(dāng)做js中的對(duì)象來使用。我們應(yīng)該發(fā)揮其所長,讓其成為客戶端編程的不二選擇或許才是一個(gè)明智之舉。