前後端使用同一種編程語言有什麼優勢和劣勢？

01-05

沒啥優勢，認為只要招js程序員就可以同時干前端和後端的活兒是幻覺

我們公司的產品前後端都是基於 Node 開發的，語言是 Javascript 的語法糖 Coffee script。

優勢自然是學習曲線降低了，語言層面的統一使得學習過程可以大大縮短，前後端開發也可以互相串著來，簡單地學習一下框架即可。

弊端暫時沒發現，寫前端自然要去了解 DOM，就好像寫後端要去了解資料庫和 Http 一樣，結構的不同本身就是門檻。

最後我想替 Coffee 正一下名，其實它的語法比 Babel 或者 ES6、7 穩定很多，同樣是編譯成 ES5 的 JS，它比 Babel 的坑更少，升級也不至於導致大面積編譯失敗，而且少寫的括弧和分號其實能提高開發效率，但有的人喜歡括弧和分號，這對之前寫 Python 的我來說是無法理解的。

廣告時間開始:

這是我們公司的後端框架，基於 Restify 和 Sequelize，提供了完整的 RESTful API 實現，代碼結構和前端框架非常類似，通過 router 為入口，controller 里的邏輯被拆分為 helper 提供了流式的流程，理念非常先進，而且更新很勤快。

https://github.com/open-node/open-rest

這是前端框架，基於 Backbone 和 Chaplin js 的單頁面應用框架，和 open-rest 珠聯璧合是個神器，技術雖然老了點，但是 Backbone 其實是個很簡單，易於調試的框架，適合商業產品。

https://github.com/open-node/kiwi

認為會某個方向的語言,就能做這個方向的活,是很深的誤解和很淺薄的認知.

我做過兩款遊戲項目，一個前後端都用 C++ 和 lua，另外一個後端用 nodejs 前端用cocos2dx + lua。

第一個項目前後端語言一致，是一個 PC 的端游，為了方便前端編譯，後端代碼也整的可以用vs編譯，這樣導致我們的代碼里充滿了前後端混合的代碼，隨處可見的是 #ifdef _SERVER 這樣的宏，代碼多了的時候有的時候自己也分不清這代碼是跑在前端還是後端，簡直就跟代碼混淆一樣，不過時間長了，也自然能明白一些看代碼的門路，寫起來反而比較方便，因為遊戲前後端有很多相同邏輯需要處理，所以同樣的模塊，同樣的函數，同樣的調用鏈會非常多，這個時候你只需要用宏區分開就可以愉快的寫了。

第二個項目是在第一個之後做的，最初的想法是前後端都用 js 寫，由於種種原因，最後前端邏輯變成 lua 寫了，一個最大的困擾就是以前那樣的相同邏輯，現在需要仔細拆分了，總不能前後端維護兩份代碼，因為遊戲邏輯修改太過頻繁，維護兩份相同邏輯的代碼基本是不可行的，我甚至找過並自己嘗試過寫工具把 lua 的代碼轉換成 js 的代碼，可惜能力不足，沒有完成自動化，最後的結果就是盡量拆分前後端邏輯，但依然沒辦法避免，所以我寫了個模塊讓 nodejs 可以直接啟動 lua 虛擬機來跑一部分前端的邏輯，並在 js 和 lua 層面傳遞數據，雖然不是特別困難的一件事，但就像樓上幾位說的，確實不方便。

如果拋開前後端有相同邏輯這點外，我覺得前後端寫不同語言或者相同語言寫沒什麼優劣，因為前後端的大部分邏輯都不同，整個架構跟想法也完全不同。至於什麼語言的學習成本，我覺得作為一名程序員來說，基本可以忽略。

【5】：B、C和S都用C#的表示，調試起來方便，Visual Studio可以允許你在BCS之間不斷地step in和step out。其它選擇都無法超越這種集成程度。

無論工作在前端或者後端，更大的因素還是在乎於人。

整個人的思維方式如果跟不上應用場景的切換速度，語言統一了可能會帶來更多的苦惱，因為他已經分不清到底是在哪一端寫代碼了。

他只要概念稍微一糊塗，你要去弄清楚他為什麼糊塗就更難了。

（黑一把：我司有個培訓班出來的phper，人也蠻勤奮好學的，公司前端少業務繁瑣，就帶著寫AngularJS了，剛開始感覺還好，後來發現不對勁了，帶著寫前端，他老想著這個和NodeJS有什麼關係，解釋了半天，我自己都快糊塗了。）

嗯，很多時候不看臉，看人。

最明顯的好處是前後端通信的數據模型和介面定義是可以共享的，而且數據轉換通常不需要做什麼額外的工作。如果是兩種不同的語言，數據模型要在兩邊用不同的格式分別定義，而且轉換過程中涉及到數據類型和序列化格式的差異很可能要踩到一些坑。要是為這個再引入IDL一類的機制的話，那麼要面對的是3種語言了。此外在工具、環境、編輯器和類庫等很多問題上也會因為共享而節約成本。當然前後端畢竟是不同的領域，所以這種節省不可能真正把開發成本降低一半，但也是很客觀的。

說句題外話，我覺得這一點對程序員的心理建設也是有好處的。畢竟不同語言之間的數據轉換實在是個繁瑣、但又談不上有多高技術含量的東西，偏偏多層應用裡頭這是個繞不開的問題。由此產生了PO、VO、DTO，還有一些我已經想不起名字的XXO，以及接踵而來的各種XXXMapper，諸如什麼代碼生成、反射、AOP、位元組碼增強、運行時編譯，總之十八般武器都用上了，你說為了數據轉換這點小事大動干戈到底是為啥？如果能用相同的格式，讓程序員不用在模型定義和轉換這種問題上浪費生命，我相信程序員的生涯還可以更美好一點。

何必不直接說javascript（這個才是真全棧語言）

網頁前端js是王

個人體會 js兩種繼承

前端html/css/js是原型對象繼承和原型函數繼承混搭萬幸有jquery這樣的庫（本質是轉化原型繼承到過程代碼）

桌面呢 qml用法也是是原型對象繼承和原型函數繼承混搭但是要原生js

移動的最好objectivec/java native， reactive那些都是屎 facebook沒有移動native的基因，這東西就是大公司的人沒事找事給自己毫無意義的人生找點價值

遊戲呢例如cocos2dxjs 側重原型函數繼承這個很簡單熟悉類oo編程的人上手極度容易

後端nodejs也是原型對象繼承和原型函數繼承混搭但是業務部分最好只用原型對象繼承不用閉包只有這樣才能做到大規模使用的oo編程語言裡面唯一的真正的熱更新（貌似除了函數型語言erlang這些 oo裡面只有原型繼承才能實現熱跟新這點秒殺類oo語言的全部）這個非原型繼承的oo語言做不到js天生的嘿嘿

資料庫 mongoldb couched couchbase map/reduce都是js操縱

大數據微軟的hadoop雲js可以操縱地有人用nodes操縱spark 這東西大數據也能搞速度杠杠地快過python接近scala原生

如果用amazon的lamda服務用的也是js寫業務邏輯哈哈

比如知乎山寨的那個stack overflow

就算前後端都用c#也得有點js吧。

這個角度只有js能完全統一。

沒試過用一種語言不過自己寫前後端挺爽的效率比較高吧想改哪裡改哪裡

感覺沒什麼區別吧

語法手冊查的少點

感覺沒什麼劣勢吧，只是沒什麼語言能做到而已。目前JS有這個趨勢。不過分久必合合久必分。

優勢就是沒有劣勢，劣勢根本不存在。比如，C端與S端都用C的。