隨著以伺服器端的NodeJS、桌面端的Electron和原生移動端React Native為代表的全棧JS迅猛發展，真正生產環境中的“JS/前端技術全棧化”已經逐漸變為可能。儘管在前端以外的領域裡，JavaScript還不能取代各領域原本主流語言的地位，但對於大量初創型公司或技術人手不足的團隊來說，更低的學習成本本身就是一種極大的優勢。
對於技術學習而言，學得好和學得巧同樣重要，選對技術棧進行學習，可能會節省大量的時間和精力，更有可能帶來更多的機會。因此結合最新的NingJS會議上的趨勢和自己過去一段時間的實踐經驗，推薦未來一段時間比較值得學習和嘗試的技術棧。
原生移動端
首先，不要幻想能用JavaScript在原生移動端一步登天，但也不要因為許多開發者對於React Native等技術的牴觸而感到畏懼。
如果你/公司的目標不是一個QQ這個級別的大型App，你只是需要給你專案中日益複雜的Web移動端減負，用更強大原生效能去彌補Web移動端在複雜互動中的不足，並且你沒有時間或者興趣去學習原生平臺對應的語言，那麼現在機會來了。
問題初現
分享一下我自己的經驗。在之前的一個Web專案中，前端使用的是Vue框架。隨著功能不斷迭代以及幾次專門針對移動端的重構之後，我認為在業務需求和效能上已經找到了一個平衡點，當時認為下一次比較大的優化可能就要基於Vue 2.0的伺服器端渲染以及用自己寫的圖表庫替代專案中的第三方圖表庫。
但是在一次小規模的使用者內測中，我們發現對於大多數非技術背景的使用者來說，對於效能問題依然是敏感又粗暴的。我們不能指望去告訴每個使用者“這個SPA超複雜的，能實現成這樣已經很棒了好嘛？”，只能繼續想辦法讓每個頁面都能在那些記憶體快被佔滿的低端安卓手機上也保持一定的水準。
當我意識到Web效能終有盡頭、公司暫時也不可能招到兩個原生平臺的開發者時，我決定要不用那些JSer也能玩的方案先做個過得去的App？
Weex準備好了嗎
由於前端使用的是Vue，因此Weex是一個非常自然地備選方案。
事實上，我在阿里的Weex內測的第一時間就申請了（當時上述專案還沒開始）。當我第一次下載Weex的playground把玩的時候，我的想法是“哇，不錯。”；當我準備開始第一個Weex專案的時候，我的想法是“咦，這文件怎麼不太順”；當我暫時放下Weex，並且在四個月後評估它是否能幫助我完成我的第一款App時，我的想法是“怎麼還這樣…”
其實Weex的團隊已經做了很多很酷的工作了，但是對於一個0原生開發經驗的人來說，光是按要求搞定Android Studio就已經脫了一層皮，跟別說沒想到一個潛在的功能需求去查issue時，發現回覆總是“我們正在排期開發”，這難免會給人帶來一種強烈的不確定感。更關鍵的是文件中有太多遺留問題，導致閱讀起來邏輯不夠通暢，進一步加深了各種小問題帶來的煩躁感。
因此在配置了一晚上Weex環境依然沒有很清晰的思路的情況下，我帶著對同時學習React和React Native的擔憂轉向了React Native。
React Native不是銀彈，但威力不俗
作為重點推薦的技術棧，這段少講小故事，多談談推薦的理由以及和Weex的對比吧。
-
首先是Getting Start部分坑不多，基本一次過成功，少數幾個問題都能夠通過搜尋快速解決，平復了我七上八下的心情。
-
其次是有比較優秀的開源專案作為參考借鑑，例如Facebook自己開源了F8App，裡面有不少最佳實踐；其次社群也貢獻了很多優秀專案，我個人主要是參考reading這個專案，通過閱讀其原始碼，儘快掌握React中的部分技巧。
-
同時不能忽略完整的除錯、測試以及打包方案。這些對於沒有原生開發經驗的開發者來說，都是極其需要並且很難自己完成的。
-
大量的社群專案輔助。React Native社群貢獻的專案主要集中在幾個方面：兩個平臺均可用且表現一致的元件、一些需要寫原生程式碼的功能例如第三方登入、一些常用功能的移植例如iconfont和svg等。大部分專案都不是由Facebook主導的，但是React Native能夠在生產上使用絕對離不開這些專案的貢獻。
基於以上這些理由，我認為現在開始嘗試React Native是一個比較合適的時機，如果你也遇到我之前所描述的這類問題，不妨試試看。
至於一些其他的方案例如Ionic、Cordova、Hbuilder、H5+等等我個人興趣不大。基於WebView做的各類優化，結果可能更像是效能以及學習成本都走向了一箇中間點，兩邊都不出彩。
用JS開發原生移動端有未來嗎
我認為這個問題主要取決於社群先厭倦給React Native造輪子還是主流原生開發者們先對React Native產生足夠多的興趣。不過在一段時間之內，React Native還是會繼續向前衝。
當然如這段的標題所寫，我們關注的不僅僅是React Native。在剛剛結束的NingJS大會上，Vue的作者宣佈成為Weex的技術顧問。對於我來說，這可能是再次去嘗試Vue的一個理由，希望尤大大不僅關注Weex本身的技術細節，還能給Weex帶來和Vue一樣嚴謹又易用的文件風格。
但是Weex團隊在專案越來越偏離公司原本的業務需求之後還能對專案投入多少持續的熱情，以及能否在營造出一個願意不斷造輪子的社群，這都將決定我們能否有機會把Weex用在自己的生產環境中。