随着以服务器端的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用在自己的生产环境中。
