跳转至

前端架构:前端架构有哪些核心问题?

你好,我是winter,今天我们来谈谈架构。

在传统桌面软件开发中,架构师是一种通过设计架构保证团队能够良好分工和有序工作的岗位。

在工程领域,我们凡是要做点什么事儿,都会有明确的目的性,这个目的性,一定是为了完成生产服务业务的。

为什么桌面软件开发需要架构师和架构设计呢?因为桌面软件开发具有高度的复杂性,如果没有架构,就没法分解成互相耦合低的模块来分工。

所以一般来说,架构是为了分工而存在的。但是到了前端领域,这个问题是否还存在呢?答案是,不存在。

前端是个天然按照页面解耦的技术,在多页面架构中,页面的复杂度大约刚好适合一个人的工作量。(所以,我们的结论是,前端根本不需要架构设计。当然,我这句话是开玩笑的。)

前端不存在分工问题,但是在多人协同时,仍然要解决质量和效率的问题,这就需要组件化了。除此之外还有前端特有的兼容性问题,也是需要从架构的角度去解决的。

对于一些追求极致的团队来说,会挑战“单页面应用”,通过单页面应用来提升用户体验,单页面应用的升级版本是谷歌提出的PWA,PWA既是业务方案也是技术方案,在技术层面,它近乎苛刻地规定了网页的各方面的体验标准。

前端领域还有一个特有的生态:框架,第一代前端框架(如jQuery, PrototypeJS)重点解决了兼容问题和API的易用性问题,在现代浏览器普及之后,这些问题逐渐变得不存在或者不重要,所以第二代前端框架(如Vue,Angular,React)重点解决了组件化问题。选择合适的框架,可以节约架构的成本,还能够享受社区资源。

本节课,我会围绕前端架构的几个核心问题,为你介绍前端架构工作。

首先我们来讲讲组件化。

组件化

组件化讲起来是个非常简单的概念,前端主要的开发工作是UI开发,而把UI上的各种元素分解成组件,规定组件的标准,实现组件运行的环境就是组件化了。

现行的组件化方案,目前有五种主流选择:

  • Web Component;
  • Vue;
  • React;
  • Angular;
  • 自研。

Web Component 是W3C推行的规范,理论上是未来的选项;但是实际上这份标准的状态堪忧,Shadow DOM 的设计比较复杂,一般的前端掌握起来都比较困难。

此外,CSS也比较难以应用,需要依靠CSS Houdini。目前来说,我还没有看到那个前端团队实际在使用Web Component作为组件化方案。当然,它的优势也非常明显:不需要任何额外的运行时支持,就能在现代浏览器环境运行,也可以跟HTML无缝结合。

Vue 是目前最受欢迎的框架(从github star来看),由华人程序员尤小右开发和维护。它有两个主要特点,一个是比较符合原本的JavaScript/CSS/HTML书写习惯;另一个是它绑定了MVVM模式,直接确定了UI架构,通过DSL的支持,数据交互非常简洁。

React 是Facebook推行的新一代Web框架。它利用JSX模式,把HTML、CSS和JavaScript都放进了js文件中,对于不喜欢CSS和HTML的前端工程师来说,是很理想的。它还可以迁移到React Native,直接编写简单的客户端应用。

Angular 是Google推出的Web框架,它是比较标准的MVVM模式。Angular曾经因为大版本兼容性而饱受诟病,目前它的核心竞争力是与TypeScript结合得较好。

上面是我对几种方案的简单介绍。但是实际上,我们做技术选型时的主要依据是团队的现状,开发移动端还是桌面端、是否跟Native结合、团队成员的技能分布都是需要考虑的因素,这些框架本身的特点,目前我认为仅仅是一种偏好选项,而不是关键因素。

兼容性和适配性

前端开发的特有问题就是兼容性,到了移动时代,需要面对不同的机型,我们又需要解决适配性问题。

兼容性问题到2011年左右都是前端的主旋律,但是在之后,随着现代浏览器的逐渐普及,兼容性问题逐渐减小,所以我们这里就不多谈兼容性问题了。

适配问题主要适配的是屏幕的三个要素。

  • 单位英寸像素数(Pixel Per Inch,PPI):现实世界的一英寸内像素数,决定了屏幕的显示质量。
  • 设备像素比率(Device Pixel Ratio,DPR):物理像素与逻辑像素(px)的对应关系。
  • 分辨率(Resolution):屏幕区域的宽高所占像素数。

在当前环境下,分辨率适配可以使用vw单位解决,DPR适配则需要用到CSS的viewport规则来控制缩放比例解决,而PPI主要影响的是文字,可以采用media规则来适配。

单页应用

前文已经讲过,前端架构的解耦问题不大,因为页面是天然解耦的,但是,大家都知道,浏览器加载HTML时是会有白屏过程的,对追求极致体验的团队来说,希望能够进一步提升体验,于是就有了“单页应用(SPA)”的概念。

单页应用是把多个页面的内容实现在同一个实际页面内的技术,因为失去了页面的天然解耦,所以就要解决耦合问题。也就是说,我们要在一个“物理页面”内,通过架构设计来实现若干个“逻辑页面”。

逻辑页面应该做到独立开发和独立发布,一种思路是,每个逻辑页面一个js,用一个SPA框架加载js文件。

从交互的角度,这并不困难,但是,这里还有一个隐性需求:保持前进后退历史。

一般来说,前进后退历史使用URL的Hash部分来控制,但是onhashchange事件并没有提供前进或者后退信息,目前还没有完美的解决方案,只能牺牲一部分体验。实现单页应用的逻辑页面发布需要改造发布系统,在工程上,这也是一个比较大的挑战。

