還要多少年, 前端開發才能像客戶端開發那樣輕鬆？

標題黨了,, 具體說意思吧, 看到 Web Compoents 規範進展很多,

Google 的 Polymer, Mozilla 的 X-Tags, Facebook 的 React,

以及一些 MV* 框架, 比如 Angular, Ractive, 都在使用自定義標籤功能加強抽象.

HTML 原先抽象起來太艱難了, 現在終於好轉..

我想知道, 要多少年才能到大家都能順手呢?

我們來分析一下究竟哪些因素讓前端開發這麼困擾。

先看看界面部分吧。

&
&
&

Panel p = new Panel();
p.title = "Test";
Button b = new Button();
b.label = "Click me";
p.add(b);


第一種容易寫，容易理解。

#2. 控制項標籤集

不管你的軟體面向什麼行業，至少都要一些控制項，或者是基本的表單輸入，或者是複雜的比如樹形表格，裡面還可以跨行跨列渲染的。

如果我們有一套映射到控制項的標籤，那麼寫代碼是肯定會簡單很多的，比如說，在HTML裡面沒有原生的Panel，那麼，剛才第一段代碼可能就要變成：

&
&
&

Simple HTML Loader& & &
&Click me&
& &

我們為了使得界面代碼編寫更高效，毫無疑問會傾向於把這麼一堆東西簡化成一個Panel標籤，這樣就會逐步建立一套面向自己行業的標籤集。

#3. 帶邏輯的控制項

剛才這個例子為什麼簡單呢，因為它只是一個普通容器，靜態的，不帶邏輯，所以即使你用什麼靜態模板也能解決問題。如果複雜一點，是一個TabNavigator，就要考慮切換的事件，再複雜一些是個樹形表格，那就更麻煩了。

我們來看jQuery提供的插件方式實現TabNaviator：

&
& &&Nunc tincidunt&& &&Proin dolor&& &&Aenean lacinia&& & &
& &
& &
& &

&
$(function() {
$( "#tabs" ).tabs();
});
&


從我個人的角度看，這種代碼很愚蠢。蠢在何處呢？HTML這類聲明式的界面描述語言，寫起來本來應當直觀一些的，但是被這麼一搞，又往命令式的方向去了。而且兩種東西混雜，聲明和渲染居然分了兩處，又增加了維護的成本。

難道就沒有別的辦法來解決這個問題嗎？

我們看看其他語言和框架，比如Flex和Silverlight。

&
&
&
&
&

&
&
&

&
&
&
&


上面這段是Flex裡面的TabNavigator，在這個鏈接底部有運行結果：TabNavigator

為什麼它可以看不到邏輯的代碼，但是又確實能有動作呢，因為它的實現類是mx.containers.TabNavigator，在這個代碼里，可以自己手動去處理一切內部實現，但是暴露給業務開發人員的就是這麼簡單的標籤。

我們看看在HTML和JS這個體系里用什麼辦法去解決。不要提JSF這類服務端技術，因為它的思路也是不好的，展示代碼的生成和渲染都不在一個地方，會有很多問題。

#4. Polymer與Angular

早期IE里有HTC，也就是HTML Components，因為別的瀏覽器廠商不喜歡，所以快要消亡了。在W3C新的HTML規範里，有一個Web Components，參見這裡：Introduction to Web Components

這個東西跟HTC的思想本出同源，它引入了Custom Elements和Shadow DOM這兩個概念，也就是說，我可以自定義一個標籤，然後在內部隨便怎麼折騰，用這個標籤的人可以很方便。

很美好，是不是，但是只適用於比較新的瀏覽器，基於這個理念架構的框架Polymer的目標也只是支持一些比較新的瀏覽器。Polymer

那麼怎麼辦呢？我們還有Angular，它也可以自定義標籤，然後用directive的方式寫內部實現。

&
&


& &


& &


&

你們發現沒有，不管用什麼非HTML的標籤體系，可能寫代碼會很快，但是有時候要修飾界面，比如只是調整一下所有容器的邊距，某些按鈕的圓角之類，就會生不如死。

這時候你會發現，HTML裡面的CSS真是神器，什麼都能幹，而且是面向切面的，只要你的HTML結構是良好的，完全不需要調整這個層面的代碼。為什麼其他體系的CSS沒有這麼強呢？比如說Flex也可以寫CSS，QT也可以寫CSS。

