Meteor 的未来模式大致是什么样子?

昨天提到我将 Meteor 分为经典模式和未来模式,今天说说这未来模式到底是个什么东西。

『未来』这两个字专指 Meteor 的未来,它将要做的事 —— 在我看来 —— 实际就是重塑 JavaScript 生态的现状。进一步解释,JavaScript 生态现在能做的事已经很多了 —— 远比四年前丰富、先进 —— 如果有那么一个角色使得原本需要较高脑力和熟悉度才能实现的事物允许被更多的人享用,那么这个世界上就会有更多的人使用 JavaScript 编写出更好的软件。这一角色,正好契合 Meteor 的使命

注:描述 Meteor 使命的页面在其官网改版过程中已被删除,也许是因为战略调整,也许是因为别的什么原因,我不清楚。

不仅如此,Meteor 连续两次在 UI 层和数据层转型,将未来押宝于 Facebook 的 React 和 GraphQL。这让习惯了经典模式的 Meteor 用户很不适应,刚把 Blaze 和 DDP 吃个半透,你说撒手就撒手,这几年积累的经验无法继承到未来的项目,这是最让人害怕的。这就是学习框架的风险,它让我风光,也终将让我过气。

我是尽量以积极的角度来看待问题,它给予我起步的动力,我已经很知足,既然它在努力让自己 relevant,我也不能停歇啊。并且,Meteor 团队的关注点正从技术创新转为专业确定性,即拥抱生态、回归生态,走上这条开放之路,今后积累的经验就能够迁移了。

在我的观察下,JavaScript 生态的现状是多样性的,没有绝对的主流。不过,也许是我关注的圈子小,我看到的趋势是 ES6/7 + React + Redux + Webpack + GraphQL + React Native. 注意,这仅是我个人的观察。

ES6/7 是对 JavaScript 语法进行扩展,允许开发者使用 JavaScript 写出更简洁、优雅的代码。

React 负责 UI 层,允许开发者像搭积木一样去构建用户界面。

Redux 负责状态的存储与分发,与 React 配合后即可对组件的状态进行集中管理,使得开发者能够更有逻辑地构建复杂的用户界面。Redux 的原理虽然简单,但要想真正理解运用,还是需要转转脑子的,我最近一直在转啊转……

Webpack 可类比于 Meteor 的 Isobuild 和命令行工具,因为我一直生活在 Meteor 温室里,所以就没有触碰过它。Webpack 将上面那些东西 —— 更准确的说是将 NPM 生态 —— 连接在一起,且远比当下的 Meteor (1.4)高效。听说初次配置起来异常复杂,这也许是事实,也许是夸张后的假象,但这正是 Meteor 这类傻瓜化工具存在的意义,也是其未来模式能够在生态中生存的价值。

GraphQL 负责数据层,Meteor 团队最近半年来集中做的事就是在数据层下功夫,打造 GraphQL 生态下的 Meteor,只不过名字叫 Apollo 罢了。据说啊,以后(其实现在就可以)负责 UI 的人可以专心构建用户界面,负责数据库的人可以专心搭建数据结构,中间沟通的事交给 GraphQL 就好了。总之就是四个大字,极~为~友~好~

React Native 曾火过,现在其势头与 React 和 GraphQL 没法比,我终还是将它列入趋势,待观察吧。

Meteor 的未来模式大致是什么样子呢?大致就是将上面这些整合到一起的样子吧,只不过门槛降低了,开发体验更加友好,并且允许和经典模式共存。对于你我,至少应该掌握 React 和 GraphQL,在这个过程中自然就把 ES6/7 学会了,再有精力就去看看 Redux,感受一下代码之美。