(精)牛逼的前端是什么样的
2023 前端趋势
https://2022.stateofjs.com/zh-Hans/
前端外包化，几个大厂带的头(一年前面试阿里就是这个趋势了)
就业前景会越来越差，必须走专业化，营造技术深度
B 端外包严重，C 端应该定位是用户体验工程师，定位纯前端是走不长的
在企业里面，不能体现业务价值的能力，等于没用的能力
注意这里的前提是”在企业里面”，可能某个技能，在 A 企业没有用武之地，但是在 B 企业就是一项好技能。
屠龙技要在合适的场景才能发挥出其价值。
所以我们的技能学习和深入方向，一定要结合公司当前的发展方向和需求去制定，否则就是白费功夫。而且没有业务上大量的需求来驱动，你也是不可能深入钻研进去的。
Web 前端开发有前途么？
参考知乎这个回答：
https://www.zhihu.com/question/571797944/answer/2903135861
国内没有哪家公司是靠前端技术壁垒占有市场的。
我们公司对外的宣讲，也从来不会将前端作为一个技术亮点。
最近面试的感触
最近面试的前端都不咋地，大差不差，没有遇到那种特别突出的人、一聊就能感觉到是个高手的人。
看到一个词语：工程打灰，应该是大部分开发人员的现状。
那么怎么样才能成为高手呢？这也是我们每个人需要思考的问题，这关乎自身的长期发展。
想要进行有效的面试，也必须想明白这个点(千万不要问一些傻叉问题)。
比如最近面试的几个人：
- 常规的前端知识都有所了解
- 基础知识点都能答上来(比如缓存、框架原理等)
- 做过的项目讲出来都感觉难度不大，就那样
- 不怎么注重工程化建设，大多都只是做过几个组件，且组件应用范围很有限
- 解决的问题都是一些具体的小点，没有形成体系化
这些人你说评个 T2 也行，好像评个 T3 也行，但是 T4 一定不行。
而类似这种，则一聊就可以感觉到，是有点内容的，至少不是一直傻傻的做业务：
有赞的后端 Node 框架：
基于 KOA，做了多层封装，包括：
1、阿童木层，主要是制定规范，以及提供了一批和业务关联较小的插件
2、业务层，封装通用业务功能
3、PC 和 H5 的 Base 层，这是独立分开的两块
4、应用层，具体的业务逻辑
像这种，我们也是可以做的，比如基于 ZRender 的上层组件库的程序设计，就很适合这样做，做成一个渐进式的组件开发框架。
做框架对于程序设计、业务抽象绝对是有很大帮助的。
架构师与技术专家的区别
架构师-解决复杂问题
关键词：业务复杂度、工程架构、程序设计、方法论
定义问题(解决不知道要做什么的问题)、权衡最佳方案(做决策)、将复杂问题拆解为普通人员可以处理的问题。
如果你画出来的系统架构图就那么寥寥几个模块，那铁定是没啥复杂度的。当你的架构图本身就是一个复杂的关系图时，才有架构可言。
我们做可视化，大部分内容是开发组件，而且是基于开源的底层库，比如 ZRender、Three.js 等进行上层框架的封装。这样在复杂度上是很有局限性的。甚至最近发现，我们其实只需要同一套封装设计，就能应对 2D、3D、静态、动态的可视化开发。所以我们走架构师这条路，如果只专注于组件开发，会因为缺乏实际场景需求的驱动，导致很难走远。要想走下去，必须要涉及可视化业务开发，且最好是做重交互的内容，比如复杂数据分析工具、编辑器等。
架构师可以将高手才能做的事情，通过架构、基建，消化为 10 个新手也能做的事情；或者是 0.2 个高手带着 8 个新手也能做-MapReduce
MapReduce
MapReduce is a programming paradigm used for processing large datasets. It is a distributed computing model commonly used in big data applications. It consists of two stages - the
mapand thereduce, wherein the problems are divided into smaller parts and solved in a parallel way. The map stage takes a set of data and converts it into another set of data, where individual elements are broken down into tuples (key/value pairs). The reduce stage then takes the output from the map as an input and combines those data tuples into a smaller set of tuples. By combining them with some form of logic, it builds the final output dataset.
类似 CPU&GPU，CPU 拆解任务，做架构，GPU 执行并行的、简单的、子任务计算。
前端的架构是什么？
架构师的工作职责：业务抽象、流程梳理、组合架构形成业务解决方案/框架。
前端架构师：
https://www.zhihu.com/question/26646855/answer/68503768
前端项目大概会经历以下这些阶段：
整体渲染
结构行为表现分离
隔离逻辑单元
插件
模块
前端 MVC/MVVM
组件
先进的想法并不会区分前后端，而是被用到了所有适用的地方。
一个软件项目，随着待解决业务问题的发展，和问题复杂度的不同，会存在以下几个阶段，
具体解决方案
共用代码
功能独立的工具
架构模式
5. 领域特定语言（DSL）
如果把前端架构这件事比喻成一场战役的规划，有两个点是必须要重视的：
一，打仗应该怎么打，也就是各方面基础知识、眼界之类
二，你目前正在打的这一场仗是怎样的，这一点很容易被忽视，但其实非常重要，比如：它处于整体战局的什么位置，要完成什么目标，参与者是怎样的技能。方案的设计一定要随着项目走，而不是先有个之前用过的通用方案，然后把项目往上套。
作者：徐飞
链接：https://www.zhihu.com/question/31948284/answer/55734123
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
技术专家-解决技术难题
关键词：技术深度
霍元甲：我这一拳二十年的功夫，你挡得住么？
在已知问题的情况下，寻找最优解决方案，让大家少走弯路。
深度决定了你是业务开发人员还是技术专家。
这条路相对更适合我们一些，但是需要我们自己不断提高标准，自己创造需求。比如性能、兼容性、渲染效果等等。
优秀的开发人员
只有看过好的东西，你才能知道正确的方向，才不会自己将把上限理解得太低了。
所以这里列几个优秀开发人员的经历和工作内容，见识下什么是好的，什么是正确的。
1、北大研究物理模拟算法的数学博士，现在在蚂蚁开发 oasis：
可以看下他的博客，从剖析 OGRE 引擎开始，到后面进行 oasis 的开发。
什么因素导致了前端工程师的职业天花板很低？
没深度&没平台化思维
5 年以上，如果不是领域专家，没有足够的深度，感觉都是找不到工作的。
对技术的理解有误
前端有很多成熟的框架和解决方案，平时大部分工作只需要基于这些框架来模仿别人的解决方案即可，平时的工作就是熟悉工具、造轮子、堆逻辑。这很容易让大家以为这就是做技术、做前端。而实际上并不是这样的，这样顶多就是一个配置人员。如果某件事情，随便换个人搞个三两个月就能搞定，那这个事情一定是没有什么难度的，也不足以形成你的竞争力。
就比如你问一个开发人员：你感觉技术高手应该做什么？我猜大部分人都答不上来，或者回答得很模糊，或者回答得很 Low。因为大家对于真正的技术，并没有一个清晰且具体的认识。或者可以说，对于技术的审美能力很弱。没见识过好东西，自然无法分辨好与坏。
解决的办法也很简单，就是不断去扩宽自己的见识，提高自己的品位。你关注下本行业最牛逼的那几个人，看看他们在干嘛，就能了解个大概了。
纯业务开发缺乏复用性，很少做抽象设计
大家写业务，经常都是一把梭，需求一到手就是干。因为业务需求常常都是一次性的，迭代很快，干完这一把，下一次可能就不一样了，因此很少考虑抽象设计。
而架构师或者高级程序员原本应该做的，就是抽象设计。如果工作中缺少了这方面的实践，怎么可能精进呢？
形成对比的，就是基建和组件、服务开发人员。比如你的工作是做一个通用的可视化组件库，会给很多业务、不同场景使用，那么这自然会倒逼着你去做抽象设计(A 场景说我需要绘制的是一个三角形，B 场景说我需要的是一个五角星…)，因此你更多时候考虑的是如何抽象、考虑的是如何将这个组件库的机制给做好，而不是考虑某一个具体的实现如何写好就够了。
业务逻辑后端化
比如我们做的金融业务，逻辑基本都是由后端处理的，这就导致前端开发人员对于业务的理解是很浅的。数据从哪里来、数据如何处理、安全问题等等，基本都不用前端去考虑。
前端人员既然不能影响关键性的逻辑，那么在公司和业务团队中的话语权是很弱的。
前端在并发上的先天弱势
前端是运行在用户本地电脑上的，每个用户独立运行，因此先天上就不会遇到高并发问题。
而软件开发行业所重视的高扩展性、高可用性，都是和并发关联在一起的。这样就导致前端在软件设计上存在致命的弱势。
没有具体的业务场景供你去实践和打磨，不可能让你在这方面有所作为，毕竟软件工程是个实践工程。
HTML 架构设计降低了前端系统复杂度
HTML 的设计本质上就是超链接(Hypertext Markup Language)，网页通过链接的方式进行跳转，每个网页都是小规模、相互独立的。
这样的设计是很优秀的，做了物理层面上的解耦。但是给前端开发人员带来的，就是前端系统复杂度很低，阻碍了系统设计上的深入。
比如后端的一个服务，可能因为业务很复杂，需要做分层处理，上层业务调用下一层的 Service，而 Service 可能又会通过 RPC 调用其他的服务，服务的下层还有数据存储，整体会是一个复杂的网状结构。想要将这个服务做好，你必须考虑如何解耦、如何保证安全、如何在部分子服务出现问题时，不影响服务的正常使用、如何在服务异常时，能够 1-5-10 恢复、如何在流量激增时动态扩容等等。应用生命周期中的每一个环节，都有非常多的内容需要考虑。这一套下来，复杂度自然而然就上来了。而程序架构，本身就是随着复杂度而衍生出来的东西。因此经常可以看到后端架构师。
但是前端则不然，大部分场景(也有一些场景存在复杂度设计，但是相对较少)，你的程序设计只需要聚焦于页面级别即可。因此很少有看到前端开发在编码之前做程序设计、画数据结构、类图的，基本上都是拿起来就开干。
成熟的工具和库解决了前端渲染层的大部分问题
比如 ZRender、Three.js 等这些渲染库，已经把 2D、3D 的渲染问题大部分都给处理掉了，这样前端开发人员在渲染层可发挥的余地就并不多了。当然，可能大部分人都没有意识到自己应该在这些方面去深入。
2023.02.23：小鱼反馈，他们公司已经不招前端了，前端的活儿是后端直接干掉。
前端技术和方向很多，会陷入一直在各种技术的低端区域瞎逛的情况
比如今天学 Vue，会做几个 Demo 了；明天学 React，又去做几个 Demo；后天学 Three.js，还是搞几个 Demo。买了一堆书，全是《XXXX 入门》这种，不知道这个领域最牛逼的是什么，也没有去关注前沿信息。
这样浅尝辄止，没有抓住每个技术的设计要点和想要解决的问题，没有形成深层次的造诣，是没啥用的。技术更新对你的打击是毁灭式的。
就像电影霍元甲里面那句话：我这一拳二十年的功夫，你挡得住么？
我们大部分人在一项技术和领域，别说二十年，可能连一年的功夫都没有，都是在重复学习和使用三五月的功夫。
前端从业人员普遍层次较低
前端肯定也是有不少牛人的，但是从平均水平来看，从业人员的层次是低于后端的。
比如看每次的春招、秋招、面试人员的简历等等，很少有 985、211 学校做前端的。虽然 学校不一定说明问题，但是也能体现一个现象。
在平均人员水平较低的情况下，前端的平均水平肯定也就没后端那么高了，大部分人都只是接活儿的普通开发，很难成为技术高手，因为没这个环境和氛围。
这个也可以从我观察到的前后端工作状态的区别来体现：
前端：平时讨论的就是接了什么活儿，接完就是直接干，基本没有什么规划，画个架构图或者做的方案设计都很 Low
后端：经常讨论领域建模、画 UML 图、数据结构和继承关系的设计、分层抽象等等
业务代码的编写，逐渐智能化和自动化
1、低代码越来越成熟
低代码平台越来越多了，之前低代码还只是针对中后台、ToB 业务的，现在针对特定领域的低代码平台，已经可以直面 C 端产品的开发了。
另外还有类似 copilot、TabNine这样的工具、设计资产直接转代码的工具等等，这些技术就像工业革命一样，会干翻一大批码农。
未来是技术的未来，是工程师的未来，但不是码农、搬砖工人的未来。
2、即使是做业务，观念上也需要从实现功能转变为做产品
产品这个词，我一直都觉得是和工程师这个词语一样，是一个有追求、高大上的词语，一定是精心打磨的东西才能叫产品。
产品 VS. 功能
工程师 VS. 码农(API 调用者、配置人员)
我们要能区分出两者之间的差别，明确自己是在做产品还是在垒功能。
不懂业务
看到过一段话：
游戏软件的本质是游戏；
文字处理软件的本质是文字处理；
社交软件的本质是社交；
作图软件的本质是作图；
计算软件的本质是计算；
购物软件的本质是购物；
影音编辑软件的本质是影音编辑。
这些其实就是业务。那么做前端开发的，懂自己这块的业务么？如果不懂，那你就铁定距离自身业务的价值点很远，也就无法影响业务，不可能成为核心成员。
比如我做可视化，如果我自己不懂可视化，是没法搞的；你做基金，不懂基金业务，光会前端技术是做不出靠谱的基金产品的。
懂技术 ≠ 懂业务，业务才是核心价值点，技术只是为了帮助业务实现价值的工具而已。一定不要本末倒置了，这是很多技术人员都会犯的错误，以为技术能搞定一切事情。
所以当你从事一个岗位之前，先问问自己：这个岗位的核心业务是偏向哪个职位的？是产品还是设计还是开发还是其他？如果你的答案不是开发，那就别搞了，因为这已经注定你不可能主导这个产品。
试想你做炒股软件，是懂股票的产品经理更重要，还是实现功能的开发人员更重要？
技术和商业发展的侧重点不在前端
近几年的大数据、人工智能，最近的 ChatGPT 等等，哪个是和前端紧密相连的？
后端在搞大数据、人工智能，前端还在搞 button、label，这显得多 low……
什么是前端的核心技术？
图形学、数学、网络、异步线程、协程、内存、GPU、CPU……
基础的、贴近原理的，才是值得我们深入学习的，因为其具有泛用性，不管什么业务，都是在这些基础之上建立起来的。
通过深入钻研这些技术，形成优秀的架构和体系，解决某一个领域的难题，这才能体现你的能力和价值。
剑走偏锋型
还有一个观点：现在各项常规问题的解决方案都很成熟了，而绝大部分公司因为没有价值放大器，其实用不到极限追求的一些内容，比如极限的页面响应速度优化等等。这种情况下，常规通用解决方案已经足够了，再往常规前端的一些性能上去钻研，意义不大。
这种情况，扩展一些小众的方向，可能会有机会，比如可视化、Web3D 等等。
我目前其实就在走这条路：常规前端我跟大家差不多水平，但是我会一些非常规的技术，以此营造个人短期的竞争力。
前端开发人员应该从事什么工作？
想一想五年后、十年后，你想到达怎么样的一个职业高度?
目前从事的工作和方向，在工作内容/技术广度/技术深度/工程复杂度等方面，能支撑你达到这个高度么？
如果你只想当一名普普通通的码农，没有追求，只是想通过写代码混口饭吃，那就不要考虑这些，不然只会让你焦虑。
想明白了上面这些内容后，就可以针对性的突破这个瓶颈，比如：
垂直领域的AIGC应用
我们的AIGC可视化就是典型代表：AIGC(AI) + 可视化(垂类)。
择业需要顺势而为，就像之前移动互联网浪潮，大家都去搞移动业务一样。当前的风口肯定是LLM，那么做AIGC就是一个非常好的方向，这甚至可以作为个人职业转型的契机。
大模型基建
大模型基建也是一个比较好的方向，不过这个方向需要你懂大模型(沉淀LLM的业务深度)，而不是仅仅做一些管理页面，那样无法真正形成竞争力。
游戏客户端
游戏行业和互联网行业是相反的，客户端反而是核心，大部分的游戏(复杂度低、规模小)，服务端凑合能用就行。
游戏客户端在技术广度和深度上也远不是 Web 开发可比的。
做游戏的本质就是做工程，后续既可以往架构师方向发展，也可以往某一个方向深挖，比如渲染/性能等。
但是要注意，游戏客户端开发分为很多方向，做架构的，做图形的，做战斗的，做 UI 的，做优化的，做工具的，别走错了去做 UI，那和前端开发没啥区别。
通用组件库
做通用组件库，通过业务场景的多样性，反向促进你进行抽象设计、机制设计，往架构师方向走。
由于受到AIGC代码的冲击，这个方向目前可能并不是一个好的选择了，
走后端路线
走后端路线，比如阿里、腾讯的Node 服务化，但是这条路要看公司和平台，在我们公司目前还走不通。
并且后端一定要有大数据量/高并发的业务场景，否则技术和架构能力是无法提升上去的，只会停留在通用工具的使用上。
轻业务、重交互体验的工作
从事一些轻业务、重交互体验的工作内容，比如 Web 版设计工具(Figma 这种)、IDE(VSCode、WebIDE)、富文本编辑器。
视觉效果比重很大的工作
从事视觉效果比重很大的工作，比如 ToB 的可视化大屏开发。
跨端基建
跨端基建，一个在任何端都可以运行、不需要安装、浏览器打开即用的软件，对用户的吸引力和传播能力无疑都是巨大的；我们的炒股软件，未来未必不能是纯 Web 的。
引擎开发
做引擎(之前我把这个理解为基建，其实不对)，比如特定业务的程序框架模板，可以极大提升程序设计能力，并且从开发提效方面也能说明价值。这个已经由郑浩琦、薛成武、沈炜、王渊分别证明过了，绝对是最正确的路线之一。甚至现在做游戏开发，必须得手写一个渲染引擎才能拿到门票。
引擎涵盖了复杂度+技术深度，是非常好的选择，但是同样难度也很高。这是一条难走但是可以长期走下去的路。
最近发现引擎也是分层次的。我们目前接触的是上层业务框架的封装，这属于比较初级的引擎；下层接近原理和硬件的引擎，才是技术密集点，目前我们的能力还不足以做这个，但是可以先学习原理。
我们工作中就有很多引擎的需求，比如：
1、D3 的业务开发库
2、Three 的业务开发库
3、Three 的组件开发库
4、ECharts 的 2D 组件开发库
5、范式 Demo 的开发框架
这些都是机会，可惜很多人你即使跟他明说了，也意识不到。
引擎似乎可以扩展为基建的概念，但是有没有基建这么广，应该属于基建下面的一个分支，更侧重程序设计，是走向架构师的一条正确的路。
啃硬骨头
众目睽睽下啃硬骨头，比如公司当前关注的页面秒开、可视化、虚拟人等问题(不过这个也不仅仅是前端的问题了)。
最好的办法：给你当前的工作引入难度
这个适合于已经发展到一定程度，比如有一定的技术经验积累的人员、组长、主管，这个时候你发现跳槽换工作并不能给你带来本质的提升，或者你会面临非常大的风险(收入锐减、不稳定等等)。那么此时，最好的方法，就是你自己想办法给工作引入难度，籍此实现自我价值和能力的提升。
比如你当前的工作是做常规的可视化图表，而且只是配置一下，显然是难度低、发展上限低的，那么是否可以：
走图表标准化，深入源码去扩展你们使用的开源库
尝试在工作中创造一些 3D 的机会
将业务抽象后，形成业务开发框架
尝试往其他的技术(比如 Unreal Engine & C++)和业务(比如物联网、产业链)延伸
探索与 AI 技术的结合，通过机器学习提升效率，或者搞定一些超越人工能力的事情
设计类软件隐藏的机会
这类软件解决什么问题
1、扩展人员的能力，比如让设计师可以做开发的事情、让开发人员可以做设计的事情，或者让其他人员可以独立完成 3D 的设计和开发；
2、提升效率，类似声明式组件一样，用户不用关注实现细节，细节以功能或者组件的形式，由平台消化掉了，用户只需要声明式的搭建所需的内容即可；
设计类软件的发展趋势
1、现在的设计软件，都在往 Web 化走(PS、Figma、Spline)
2、工具都倾向于往平台化走，模糊边界，集成创作者所需的各种功能，提供一站式全方位服务；比如这个设计软件，已经不局限于纯设计了，而是把平时开发人员的大部分工作内容也涵盖进来了。因此，整合目前零散的 Web3D 工具和技术，形成LowCode/NoCode平台化的工作流，大有所为，并且这条路难度也不高(前提是你对于这些技术的原理要了解，知道是如何实现的；因为是设计软件，都是和数字图像、虚拟仿真技术有关的，这些技术基本也都和计算机图形学相关联)。
3、好的软件，官方一定都有完善的教授视频，比如 UE、比如这个 Spline；门槛降得足够低，才能大面积推广出去。
应该重点学习什么知识？
知识都是会贬值的，但是原理型的知识贬值速度会慢一些。
经验型知识
各种框架、库、API、兼容性问题、跟平台和环境强绑定的内容(比如 flutter 开发)
可以看下过去十年被淘汰的技术：
jQuery、CSS 的 table 布局、IE 兼容性问题、ExtJS 框架、SeaJS、Grunt、Smarty 模板、phtml 模板。
另外现在借助Copilot类的AI工具，这类经验型的编码已经完全不是问题了，甚至你不用懂具体的语法和API，也能在Copilot的帮助下快速完成编码工作。
原理型知识
数学、计算机组成原理、图形学、算法、设计模式(其实也在变，但是比较慢)、抽象能力。
深度
浅尝辄止的知识，都是不值钱的。只有深入到一定程度，才能让你区别于普通从业者，才能解决难题，才能产生更多的想法。
Web3.0，前端人员的机会在哪里？
Web3.0 的核心技术是：Web3D(资产) + 区块链(管理资产)
前端不只是网页，技术不只是 web，只要是用户端的(游戏端开发、客户端开发)，都算前端，不要自己把路走窄了
游戏化和社交是未来的趋势
炒股不能游戏化么，不能社交化么？未来很可能是虚拟一体化世界。
如果我们没有提前准备好，连门票都没有，怎么进入这个领域？
前端未来的路，就是基于图形学的 3D 世界构建者：3D World Creator.
前端+
源自知乎上的一个帖子：
代码+金融 = ico 跑路党
代码+数学 = 人工智能大师等
代码+机械 = 富野由悠季（233333）
代码+赌博 = 东南亚黑庄
代码+美术 = 开发游戏大佬
代码+写作 = 廖雪峰
代码+图形学 = 叛逆者
代码+黄油 = 轮子哥
T5 前端应该做什么？不应该做什么？
至少应该多看书吧~
工程化的理解误区
先问几个问题：
给项目引入 Vite 算不算工程化？
给项目搞了 webpack 配置算不算工程化？
我觉得不算。
我理解的工程化，应该是结合业务特性做出的一些提效提质的内容，应该是目前外面所没有的内容，具备创新性。而上面的这些，只是配置环境而已。
比如想办法让可视化/3D 应用可以大批量自动化生成，这才是工程化。
而这些就应该是 T5 人员做的事情。
个人在这个时代能干嘛？
打工的话，你只能成为一块砖，除非走到高的领导层，否则是很难影响大局的；而且在公司里面做事，公司越大、限制越多，到后面很可能处理人际关系、跨团队纷争的精力会大于你实际做事的精力。
个人创业的话，自媒体、自动化内容生成应该是最好的方向了。
业务开发就真的没前途么？
也不是，关键看你是否真正喜欢业务开发的特性。
做应用开发的，你最好不要有“哪个技术更长久发展”这种想法，因为这行最有意思最好玩的反而就是发展速度非常快，一直有新东西出现，一直有新玩具可以玩，永远不会枯燥。如果你想求“稳定，长久”，那应该去做基础研究，研究研究数学啊，量子计算机啊，AI 底层算法啊什么的，不要做应用开发了。
如果你喜欢追求浅层面的新鲜事物(注意：这不是贬义！)，且能适应这种更新速度，乐在其中，那么做业务开发也是很不错的。
能让你快乐的工作，才是最好的工作。