Skip to content

yhtml5fed/front-end-share

Repository files navigation

Front-end Technology Share丨2016.08

前言

非常荣幸的能和在坐的各位一起学习,探讨,分享一下前端这块领域。 在这里,我会根据自己开发过的项目,使用的技术栈与大家一起做一次前端技术分享.
如果分享过程中,哪里有问题都可以及时提出来 以下是我要和大家一起分享的内容:

  1. 重新认识前端开发
  2. 前端开发的几个阶段
  3. 前端性能优化
  4. 前端未来变革
  5. 如何开始一个前端项目

重新认识前端

据我所知,时至今日仍然有很多团队会把前端开发归类为美工,切图仔,网页制作. 觉得写一个页面,改一个class很简单.
虽然身份之争多少有些无谓,但我对这种偏见还是心存芥蒂. 下面我试着从工程的角度系统的介绍一下我对前端开发的理解。

前端,是一种GUI软件

现如今前端可谓包罗万象,产品形态五花八门,涉猎极广,什么高大上的基础库/框架,拽炫酷的宣传页面,还有屌炸天的小游戏……
不过这些一两个文件的小项目并非是前端技术的主要应用场景,更具商业价值的则是复杂的Web应用,它们功能完善,界面繁多,为用户提供了完整的产品体验,
可能是新闻聚合网站,可能是在线购物平台,可能是社交网络,可能是金融信贷应用,可能是音乐互动社区,也可能是视频上传与分享平台…… 从本质上讲,所有Web应用都是一种运行在网页浏览器中的软件,这些软件的图形用户界面(Graphical User Interface,简称GUI)即为前端。
如此复杂的Web应用,动辄几十上百人共同开发维护,其前端界面通常也颇具规模,工程量不亚于一般的传统GUI软件:

尽管Web应用的复杂程度与日俱增,用户对其前端界面也提出了更高的要求,但时至今日仍然没有多少前端开发者会从软件工程的角度去思考前端开发,来助力团队的开发效率, 更有甚者还对前端保留着”如玩具般简单“的刻板印象,需要开发一个官网, 右击新建.txt文件, 直接开始写了. 或者直接网上看到一些好看的, 右击下载过来改一下.
首先不考虑页面性能,浏览器兼容性,软件可维护性,测试bug等大问题. 写到后面你会发现连最基本的class命名也不会了,各种拼音缩写,各种命名方式,想不出来来个div1,div2
历史悠久的前端开发,始终像是放养的野孩子,没有统一的开发标准, 没有专业的培训,我相信在做的各位大部分都是凭着自己的兴趣,自学成才

前端工程的四个阶段

回顾一下曾经经历过或听闻过的项目,为了提升其前端开发效率和运行性能,前端团队的工程建设大致会经历三个阶段

第一阶段: 库/框架选型

前端工程建设的第一项任务就是根据项目特征进行技术选型。
基本上现在没有人完全从0开始做网站,哪怕是政府项目用个jquery都很正常吧
React/Angularjs/Vuejs等框架横空出世,解放了不少生产力,合理的技术选型可以为项目节省许多工程量,提高项目开发进度,这点毋庸置疑。

第二阶段: 简单构建优化

选型之后基本上就可以开始敲码了,不过光解决开发效率还不够,必须要兼顾运行性能。
前端工程进行到第二阶段会选型一种构建工具,对代码进行压缩,校验,之后再以页面为单位进行简单的资源合并。

前端开发工程化程度之低,常常出乎我的意料,之前面试过的几家公司,与他们前端负责人,技术总监交流才发现,
能做到这个阶段在业界来说已然超出平均水平,属于“具备较高工程化程度”的团队了.
查看网上形形色色的网页源代码,能做到最基本的JS/CSS压缩的Web应用都已跨入标准互联网公司行列,
所以,不难理解为什么很多前端团队对于前端工程构建的认知还仅停留在“压缩、校验、合并”这种程度。

第三阶段: JS/CSS模块化开发

分而治之是软件工程中的重要思想,是复杂系统开发和维护的基石,这点放在前端开发中同样适用。
在解决了基本开发效率运行效率问题之后,前端团队开始思考维护效率,模块化是目前前端最流行的分治手段。
很多人觉得模块化开发的工程意义是复用,我不太认可这种看法,在我看来,模块化开发的最大价值应该是分治,是分治,分治!(重说三)。
Unix,linux系统能做到现在这面大, 发行有上千个版本, 在服务器,单片机,智能硬件等领域占据绝对的统治地位.
有一点非常重要: 就是模块化,各模块之间互相解耦,每个模块小而专一,一次只做一件事情;单个模块移植性,拓展性都非常强

