从最新的技术趋势看前端的将来

本文仅表明 Phodal 的我的观点，来听听一个前端程序员的 YY。

新一期的ThoughtWorks技术雷达有点出乎意料，使用new标签的框架、工具、技术、语言等等超过了一半——Vue.js、ES2017上榜，Three.js凭着VR的火又上榜了，还有熟悉的Electron，以及微前端的概念。

让咱们先看看一些技术亮点~~。

前端在可见的将来

在那篇《最流行的编程语言JavaScript能作什么？》的文章里，咱们看到了JavaScript在各个领域的应用。在这一期里，仍然有不少亮点（new）：

Vue.js，若是你在使用Vue.js，那么你更应该找到至关的自信了，如今它已经被列入了评估期了。Vue.js是一个简单易上手的框架，而且至关的轻量，在最近的这段时间里，它发挥得至关的出色。

惋惜，宝宝如今在用Angular.js 和 Angular 2，毕竟我如今是开发混合应用的。不过相信在半年后，Angular 2 和 Ionic 2是会上榜的。

Ember.js，尽管没有证据代表这个框架在国内将火起来的趋势，我如今还对这个框架缺少深刻的了解。

ECMAScript 2017，尽管我如今已经倾向于使用TypeScript，不过 ES2017 仍是会用到的，只是我以为 Babel 对我来讲就是个坑啊

Electron，若是你是一个老读者，那么你已经知道我在不少场合里使用了这个框架，从NodeWebkit开始写编辑器，再到用Electron完成Growth 1.0的桌面版。

Physical Web，如今咱们能够在浏览器上来控制真实世界，经过蓝牙低功耗技术。

不过与此相比，我更看好 Progressive Web App，毕竟他可让Web应用接触到更多的底层API，而不是局限于蓝牙，还能够是Push Notification等等。

Three.js，它上榜的缘由是由于 WebVR 的流行。这一点能够从我去年写的那篇《Oculus + Node.js + Three.js 打造VR世界》，就能够看到一些趋势。这些就和如今的单页面应用同样，虽然运行起来不是那么流畅，可是仍是行得通。于是在可见的将来使用 Web 技术来开发 VR 也有一点苗头，将来浏览器上应该是能够运行编译事后的代码，而不是在运行时。

WebRTC，它可让咱们在浏览器端实现实时视频聊天。第一次接触到这个视频流技术是在两年多之前，上一次接触则是在半年多之前使用 WebRTC + Oculus，你能够在我博客的那篇《JavaScript在VR世界的应用》中了解到更多的详细信息。固然如雷达所说，WebRTC将会造成将来在Web上进行AR/VR 协做的基础。

接着再让咱们看看一些架构上的变化吧。

前端引发的架构变化

在过去的两三年里，前端火得一塌糊涂——对于后端程序员来讲，这有点 winter is coming 的感受。我在那篇《前端演进史》对前端的演进作了至关多的介绍，并在《后台即服务演进史》里对后台即服务开了个头，在这篇文章里让咱们根据《技术雷达》来继续补几刀。

咱们能够看到在中大型团队里，已经分解为前端和后台两个小组，沟通能够经过接口、契约等等的方式来进行。可是这一点儿也不精益，沟通在这时仍然是一个问题，让我有点怀念起以前先后端都作的项目了——本身能够建立本身想要的接口。

不过，这意味着前端和后台在技术选型上更加独立了。

臃肿的前端——微前端

在上一个项目里，咱们一步步地将一个有近10年系统的系统替换掉。起初这是一个传统的Spring + JSP网站，而后咱们用JSP建立了JSON API，后来建立了一个新的 API 来服务移动应用和单页面应用，再后来这个 API 被拆分红了几个 API。咱们的后台已经成一个单体应用变成了一个微服务架构的应用，可是这一点并无在前端上应用——前端应用正在变得难以维护。

