我轉了快2個月了，準備 談談感想。晚上回家吃完飯開更。
---------
看到這麼多贊，不填坑對不起大家，但是本人水平有限，內容又太多太雜，今天先更新一部分，這幾天較忙。之後慢慢補，謝謝大家支持和點贊。
1，普通pc端開發與移動端開發區別。
先說背景，我大言不慚的說一下，我pc端的前端開發幹了有快4年多，不算大牛，也算一個標準的前端開發工程師吧，可憐的是我2015年之前做過的移動端項目不超過1個。。所以幾乎經驗爲零。我對這個神祕又被炒的火熱的名字迷惑了很久，移動前端開發工程師，h5前端開發工程師，native前端開發工程師，Hybrid前端開發工程師，臥槽感覺屌屌的有木有啊。。
所以我在15年決定棄坑了（pc的代碼實在寫膩歪了。。），投身到專屬的移動開發中，業餘時間也做過phonegap，也知道和了解過一些h5+native開發的方式，下面就慢慢給大家【科普】一下。。說錯了別噴。
普通pc端開發，我理解就是你拿電腦打開的網頁都算【這不是廢話麼】。
那麼移動端前端開發工程師，說白了就很好理解了，做手機網頁的前端開發工程師。
這麼一比，是不是感覺，移動端開發簡單多了？
沒錯，我轉了之後發現還真是呢。。。【還有點小激動】
pc，我們需要考慮什麼呢？有點開發經驗的同學都知道，ie6-11，firefox，chrome，safari都得兼容的吧。哪個都夠你吃一壺的，無論是css還是js。
mobile的網頁開發，我們需要考慮什麼呢？
就目前來說，我們只需要考慮webkit內核的瀏覽器和chrome，uc，qq，小米手機瀏覽器就好了。。。【後面特意會說這幾隻國產瀏覽器哪裏屌了】
相比較而言，除了經驗是0以外，需要兼容的東西還是少了，少了，少了呢。
ok，單純說pc和移動端開發的區別，其實也就是這個，可以簡單的概括來說，mobile端的網頁開發比pc端的網頁開發，更簡單一些。【頁面小了啊，裝的東西少了，css和html寫的少了吧】交互簡單一些【滑動，觸屏，手勢，平時看看手機你還能有啥特殊操作？】
so，別被這玩意嚇壞了，根據我的經驗來看，pc端的前端開發程序員，轉mobile開發，一點問題沒有，而且上手會很快。
夠直白的解釋了。
2，移動端web app開發與套殼開發區別。
移動端web app，移動端網頁，Hybrid開發【我喜歡叫套殼開發工程師……】，無所謂叫什麼，移動端開發無疑就是這3種了。下面一一解釋下我的理解。
移動端web app是什麼呢？簡單理解就是頁面頭部加入了下面這一句話的東西：<meta name="apple-mobile-web-app-capable" content="yes">
這個meta的作用是讓普通移動網頁被添加到主屏幕後，擁有一些類native的功能，很多同學應該都很熟悉了。就是類似隱藏ios的上下狀態欄，實現全屏，禁止彈性拖拽，全屏，修改頂部顏色等。
我理解這種模式的網頁爲web app，當然還有一種類型就是大家平時都訪問的那些網站，比如手機taobao，手機美團，手機微博的網頁版，大家打開的時候，不是全屏的，但是用起來，開發者把它們僞裝的很像這種web app的交互體驗而已。
以上2種我覺得可以總結爲web app。而不是普通的移動端網頁，如果想看移動端網頁，可以參考手機新浪網，手機網頁，手機騰訊新聞，手機鳳凰，是很好的對比。
之後我來說下套殼的吧。這部分如果沒有開發過phonegap或者類似和native連調過webview的同學，可能覺得很陌生，其實不是，這種套殼開發和開發普通的網頁沒什麼區別，只不過資源大部分是file開頭的，本地資源，網絡資源分爲使用js異步接口獲取和native獲取，再和js的接口交互，類似ios中，可以直接在oc或者swift可以直接在webview中執行js，android同理，但是js想調用native功能怎麼辦呢？
我們這邊的做法是有一個負責通訊的iframe，我們通過修改這個iframe的url，來讓native來監控一系列特殊的url地址請求，再在native中調用對應的功能，比如攝像頭，特殊交互，呼起，或者提供接口數據。數據的提供方式類似jsonp的原理，在執行函數的參數中傳回來。
理解了這塊，其實做套殼的比做普通web app和網頁都簡單，因爲在native的webview中是可以指定是什麼版本的webview，用什麼內核，擁有什麼等級的安全權限等等，ios和android做法不一樣，但是原理一致，對於前端開發工程師來說是無差的。
而且套殼開發還有個好處就是，因爲資源是本地化的，所以可以使用比較重的框架，如angular，react，一些三方框架，因爲最終都是通過和native代碼捆綁發佈的。
套殼native的靜態前端部分的更新，我們可以使用遠程下載靜態資源包的方法實現，不發佈大版本而修改webview中邏輯的需求，這一點也是大部分公司選擇一半native一半h5來開發的原因。都知道ios審覈發版很慢。
這些就是我知道的一些很通俗的區別了，技術細節就不說了，太多。大家有個概念就好啦。
3，對js和css的使用選擇。
這部分我提前預警，這是我自己的看法，不一定是正確的，大家互相討論。
我的想法是不使用目前那些主流的移動端框架，選擇手寫。我會說爲什麼。
比如jq mobile，zepto，backbone，angular，還有類似工具集，underscore，一些動畫框架，還有小型的遊戲框架，統統其實是不太需要的。
我並不是說他們不好，而是這些對於新手來說，只能是陣痛藥，而不是萬能藥。爲什麼呢，移動端的優化很大的一個瓶頸就是網絡加載速度不一致，有wifi，有3g，有4g，還有2g。代碼量在移動端開發是很大的一個考察點。
我們反觀這些框架：zepto最先說，你用它做什麼？動畫？選擇器？事件委派？基於zepto的插件？可能大部分人就是用個選擇器吧。但是移動端的原生選擇器方法應有盡用，原生的完全夠用，包括事件和委派，一共寫起來不超過10幾行的東西，引入一個框架不值得。再說mvc的框架，如果不使用離線存儲，我是反正不敢想沒wifi的情況下體驗如何，外加移動端真的是否需要分層這種處理不說，主要還是看業務場景。
套殼的那種上面說了，框架隨便用，因爲足夠複雜，但是普通移動端開發，我個人是不推薦使用的，可以直接上原生的來寫，最多來一個模塊化工具。我下面就說說自己是怎麼做的吧。
手機端對ES5的特性已經全部都支持的很好了，參考：
xiaojue/ES-shim · GitHub
這裏的api特性，只實現了一部分，但是其實平時對數據的處理，對象的處理，已經完全足夠。我不說優缺點，我只說，移動端這些都是純天然的而已。
然後是我們對手勢的處理，zepto中有幾個很有用的事件，swipe，swipeLeft，right，up，down，一類的，還有tap，我們可以看下zepto的源碼：
zepto/touch.js at master · madrobby/zepto · GitHub
我們真的所有場景都需要所有的功能麼，tap，doubletap，有多少人用了。。用到的時候，也是非常好實現的功能。我推薦直接手寫，或者自己寫一個swipe的基類，也不會比zepto的touch.js多太多，而好處是我們可以讓它貫穿我們的項目，作爲一個base類使用，當然我不是噴zepto多餘，它很多代碼做了兼容處理，但是就目前我們的業務來說，我們只需要考慮webkit，只需要考慮幾個特定國產瀏覽器，因爲這是統計數據說了算。
沒了框架，我們就不能寫代碼了麼？移動端開發，我覺得更考驗的是前端的基本功，只要基本功紮實，其實都是很簡單的需求，正因爲都是自己一行一行寫的，遇到詭異問題就更好解決，而不再需要糾結於，到底是我做錯了，還是框架錯了這個問題。
我不止一次的修改過iscroll的源碼來適應和“滿足”我們的測試。。。比如ios下用了iscroll，a標籤無法點擊跳轉，很多人遇到過吧，不看文檔你還真是一時不知道怎麼解決，iscroll由於禁止了頁面原生的滾動，很多本來很簡單得東西複雜化了，而我們需要的是什麼？一個下託刷新？一個慣性滾動特效？開什麼玩笑，原生的也沒幾行啊。。。對於一個寫了多年pc端的前端來說我相信徒手寫個下託刷新禁止頁面慣性反彈的代碼，應該不復雜吧？這裏給個思路，比如我們檢測touchmove的位置快到達頁面【或者容器】底部的時候，阻止touchmove，做容器或者頁面translate移動，再在下部埋一個loading，touchend之後再做緩動回覆，應該普通前端都能做到。
再說一個常用的移動端框架，swipe.js 做幻燈用的，我相信幻燈片做pc端得前端應該每個人都寫過不下5遍了吧。只是事件換了，當然移動端有移動端自己需要處理的問題，但是我使用swipe框架的經歷也是很痛苦的，比如無法很好的設置滾動過的距離，自定義緩動效果，還有無法它自己本身帶的一些問題，比如橫豎屏的時候復位問題，動態插入子節點重排等，讓我第一次用的時候越開發越傷心，後來乾脆也是自己實現。
所以其實，1，我們的需求，那些移動端框架不一定滿足我們。2，太大，太複雜，太難調試。3，需求其實本身不復雜，只是我們想偷懶了。
有點跑題，這個標題說是js和css的選擇，js的立場我足夠明確了，如果簡單功能，不需要js框架，原生足夠，已經做得很好，下面說說css。
首先，做pc我們都需要一個reset或者common，我共享下我們的，
https://gist.github.com/xiaojue/8bac56fb488532e7857f
當然裏面有一些我們特殊的顏色字體，我css並不是特別好，我簡單的重複一下我們css同學的一些注意要點，可能不全：
這其中字體的選擇是根據平臺來做的，我們平時用控制檯模擬開發的時候是沒有ios或者android系統字體的，但是你不設置又很醜，所以基本是從電腦支持，到移動端支持這個順序排列的。下面截圖幾個wiki：
&amp;lt;img src="https://pic2.zhimg.com/50/2377c617322354461979274b8bf26cae_hd.jpg" data-rawwidth="1072" data-rawheight="445" class="origin_image zh-lightbox-thumb" width="1072" data-original="https://pic2.zhimg.com/2377c617322354461979274b8bf26cae_r.jpg"&amp;gt;
&amp;lt;img src="https://pic3.zhimg.com/50/992499c563a3a461778077450e204743_hd.jpg" data-rawwidth="675" data-rawheight="303" class="origin_image zh-lightbox-thumb" width="675" data-original="https://pic3.zhimg.com/992499c563a3a461778077450e204743_r.jpg"&amp;gt;
&amp;lt;img src="https://pic2.zhimg.com/50/6c55898274e9641cb678a3a8f998f410_hd.jpg" data-rawwidth="1076" data-rawheight="447" class="origin_image zh-lightbox-thumb" width="1076" data-original="https://pic2.zhimg.com/6c55898274e9641cb678a3a8f998f410_r.jpg"&amp;gt;
&amp;lt;img src="https://pic2.zhimg.com/50/ebbc3d81f6d395ca788c17161a339bda_hd.jpg" data-rawwidth="648" data-rawheight="200" class="origin_image zh-lightbox-thumb" width="648" data-original="https://pic2.zhimg.com/ebbc3d81f6d395ca788c17161a339bda_r.jpg"&amp;gt;
還有很多，我只找一些我認爲可能知道的人少一些的，我們的wiki還有很多，我css並不太好，這部截自同事的wiki貢獻。css這個方面的東西，我不好多說，畢竟我承認我css一般，但是有幾個原則可以提煉出來的就是：
1，很多坑的造成是對原生屬性的掌握程度不熟練或者不知道有這個特性。
2，很多屬性極限突破可以使用縮放，傾斜這種手段來hack，比如最小字體，比如各種自己畫的僞類圖標。
3，能css畫的不要用圖。
4，大小需要自適應的圖標做成字體的不要畫。
5，能flex佈局的不要用浮動，不要用絕對定位（不利於頁面佈局的擴展）
本來還有幾個比較典型得css案例，這個找機會在其他答案裏說吧，都是上週css比較屌的同事分享的，我也受益匪淺。總說就是移動端的css的寫法和pc相差甚遠，而且技術含量更高了，可喜的是兼容性問題少了，更多的是如何處理的更好擴展和精簡。
4，模塊化移動端的常見組件。
我只說我們非業務方面的，可以抽象出來的，可能和公司業務場景掛鉤。
1，touch對應的swipe事件。
2，各種滑動翻頁效果。
3，簡單的小遊戲框架。
4，視頻和音頻的包裝。
5，各種lazyload。
6，各種keyframes效果收集。
7，拉拽刷新。
其實很多pc要有的mobile端也都有，比如浮層，tip，氣泡，分享，添加主屏一類，可能和業務關聯太多，就不一一列舉了。這部分的組件其實市面上也沒有太多開源的比較簡易的，大部分都是又支持pc，又支持mobile，導致了很多冗餘，或者質量和需求，api不過關，導致很難擴展，各家都是自己寫。比如在微信的webview裏分享和在qq的webview分享，和在普通頁面的分享，在微博的webview裏分享，提示和實現的方法都不一樣，但是其實完全都是可以抽象成一個公共的東西的，我的團隊也在做這方面積累。
這個再安利一下，我做的一個做劃屏活動頁的組件：
xiaojue/EasySlide · GitHub
慢慢我也會開源我們內部抽象好的移動端組件出來的。
5，移動端的性能優化和統計。
性能優化必須建立在統計的基礎上，否則都是耍流氓，所以先說統計。
目前我的做法和pc差不多，監控一些前端關注的時間點，首屏，doc ready，window ready，css ready，實現統計方法和pc也都一樣，應該各個公司都有，我簡單說下前端實現首屏統計如何做：
我的思路是，首屏的圖加載完，即首屏完成，首屏無圖，最接近首屏的dom節點ready的時間點爲首屏時間，我們可以在load的時候和document ready的過程之間檢測這幾個臨界，來收集首屏的完成時間，當然很不準啦，但是也是有一些參考價值的。。。
有了數據，我說一下移動端的統計極值問題，舉個例子，我們手機打開一個網頁，還沒有load完成，切到了後臺，這個時候腳本是不會執行的了，過了幾小時，幾天再回來的數據，我們都能收集到，這部分屬於垃圾數據，是需要算平均值的時候去除的。這點和pc不太一樣。
然後是性能優化建立在均值性能指標上的，我們儘快的提升首屏和win load的時間即可，原則和做法和pc一致，當然，移動端不是資源越合成一個越好，我們的實踐是分散成不同的幾個資源下載，總時間比較快，比如活動頁面，h5小遊戲頁都是這樣。可以統一把資源圖拆開加載，然後增加loading即可。
----我還在奮力思考和編寫中-----今天先到這裏了。。。。【這裏還有一個點，我想討論一下是mobile的cache的利用率問題，這個明天我詳細說，決定找些權威的數據或者自己做下測試再開始寫】
6，移動端網頁佈局方法與pc的差異。
主要是css方面，外加如何做到同一url，不同客戶端展現不一致的做法，俗稱pc和mobile都兼容。還有會說一下rem的相關用法和一段比較經典的rem.js
今天有空來更新一下這個rem在移動端佈局的一個用法：）（20151013更新）
首先，em和rem的概念我簡要說一下，em是父元素fontsize的倍數表示，rem則是root即爲html的fontsize的倍數表示。比如我html.style.fontSize = 12px;那麼1rem則爲12px，0.5rem爲6px；
好了，概念有了，那麼做佈局的時候我們怎麼用呢，大家應該用過的都知道，移動端的字體默認爲16px，那麼1rem我想表示爲10px的話，我們就需要 10 % 16 = 0.625 即爲62.5%，這樣就可以比較方便的把設計稿裏的px轉換成rem單位來做到自適應了。這樣無論用戶如何設置電腦或者手機的默認字體大小，設置爲rem的單位的長度都會隨比例變化。
這是一種常規做法，其實換個角度我們還可以這樣用：
我們想象一個設計稿寬度爲640，800，1200px等尺寸時，我們如何來快速完成響應式的佈局呢？
百分比？flex？這些還是有些複雜的。
後來發現，柵格等比縮放整個設計稿看起來是個更簡單粗暴的方法。而且正好可以利用rem這個比例變化單位。
看下這段js：
https://gist.github.com/xiaojue/0615797dd6a7160177bd
比較好理解，我們首先根據psd的設計稿寬度設置一個基值，然後我們js獲取到當前窗口的寬度值，然後把這個設計稿寬度除以100柵格化一下，獲得一份的寬度數，之後再用真實窗口的寬度除以這個一份的寬度，拿到就是我們需要給html設置的fontsize的px值。
這樣我們只需要把對應psd裏的px單位除以100，就得到了任何寬度環境下的rem值。當然實際發現有些瀏覽器這個rem單位是存在bug的，比如比例值不準，那麼我們就需要獲得這個不準的比例再轉換成準的再賦值html的fontsize，可見calcTestDom函數，之後再處理一下旋轉屏幕時候的情況，resize時候的情況就好了。
這樣我們在做一些活動專題頁面時，只需要引入這段js，在頁頭設置一個設計稿寬，然後對着設計稿一頓瘋狂的px除100來定位就好了。。比設置成62.5%的方式要更好（1，修復了瀏覽器bug，2，轉換單位更方便直觀，px/100即可）
7，常見js組件與pc端組件差異。
這部分還在想怎麼說比較通俗易懂，哪些組件是非常典型得，需要我回去慢慢想想，找幾個實際的對比例子。
8，一些常見的坑。
分享一下內部wiki的經典移動端坑和解決辦法。（不會太多，別抱太大期待了。。）
9，適配【機型，瀏覽器】的方法和選擇。
1，統計說話。
2，調試方法。
10，測試技巧與pc的差別。
幾個比較經典的調試方法和工具介紹。
慢慢壘，先補提綱，5678910都沒寫。。。
前端是個很大的概念，我的理解是用戶能夠看到，直接接觸到的層面都算是前端，比如IOS客戶端界面，安卓客戶端界面，網頁界面，甚至PC/MAC 桌面端軟件界面；現在最常見的說法一般是指Web前端，也就是針對於網頁端開發的工作。
也有個說法就是前端就是大前端嘛，如果你的工作真的那麼讚的話，那就包括了web啦安卓啦ios啦甚至pc mac客戶端的界面啦。但我覺得現在一般大家都還是有專攻的。
Web App指的是【Web application】，也就是以瀏覽器作爲客戶端的軟件。比如你要寫文檔，一般會打開Office 2012之類的本地軟件；但是你也可以選擇在瀏覽器裏輸入一個網址，比如我很喜歡StackEdit — *smart* markdown editor ，然後直接在裏面寫東西直接發佈到gist上； 再比如用桌面客戶端來收發郵件，但你也可以直接用瀏覽器登陸gmail亦或者QQ郵箱，直接把這個當客戶端用。總之就是使用網頁版代替本地軟件。
Mobile Web App 當然就是指在手機端打開的Web App啦。我推薦看看Gmail的移動版。
感覺樓主問的問題還挺模糊的，所以我大概照我的理解依次解釋下：
移動客戶端的開發類型（因爲我是個前端所以我是站在前端立場上來說的哈），主要是三種：
Native App（原生APP），也就是完全使用移動設備系統語言寫的客戶端，iPhone iPad就是純Object-C，安卓就是純JAVA, 就是用戶看到的界面啦體驗到的交互啦都是原生的。這是性能最棒的開發方式，但靈活性就沒下面的好。
Web App, 這個就是在移動瀏覽器裏打開的，純HTML+CSS+JS，說白了就是個網頁，只不過非常的富應用，比如手機瀏覽器訪問的GMAIL啥啥的。但說白了就是在瀏覽器裏打開的頁面。。IOS支持可以在桌面創建訪問的快捷方式，但是說到底還是打開Safari跑。。而且對設備硬件的接口什麼的挺薄弱。
Hybrid App.[HTML5 in mobile devices] 我覺得這個更爲合適一些。實際上是使用原生寫了一個容器，然後使用HTML+CSS+JS來實現用戶界面和交互。Web App的短處便可以克服（因爲自己寫的容器可以輔助暴露偏底層的接口，比如本地存儲或者麥克風控制之類），同時比起純原生的java或者object-c開發靈活性要高（更新可以更快更迅速，也不依賴於市場，因爲說白了，就是自己下載更新網頁資源。。）實際上這種方式已經不限於移動端。。豌豆莢其實是個pc端的hybrid app 哇~~~ 而且說實在的，桌面開發的性能就現在來說要比移動好很多。。
以上三種開發方式的比較和分析谷歌裏面一搜一大堆我就不廢話啦哈。我記得2011年的Google io上就有一場talk是android native和web app等開發方式的大PK。。看倆工程師吵還是很有意思的。我順手找着了 [ http://www.youtube.com/watch?v=4f2Zky_YyyQ ]
題主似乎是想學移動方向的前端開發？那是針對哪個方向的捏？個人覺得其實如果還是html+CSS+js的話核心都是一樣的，只不過移動端可能在頁面建構時有些關於尺寸方面（物理像素css像素設備獨立像素這一堆）的細節需要注意下，包括圖片處理之類的，這些可以參見蘋果和安卓的官方文檔，雖然是針對原生開發者的，但很多地方前端是完全該知道的；此外js方面可能就是注意性能方面的問題，我覺得就眼下的情形來說國內要做依賴於html css js又要非常富應用和高性能的移動端可能不太現實。。。而且我覺得移動端開發就目前現狀而言。。拼的完全是痛苦的設備測試和調試。。
然後我跑題感慨下。。。這種遍地都是坑的節奏。。。在我剛開始高興哈哈不用兼容IE了的時候，我發現webkit和安卓碎片化的坑纔是最大頭的。。。
---------
知乎說我的內容不符合社區規範？！why?
1.web前端開發
用最簡單粗暴的方式來講，就是用html + css + javascript來構建一個供人瀏覽的網頁，其中又包括兩個主要的分類：pc端網頁開發以及移動端網頁開發（很多時候被稱爲h5開發）。
那麼這兩者有什麼區別呢，依據本人的經驗來看，pc端的網頁開發要考慮更多樣式兼容性的問題，ie，火狐，chrome等各大瀏覽器內核不一，使用到新特性的時候需要給樣式加上最基礎的兼容前綴，所以最好的做法還是儘量避免使用新樣式屬性來完成預期的效果。在移動端開發網頁就基本不用考慮這種瀏覽器間的兼容問題了，手機上的瀏覽器絕大部分是webkit內核的，所以在移動端網頁開發的時候能用到很多新的特性，像是極大簡便了頁面佈局的flex佈局，還有各種語義化的標籤等。但是由於移動端手機的尺寸種類繁多，所以在這方面要下點功夫，舉個最簡單的例子就是一行本來是能顯示3個目標的item但是在某些小尺寸的手機上只能顯示2個。其他還有一些細微的區別例如js庫的選擇（pc上用jQuery，移動端用zepto等）。
像一個官方網站肯定是需要在pc上以及移動端都能有較好的顯示效果，爲了解決這個問題的方案主要有2種。一是使用像是bootstrap這種自適應的網頁UI框架，根據設備的寬度不同顯示不同的效果。但是現在主流還是做2套UI再根據UserAgent等來分別顯示不同的頁面，這樣在移動端的顯示能更靈活一點。
2.移動前端開發
主流的移動前端開發指的是Android一級iOS的原生開發，什麼是原生開發，最簡單來講就是Android用java寫iOS用ObjectC（swift）寫。這樣做出來的app在瀏覽體驗上肯定是優於網頁的。
由於原生開發需要兩個端開發，開發週期長（原生開發難度比web開發要大），所以最近很多公司都會把產品的一些頁面抽出來用webview來實現，甚至還可以使用phonegap將你的網頁打包成app（可以理解爲純webview的一個app）。這樣的app稱爲hybrid app，可以說是在開發效率以及用戶體驗上各有取捨得出來的產物吧。本人也是使用過ionic以及react native這兩個hybrid app框架，可以說是節約時間人力成本的一種不錯的選擇吧，並且還能讓你一個web程序員產生了一種自豪感：“臥槽我居然能開發app了。”
這時候我又想起了 Jeff Atwood的一句話：
“any application that can be written in JavaScript, will eventually be written in JavaScript. ”