新的一年已经过去几个月,小伙伴们对前端的技术规划是否还处于一个迷茫期呢,那么不要担心,今天小编在这里给你们在这里做一个技术上指引。
有些技术,则会从采用走向弃用。若是以此为出发点,那么这个 2019 年和过去的 2018 年相比,并不会有太大的区别。
学一些新的技术,忘掉一些不同使用的技术。
只是前端一个这么广的领域,到底要关心什么技术,到底要忽略什么技术呢?
前端是个最近几年火起来的工种,而且持续火热中,有个词叫水涨船高,来的人多了,竞争多了,标准也就提高了。
现在对前端工程师的要求跟当年前已经不能同日而语了。
今天给大家分享下前端的趋势,当然了,所谓的趋势,不是一天两天就到来的,它是未来的一个技术方向。
我们之所以关注趋势,是要关注变化,技术的发展与普及不是一日之功,一定是慢慢过渡的,但是你能够比其他人提前看到方向。
真正的市场到来的时候,你就可以提前做好准备,提前发掘机会。
我光告诉你 2019 将会流行什么,可能并没有多大的意义。你们需要自己去学会拥有这样的技能,学会去分析出 2020 需要规划什么内容。
技术规划
W-H-Y
每每谈到技术规划,我们谈的总是下一年、下一个阶段、下一个五年的目标。可为什么我们需要做技术规划?或许是出于 KPI 的影响,或者是出于预算的原因,或是在追求技术卓越。
我们的目的是: 变得更好 。于是乎:“为什么我们就不能使用现在的架构?现在的架构不是挺好的吗??”
为此,我们只需要尝试回答这么几个问题:项目的编译速度快吗?编写新功能的速度快吗?能满足快速上线的需求吗?多个团队并行开发,会出现问题吗?我们依赖的第三方组件,会出现问题吗?……
嗯,对这个问题就好像,别人在问你,“你有什么不足?”。
HOW
从这篇文章的写作过程,及笔者的相应规划步骤来看,可以分为这么几步:
调研技术远景
从社区获得相应的输入
整理潜在的技术方案、架构、技术栈
从利益相关者获得想法。
制定相关的实施计划
规划,它类似于技术远景的味道。可一谈到远景,那么要谈论的东西可多了。说不到我们还需要寻找利益相关者——如团队成员、项目领导,了解一下,他/她对于技术团队的一些期望。我们在社区上看到相似的问题,总有一个相似的开头:“我们的领导……。”
谈理想都特别有意思,因为我们不一定会去做。我们有了一个宏大的想法,只是受限于多个因素,我们只能做这么一点。比如说,我们未来想造一个笔记本,那么现在我们可以只选一个螺丝钉。
而在我们获取更进一步方向的时候,需要从这么几个维度来考虑问题:
从业务现状出发 。
譬如,在下一年里,我们的团队将从 20 人扩大到 100 人,为了支撑这么大的团队。
我们需要拥有培训机制,来应对这样的人员扩张;需要设计一个更好的架构,来实现多个团队的并行开发。从技术、架构出发 。
在项目中引入新的技术,改进原有的技术方案。
架构的预研 。提前试用未来可能使用的技术,如 AR、VR。这些往往是一些非必需的规划,但是有了它们会更好。
团队能力规则 。谈论到团队规划,我怕是并不是那么擅长。
大抵上,哪怕是技术负责人也不是 KPI 的制定者,我们只能谈谈理想,聊聊团队建设的一些建议。
有针对性地培养项目的 2nd Tier,至少对方是否能接受,那便不在我们的控制之下。这大抵也是个人发展的好处,可以选择自己感兴趣的内容学习。
当然了,其它相当多的东西,还是要落地的——我们还是得造螺丝钉。只有落地的东西,才能证明它是真正有价值的东西。
为此我们要用 SMART 原则制定一个 smart 目标。当然了,如果你还要对领导汇报,请不到忘了你的时间节点。
总之,保持现在,探索扩展,尝试未来。
WHAT
是不是我们规划每件的事,都值得去做?是不是我们只做规划的事情?未来是一直在发生变化的。
而规划,只针对我们知道的内容提出的。它无法用于我们不知道的领域。它也无法应对未知的事务,如产生了一个新的技术,它提高了三倍的生产力。
那么,先前我们设计的一些规划,可能在此被新的技术替代掉了。
这方面的实践,便有点类似于演进式架构的味道。
我们定好了一个大体的目标,核心的部分,只在真正实现的时候完善。
为此,它需要具备一定的可演进式,也因此不会受过去的设计所限制。倘若基于这一点因素考虑,那便是容易得多了。
只需要去寻找那些真正可能影响我们的趋势,套上一个模糊的概念,就可以这么轻装上阵。
可是呢,在做这件事情的时候, 每个人心里都有了一个答案 。
事实上,你心底也已经有了一个答案,只是说呢,你不敢、不想直接说出自己的想法——一来,受限于能力;
二来,怕做了错误的决定。而直接、间接地,你在社区上看到一个大佬的回答,与你想要的答案是类似的。
便将这个答案怀chen出来,信心也就有了,再说 “我们也可以这么搞”。好了,以后一旦出现了问题,还有一个人可以莫名地帮你背锅。
大家活着都不容易,背锅事小,不带人身攻击就好。责任,它与能力和屁股的位置是成正比的。
我们从基础来看,在对2019前端开发如何进阶,提升自己,再做更深一层讲解。
1 基础技术
前端的三大基础毫无疑问就是HTML、CSS和JS。我称之为前端的骨、肉和魂。
先说“骨”——HTML。HTML,翻译过来就是超文本标记语言,而不是江湖上的HOW TO ML。方向不能搞错了,我们整的东西可是老少咸宜的。HTML学习最重要的标签的学习,div、h1-h6、p、ul-li、strong、图片、字体等,什么内容用什么框.
再说“肉”——CSS。CSS定义了HTML标签的显示外观,气质。主要掌握浮动,宽高设置、显示属性等
最后“魂”——Javascript。这是运行在浏览器上的脚本,但是现在javascript已经远远不是当年的那个js了,尤其Ecmascript6标准出来后,nodeJS 横空出世,JS暴露出一统天下的野心,JS让网页变得灵活,其实现的每一个明里暗里的交互,其实是为了触及您的灵魂,这也是其成为魂的原因。
而现在,CSS3和HTML5的发展,又将web推向下一个时代,一个更为丰富多彩的时代。
2 环境基础
设备、浏览器以及工作原理
必须指出的是,html CSS JS都是运行在浏览器的,是由浏览器负责编译和呈现的。所以必须了解浏览器的工作原理。但是浏览器千千万万,也不是每个都要去解剖,主要的有Chrome, Firefox, IE,Safari,Opera,国内的主浏浏览器基本是基于chrome内核开发,做了一些更为接地气的功能,了解下就可以了,主要有QQ浏览器,UC,百度浏览器,360浏览器,搜狗浏览器,猎豹浏览器等。
3 计算机基础
计算机网络,http协议。既然是web必不可少需要知道计算机网络的知识,这对于网页的加载和速度优化有很大的帮助,并且,我们做的不是静态的页面,而是动态的,所以必然涉及到与后台之间的数据的传输和存储,这个是要掌握的。
必须懂:Ajax,必须会的工具:fiddler
4 流行框架
流行的前端UI框架:
Bootstrap、jQuery UI、Amaze UI
流行的前端框架:
Node.Js
jquery mobile
angular.Js
Vue.js
React.js
5 可视化组件
Echarts
tableau(收费)
前端 in 后端
所谓的前端 in 后端,便是 在后端开发中,使用前端相关的语言和技术栈 。
最典型的场景,便是使用 Node.js 开发后端服务。
虽然 Node.js 已经有了 10 年的历史了,但是以我的角度来看,我更希望的是使用编译型语言,来开发后端服务。
动态语言,无法使用编译器来检测错误,难以约束代码变动。
大前端
作为一个新兴的技术领域范围,大前端在不同的语义环境下,有着不同的解释和含义,我们以几个视角去对大前端并做逐一的分析。
Node.js 与前后端分离
在绝大多数的前端开发者口中,大前端有时与 Node.js 一起讲,有时与前后端分离一同讲,事实上,大前端概念也正是由广大前端开发者提出的。
过去几年,前端技术经历了爆发式的发展,这种发展最重要的推动者之一就是 Node.js。
Node.js 为前端建立了与系统之间沟通的桥梁,从此前端技术不仅能在服务端大放异彩,并且在本地的前端开发工具与工作流上大展身手,前端从此被解放,JavaScript 统治世界的论调一度甚嚣尘上。
不过,当人们冷静之后,发现 Node.js 在服务端并没有太多的优势,再加上 Node.js 本身技术发展的一些波折,导致它在服务端的应用并不理想。
但尽管如此,广大的前端开发者还是取得了一些阶段性胜利,其结果就是前后端分离。
在传统 Web 开发时代,前端页面模板是由后端生成的,导致在页面需要频繁修改的时候,效率极低。
前后端分离指的是后端只提供接口,前端对页面有完整控制,同时通过中间层将前后端隔开,在这里对数据进行抽取、聚合、分发等操作。这个中间层,通常也是由前端开发工程师负责。
从这种意义上讲,大前端的原始定义可以称为前端技术的扩大化,包括 Node.js,同时对 Web 页面有更强的控制权,开发也将承载更多功能的页面。
Node.js 打造后端服务
从社区的探索来看,存在一些完全使用 Node.js 开发的后台服务。
但是,也存在一系列由于代码不规范造成的问题。
从社区的经验来看,Node.js + Express + MongoDB + Angular/Vue/React,便是一些不错的选择。
当然了,也有相当多的应用,只是采用了 Node.js 来完成 BFF 层(Backend For Frontends)。在这一层业务上,它只做业务数据的中间处理。
虽然,我经常建议在一些关键的节点上,不要采用 Node.js 来打造后台服务。
可一旦涉及到 SPA 的服务端渲染,我们就不得不使用 Express、Koa 等这样的服务端 JavaScript/TypeScript 框架,来解决这样的问题。
Serverless
作为一种折中方案,也是我最喜欢的方案。
Serverless 架构是指大量依赖第三方服务(也叫做后端即服务,即“BaaS”)或暂存容器中运行的自定义代码(函数即服务,即“FaaS”)的应用程序,函数是无服务器架构中抽象语言运行时的最小单位。
采用 Serverless 架构,也就意味着,我们提取出了大量的基础设施。而使用 Node.js + JavaScript 作为胶水,来快速连接不同的服务,以形成一个快速有效的方案。并且,编写更少的代码,也意味着更安全、快速。
除了直接基于 AWS 的 Serverless Framework 框架的方案,还有 OpenFaaS、Kubeless、OpenWhisk、Fission 等不同的 Serverless 框架。
前端架构
由于前端的代码量在不断地增加,前端不在是一个大泥球架构,越来越多的新架构,将出现在前端领域。
微前端架构
微前端是一种类似于微服务的架构,它将微服务的理念应用于浏览器端,即将 Web 应用由单一的单体应用转变为多个小型前端应用聚合为一的应用。
各个前端应用还可以独立运行、独立开发、独立部署。
从笔者在 2018 年的实践经历来看,微前端架构确实是一个不错的架构方案。
它能有效地解决臃肿前端应用、遗留前端应用和复杂前端应用。
我们在项目上尝试使用了多种不同的实践方式:微件化、微应用化、路由分发、前端微服务化等。
将一个应用分解,拆解成更多的应用,确实能相对高效地提升开发效率。
如果你们的应用已经相当的大,记得采用微前端相应的技术。还有阅读我写的《微前端的那些事儿》。
组件库及设计系统
自 Ant Design 的圣诞节事件之后,我相信: 在 2019 年,有越来越多的团队将构建自己的组件库 。一种颇为简单的方案,便是:
评审一个开源组件库 Ant Design、Material Design 等
在开源组件库的基础上,进行二次封装。如 变成
替换部分的开源组件代码
随后,在那些的基础上,加入自己的模式库和设计系统。
BFF 架构
有越来越多的系统中,出于应对多端(Android、iOS、Web)变化的考虑,便在后端做数据相关的处理工作。
为了更好的解耦业务逻辑,并提供更快的业务响应,便在这一层级采用了 BFF 架构。
BFF 全称是 Backends For Frontends (服务于前端的后端),它是指在设计 API 时根据不同的设备类型,来返回不同的结果。
除了,采用 Node.js 中相应的后端框架,作为 BFF 层的开发模式。GraphQL 是在 2018 年特别流行的一种 BFF 模式,毫无疑问在 2019 年也是一个值得考虑的方案。
好了今天小编就更新到这里,还有太多内容下次更新,一回更新太多,怕你们消化不了,让我们一起期待下一次的干货分享。