因為CSS的部分實在是太複雜了，複雜到整個瀏覽器裡面絕大部分的代碼都在處理這方面的東西，像Google的Chrome團隊有1000多人，別的體系沒法有這麼大投入，只能看著羨慕。

上次看到一個問題，近30年來軟體開發體系有哪些本質的改進？我覺得CSS真的可以入選，這是一個把結構和展現完全分離的典範，並且實現得很好。

我們的前端開發一般都是面向某個領域的，不管什麼領域，CSS方向都可以有一個很獨立的規劃，因為它可以不影響界面的結構。所以這個方面，其實不太會對前端開發造成太多壓力，壓力只集中在維護CSS的人群身上。

好了，上面扯了那麼多，其實到現在還在界面的層次，一直沒有去談到真正的邏輯。那麼，最讓我們困擾的部分是哪裡呢？

#7. 模塊化和載入

Web前端開發有個最苦悶的事情就是選型，因為HTML這個體系很開放，提供的默認能力又不是很足夠，如果要做複雜交互的東西，會需要很多額外的工作。有各種框架從各種角度來解決問題，但怎麼把這些東西整合到正好符合自己的需要，是一個很花精力的事情，很多時候恨不得自己把全部輪子都造一遍。

真正的開發工作中，跨瀏覽器，踩各種坑應該是最煩悶的事，其他部分，如果有做好自己領域裡標籤的定義，或者不用標籤用其他方式，應該不算特別困難。

有人說JavaScript語言本身比較鬆散，所以寫業務邏輯比較頭疼，這不算大問題。基於B/S的開發，有一個大坑是你在運行的時候要先把代碼載入過來，然後才能跑。你看那些C/S軟體，有這困擾嗎？再看看後端程序員，誰還要關心自己的代碼執行之前要做的事情？

所以後端程序員寫前端代碼，都情不自禁地會引入一大堆庫。我們形象一點來描述一下這個過程：

嗯，大家都用jQuery，我也引入，抄了兩段代碼發現真不錯。咦，我要個樹控制項，網上逛了一圈，拿了個zTree回來。再埋頭苦幹半個小時，缺數據表格控制項，於是過了一會，jQuery UI被整體引入了。再埋頭苦幹，上網亂點了點，瀏覽器跳出個廣告，一看叫做Kendo UI，看看發現不錯，引進來再說，用裡面的某個控制項。又過了一陣，聽說最近Angular很火啊，看了看例子，表單功能怎麼那麼強，我也要用！搗鼓搗鼓又加進去了。項目里又要用圖表庫，看了半天眼睛都花了，百度的ECharts不錯哦，引進來。哎呀我界面怎麼那麼丑，人家的怎麼那麼清爽，查看源碼，一看，Bootstrap，去官網一看，真乃神器，不用簡直對不起自己。

沒多久之後，這個界面已經融合了各種主流框架，代碼寫法五花八門，依賴了幾M的JS庫，更要命的是裡面某些JS有衝突，某些樣式也互相覆蓋，快瘋了。

這裡有哪些問題呢？

• JS代碼要先載入到界面才能執行，而這麼幾M的代碼載入過來就要好久了，然後每個框架還要把自己初始化，又耗不少時間，半分鐘之後自己寫的JS才開始執行，用戶等得都快懷孕了。
• 不管是JS還是CSS，都應當控制基準的代碼，這件事的主要意義是避免衝突，因為整個體系都比較鬆散，如果不加控制，就會造成衝突。即使在服務端寫Java，也有類簽名一致性之類的問題，所以這個部分必須要重視。

剛才這兩點，第二點暫時不是我們要探討的範圍，第一點，引出的話題就是非同步載入，這是一個可以展開說很多的話題，也不再說了。非同步載入和緩存是面對複雜場景必做的優化措施。

但是這個裡面規範就有好幾種，具體實現方式就更多了。ES6的module也許可以解決這個問題。harmony:modules [ES Wiki]

#8. 邏輯的分層

網站型和應用型Web程序對分層的需求是不一樣的。網站型的邏輯大部分都在處理UI，而應用型可能有很多業務邏輯，這部分需要更好的組織，以便復用，或者即使我們的目標不包括復用，為了這個代碼的可維護性，也需要有比較好的組織方式。

