JSer全棧化技術(shù)棧推薦(一)——原生移動(dòng)端是天堂還是泥潭

includecmath 發(fā)布于2019-08-01 15:40 / 2473人閱讀

摘要：隨著以服務(wù)器端的桌面端的和原生移動(dòng)端為代表的全棧迅猛發(fā)展，真正生產(chǎn)環(huán)境中的前端技術(shù)全棧化已經(jīng)逐漸變?yōu)榭赡堋２贿^在一段時(shí)間之內(nèi)，還是會(huì)繼續(xù)向前沖。在剛剛結(jié)束的大會(huì)上，的作者宣布成為的技術(shù)顧問。

隨著以服務(wù)器端的NodeJS、桌面端的Electron和原生移動(dòng)端React Native為代表的全棧JS迅猛發(fā)展，真正生產(chǎn)環(huán)境中的“JS/前端技術(shù)全棧化”已經(jīng)逐漸變?yōu)榭赡堋１M管在前端以外的領(lǐng)域里，JavaScript還不能取代各領(lǐng)域原本主流語言的地位，但對(duì)于大量初創(chuàng)型公司或技術(shù)人手不足的團(tuán)隊(duì)來說，更低的學(xué)習(xí)成本本身就是一種極大的優(yōu)勢(shì)。

對(duì)于技術(shù)學(xué)習(xí)而言，學(xué)得好和學(xué)得巧同樣重要，選對(duì)技術(shù)棧進(jìn)行學(xué)習(xí)，可能會(huì)節(jié)省大量的時(shí)間和精力，更有可能帶來更多的機(jī)會(huì)。因此結(jié)合最新的NingJS會(huì)議上的趨勢(shì)和自己過去一段時(shí)間的實(shí)踐經(jīng)驗(yàn)，推薦未來一段時(shí)間比較值得學(xué)習(xí)和嘗試的技術(shù)棧。

原生移動(dòng)端

首先，不要幻想能用JavaScript在原生移動(dòng)端一步登天，但也不要因?yàn)樵S多開發(fā)者對(duì)于React Native等技術(shù)的抵觸而感到畏懼。

如果你/公司的目標(biāo)不是一個(gè)QQ這個(gè)級(jí)別的大型App，你只是需要給你項(xiàng)目中日益復(fù)雜的Web移動(dòng)端減負(fù)，用更強(qiáng)大原生性能去彌補(bǔ)Web移動(dòng)端在復(fù)雜交互中的不足，并且你沒有時(shí)間或者興趣去學(xué)習(xí)原生平臺(tái)對(duì)應(yīng)的語言，那么現(xiàn)在機(jī)會(huì)來了。

問題初現(xiàn)

分享一下我自己的經(jīng)驗(yàn)。在之前的一個(gè)Web項(xiàng)目中，前端使用的是Vue框架。隨著功能不斷迭代以及幾次專門針對(duì)移動(dòng)端的重構(gòu)之后，我認(rèn)為在業(yè)務(wù)需求和性能上已經(jīng)找到了一個(gè)平衡點(diǎn)，當(dāng)時(shí)認(rèn)為下一次比較大的優(yōu)化可能就要基于Vue 2.0的服務(wù)器端渲染以及用自己寫的圖表庫替代項(xiàng)目中的第三方圖表庫。

但是在一次小規(guī)模的用戶內(nèi)測(cè)中，我們發(fā)現(xiàn)對(duì)于大多數(shù)非技術(shù)背景的用戶來說，對(duì)于性能問題依然是敏感又粗暴的。我們不能指望去告訴每個(gè)用戶“這個(gè)SPA超復(fù)雜的，能實(shí)現(xiàn)成這樣已經(jīng)很棒了好嘛？”，只能繼續(xù)想辦法讓每個(gè)頁面都能在那些內(nèi)存快被占滿的低端安卓手機(jī)上也保持一定的水準(zhǔn)。

當(dāng)我意識(shí)到Web性能終有盡頭、公司暫時(shí)也不可能招到兩個(gè)原生平臺(tái)的開發(fā)者時(shí)，我決定要不用那些JSer也能玩的方案先做個(gè)過得去的App？

Weex準(zhǔn)備好了嗎

由于前端使用的是Vue，因此Weex是一個(gè)非常自然地備選方案。

事實(shí)上，我在阿里的Weex內(nèi)測(cè)的第一時(shí)間就申請(qǐng)了（當(dāng)時(shí)上述項(xiàng)目還沒開始）。當(dāng)我第一次下載Weex的playground把玩的時(shí)候，我的想法是“哇，不錯(cuò)。”；當(dāng)我準(zhǔn)備開始第一個(gè)Weex項(xiàng)目的時(shí)候，我的想法是“咦，這文檔怎么不太順”；當(dāng)我暫時(shí)放下Weex，并且在四個(gè)月后評(píng)估它是否能幫助我完成我的第一款A(yù)pp時(shí)，我的想法是“怎么還這樣...”

