最近国内开始越来越多地提及“大前端”的概念，一说是前端和移动端的整合，一说是前端和中间件的整合。虽然还没有一个明确的共识来说明“大前端”究竟是什么，但不少团队已经开始以“大前端”来为自己命名了。

点融网自2015年就开始组建客户端团队，包括传统意义上的前端（Web）、iOS、Android、Node.js 等在内的各种技术和开发工程师在内。成立至今，数经变动，虽无“大前端”加冠，然早行“大前端”之实。

开发工作不断深入，成绩斐然，但所有的资深都有一段菜鸟岁月，所有的经验都来自于踩过的坑。大前端的热也让作为点融网前端负责人的笔者在回顾过往工作时，有了更多的认识和新想法，故作此文，与君共勉。

大前端——所有表现层的整合

过去的一段时间里，Web 端的开发同事与笔者谈起 Web 开发不被重视、被边缘化和碎片化的问题。确实，以我司官网（https://www.dianrong.com）为例，如果单纯从一个传统意义网站的角度来看，相比于移动端，Web 端投入的人力和资源都相对较少，演进较慢。尤其是在公司确定了“Mobile First”的发展理念后，各类产品及功能都优先在移动设备上开发和展示。

因此对 Web 端同事造成了这样一种感觉：iOS 和 Android 这类的 Mobile App 开发是公司的首要战略地位产品，Web 开发只是一个辅助技术，难以获得认可。

1、“Mobile First” ≠“Mobile App First”

笔者始终认为：“Mobile First” ≠“Mobile App First”。这里的 Mobile 更多指的是移动设备上的表现，至于是选择 App 还是 Web 方式，并不重要。

从用户体验的发展看，演进的方向是从大屏的 PC 到小屏的移动设备，在这个过程中 App 因为可以提供较好的性能和体验从而在一段时间内快速发展。随着移动设备的增多，开发团队的效率与移动设备增长呈负相关，因此，为了提高开发效率，Hybrid 技术获得了迅速发展，表现层领域（即所谓泛 GUI 领域）越来越往跨屏跨设备的方向进步。作为目前唯一真正实现跨屏的 Web 技术需求逐步增加，到现在已经几乎渗入到移动开发的各个领域。

有一阵子业界颇有 Web 即将统一全平台的趋势，然而随着 Web 技术在性能和表现力上的短板，在实际应用中不得不退回到 Hybrid 模式。但经历了这样一个事件后，业界充分认识到了各自平台和技术的短处和长处，从而进一步促进了 Native 和 Web 的整合。时至今日，再想很明确地区分具体的表现媒介已经很困难了，大前端的概念应运而生。

2、“客户端团队”之名，“大前端”之实

具体到点融网，我们团队采用的名称实际上是客户端团队（Clients），恰好反映出了对大前端的理解。传统的 C/S 架构体系中，客户端往往负责了所有的业务展示和表现。

在新的互联网体系下，我们认为所有的表现层技术以及辅助这些表现层技术的技术都隶属于大前端的范畴，原因是所有这些技术和设计的目的只有一个：为业务展示服务。

3、表现层和业务逻辑层的分离都意味着前后端的分离

《当我们在谈大前端的时候，我们谈的是什么》这篇文章归纳了从 Node.js 分离前后端开始到与泛 GUI 层交互的大前端概念，在我看来其实都是将表现层概念独立出来。Node.js 的引入彻底分离了系统的表现层和业务逻辑层，使前端工程师第一次有机会渗透到了后端的领域，用前端的方法来解决表现层的问题。

Node.js 是触发这样变革的一个引爆点，在实际实践中，但并不局限在 Node.js 技术。任何技术上的表现层和业务逻辑层的分离都意味着前后端的分离，也都意味着纳入了为业务展示服务的领域，所以这些表现层的开发工作都是在大前端工作中不可缺少的部分。

终端碎片化时代，大前端紧密整合时代

上面所引用的文章提到我们已经进入了一个终端碎片化时代，越来越多的终端设备以各种方式来占据每个人的碎片时间。绝大部分设备有屏幕，无屏幕的终端也并非绝无仅有。在这样的背景下，单个业务逻辑会被各种终端以各种形式进行表现，除了文字图像视频以外，还有其它各种意料之中、之外的形式，更不用说各种传统意义上包括多语言、多文化等等的多重表现展示。