本質上這些組織方式與傳統的客戶端軟體開發沒什麼不同，主要要做的無非就是UI層的隔離，或者模板化，或者別的什麼方式。純邏輯的代碼大家都會寫，但這個邏輯怎麼跟界面產生關係，這是個問題。

有些框架通過在HTML元素上設置額外屬性，然後啟動的時候讀取，在框架內部做一些相關的事情，比如Angular、Avalon和Knockout。有的框架在視圖層中讓開發人員手動去處理界面，就像未引入框架的那樣，比如Backbone，兩者是各有利弊的。

前面這種，一般功能是會很強大，但是它自身所做的東西必須足夠多，多得幫你做掉絕大部分本來該自己做的事，你才會特別爽。所以，用這類框架來做表單型應用的時候，是會非常舒服的，因為這些需求他做框架的時候能預見，所以比如校驗、聯動、存取之類的都會處理掉。假如你要做一個繪圖類應用，這就麻煩了，不管你是用Canvas還是SVG，它所能幫到的都不多。這時候，後面這類可能反而適合一些。

這些數據分層框架的原理是什麼呢？是要做一層表單與數據的對應關係，所以他要檢測數據的變動，比如一個Object，它某個值變更了，要去把對應的界面更改之類。這裡面也有很多的坑，可以一步一步踩過來。。。

到現在，我大致可以回答你的問題，什麼情況下前端開發會比較輕鬆呢？

• 針對自己領域的界面標籤庫比較完善，或者易於擴展
• 樣式容易調整，並且獨立於界面元素
• 邏輯模塊化，層次分明，在某種統一規範上存在大量可用庫

咦，我這三點好像在說微軟的WPF體系嗎？

---

我覺得現在前端已經可以很流暢地像客戶端一樣開發了. 直接上圖比較直接. 這個是我們新開發的引擎工具 http://fireball-x.com/, 整個都是 HTML5 技術做界面. 我想說如果我用 WPF, QT 什麼的寫的話, 這個項目基本就難產了.

如果你是一個像我一樣對操作細節有瘋狂追求的人, 那麼你寫界面的時候一定會希望更多的自定義和對原生控制項的修改. 這個時候你會發現 HTML5 的界面書寫才是你的好夥伴. 比如:

設計這種貼心的 gizmos:

精準的 tree view 插入提示:

為每個控制項量身定做的 focus 視覺效果:

甚至還有窗口間的 dock/popup:

然後一開 Dev Tools 就可以調節樣式, Debug, 很符合處女座們對 1px 的追求:

更新 =============================

我只是回答了一下問題, 順帶show了一下我們未公開的項目. 沒想大家挺好奇這個項目的. 我就簡單介紹一下大概的技術結構和選型過程:

整個項目是構建在 Atom-Shell 之上的. 我們最開始是在 Node-Webkit 上面編寫, 但是無奈 Node-Webkit Bug 比較多, 更新和反饋不是很及時, 所以就換到了 Atom-Shell. Atom-Shell 項目活躍度很高, Report Issue 基本都是當天回復, 而且我發現 Atom-Shell 的作者之一趙成戰鬥力驚人, 也是 Github 上得滿綠程序員.

這是我的戰鬥力:

這是趙成的:

所以我是腦殘程序粉, 喜歡 fo 戰鬥力爆表的程序員和他的項目. 於是我們就改成 Atom-Shell.

底層 UI 部分我們是在 Polymer 基礎上構建的. 所以我們玩的很 fashion 很 high! Shadow DOM, Custom Element, Object Observe, css flex, Web Animation, SVG, 任何你能想到的酷炫新技術, 都在我們的編輯器開發中一一使用. 最開始我使用 Angular 和 React 分別作了一版, Angular 因為採用 MV結構, 不太適合 IDE 類型的程序形態, 具體 MV 粉們就別噴我了, 我是那種不太會用框架,架構的土鱉程序員, 從小到大最愛用的語言是 C 語言, 到現在都只會寫函數 + 結構 的編程方式, 什麼面向對象之類的完全玩不來 (只懂得 struct 裡頭加 父類的 struct head, 只會寫 func ptr ). 用的編程工具也很土鱉, 是我自己寫的一個 Vim 的改版叫做 exVim: Home. 所以, 就是因為我的編程思想非常古老, 以至於我無法接受 Angular 的高大上, 而 Polymer 只是對原生的幾件事情薄薄的包了一層, 符合我們的初衷. React 主要問題在於雙向綁定部分, 不符合我們的項目需求, 否則 React 是個好東西. 估計以後我做網站和其他小東西就靠他.