不管我们将来是否要复用某段代码,你都有充分的理由将其分治为一个模块。
JS模块化方案很多,AMD/CMD/UMD/ES6 Module等,对应的框架和工具也一大堆,大家有兴趣可以了解下
CSS模块化开发基本都是在less、sass、stylus等预处理器的import/mixin等特性支持下实现的。

虽然这些技术由来已久,在如今这个“言必及React”的时代略显落伍,但想想业界的绝大多数团队的工程化落后程度,放眼望去,毫不夸张的说,
能达到第三阶段的前端团队已属于高端行列,基本具备了开发维护一般规模Web应用的能力。
然而,做到这些就够了么?还不够!

第四阶段: 思考

前端是一种技术问题较少、工程问题较多的软件开发领域. 当我们要开发一款完整的Web应用时,前端将面临更多的工程问题,比如:
大体量:多功能、多页面、多状态、多系统
大规模:多人甚至多团队合作开发
高性能:CDN部署、缓存控制、文件指纹、缓存复用、请求合并、按需加载、同步/异步加载、移动端首屏CSS内嵌、HTTP 2.0服务端资源推送
这些无疑是一系列严肃的系统工程问题。
前面讲的三个阶段虽然相比曾经“茹毛饮血”的时代进步不少,但用于支撑第四阶段的多人合作开发以及精细的性能优化似乎还欠缺点什么。
到底,缺什么呢?

第四阶段:组件化开发与资源管理

浏览一下现阶段比较流行的开发语言,几乎所有的程序语言都有组件化开发,模块封装的概念与对应的API,唯独js没有
进入第四阶段,我们只需做好两件事就能大幅提升前端开发效率,并且兼顾运行性能,那就是:

组件化开发与资源管理。

slide1

分治的确是非常重要的工程优化手段。在我看来,前端作为一种GUI软件,光有JS/CSS的模块化还不够,对于UI组件的分治也有着同样迫切的需求
如上图,这是我所信仰的前端组件化开发理念,简单解读一下:

  • 页面上的每个独立的/可视/可交互区域视为一个组件;
  • 每个组件对应一个工程目录,组件所需的各种资源都在这个目录下就近维护;
  • 由于组件具有独立性,因此组件与组件之间可以 自由组合;
  • 页面只不过是组件的容器,负责组合组件形成功能完整的界面;
  • 当不需要某个组件,或者想要替换组件时,可以整个目录删除/替换。

其中第二项描述的就近维护原则,是我觉得最具工程价值的地方,它为前端开发提供了很好的分治策略,
每个开发者都将清楚的知道,自己所开发维护的功能单元,其代码必然存在于对应的组件目录中,
在那个目录下能找到有关这个功能单元的所有内部逻辑,样式也好,JS也好,页面结构也好,都在那里。
组件化开发具有较高的通用性,无论是前端渲染的单页面应用,还是后端模板渲染的多页面应用,组件化开发的概念都能适用。
组件的HTML部分根据业务选型的不同,可以是静态的HTML文件,可以是前端模板,也可以是后端模板:
不同的技术选型决定了不同的组件封装和调用策略。不论用了react/angular/vue,或者是自己造轮子,亦或是php, velocity
基于这样的工程理念,我们很容易将系统以独立的组件为单元进行分工划分:

slide2

由于系统功能被分治到独立的模块或组件中,粒度比较精细,组织形式松散,开发者之间不会产生开发时序的依赖,
可以理解为的单线程切换到多线程,大幅提升并行的开发效率,
理论上允许随时加入新成员认领组件开发或维护工作,也更容易支持多个团队共同维护一个大型站点的开发。
当然队员之间会事先约定好api风格,命名方式,约定好使用哪一系列的技术栈. 必要情况下进行内部培训

slide3

结合前面提到的模块化开发,整个前端项目可以划分为这么几种开发概念:
如果项目规模较大,涉及多个团队协作,还可以将具有相关业务功能的页面组织在一起,形成一个子系统,
进一步将整个站点拆分出多个子系统来分配给不同团队维护

slide4

