1 月 19 日 weex 團隊在杭州開 weex conf。半閉門邀請制,由於我以前的項目裏嘗試性的接入了 weex ,恰好失業在家有空,就約上冰霜一塊兒報名參加了。前端
雖然這次會議規模不大,現場不到百人,可是彷佛是隻邀請了項目裏有使用過的 weex 的人,現場也不乏騰訊、網易、蘑菇街規模大一些的公司,因此現場討論的氣氛仍是挺好的。下午的演講都是介紹各自團隊在使用 weex 的實踐總結,算是讓我對 weex 的現狀有了更清晰的認知。把我一天下來的感想總結一下。vue
一份代碼,多端運行的思路是邏輯使用 JS 編寫,JS 文件動態的同步到本地,以後本地的 JS 引擎執行 JS 的代碼,經過調用本地提早註冊好的 native 函數實現業務。若是更抽象一步,就是約定一份語法格式(DSL),不一樣平臺針對這個語法執行響應邏輯。有點像編譯的過程,把自定義的字符串解析成本地對應的代碼。只是在早期的時候,有現成的 JS 和 JavaScript Core,天然而然的利用現有的完備的技術體系。react
那麼現有體系有什麼硬傷呢?git
JS 環境和 native 環境通訊性能問題程序員
JS 的 runtime 和本地的 runtime 不一致。兩個環境的互相調用仍是有比較明顯的性能損失。會上有人提到本地的 GPS 定位持續的傳給 JSC,函數響應的過程可能須要幾十毫秒。雖然這種持續的函數調用雖然不是常見的場景,可是這個場景突顯了這種模式的先天的硬傷。github
對不一樣平臺 JavaScript Core 的依賴web
在 iOS 端,weex 使用的是 iOS 自帶的 JavaScriptCore framework;安卓端原先用的是 V8 引擎,後來替換成了 JavaScriptCore 。兩端的 JS 引擎有着不同的代碼,並且 iOS 端的 JSC 是閉源的。若是同一份 JS 代碼,兩個端運行結果不同,調試起來就很是困難。前端框架
其實我原本想用「吊打」這個詞,畢竟 RN 根本不支持 web。以前在技術會議上看到攜程、京東都提到他們打算本身維護一套工具,以支持 RN 的 web 端能力。但是普通小團隊都沒有這樣的研發力量。weex 由於來自自身(淘寶) web 端的需求,因此一開始就支持了三端。雖然 web 端的能力通常,但也仍是能用。這是一個真實的痛點,現場來的不少團隊選擇 weex 就是由於須要同時支撐 web 端。weex
前端框架的優劣就不談了,可是我的喜愛確實不一樣。由於現場團隊聽見有的團隊說咱們對 Vue 比較熟,不想再接觸 react 那一套,就選擇了 weex 。app
畢竟 weex 的最初使命就是解決自身的開發效率問題。阿里內部的認同對於這個項目的穩定性影響至觀重大。隨着 weex 的性能提高,淘寶的雙十一會場的幾千個頁面都是利用 weex 實現的。看來是穩了。
聽到飛豬團隊的一個分享提到的一個業務場景頗有意思。飛豬有一半的流量來自其餘阿里系 app(淘寶等),之前經過 hybrid 的網頁實現。可是網頁的缺點你們都知道了,加載慢和交互體驗差。如今由於其餘 app 都帶了 weex ,因此約定好一些 module ,能夠很是方便的支持其餘 app 嵌入自身的業務。
總之,阿里內部對 weex 已經有價值上的認同。好吧,其實我也不是很關心這個,我知道明天 weex 團隊不會解散就行了。
Weex 開發者社區的活躍度對比 RN 能夠用慘淡來形容。這種心情大概就是兩個開發者若是知道對方用的是 weex 會相視一笑,而後抱頭痛哭。
社區不活躍會對技術的使用提升不少門檻。
好比我看到的一件事,weex 移交到 Apache 後,原先 github 上的 repo 就再也不維護了。Apache 上面並無提 issue 的渠道。開發者也廣泛對 Apache 經過郵件溝通的方式不太習慣。因此一位開發者使用 weex 碰到問題就不知道去找誰了。某些網站上提問有人回答也是幾個月後纔有稀鬆的幾個回答。一個技術要普及,門檻就必定要低。不能但願使用的團隊技術都有一線互聯網公司的水準,能本身看源碼解決;或者都能有渠道找到阿里的朋友幫忙解決問題。
社區不夠活躍,技術的實踐資料也就少了。若是用 RN 想要作路由,一搜就能搜到幾個解決方案。甚至出版社的紙書,RN 都有好多本。然而搜一下 native 如何往 weex 傳值都要找很久。
冰凍三尺非一日之寒。若是要入坑 weex ,社區雖然在變好,可是可能仍是沒有主流的框架那樣活躍,要作好心理準備。
誰不但願看到一箇中國團隊開發的技術方案走向世界舞臺呢?
歡迎關注個人微博:@沒故事的卓同窗
掘金博客地址:juejin.im/user/5624c8…
若是想與我有更密切的交流也能夠加入個人小密圈:程序員生存指南