这些千奇百怪的表现形式背后就是系统提供的业务逻辑，理论上说所有的表现形式都应该表达统一的业务信息。但另外一方面，表现层面对的用户多样性使得这个系统在一致性的基础上需要按照用户的不同需求提供在统一业务逻辑基础上的细分定制。这两种看上去互相矛盾的一致性和个性化的要求使得现在的客户端开发面临着前所未有的挑战。Node.js 这样的服务端表现层技术提供的不仅仅是服务端渲染这样的纯粹表现层任务，而是更多地起到了一个表现信息中心管理系统的作用。我们的各种内容管理系统、配置系统纷纷被实现出来并逐步增强，通过这个管理中心来控制和协调各个终端上的所有表现逻辑。这部分是从传统前端团队迈向大前端团队所必须的一步，也是标志大前端各个终端进行互相渗透和交叉的关键组成部分。

在实际的实践中，这样的一个系统往往身兼数职，不仅仅是展示，也有用户运营相关的功能，甚至还有 A/B 测试、灰度发布、客户端远程排错等纯技术相关的功能。并且也有很多是使用 Java 这样的传统技术开发的，但技术架构为业务服务这个事实并不会因此改变，不妨碍它在定位上是为展示服务的终极目标。

在现在这个时代，产品在各个终端上的展示必定是互相交错并影响的，孤立的终端不再是产品的全部，这不仅仅对于开发工程师是一个挑战，更是对于产品设计和体验设计的一个挑战。

从这个角度上说，大前端不仅仅是一个技术上的概念，也是对产品设计的一个观念更新：需要把大前端看成一个整体，把终端展示看成一个功能，有节奏地推进在各个终端上的各种信息和逻辑展示。各种展示需要在逻辑上一致，又要充分利用终端的展示特性和用户使用习惯来分别调整。

大前端时代对工程师的要求

在大前端时代，工程师所需要了解的专业知识比原来单一的客户端领域要广。移动平台和 Web 的紧密结合导致 Native 开发工程师对于 Web 技术等需要一定的了解，反之亦然。

不仅如此，在客户端开发的过程中，还需要配合 Node.js 这种信息管理中心进行设计和开发，确保各个客户端在一个大脑的指挥下统一表现和展示。大前端作为一个整体系统，如果每位工程师仅仅考虑自己的领域，必然导致各项设计互相割裂，难以达成架构师所希望的整体架构设计效果。然而一个人精力有限，不可能一开始的时候就广为涉猎深入了解各种技术，在实际开发过程中，也需要在某一个或者几个特定领域有特别深入了解的人负责具体领域的技术专家职位。故而综合来说，从技术的广度和深度，对于基层的工程师的要求增加不多，但对高级工程师和架构设计师来说提升了一定的难度。

服务端开发技术经过了几十年的发展已经日趋成熟，在发展过程中充分结合了软件开发工程中的各种成熟模式和技术，但表现层和移动客户端的开发方兴未艾，新技术还在层出不穷，新的开发技巧和模式也在不断的涌现中。这注定客户端的开发思路需要经历一段时间的百家争鸣后才能最终形成稳定成熟的开发技术。Web 端和 App 端的大量框架和概念纷纷涌现的现状与十年前的 Java 社区是多么相似。从小规模的开发走向大规模开发，这样的过程是一个必经之路，是各方面互相竞争和协作的结果。但和十年前不同的是，现在大前端工程师在这个过程中可以参考服务端开发发展的经验，传统的开发模式和理念至今对于大前端的开发工作还是有很大借鉴意义的。不盲从新技术，但保持对新兴技术的关注并理解其背后的理念对于在眼花缭乱的各种技术做出正确的选择极其重要。不仅需要学习各种新兴技术并归纳适应新的发展趋势，也要从传统开发模式中吸取有益的知识。

总结

从最初的前后端分离到业务逻辑和表现逻辑分离，大前端是在目前众多终端碎片化后技术架构发展的结果，不管最后它的名字叫什么，但作为产品经理、架构师和开发工程师都需要正视这样的发展，尽快改变理念，才能在这个时代生存下去。

本文作者：徐翎 Andrew（点融黑帮），任职点融网客户端开发总监，组建了移动和网站的开发团队，开发了点融网各款客户端软件。曾就职于微软等公司，参与过包括Hotmail 和Windows 在内的大型跨国际软件开发项目的研发。