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

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

前端在可见的未来

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 的感觉。我在那篇《前端演进史》对前端的演进做了相当多的介绍,并在《后台即服务演进史》里对后台即服务开了个头,在这篇文章里让我们来继续补几刀。

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

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

臃肿的前端——微前端

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

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

因此在这里,你可以看到微前端的概念(micro frontends)。这也是在上一个项目里,我们尝试做的一部分,遗憾的是并没有成功完全实施。这是一个搜索类型的网站,网站的首页承担着大部分的访问 量,而详情页的主要流量来源则是搜索引擎。我们在首页上使用jQuery + Require.js技术栈,而在其他页面(搜索结果页 + 详情页)使用 React.js,我们在最初的时候考虑过将详情页静态化——因为需要 SEO 的缘故,这样可以让我们降低 SEO 带来的复杂度。

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

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

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

API 设计——应该变得简单

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

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

因此在 API 设计上,给出了两个不错的案例:

强化后台查询

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

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

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

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

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

前后端同时优化

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

Netflix对于这样复杂的API请求下,创建了 自己的库Falcor——它可以从多个数据源获取数据,并在服务端上汇总成一个 JSON model;在客户端上,请求的时候我们只需要在请求的时候加上对应的参数即可——可以将多个请求合并到一起,也可以只针对某一个部分发出请求。这样可以 减少发出多个请求,所带来的复杂度。

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

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

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

除了上面的这些内容,后台还有一些东西还蛮好玩的,其中一个就是 Serverless 架构,即无服务器架构。不过,这种架构目前在国内运行起来还是有点难度的,缺少一系列的配套措施。

我就不多说了~~,读者可以自己去看。

那么未来,你看想玩哪种技术。

本文文字及图片出自 CSDN

余下全文(1/3)
分享这篇文章:

请关注我们:

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注