第九十期:前端的局限性

·  阅读 149

这里记录工作中遇到的技术点,以及自己对生活的一些思考,周三或周五发布。

封面图

前端的局限性

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

当然这只是从宏观的方面来看待整个行业。那么从具体的前端一部分来看呢?其实也挺卷的,往前数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渲染的算法提升一个量级,是不是就可以忽略这些所谓的优化策略了呢?

思维还是太局限了。

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

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

最后

  • 公众号《JavaScript高级程序设计》
  • 公众号内回复”vue-router“ 或 ”router“即可收到 VueRouter源码分析的文档。
  • 回复”vuex“ 或 ”Vuex“即可收到 Vuex 源码分析的文档。

全文完,如果喜欢。

请点赞和"在看"吧,最好也加个"关注",或者分享到朋友圈。

分类:
前端
分类:
前端
收藏成功!
已添加到「」, 点击更改