最近小伙伴们应该陆续回公司开始撸代码了，在新的一年里，有些新的技术会 从实验走向试用；
有些技术，则会从试用走向采用；
有些技术，则会从采用走向弃用。若是以此为出发点，那么这个 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 年也是一个值得考虑的方案。
HTML 5 大型游戏
随着移动端的性能不断变好，在 2019 年，我开始看好使用 HTML 5 技术来开发一些游戏。
当然了，主要原因还是微信小游戏的出现。但是，不管怎样，我开始尝试在这个领域的探索。
前端 in 前端
前端领域，在 2018 年已经趋于平衡，Angular、Vue、React 都没有出现太大的变化。
框架
架构选型上，也趋势于平衡。该用啥的还是用啥，偶尔还是会出现一些框架切换的新闻。
尽管在 2019 年，会出现一些新的框架，但是还不太可能快引起变化。
TypeScript
TypeScript 真香。
前端，没什么好看——除了，娱乐新闻。
前端 in IoT
从 2018 年的趋势来看，至少物联网会在 2019 出现一定的上升趋势。
目前的主要表现阶段，是在智能家居相关的领域。如果只是就一领域而言，那大抵还是不错的。
笔者在撰写《自己动手设计物联网》时，使用的技术便是 JavaScript 作为后端和 Web 前端、移动应用的开发技术。
而无疑的物联网领域，除了现有的 Web 领域，还有各个地方都可以使用 JavaScript 作为开发语言。
嵌入式 UI 界面。对于处理器资源丰富的设计来说，它们可以采用完整的浏览器来运行前端应用，而不再是裁剪过的引擎。
智能音箱。在过去一年里，已经成为了一个新的入口了。而诸如 AWS Alexa 等都可以采用 Node.js 来开发语言技能。
嵌入式开发语言。诸如可以使用 JavaScript 作为开发语言的 IoT.js。事实上，它会变成类似于 Emacs 架构，由原生来实现编译器，由动态语言来增长特性。
……
你觉得呢？
开发工具完善
开发工具的完善，一直在每年的规划里。在 2019 年里，也是如此，引入更好的工具，如更好的拖拽工具，更好的代码生成工具——由 AI 生成。
前端 in mobile
前端 in mobile，指的是用前端的技术来开发移动应用。
RN 及 Flutter
依我的角度来看，使用什么跨平台框架来看，区别并不是太大。
目前主流的方案，仍然是原生（含跨平台框架） + HTML5 应用。从业务的角度上来看待这个问题，那么还是希望，可以用 HTML 5 的地方多——更新功能方便。
也因此，虽然在过去，笔者写过基于 React Native 的混合应用框架 Dore。我相信：Flutter 也会出现这样的混合应用框架。
不过，对于有原生开发能力的团队来说，它们的框架还会是三部分：
原生功能部分
原生 + H5 的频繁更新部分
Fultter 的跨平台部分
写业务嘛，框架都只是工具。
小程序
小程序，即 HTML5 小程序，即无需安装即可下载运行的应用程序。与普通的移动 Web 应用不同的是， 小程序相当于是高阶版的混合应用 。
如果只是从这一点上来看，其实是不是和微信一样的定制型小程序，并不是那么重要。重要的，在于与原生 界面结合，并提供离线使用功能。 它也是小程序与普通的 HTML 应用的区别。
安全
从 2018 年的前端社区经验来看，NPM 包的安全，也成为了一个值得考虑的问题。
也因此 2019 年，也不得不进行相应的安全机制的设计。
也因此 2020年，也不得不进行相应的安全机制的设计。
也因此 2021 年，也不得不进行相应的安全机制的设计。
源自：http://news.51cto.com/art/201901/590502.htm
声明：文章著作权归作者所有，如有侵权，请联系小编删除。
感谢 · 转发欢迎大家留言
本文分享自微信公众号 - web前端学习圈（web-xxq）。
如有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。
