關於跨平臺技術選型的思考前端
在咱們進行技術架構和技術選型的時候,咱們常常犯一個錯誤就是,試圖找一個完美的解決方案即:坑少、功能多。vue
可是,無數次慘痛經歷仍然難以記住這個事實,就是,好的架構是須要迭代的。react
好比咱們團隊選擇vue(weex)而不是react(rn)主要是考慮到了當前狀況和團隊條件以及應用場景後作了一個艱難的權衡。weex
對於跨平臺,自己就不存在完美的方案。不管是所有原生仍是weex再或者是rn都有使人心動的地方,但,也都有坑。架構
關鍵並非如何找到最好的方案,關鍵應該是如何駕馭這個方案,好比針對存在的坑,你如何找獲得繞過坑的辦法。app
好比。針對weex存在的坑。先不要草率地被網上的對於坑太多的情緒誤導而放棄,而將注意力放在它是否能達到咱們的目標,我並不關心坑多坑少,我關係的是如何填坑,個人作法是尋找能把坑填上的高手和組織,經過創建weex大前端社羣。將國內幾個weex領域的大牛聯合起來,幫我填坑。開發
RN的生態確實比weex大和成熟,可是對咱們不適合,緣由不單單是由於它更適合用react開發整個app而不是原生+業務模塊的場景。而更在於咱們已經對vue很熟悉了,不太能承擔得起轉換國籍的成本。產品
說到底,架構和產品功能同樣。也是須要不斷迭代的。無論如今選擇什麼方案,可能隨着業務變化和團隊發展,後續都要根據狀況調整甚至推到重來。要綜合考慮現實人員、成本、業務需求。沒有最優的,只有相對可行的方案。flutter
只要達到企業目標,實現了企業價值,就是好的架構。技術
對於跨平臺前端的將來,如今無論採用什麼技術,或許都是臨時的措施。將來或許是屬於flutter的。可是目前,我仍然選擇weex。weex坑不少,可是我已經找到了填坑的辦法。所以對於我來講,就是好的架構方案。
當團隊能力達到了新的高度。若是經費充裕,甚至能夠回到原生開發。或者遷移到RN。或者使用前衛一點的flutter。
在考慮跨平臺的時候不要忘了跨平臺的目的。