編譯層我們使用 Gulp, 還是上面的觀點, 土鱉喜歡簡單的東西. Grunt 像我這種用 Vim 寫代碼的程序員, 敲代碼手痛. Gulp 的問題主要在於他的插件編程門檻比較高一些, 畢竟一切都要 streaming, 所以插件的質量普遍不如 Grunt. 好在我們程序員天生喜歡 DIY , 不行自己寫唄.

而這些主要的底層技術選型做好以後, 剩下的事情就是沒(朝)日(九)沒(晚)夜(六)地寫代碼了.

我們團隊缺人, 雖然我編程古怪, 思想老舊, 但團隊成員都是自由選擇, 自由發揮.

如果你是一枚前端, 後端, 全棧 或者 優秀的遊戲引擎工程師, 或者乾脆只是喜歡玩酷炫技術的阿宅, 或者看到這個工具右上角那個圖標就秒懂我們日後要做成什麼樣子. 恰巧喜歡廈門這個地方和沒有打卡的生活方式, 又碰巧想用 Html5, Nodejs 寫寫酷炫的東西. 歡迎聯繫我們.

發簡歷到: team@firebox.im

---

本答案僅為反對輪子和輪子的腦殘粉而寫。【請輪子的腦殘黑也自重，不要跑到本答案的評論區叫好。】

微軟十幾年前早早搞出了HTML Component，但是netscape的餘孽創辦的W3C極力阻撓。現在好了，大家還在慢慢等Web Component。要是當初那一小撮人老老實實接受失敗，現在前端們的日子都很好過。現在的前端，就想被賣了還替他數錢一樣。

輪子你能不能不要對自己不知道的領域亂說話？w3c是TBL創立的，跟netscape有毛個關係。實際上當初的web components提案（Behavioral Extensions to CSS）是MS和Netscape一起提的。

【補充對問題本身的回（tu）答（cao）】

這個提問（還要多少年, 前端開發才能像客戶端開發那樣輕鬆？）又是一個前提（客戶端開發比前端開發輕鬆）就未必成立的提問。實際上長期以來，瀏覽器端開發一直比客戶端開發要更方便優雅。

當然，我贊同 @徐飛 答案里的大部分分析。但是那答案是講web開發本身的挑戰，沒有跟客戶端開發的比較。其實客戶端開發的翹楚，比如WPF——XAML顯然大量借鑒了web開發的方式。

---

關鍵是兼容性。所以說。沒幾年了。後端是統一環境。前端各種廠商的歷史坑。沒可比性。話說回來，就算所有人都用一個瀏覽器的時候。我覺得後端開發也比前端開發複雜多了……知識指數不是一個量級的根本。

---

我最近看了一些WebComponent的東西，包括Google的Polymer，也嘗試了寫一點玩具代碼。說下感想。

寫在前面：WebComponent和MV*的關係其實沒那麼大，和Angular、React關係也沒那麼對立，Angular、React關注了比WebComponent多得多的問題，但在我眼裡它們並不在一個層次上，不衝突。

WebComponent幫我們解決的問題是如何進行UI的組件化開發，而MV*框架在其上層，是關注怎麼構建應用程序。

總結：我覺得Web Component是離我對WebUI開發的理想態最近的一次。

HTML Import，幫助我們終於可以以一個文件一個組件的形式，引入和管理組件，告別一個組件等於1.css，1.js的局面。

Custom Element，是一種理想的組件開發方式，它不僅僅是將組件封裝在一個自定義標籤里那麼簡單，還為自定義元素提供了與原生HTML元素一樣的完整的DOM體系，比如DOM Events，比如document.createElement，比如生命周期相關的回調。你可以通過Attribute來暴露你的屬性，並且能實現像input一樣的界面與value屬性綁定（多優雅！）。也可以暴露自定義方法，.enable(), .disable(), .slideUp(), .expand(), .collapse()（多優雅！）。儘管還有一些不盡如人意，比如content和select用起來就怪怪的感覺，attribute與模型的綁定也沒有自帶（Polymer提供了）。

