第八十四期：前端的局限性

前端的局限性

我以前从来没去思考过这个问题。但是今年倒是看了些相关的东西，有的说是互联网行业已经从以前的野蛮生长阶段，到现在已经没有太多的增量空间。没有增量空间，就只能做精细化运营，从现有的量中去挖掘新的需求，有点私域的意思。

当然这只是从宏观的方面来看待整个行业。那么从具体的前端一部分来看呢？其实也挺卷的，往前树5，6年，前端工作应该算是比较好找工作的吧，那时候没有现在这么多框架，html，css ,js 前端三剑客足够了。

然后各种框架开始涌现，具体的时间就不说了。angular , react ,vue，最早的时候还用angular写过一些项目，后来换了其他的框架慢慢的就不再写angular。

以前觉得前端开发挺好的，但是现在越来越觉得单纯的做前端太局限了。

写的越多，写的越熟练，你会越觉得有局限。

前端最核心的问题是处理用户交互。

虽然也涉及到一些基本的业务逻辑，但是其实又似乎跟业务逻辑没有关系。你可以通过界面跳转知道大体的业务流程，但是你不知道底层的数据详细的流转过程。举个例子：用户下单，支付完成，物流信息反馈，这些数据在数据库中表结构怎么设计，应该设计哪些表，怎么查，这些东西前端很多时候是不知道的。只知道跟后端说，我要这个接口，然后把数据显示到界面上，这个过程就结束了。

这样的事情做久了，你就会感觉到越来越局限，思维也僵化了。

整个行业竞争越来越激烈。表现到具体的工作中呢，就是kpi的考核。为了完成绩效考核，就会出现很多有意思的现象。比如我写个手册，他写个框架，他又写个别的什么文档，诸如此类的东西。但是这些手册，框架和文档有意义吗？对于个人来说肯定是有意义的，因为至少可以完成考核。但是对于业务上来说呢，假设我用了这个框架，满足不了需求，又有何意义呢？满足不了需求，找写框架的人提新的需求，然后开始新一轮的扯皮。。。

我特别理解这种现象，但是以我目前的能力却无法破这个局。因为我也被限制在这个框架之中。

一个非常典型的例子，我们都热衷于新的技术点。react 框架出来以后，热衷于看react，vue出来后热衷于vue , 后来又热衷于微服务，低代码，web-component。。。

我自己也试着去写一个自己的ui框架，整一个简单的微服务工具，试着去做一个低代码的demo，也试着用web-components去重新开发一套兼容多个框架的组件库。做这些事情确实是因为我个人对技术有比较高的热情。通过自己去尝试着写一些东西，对其中一些的原理有一个基本的认识，未来在工作中真的需要做这些事情的话，不至于无从下手。但是这些事情又不是一个人可以做的事情，所以大部分时候都是浅尝辄止。

放到现实的工作中，很多公司的业务根本就用不上。公司其实追求的不是我们使用哪个技术框架，公司追求的是业务的健康发展。即便我们不用这些框架，最原始的技术也是可以完成功能的开发的，而且熟练的话，其实效率也并不比用这些框架低多少。

日常的前端工作本质上都是在调用算法写好的api。

问一个很经典的问题：我们都说dom渲染速度远远慢于js的执行速度，那么为什么dom渲染速度会这么慢？

这个问题可以归纳到前端性能优化的问题中。但是真能把这个问题讲明白，让人能听清楚的有几个呢？

所以一提到性能优化，我们都会说什么减少dom操作，图片压缩，之类的，这些都是旁敲侧击，如果我们能把dom渲染的算法提升一个量级，是不是就可以忽略这些所谓的优化策略了呢？

思维还是太局限了。

我们都在这个框架之中，从来没有想过要突破这个框架，所以一个小问题，看了八百篇文章都是在说同样一个事情，没有意义。

我们需要有独立思考的能力。