关于跨平台技术选型的思考

31次阅读

共计 798 个字符,预计需要花费 2 分钟才能阅读完成。

关于跨平台技术选型的思考
在我们进行技术架构和技术选型的时候,我们经常犯一个错误就是,试图找一个完美的解决方案即:坑少、功能多。
但是,无数次惨痛经历仍然难以记住这个事实,就是,好的架构是需要迭代的。
比如我们团队选择 vue(weex)而不是 react(rn)主要是考虑到了当前情况和团队条件以及应用场景后做了一个艰难的权衡。
对于跨平台,本身就不存在完美的方案。无论是全部原生还是 weex 再或者是 rn 都有令人心动的地方,但,也都有坑。
关键并不是如何找到最好的方案,关键应该是如何驾驭这个方案,比如针对存在的坑,你如何找得到绕过坑的办法。
比如。针对 weex 存在的坑。先不要草率地被网上的对于坑太多的情绪误导而放弃,而将注意力放在它是否能达到我们的目标,我并不关心坑多坑少,我关系的是如何填坑,我的做法是寻找能把坑填上的高手和组织,通过建立 weex 大前端社群。将国内几个 weex 领域的大牛联合起来,帮我填坑。
RN 的生态确实比 weex 大和成熟,但是对我们不适合,原因不仅仅是因为它更适合用 react 开发整个 app 而不是原生 + 业务模块的场景。而更在于我们已经对 vue 很熟悉了,不太能承担得起转换国籍的成本。
说到底,架构和产品功能一样。也是需要不断迭代的。不管现在选择什么方案,可能随着业务变化和团队发展,后续都要根据情况调整甚至推到重来。要综合考虑现实人员、成本、业务需求。没有最优的,只有相对可行的方案。
只要达到企业目标,实现了企业价值,就是好的架构。
对于跨平台前端的未来,现在不管采用什么技术,或许都是临时的措施。未来或许是属于 flutter 的。但是目前,我仍然选择 weex。weex 坑很多,但是我已经找到了填坑的办法。因此对于我来说,就是好的架构方案。
当团队能力达到了新的高度。如果经费充裕,甚至可以回到原生开发。或者迁移到 RN。或者使用前卫一点的 flutter。
在考虑跨平台的时候不要忘了跨平台的目的。

正文完
 0