以上5种开发概念以相对较少的规则组成了前端开发的基本工程结构,基于这些理念,我们来总结一下:
如果项目规模较大,涉及多个团队协作,还可以将具有相关业务功能的页面组织在一起,形成一个子系统,
进一步将整个站点拆分出多个子系统来分配给不同团队维护
根据以上架构设计我开发了几个项目,是行之有效的前端工程组件话开发的方案。

吐槽:我本人非常反对某些前端团队将前端开发划分为“JS开发”和“页面重构”两种岗位,更倾向于组件粒度的开发理念,
对GUI软件开发的分工规划应该以功能为单位,而不是开发语言;一个合格的前端开发者也应该掌握完整的端内技术。

“智能”静态资源管理

上面提到的模块化/组件化开发,仅仅描述了一种开发理念,也可以认为是一种开发规范,倘若你认可这规范,
对它的分治策略产生了共鸣,那我们就可以继续聊聊它的具体实现了。
很明显,模块化/组件化开发之后,我们最终要解决的,
就是模块/组件加载的技术问题。然而前端与客户端GUI软件有一个很大的不同:
Web前端是一种远程部署,运行时增量下载的GUI软件
Web前端应用没有安装过程,其所需程序资源都部署在远程服务器,用户使用浏览器访问不同的页面来加载不同的资源,
随着页面访问的增加,渐进式的将整个程序下载到本地运行,“增量下载,动态更新” 是前端在工程上有别于客户端GUI软件的根本原因。

slide1

本图展示了一款界面繁多功能丰富的应用,如果采用Web实现,相信也是不小的体量,如果用户第一次访问页面就强制其加载全站静态资源再展示,
相信会有很多用户因为失去耐心而流失。根据“增量”的原则,我们应该精心规划每个页面的资源加载策略,使得用户无论访问哪个页面都能按需加载页面所需资源,
没访问过的无需加载,访问过的可以缓存复用,最终带来流畅的应用体验。
这正是Web应用“免安装”的魅力所在。也是现在主流框架也是各大互联网公司正在做的事情

我们来看看淘宝网,会发现它响应非常快, 看似没和普通电商网站没什么区别, 没什么高大上的特效. 资源似乎杂乱无章,内联样式,行内样式都有. head里面加载各种js.
似乎颠覆了我们对极致前端的概念. 但它这背后有数个前端团队在做维护, 多个部门提供后端数据服务. 可以算国内比较顶级的站点了
以后我会带着大家去了解大公司,尤其是大的互联网公司是如何进行前端开发的

由“增量”原则引申出的前端优化技巧几乎成为了性能优化的核心,有加载相关的按需加载、延迟加载、预加载、请求合并等策略;
有缓存相关的浏览器缓存利用,缓存更新、缓存共享、非覆盖式发布等方案;还有复杂的BigRender、BigPipe、Quickling、PageCache等技术。
这些优化方案无不围绕着如何将增量原则做到极致而展开。

所以我觉得:第四阶段前端开发最迫切需要做好的就是在基础架构中贯彻增量原则。
相信这种贯彻不会随着时间的推移而改变,在可预见的未来,无论在HTTP1.x还是HTTP2.0时代,无论在ES5亦或者ES6/7时代,
无论是AMD/CommonJS/UMD亦或者ES6 module时代,无论端内技术如何变迁,我们都有足够充分的理由要做好前端程序资源的加载策略。

正如前面说到的,第三阶段前端工程缺少点什么呢?我觉得是在其基础架构中缺少这样一种“智能”的资源加载方案。
没有这样的方案,很难将前端应用的规模发展到第四阶段,很难实现前面介绍的那种组件化开发方案,
也很难让多方合作,共同高效率的完成一项大型应用的开发,并保证其最终运行性能良好。
在第四阶段,我们需要强大的工程化手段来管理在外行人看来”玩具般简单“的前端开发。

slide2

前端自动化流程构建工具

  • Yeoman + Gulp
  • angular-cli/vue-cli
  • JD Athena
  • Baidu FIS3

这里今天不深入探讨研究.

