前端领域的快速更迭告诉我们顺应时代的变化才是核心。这是我浏览了一些2022前端发展趋势文章后的一些感受。
前端技术前言
现如今的前端开发，早已不是添加一个jquery库，然后手写原生html、css、js就能搞定的了，我自己回顾了下自己做开发前端的几年，并总结了下我个人感觉的前端发展过程：
- 最开始呢，我开发前端就是通过html写页面，在js里面通过jquery操作dom改写页面，css调整样式。
- 然后是前端模块化，我感觉这带来了前端工程化的雏形，因为那时候需要考虑代码组织了。并且印象中，html模板也在流行，虽然我没写过。他是从业务和功能角度对代码的拆分。
- 然后我认为对前端影响比较大的转折点来了：node，node发展对前端带来的影响是巨大的，虽然我不喜欢大厂乱造的词，但是这里node真的给前端赋能，对于前端开发来说，node是一个强有力的武器，这使前端发展进入了高速模式，对于现代前端开发来说，目前node已无法替代
- 由于node的出现，前端打包、前端编译、lint、测试、前端开发环境等等前端工程化方面也逐渐完善，而打包、前端编译是除了node之外的另一个大的发展基础，他们的出现，让开发不再仅仅局限于原始的js、css、html语言，而是让他们拥有了无限的可能，你现在很难见到原始的js、html代码直接跑在浏览器上了。
- mvvm和组件化，这是对前端开发模式的一次重大改变。组件化和模块化的不同在于组件化可能更偏向从UI的角度对代码进行拆分。
- node服务端：服务端渲染、全栈
关于node：因为语言及其生态的发展更多的是靠相应领域的开发者，你总不能指望让做java开发的来帮你推进前端开发的发展吧，而在node出现之前，前端领域的发展我觉得是受限的，因为即使你能用js完成很多事情，比如写一个编译工具、打包工具，但是该怎样应用到实际的项目呢？js那时候只能跑浏览器，且无法和操作系统打交道，这就导致了前端所能做的事情被限制了。而你也可以说不用前端熟悉的东西来完善前端生态，比如用java？python？可以是可以，但是生态发展怎么办？你总不能指望很多写java、python的开发者会积极讨论前端怎么发展吧，而且你也总不能指望前端人人都会这些吧，所以就会出现一种：能写的人不写，想写的人写不了的困境。而node的出现，则能完美解决掉这些问题，提供了同操作系统交互的能力，比如文件系统，让前端能做的事情不再受限，且用的是前端领域人人都会的js语言，我认为这是前端能做到百花齐放的基础。
而今年（2022），前端技术方面的大方向没有什么改变，只不过出现了是追求更快的性能、更好的开发体验，没有其他本质的改变。
打包工具、脚手架
打包工具
得益于其他语言在前端领域的应用，打包工具除了webpack和rollup这两个老大哥之外，也涌现了许多由其他语言编写的打包工具，这些工具的最令人兴奋的特点就是：快
- esbuild：go编写的打包工具
- parcel2：利用多线程，且使用由rust编写的、类似babel的swc作为编译工具
这些工具确实是快，不过其生态要追上这些老牌的打包工具，还需要发展一定的时间。
脚手架
如果仅仅只是一个打包工具，对于一个公司来说，其实是不够的，甚至对于目前日益完善的前端工程化项目来说，也是不够的，所有，才有了脚手架的存在，来帮助我们快速搭建一个完善的前端工程化项目。
目前最火热的脚手架非vite莫属了，他除了帮你完成项目搭建：例如项目创建、框架依赖、开发环境配置、单元测试、完整的打包工具配置、大部分常见场景的优化、代码规范等等工程化配置外，最大的特点就是利用了esbuild以及原生 ESM 文件来提供几乎0编译的开发体验。
而像框架的框架，比如next、umijs这种，其本身自带的脚手架，除了帮你完成了项目搭建外，其框架还自带：路由、mock、服务端渲染（SSR）方案等等你可能用到也可能用不到的功能。
其实，不管是独立的脚手架，还是项目自带的脚手架，其目的都是为了帮我们创建项目，而对于公司来说，这类工具可以直接使用现有的流行方案，也可以基于已有的进行二次开发来创建符合公司内部开发习惯的脚手架。其本质只是一个项目模板生成。
而目前的前端项目，已经不止是说一个html、js、css就能直接开写的阶段了，前端工程化早已经出现在前端开发多年，且仍然在发展。从目前的打包、脚手架的流行趋势看，有几个方面：
- 其他语言编写的打包构建工具：其目的是为了追求更快的性能
- 原生ESM文件、更快的热更新：为了更好的开发体验，性能
上面这些，更多是为了应对日益庞大、复杂的前端项目，所作出的追求性能的体验的改变。
前端工程化
我认为的前端工程化，基础的框架、语言选择（js、ts、css、scss、less这种）这里就不说了，在这之外的，前端项目还包含以下几个部分：
- 项目结构（架构）
- 普通项目
- monorepo
- 打包构建
- 各种资源打包
- 为项目进行优化
- 开发环境
- 原生esm文件
- mock
- 热模块
- 开发模式
- 模块化、组件化
- 测试
- 单元测试
- 组件测试
- 集成测试
- e2e(端到端)测试
- 规范lint
- 代码规范
- git提交、分支规范
- 文档
- 项目文档
- npm包、组件库文档
以上的内容，对于现代前端开发而言，没有一个能够绕开，有些方面可能还有遗漏，目前的前端开发，各个方面都有很多类似的工具、库、方案，都有优劣，没有银弹，没有一套在各个方面能适用所有场景的“最佳实践”。其中有一些方面是选择哪个的问题，比如lint、打包构建、开发环境、测试等，而有一些方面，比如项目结构策略选择，则没有那么好运，你需要根据实际情况去考虑，去抉择。至于框架、技术选型，这其实是另外一回事了。
我个人觉得，这些内容大多数都不像所谓的模块化、组件化、MVVM这种影响前端开发本质的改变，但是也在现今天越来越日益庞大、复杂的前端项目中无比重要。devops相关的咱后面再说，因为我更喜欢将其归类为基础建设。而微前端，我觉得倒不完全属于前端工程化范畴中。
devops、CI、CD
devops、敏捷开发、持续集成（CI）、持续部署（CD）这些词、这些概念就不提了
devops根据维基百科的介绍，好似是一种思想，这个感兴趣的可以深入了解一下：维基百科-DevOps，我们这里重点说一下我们公司的CI/CD。
CI/CD是一套软件实现自动化构建测试部署的工具系统，具体是啥，随便搜了个链接：什么是持续集成（CI）/持续部署（CD）？ - Linux中国的文章 - 知乎 感兴趣可以了解了解。
目前，我在公司过的CI/CD任然处于起步的完善阶段，其主要的侧重点是构建部署。
前端页面渲染方案
摘抄：
- 不同业务场景选择不同的渲染方案，SSG、ISR、CSR、SSR、ESR、SPR等；
- 所有场景的选择本质都是render侧重的取舍而已，软件工程中没有银弹，选择适合本业务场景的渲染方案才是上善之策。
前端的渲染虽然有很多种，本质上都是页面怎么样生成，目的是为了更快缩短用户看到页面的时间，同时不同的方案都是在性能、工程化、实现难度、效率、SEO等各方面的不同取舍。
微前端
这个技术的应用需要有实际的需求，看他解决的是什么问题，是否适合这个场景，不要为了微前端而微前端。
可以参考我之前写的这篇文章：微前端应用思考
小程序
参考文章：
本质上从前端技术和发展角度来看，没有什么大的创新和突破，更多的是前端展现形式和模式的转变，这意味着除非你深入其小程序核心，否则对于普通开发来说，进入这个领域没有太多成本，只有经验，而框架、行业经验，依托于框架或者行业本身的兴衰，脱离了技术、编程的本质，风险太大。
其核心的目标是轻量级app，所以，小程序，pwa等都是这一个目标的不同技术方案。
而目前的小程序，正式规范还在制定，行业发展先不说，通常对于开发人员来说，要求掌握小程序开发相关的两个框架即可：
- react：taro
- vue：uni-app
而和小程序有类似概念的还有一个方向，即pwa应用（与之关联的还有一个service worker技术），然而相较于pwa应用不温不火，在国内似乎小程序已经优先发展起来了。
Serverless
参考文章：
无服务器计算，或者说叫功能即服务。
即将某一个代码放到云服务器上去执行，并且按照执行次数以及所使用的资源收费，这通常是云服务器产商才能支持的技术建设（Faas：function as a service）
它被认为是云计算发展的下一个阶段，关于其发展解读，可以参考上述的文章。
对于前端来说最可能的应用，可能是在你去编写一个一个功能函数，然后放到faas平台上去运行。而且从目前公司的发展来看，暂时不会涉及该领域。而对于前端的影响，目前还没有看出太多东西。
低代码/无代码
一种软件开发方式，基本上你可以认为通过类似图形界面中的拖拉的方式来生成页面，创建应用程序。
目前低代码这边是在从单点的业务低代码平台到集成化的平台这个方向发展，这个的意思呢我理解就是之前的低代码是为某一个业务场景搭建的，这个低代码只是单纯支持这个业务使用，而集成化平台呢，就是为了适用于某一个领域搭建的低代码平台，比如为企业用户的流程管理搭建的低代码平台，以支持各种企业管理应用的搭建这种。反正就是越做越大，越做越通用（针对某个特定领域，之前是特定业务）
低代码的技术特点：
- 模块化、可复用的功能组件
- 可视化的应用搭建平台
跨平台
这个主要看中的是效率和成本。
这里指的是类似于，一份代码，能在多端跑的这种。
app跨平台
支持在Android和ios上运行
比如React Native和flutter
桌面应用程序跨平台
支持在windows，mac，linux运行
比如：electron、tauri（webview + 前端技术栈 + rust后台服务）、flutter
web跨平台
支持在移动端h5、pc端web，app，小程序（各平台）运行
比如：Taro、uni-app
说明
跨平台这项技术并非为了完全替代原生开发，针对每个场景我们都可以用原生写出性能最佳的代码。但是这样做工作量太大，实际项目开发中需要掌握效率与优化之间的平衡，跨端的使用场景并不一定是项目级别的，可以是业务级甚至是页面级的。所以，混合这种东西其实目前来说更有意义。
而且，如果你想要编写一个优秀的跨平台应用，那么你也是需要对不同平台的应用程序开发有所了解，而且不同平台构建后出现的问题，也需要你有能力解决，这都是对跨平台开发者的一些要求。更不要说从web应用开发者到桌面应用开发者的转变了。
不过，桌面端或者移动端的跨平台开发，我觉得是一个比较好的发展方向。开发的成本和速度这是两个绕不过的核心指标。
多语言在前端的发展
- go
- esbuild：类似webpack、rollup这种打包工具
- rust
- swc：类似babel的编译工具
- Tauri：一个基于rust、利用web技术开发桌面应用程序的框架
- wasm（这其实是前端的第四门语言了）
- c/c++：node
摘抄：
在端侧，Nodejs为主，Deno适当考虑，cpp配合优化；在边缘侧，rust+wasm前景广阔（基础建设）；在云侧，go不二首选。
对目前的前端来说，你会这些那很好，而如果不会，那么在你开始学习之前，可能需要权衡一下：go的话，我觉得如果你想发展全栈（除了node之外的后台服务外）可以考虑一下go。c++不用说了，与node有较大关系，node原生模块就靠他了，不过，对前端来说，其难度很大。rust和wasm感觉一直被拿在一起说，他们配合确实很默契，但是怎么说呢，，，rust也不简单，而且wasm能否被真正应用项目，也是你需要考量之一，不过可以持续关注其发展。
总结起来，其他语言同前端的发展主要有以下几个方面：
- 前端基础建设（esbuild、swc）
- 对性能有要求的前端工具库（rust+wasm），比如ffmpeg的wasm版
- 桌面端，通常来说其他方案就是将node和Chromium替换为原生webview+其他语言，比如Tauri或者go-astilectron，而页面仍然由web技术栈编写。
全栈
嗯~，感兴趣的人可以去了解一下，这确实是近年来一直被提起的话题。然而，其要求掌握更加全面的技能：前端自不用说，后台的话，go是个不错的选择（指nodejs之外），数据处理（数据库）的话，MySQL、mongoDB、redis之类吧，而运维的话，从其他资料上看，倒是看好serverless来完成运维这一部分的工作（甚至数据处理部分）。
中台
这个呢，可以参考这篇文章了解：“中台”到底是什么？
我觉得，这个确实需要业务发展到一定程度后，才会考虑搭建中台，其本质的目的是抽离通用的业务、技术，来提高开发效率，降低成本。我觉得，公司在名义上有没有中台从开发角度来看，其实没有那么重要。因为你真正在开发过程中，肯定会向复用、解耦等角度优化你的项目，其实目的是一样的，只是维度不同而已。
基建
前端的基建，看具体的公司情况了。我认为不同阶段下，公司需要的以及所能做的基建是不同的。
更多的基建可以参考这篇文章：如何推动前端团队的基础设施建设
其他
图像、游戏、通信
- 游戏：canvas、webgl、webgpu
- 通信：websocket、webrtc
web3.0/元宇宙？
额，看不清看不清