Shadow DOM，將組件的內外隔離做到了極致，從此我們可以告別那冗長的CSS classname前綴以及結構化命名方式，而使用更短、更語義、更功能化的classname，讓每一段CSS都有它的作用域，改變我們對CSS組織的看法。不僅僅是這樣，Shadow DOM還可以將內外的DOM Events隔離，這真是太好了，Shadow DOM里的事件只會冒泡到Shadow Root就不會再往上了，乾淨、無副作用對吧？

這三者的組合，缺一不可，給了我很大的前瞻感，讓我相信未來有一天，我們對Web開發可以回到HTML/CSS/JS的本質上——你要一個模態框？好啊，給你一個modal.html，你import進去，就可以&你的內容&一個，或者document.createElement("ui-modal")一個，然後拿著它的DOM節點.show(), .hide()就可以了，多好。

從一個標籤出發，裡面就像個黑盒，給你無限的可能，配合上雙向數據綁定等，終於可以讓WEB開發變得更OO，變得更聲明式了，一個字：優雅！

而這一切，用的都是我們熟悉的技術：我們所熟悉的DOM，親切的的事件冒泡，簡單的不能再簡單的標籤嵌套和組合，滾瓜爛熟的CSS。你甚至幾乎不用學習額外任何框架，就可以進行組件化開發！

這就是我所說的回歸本質

---

這個問題應該也不會有一個最終答案，什麼叫「像後端那樣輕鬆」，後端的東西也一樣折騰人，不然要那麼多人幹嘛。

想要自己或團隊輕鬆一點才是真的，不管前端還是後端，只要能找到提高研發效率的辦法自然就輕鬆了。

如何提高研發效率是一個很大的話題，但核心還是要適合自己的團隊，幾個人的團隊照搬企業級的方案是行不通的。

1. 擁抱開源社區，取之於社區，減少自己的開發成本。但要規劃好，最好是一個體系的（用了 jquery 就不用 Yui）。

2. 使用本地調試工具，減少前後端的開發依賴。

3. 構建部署自動化，大大節約時間，可以看看 grunt。

4. 模塊化，讓代碼更加清晰，維護性很好。 component, browserify, seajs 都是不錯的選擇。

5. 提供單元測試，保證模塊質量。

做上面這些工作是為了讓開發人員更專註代碼，作為一個程序員只讓你寫代碼而不用關心那些瑣碎的事會不會輕鬆一些。

代碼層面的問題上面很多人已經提過了，我就不多嘴了。（手機碼字好累）

---

矮油我艹，什麼時候客戶端開發比前端開發輕鬆了，我穿越了么

---

各大平台的native GUI 程序開發發展這麼多年了，也沒比Web 前端開發輕鬆啊。計算機與人類交互的界面問題本身的複雜度限制了它沒法出現一個Ruby on Rails 那樣的框架來簡化開發，你看後端與前端的介面一共就那點兒邏輯唄：路由、驗證、CRUD等。而你如果把前端界面的邏輯也限制到那麼幾種，要麼你的界面會很乏味（比如完全按照蘋果的人機交互指南用官方控制項做出的iOS應用），要麼這個抽象層次太高，需要你作太多的具象化工作。

---

其實都不輕鬆，因為都有各自的要求。

但前台開發因為更多涉及「人」這種最大的不確定因素，所以自身的不確定性也更大，更接近「藝術」的範疇——什麼時候見「藝術」有過確定範式？而後端處理的是邏輯，邏輯是更確定的東西，就好辦多了。

---

客戶端開發簡單嗎？不覺得啊。。。

原來有段時間煩VC的界面設計，就大用特用那個HtmlDialog，全用HTML做界面

---

我覺得前端開發很順手啊。

用過 wxWidgets、FLTK、SWT、Swing，覺得都非常蛋疼，代碼冗長，且很難靈活地實現想要的效果。相比之下 web 前端簡直是好寫到不知道哪裡去了。

於是後來就各種用 Adobe AIR + HTML、各種嵌入 WebKit，再也不寫桌面上原生 UI 的應用了。

就醬，歡迎摺疊。

---

身為一個前端開發從業者，真是覺得要比後端輕鬆很多啊。

目前為止經歷的複雜項目，無法就是交互，數據，渲染這三部分的映射比較多，但是用框架完全可以輕鬆解決啊。話說，即使不用框架的話，基本不涉及到任何演算法問題，只有結構設計的合理，其實做起來還是要比後端的那一坨的各種邏輯要輕鬆多了。

---

我們的項目業務邏輯都壓在後端

---