其實(shí)Weex的團(tuán)隊(duì)已經(jīng)做了很多很酷的工作了，但是對(duì)于一個(gè)0原生開發(fā)經(jīng)驗(yàn)的人來說，光是按要求搞定Android Studio就已經(jīng)脫了一層皮，跟別說沒想到一個(gè)潛在的功能需求去查issue時(shí)，發(fā)現(xiàn)回復(fù)總是“我們正在排期開發(fā)”，這難免會(huì)給人帶來一種強(qiáng)烈的不確定感。更關(guān)鍵的是文檔中有太多遺留問題，導(dǎo)致閱讀起來邏輯不夠通暢，進(jìn)一步加深了各種小問題帶來的煩躁感。

因此在配置了一晚上Weex環(huán)境依然沒有很清晰的思路的情況下，我?guī)е鴮?duì)同時(shí)學(xué)習(xí)React和React Native的擔(dān)憂轉(zhuǎn)向了React Native。

React Native不是銀彈，但威力不俗

作為重點(diǎn)推薦的技術(shù)棧，這段少講小故事，多談?wù)勍扑]的理由以及和Weex的對(duì)比吧。

首先是Getting Start部分坑不多，基本一次過成功，少數(shù)幾個(gè)問題都能夠通過搜索快速解決，平復(fù)了我七上八下的心情。

其次是有比較優(yōu)秀的開源項(xiàng)目作為參考借鑒，例如Facebook自己開源了F8App，里面有不少最佳實(shí)踐；其次社區(qū)也貢獻(xiàn)了很多優(yōu)秀項(xiàng)目，我個(gè)人主要是參考reading這個(gè)項(xiàng)目，通過閱讀其源碼，盡快掌握React中的部分技巧。

同時(shí)不能忽略完整的調(diào)試、測(cè)試以及打包方案。這些對(duì)于沒有原生開發(fā)經(jīng)驗(yàn)的開發(fā)者來說，都是極其需要并且很難自己完成的。

大量的社區(qū)項(xiàng)目輔助。React Native社區(qū)貢獻(xiàn)的項(xiàng)目主要集中在幾個(gè)方面：兩個(gè)平臺(tái)均可用且表現(xiàn)一致的組件、一些需要寫原生代碼的功能例如第三方登錄、一些常用功能的移植例如iconfont和svg等。大部分項(xiàng)目都不是由Facebook主導(dǎo)的，但是React Native能夠在生產(chǎn)上使用絕對(duì)離不開這些項(xiàng)目的貢獻(xiàn)。

基于以上這些理由，我認(rèn)為現(xiàn)在開始嘗試React Native是一個(gè)比較合適的時(shí)機(jī)，如果你也遇到我之前所描述的這類問題，不妨試試看。

至于一些其他的方案例如Ionic、Cordova、Hbuilder、H5+等等我個(gè)人興趣不大。基于WebView做的各類優(yōu)化，結(jié)果可能更像是性能以及學(xué)習(xí)成本都走向了一個(gè)中間點(diǎn)，兩邊都不出彩。

用JS開發(fā)原生移動(dòng)端有未來嗎

我認(rèn)為這個(gè)問題主要取決于社區(qū)先厭倦給React Native造輪子還是主流原生開發(fā)者們先對(duì)React Native產(chǎn)生足夠多的興趣。不過在一段時(shí)間之內(nèi)，React Native還是會(huì)繼續(xù)向前沖。

當(dāng)然如這段的標(biāo)題所寫，我們關(guān)注的不僅僅是React Native。在剛剛結(jié)束的NingJS大會(huì)上，Vue的作者宣布成為Weex的技術(shù)顧問。對(duì)于我來說，這可能是再次去嘗試Vue的一個(gè)理由，希望尤大大不僅關(guān)注Weex本身的技術(shù)細(xì)節(jié)，還能給Weex帶來和Vue一樣嚴(yán)謹(jǐn)又易用的文檔風(fēng)格。

但是Weex團(tuán)隊(duì)在項(xiàng)目越來越偏離公司原本的業(yè)務(wù)需求之后還能對(duì)項(xiàng)目投入多少持續(xù)的熱情，以及能否在營造出一個(gè)愿意不斷造輪子的社區(qū)，這都將決定我們能否有機(jī)會(huì)把Weex用在自己的生產(chǎn)環(huán)境中。