扩展前端新边界

除了解决现实问题,我认为前端架构的职责还包括扩展前端的边界,所以前端架构还包含了很多Native开发任务:如客户端和前端结合的方案 Weex 和 React Native;如前端和图形学结合的方案 GCanvas;如前端的3D框架Three.js,这些都是试图用架构的手段赋予前端新的能力的尝试。

这些具体的尝试涉及很多领域知识,我这里就不做详细介绍了,但是如果你成为了一个前端架构师,我希望你也把“拓展前端边界”当做团队的核心目标之一。

总结

今天我从宏观的角度介绍了前端架构相关的知识,我重点介绍了“组件化”“适配性”“单页应用”三个前端架构需要解决的核心问题,组件化在社区有很多现成的方案,我们需要做的主要工作是框架选型。适配性需要用到CSS的几种特性:vw单位、viewport规则和media规则,单页应用重点是逻辑页面解耦、独立开发和发布和保持前进后退历史。

最后留一个思考问题,你所在的团队有前端架构师吗?如果有的话,他的工作职责是什么?

精选留言(15)
  • 爱学习的大叔 👍(6) 💬(2)

    感觉我们没有前端架构,就是撸代码。实现功能就行。

    2019-07-15

  • 靠人品去赢 👍(3) 💬(1)

    你好老师,现在管理的一个后台系统是JSP+Java合在一块的东西。想弄个功能类似上传视频,找到很多插件都是很久没有维护的,就在想要不要把这个前端JSP展示的部分提出来作为一个前端,后台只是作为一个core响应请求。如果是你的话,你会怎么做? 想问一下,想阿里的后台管理是怎么搞的,是不是前后端分离的,因为我知道阿里也是Java大户,像这种后台管理怎么做的?

    2019-07-08

  • sugar 👍(2) 💬(1)

    spa好像不止hash一种实现方式,抛弃老版本浏览器的话,似乎可以利用history api,结合服务端url path接力,实现可前进后退的spa吧?我见过这样的 不知这种方式除了旧版本兼容性外 还有没有啥坑~

    2019-10-10

  • sugar 👍(1) 💬(1)

    目前实现spa方面 是否有较为成熟的框架推荐

    2019-10-10

  • 阿成 👍(36) 💬(0)

    我头铁,直接上新技术(react+hooks),因此遇到不少坑,不过是个小项目且只有我在做啦😂😂😂 怎么说,我觉得有时候还是要大胆一些... 当然多人协作的项目就不要搞人家了...

    2019-05-18

  • Neil 陈荣 👍(18) 💬(0)

    我觉得在 spa 成为普遍现象的今天,前端架构特别重要。 然后大多数的小团队单是跟进前端技术的发展就已经很费力了,这时候如果是一个前端技术工具方面玩的溜一点的,却缺少架构思维的人在早期来主导项目的代码结构的话,往往会成为整个项目的灾难。 在团队缺少架构高手的情况下,还是做多页应用来得更可控些,需要体验优化的页面就是自己做成一个简单一些的 spa. 这是我从之前两个项目中学到的教训。

    2019-05-18

  • 行云 👍(11) 💬(0)

    我很无耻的说一下,感觉spa更简单,反而传统的多页面开发模式,更麻烦

    2019-05-22

  • 行则将至 👍(8) 💬(0)

    请问每个逻辑页面如何可以做到独立发布呢?

    2019-05-21

  • 佚名 👍(6) 💬(5)

    在公司闲着无聊搭了一套 React 的架子想推广,结果被 CTO 直接拍死,说国内这么多学 Vue 的你给我搞什么 React...😂😂😂

    2019-07-23

  • Neil 陈荣 👍(4) 💬(5)

    关于组件化,我很不喜欢 react 中的 Functional Component 以及 HOC. 对于整个产品需求非常稳定情况来说,这样做也许没问题。把 UI表现和功能,按照不同的 perspective 去拆开,即所谓 separation by concern 的思路。 但对于一般的项目而言,往往需求变化都是比较频繁的,我认为更好的组件化方式是按功能切分。因为这样的组件内聚性比较好,会更便于代码阅读以及快速开发迭代。 在 React 上有些人比较推崇的那种纯 ui 表现类的组件,然后通过 HOC 来组装,实在是太绕了,完全不对我的胃口。

    2019-05-18

  • cjd 👍(3) 💬(0)

    没有架构 项目用什么自己定 经常会很纠结用什么技术😂 有些想尝试的新技术 由于能力有限加项目通常都很赶 不敢实践到项目中 不加班的时候 会自己写些demo 折腾折腾

    2019-05-18

  • Cool 👍(2) 💬(0)

    一个人撸到尾,github就是我的架构

    2019-07-18

  • ryannz 👍(1) 💬(0)

    今天连webide都出现了,在中后台领域,架构的重要性还是无法忽视的

    2022-03-18

  • Yully 👍(1) 💬(0)

    有前端架构师 公司的后台管理系统就是公司大佬用web component实现的,并且也一直在推,但是就像老师文章里写的,不好上手,组件库对前端团队公开之后,陆陆续续后来新增的组件,基本上都不是web component了……

    2020-06-08

  • 令狐洋葱 👍(1) 💬(0)

    “实现单页应用的逻辑页面发布需要改造发布系统,在工程上,这也是一个比较大的挑战。” 老师,这句话是指单独发布部分逻辑页面么?

    2019-08-19