1.盡量不要浪費時間在處理瀏覽器兼容上面，因為可以採用差異化設計而且那些舊瀏覽器的淘汰率會越來越高。

2.提高自己的英語閱讀和底層API使用能力，不要指望一套方法就能讓前端開發變得簡單許多，提高自身能力雖然比較慢，但是更加長久而且有效。

3.不要迷信所謂框架，所有框架都有它所特定適合解決的問題，比如Angular一般只適合做表單應用，複雜互動式的應用做起來很費勁，而且因為很多自定義的設計，最終修改維護的成本相比與component之類的模塊化框架會高出許多。就拿上面的tab來說，你把template寫死怎麼讓人修改裡面的class？沒有事件介面，怎麼才能讓你的tab與其它的組件進行交互？通過全局變數、scope繼承或者自定義sevice都是極其複雜、難以維護的高耦合方案。另外Angular的這套自定義標籤的API過於複雜多樣化，一個是容易導致濫用，另一個是除非實現功能很簡單，否則別人很難通過代碼去學會它該怎麼用或者怎麼去改。

---

微軟十幾年前早早搞出了HTML Component，但是netscape的餘孽創辦的W3C極力阻撓。現在好了，大家還在慢慢等Web Component。要是當初那一小撮人老老實實接受失敗，現在前端們的日子都很好過。現在的前端，就想被賣了還替他數錢一樣。

---

世界上沒有什麼事情是輕鬆的，如果某件事情，過於輕鬆，那所有人都會來做這件事情。我們能做的，只能在自己的範圍內，把自己搞的輕鬆一點

---

典型的別家的飯菜香……

還是分開來說吧，如果是建設一個簡單的不需要後續維護和重構的項目，前後端都簡單。

但是在實際需要經過用戶驗證的項目中，後端更多考慮的是可持續開發和可維護性，這個時候，大家想的問題不一樣，如果前端一開始就考慮這兩個點，也會跟後端一樣「輕鬆」。

---

我覺得問題應該反過來阿。前端開發遠比native開發方便太多，作為一個資深前端轉資深客戶端，真的都是淚阿。不說了，反正我要回歸前端了。

---

本人在web前端和後端及windows客戶端和伺服器端領域做開發N多年，所以言論會相對客觀些。

先科普一些，什麼是前端開發？什麼是客戶端開發？

前端開發

我們通過一些工具（比如瀏覽器）瀏覽的互聯網上的網站，那麼這個網站的製作過程中的，所編寫的所有前端文件的過程，被稱為前端開發。其中，前端文件指通過用戶客戶端渲染的文件，比如html，css，js等。

與之相對應的還有後端開發，指所編寫的文件，是需要在伺服器上運行的，最終生成html數據後，返回給客戶端瀏覽，比如asp、php、java、dotnet等。

其中最明顯的區別就是，前端文件指運行在客戶端的文件，後端文件指運行在伺服器端的文件。客戶端指使用服務的機器，伺服器端指提供服務的機器。比如你在家裡訪問百度網站，你家裡的電腦就被稱為客戶端，存儲百度網站的那台電腦被稱為伺服器。

客戶端開發

大家通常說的客戶端開發，原先通常指PC端桌面應用程序開發，比如你電腦里的QQ、殺毒軟體、遊戲等，在window下，擴展名為exe。最近這幾年，隨著移動互聯網越來越火，客戶端應用程序開發，也泛指手機裡面的應用程序，就是所謂的App開發了。無論是PC端，還是移動端，都分客戶端和伺服器端兩種開發。

與web相對應的，應用程序中客戶端開發，指運行在客戶端的文件，伺服器端開發，指運行在伺服器端的文件。

我們以前總說的B/S指瀏覽器對伺服器，C/S指客戶端對伺服器。B/S架構就是web開發，C/S架構就是應用程序開發。

回到主題，對主題拆分處理，我們為什麼認為客戶端開發輕鬆？我們為什麼認為前端開發困難？

認為客戶端開發輕鬆的理由主要為下面兩點：

1、完整的開發平台

比如微軟的Visual Studio，比如蘋果的xcode，你研究後發現，你所能想到的事，這個平台都能給你解決。

2、 控制項特別多

我們想實現什麼功能，人家都給我們做好了，我只需要把控制項拖到我們的窗體中，稍微更改下參數就可以了。

我們換一種思路，重新看待這兩個優點。

