新的一年，一些新技术将从实验走向试验；一些技术将从试验走向采用；一些技术将从采用走向放弃。如果这是起点，那么这个2019与过去的2018并没有太大的不同。学习一些新的技术，忘记使用不同的技术。只是前端这么广阔的领域，我们应该关注哪些技术，哪些技术应该忽略呢？这就是我写这篇文章的原因。不过在写的过程中：“不，我只是告诉你2019年会流行什么，可能意义不大，你需要自己学会拥有这样的技能，学会分析2020年需要规划什么》这里，这篇文章分为两部分，如何做前端规划和2019年我们需要什么，以及未来五年。但是为什么要做技术规划呢？可能是为了影响KPI，也可能是出于预算原因。我们的宗旨是：变得更好。所以：“为什么我们不能用现在的架构？现在的架构不是很好吗？”为此，我们只需要尝试回答这几个问题：项目的编译速度快吗？编写新功能速度快吗？能否满足快速上网的需求？多个团队并行开发，会不会有问题？我们依赖的第三方组件会不会有问题？...好吧，就像有人在问你，“你的弱点是什么？”对于这个问题。HOW从本文的写作过程和作者相应的规划步骤来看，可以分为以下几个步骤：调研技术前景从社区获取相应的输入整理潜在的技术方案、架构、技术栈从中获取思路利益相关者。制定相关的实施方案规划，类似技术愿景的味道。但是谈到前景，有很多事情要谈。更不用说我们还需要寻找利益相关者——比如团队成员、项目负责人，了解他/她对技术团队的一些期望。我们在社区看到类似的问题，总有类似的开头：“我们的领导……”谈理想特别有意思，因为我们不一定会去做。我们有一个好主意，但我们受到许多因素的限制，我们能做的只有这么多。比如我们以后要组装笔记本，现在可以只选择一个螺丝。当我们得到更进一步的方向时，我们需要从几个维度来考虑问题：从当前的业务情况出发。比如明年，我们的团队会从20人扩充到100人，以支持这么大的团队。我们需要有一个培训机制来应对这种人员扩充；我们需要设计一个更好的结构来实现多个团队的并行开发。从技术和架构开始。将新技术引入项目，改进原有的技术方案。架构预研。早期试用未来可能的技术，如AR、VR。这些通常是不必要的计划，但最好有它们。团队能力规则。说到团队规划，恐怕我不太擅长。一般来说，即使是技术总监也不是KPI的制定者。我们只能谈谈理想和团队建设的一些建议。有针对性的培养2层项目，这不是我们能控制的，至少对方能不能接受。这大概也是对个人发展的好处吧，可以选择自己感兴趣的内容学习。当然还有很多东西还是要接地气的，还是要做螺丝。只有落地的东西，才能证明它是真正有价值的东西。为此，我们需要使用SMART原则来制定明智的目标。当然，如果你还要跟领导汇报，请不要忘记你的时间节点。总之，保持现状，探索扩展，并尝试未来。什么意味着我们计划的一切都值得去做？我们只是在计划事情吗？未来总是在变化。该计划仅针对我们所知道的提出。它不能用于我们不知道的区域。它也无法应对未知事物，例如将生产力提高三倍的新技术。那么，我们之前设计的一些方案，可能会被这里的新技术所取代。这方面的做法有点类似于进化架构的味道。我们定了一个总的目标，核心部分，真正实现了才去完善它。为此，它需要具有一定的可进化性，因此不受过去设计的限制。如果是基于这个因素，那就容易多了。我们只需要寻找可能真正影响我们的趋势，套上一个模糊的概念，就可以轻装上阵。不过，在这样做的时候，每个人的心中都有了一个答案。其实你心里已经有了答案。只是你不敢或不想直接表达你的想法。第一，你的能力有限；第二，你害怕做出错误的决定。并且直接和间接的，你在社区看到一个大佬的回答，和你想要的答案差不多。然后我把这个答案从心里说了出来，我有了信心，说：“我们也能做到。”好吧，以后有什么问题，还有一个人可以无缘无故帮你顶锅。每个人活着都不容易，背锅也不容易。责任，与能力和屁股的位置成正比。前端在后端所谓前端在后端，是指在后端开发中使用前端相关的语言和技术栈。最典型的场景就是使用Node.js开发后端服务。虽然Node.js已经有10年的历史，但从我的角度（Phodal）来看，我更愿意使用编译型语言来开发后端服务。在动态语言中，编译器不能用来检测错误，也很难约束代码的变化。Node.js搭建后端服务从社区的探索来看，有一些后端服务是完全使用Node.js开发的。但是，代码不规范也会带来一系列问题。从社区的经验来看，Node.js+Express+MongoDB+Angular/Vue/React是一些不错的选择。当然，也有不少应用只是使用Node.js来完成BFF层（BackendForFrontends）。在这一层业务，只是对业务数据进行中间处理。虽然，我经常建议不要在一些关键节点上使用Node.js构建后台服务。但是一旦涉及到SPA的服务端渲染，就不得不借助Express、Koa等服务端JavaScript/TypeScript框架来解决此类问题。作为折衷方案，Serverless也是我最喜欢的解决方案。无服务器架构是指严重依赖第三方服务（也称为后端即服务或“BaaS”）或在暂存容器中运行的自定义代码（功能即服务或“FaaS”）的应用程序。体系结构中抽象语言运行时的最小单位。采用无服务器架构意味着我们提取了大量的基础设施。并以Node.js+JavaScript为胶水，快速连接不同的服务，形成快速有效的解决方案。而且，编写更少的代码也意味着更安全、更快。除了直接基于AWS的ServerlessFramework框架的解决方案，还有OpenFaaS、Kubeless、OpenWhisk、Fission等不同的serverless框架。前端架构由于前端代码量在不断增加，前端不再是一个大泥球架构，前端领域会出现越来越多的新架构。微前端架构微前端是一种类似于微服务的架构，将微服务的概念应用到浏览器端，即将一个web应用从单一的单一应用转变为将多个小前端应用聚合为一个的应用.每个前端应用也可以独立运行、独立开发、独立部署。从笔者2018年的实践经验来看，微前端架构确实是一个很好的架构方案。可以有效解决臃肿的前端应用、遗留的前端应用和复杂的前端应用。我们在项目上尝试了多种不同的实用方法：widget化、微应用、路由分发、前端微服务等，将一个应用分解成更多的应用，确实??可以相对高效地提高开发效率。如果你的应用已经相当庞大，记得采用微前端相应的技术。也看看我写的《微前端的那些事儿》。组件库和设计系统自从AntDesign的圣诞活动之后，我相信：在2019年，将会有越来越多的团队构建自己的组件库。一个比较简单的解决方案是：在开源组件库的基础上再复习一个开源组件库AntDesign、MaterialDesign等进行二次封装。例如，