所以在这一期的雷达里，你能够看到微前端的概念（micro frontends）。这也是在上一个项目里，咱们尝试作的一部分，遗憾的是并无成功彻底实施。这是一个搜索类型的网站，网站的首页承担着大部分的访问量，而详情页的主要流量来源则是搜索引擎。咱们在首页上使用jQuery + Require.js技术栈，而在其余页面（搜索结果页 + 详情页）使用 React.js，咱们在最初的时候考虑过将详情页静态化——由于须要 SEO 的缘故，这样可让咱们下降 SEO 带来的复杂度。

后来，我也在个人博客上解耦了两部分，为了更快的访问首页的速度——将首页独立出来，不使用JS，直接使用Pure.css来担重任；在其余页面里使用Material Design Lite做为 UI 部分。

有一点值得考虑的是：对于微服务架构来讲，在一个系统的不一样的部分使用不一样的技术栈是一种不错的体验；而对于一个前端团队来讲，在同一个系统的使用不一样的技术栈就不是一种不错的体验。

API 设计——应该变得简单

如咱们所见的Spring Boot已经变成推荐采用的程度了，按雷达上的习惯用语：“咱们已经在多个项目上使用这个框架”——反正我最近的项目都是用这个框架。若是你考虑使用 Java，那么你必定不要错过这个框架，以及使用这个框架来实施先后端分享。

对于大部分不须要考虑 SEO 的应用来讲，将后台变成一系列 RESTful 的 API 并非一件复杂的事，可是在后台 API 上的设计就变成一件麻烦的事。所以尽管在实见的过程当中，有契约来做为保证，可是不必定是可靠的。做为一个前端程序来讲，咱们在调用后台 API 的过程当中，总会遇到这样、那样的问题。除此，还有接口很差用的问题——“要是你能够在这里使用超媒体 API，那么个人代码就会更加简单了”。

所以在 API 设计上，雷达上给出了两个不错的案例：

强化后台查询

表明的例子就是 Facebook 的 GraphQL，它是在 Facebook 内部应用多年的一套数据查询语言和 runtime。本来为了请求一个用户及其好友信息的请求，须要发起多个 API 请求。如今，咱们只须要在客户端拼装好对应的 Query语句，在这个语句里将大部分须要查询的东西写好，即 JSON 格式的数据，而后发给服务端来处理。而在咱们客户端上，咱们所获取到的结果都是咱们所须要的，不须要再作特殊处理了。

这一切，看上去很美好——除了，在客户端上拼查询语句。

过去，咱们使用搜索引擎来搜索数据，就须要在前端拼好对应的 Query，再传给后台 API，由后台 API 返回咱们须要的结果。在这个过程里，咱们在Query作一些对应的数据处理。

反正，他们都是使用查询语言来搜索结果。若是你考虑使用 QL 的话，不妨作一层 Wrapper，之后好作迁移。

先后端同时优化

Netflix对于这样复杂的API请求下，建立了 本身的库Falcor——它能够从多个数据源获取数据，并在服务端上汇总成一个 JSON model；在客户端上，请求的时候咱们只须要在请求的时候加上对应的参数便可——能够将多个请求合并到一块儿，也能够只针对某一个部分发出请求。这样能够减小发出多个请求，所带来的复杂度。

我想，一种最实用的作法：就是将一些更新频率较低的API合并成一个大的 API 了——大部分人都会这样作吧。

简化的后台——无服务器架构

除了上面的这些内容，后台还有一些东西还蛮好玩的，其中一个就是 Serverless 架构，即无服务器架构。不过，这种架构目前在国内运行起来仍是有点难度的，缺乏一系列的配套措施。如在这期的雷达上的Auth0能够为咱们提供一个受权服务，以及AWS Lambda能够直接使用 AWS系列云服务来对数据进行处理。

我就很少说了~~，读者能够本身去看。

那么将来，你看想玩哪一种技术。

访问 https://www.thoughtworks.com/... 获取最新一期ThoughtWorks技术雷达（PS：若是你访问不了原文连接，能够修改DNS为 8.8.8.8，或者放在个人GitHub Page上的备份：http://radar.phodal.com/2016.pdf ）