1，完整的開發平台意味著你極為依賴它，如果換了其他平台，你是否也能解決問題，比如你能夠在xcode下完成window開發任務嗎？答案顯然是不能的。再加上如果這種開發工具做了大幅調整，學習工具的使用，也是需要消耗我們精力的。

2，控制項特別多，同樣意味著你學習表面知識的任務特別重，再加上有些控制項只能出現規定的效果，而不能差異化處理，所以這意味著，你部分差異化的需求是沒法直接通過控制項實現的。

認為前端開發困難的理由主要為下面三點：

1、 javascript難學

原型、繼承、類、構造函數、作用域、同步非同步、ajax、cookie、定時器、dom、bom操作等理解困難，不會使用。

2、 前端框架太多

angular、vue、react等這種框架太多，不知道學哪個，學起來也太難。

3、前端工程化太複雜

模塊化開發的思維，gulp和webpack的使用，什麼叫做模塊，什麼叫做包，npm是啥東西，項目流程如何體現，版本如何進行控制，發布，壓縮，混淆，合併等一頭霧水。

確實，你要是這麼對比的話，前端開發比客戶端開發難得多了，但我覺得這種對比有失公平。

再次用簡單的語言科普一下歷史，是先有的一幫科學家，創造了電腦。然後一幫科學家逐漸的對操作系統進行升級改造。直到現在，無論軟體還是硬體的升級過程，還是在進行中，從現在的情況看，除非人類毀滅，否則這個升級的過程會一直存在下去。

PS：本人為聯想、聯發科服務過一段時間，所以硬體部分也了解下，目前從事教育工作。

從編程語言的迭代來看，先有的機器語言（0與1，二進位編程），這幫科學家覺得機器語言太難懂太難操作，你注意，這幫人是科學家，他們覺得機器語言不適合他們，所以他們研究出一種彙編語言（符號語言，各種助記符），然後發現彙編語言也不太適合編程，所以他們又研究出一種高級語言，你注意，這裡面的高級語言指的是更符合人類思維，人類可以更好操作的編程語言。最早出現的最具有影響力的高級語言，c語言誕生了。然後一部分智商比較高的聰明人解放了，他們可以通過c語言，來創造世界了。

推動人類科技進步的是誰？

答案當然是那幫科學家，那麼維持科技發展的大部分人群是誰？答案當然是那幫工程師，隨著時代的發展，IT行業需要的人才越來越多，工程師的水平差異化越來越嚴重，即水平參差不齊，所以Java、DotNet這類的高級語言出現之後，會讓原本用c語言的那幫工程師覺得編程簡單了，生命有樂趣了。

桌面應用程序的需求越來越旺盛

需求多了，從業人員也多了，但從業人員水平不行，所以類似微軟這種企業，在研發開發工具時，會提前把複雜的功能做出來，這樣，水平一般的程序員，在開發的時候直接使用就可以了。這種思維方式，也是好多同類公司的運營策略。

但對待那種差異化的需求，微軟沒有對他們進行封裝，所以程序員們需要自己一步一步開發，這個過程，不比我們原生JavaScript輕鬆，甚至所涉及的知識點還要更多。

人懂得越多，越知道自己渺小。

當人們得出一個結論的時候，往往是根據自身的學識和經歷推出的，所以往往年長的人，和有相關經驗的人，所說的話會更靠譜一些。

如果一個人覺得前端開發難，客戶端開發簡單，那麼我覺得這種結論不太靠譜。

所以，我最終的答案是，對會這技術的人來說，不難；對不會這技術的人來說，挺難；就像窗戶紙，捅破就好了。

如果需求當中，差異化、個性化、界面、布局什麼的不是特別在乎的話，只在乎核心功能是否能實現的話，大部分的編程工具都會提供一些已經寫好的控制項，我們只要調用就好了，我們web開發也一樣，網站模版本質上和應用程序中的控制項是一樣的，直接使用就好了。

反之，如果什麼都要求盡善盡美的話，你的產品當然要一點一點的打磨，這樣所消耗的精力，及所涉及到技術的多元性也會越來越多的。

最後，套用屈原的一句話，「路漫漫其修遠兮，吾將上下而求索」，少年們，努力吧。

---

怎麼會得出後端輕鬆這樣的結論來？後端只是不用兼容瀏覽器罷了。。。，碰到複雜的應用後端可真不輕鬆啊。。。。

---

推薦閱讀：