端工程的认知度很低,觉得前端构建不就是几个压缩优化校验打包任务的组合吗, 构建工具只能通过静态分析来优化加载,具有很大的局限性,单页面/多页面/PC端/移动端/前端渲染/后端渲染/多语言/多皮肤/高级优化等等资源加载问题, 静态资源管理系统 = 资源表 + 资源加载框架 资源表是一份数据文件(比如JSON),是项目中所有静态资源(主要是JS和CSS)的构建信息记录记录了资源的类别、部署路径、依赖关系、打包合并等内容,比如: 而资源加载框架则提供一些资源引用的API,让开发者根据id来引用资源,替代静态的script/link标签来收集、去重、按需加载资源。 调用这些接口时,框架通过查表来查找资源的各项信息,并递归查找其依赖的资源的信息,然后我们可以在这个过程中实现各种性能优化算法来“智能”加载资源。 根据业务场景的不同,加载框架可以在浏览器中用JS实现,也可以是后端模板引擎中用服务端语言实现,甚至二者的组合,不一而足。 因为有了资源表,我们可以很方便的控制资源加载,通过各种手段在运行时计算页面的资源使用情况,从而获得最佳加载性能。 无论是前端渲染的单页面应用,还是后端渲染的多页面应用,这种方法都同样适用。 从此彻底告别一个团队维护一套工具的时代!!! 

slide3

回顾一下前面提到过的前端工程四个阶段:

第一阶段:库/框架选型
第二阶段:简单构建优化
第三阶段:JS/CSS模块化开发
第四阶段:组件化开发与资源管理

由于先天缺陷,前端相比其他软件开发,在基础架构上更加迫切的需要组件化开发和资源管理,而解决资源管理的方法每个团队都有自己的一套方法, > 一个通用的资源表生成工具 + 基于表的资源加载框架 近几年来各种我们听到过的各种资源加载优化策略大部分都可以在这样一套基础上实现,而这种优化对于业务来说是完全透明的, 不需要重构的性能优化——这不正是我们一直所期盼的吗?就像海军提出的前端预演:我们可以把优秀的人,感兴趣的人集中起来去优化加载。 

如何选型技术、如何定制规范、如何分治系统、如何优化性能、如何加载资源,当你从切图,调样式, 开始转变为思考这些问题的时候,我想说:
前端开发, 你已经入门了, 让我们我们来学习NodeJS吧

比较热门的库和框架有哪些, 你用过哪些 简单构建优化工具有哪些, 用过的感想 模块化开发的好处有哪些 组件化开发的策略与资源加载研究

前端性能优化

前端性能优化的手段,方法,措施, 可以从哪些方面入手

前端是一种远程部署,运行时增量下载的GUI软件
前端应用没有安装过程,其所需程序资源都部署在远程服务器,
用户使用浏览器访问不同的页面来加载不同的资源,随着页面访问的增加,渐进式的将整个程序下载到本地运行,“增量下载”是前端在工程上有别于客户端GUI软件的根本原因。

我专职做前端开发的时间不长,短短2年,但从小学就开始接触网页制作,那时候是用FrontPage做页面,flash做按钮. 鼠标移动一下,有星星跟随. 大学的时候开始折腾个人站长, 买了一个阿里云服务器, 用apche+php+mySQL.做一个简单的blog. 已经关注Web开发也有十余年时间。 在这期间, 我看到网页三剑客已衰落至死;看到ES6标准使Javascript拥有更多高级语言的特性; 看到NodeJS拓展Javascript程序员的空间;看到npm成为前端开发的大宝库; 看到React,Angular,Vue这些优秀的JS框架;看到Sass,Less将老旧的CSS焕发新生; 看到webpack将Web应用打包的干净优雅…… 最初看到这些事物的时候,每天都有新东西思考、探索和研究,就如同看到“一个全新的世界”,这也是为什么我喜欢前端开发. 它就代表了这整个互联网行业 

前端角色定位

我们要与设计师,产品经理,后端工程师打交道, 我们编写的代码是距离用户最近的代码
我们不懂设计,但是设计的每一个细节都掌握在我们手上
我们不懂产品,但是产品的每一处逻辑都需要我们实现
我们不懂后端,但是数据的每一块渲染都需要我们操作
并且能将这ui设计,产品思路,后端数据完美编织在一起,展现给用户的只有我们前端能做到
前端技术 宽无止尽,深不见底
我们对前端技术一定要有敬畏心态,不要悲观不要傲娇,认真对待技术,技术将带领我们改变世界,不能改变世界,起码会改变我们的薪资

About

share Front-End technology

Topics

Resources

License

Stars

Watchers

Forks

Releases

No releases published

Packages

 
 
 

Contributors