摸鱼刷掘金印象中看到好多前端已死的论调，在综合文章榜前列也看到好多讨论的文章。就在此刻，首页还挂着呢。前端er们，是个好消息，前端死不了了。 ![企业微信截图_16823850084274.png](https://p6-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/90590323a7574cfeaefce908b11007db~tplv-k3u1fbpfcp-watermark.image?) 顺便，闲得无聊，统计了一下【掘金文章榜 · 综合】上榜文章，总共49篇文章中前端类文章就有20篇。要知道这里可是有8个子模块，其中后端还有多种主流语言，而前端在其中就足足占到了40%。 ![企业微信截图_16823855231563.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/9bca4e5539f446ecb5a9020445d26205~tplv-k3u1fbpfcp-watermark.image?) 好家伙，前端这是在凡尔赛吧。
我在网站里搜索“前端已死”,这些文章几百赞几百评论几万的阅读，属实是找到了流量密码。给我眼红的！（逃
有看别人看前端已死的有假装漠不关心的有纯粹蹭流量的，标题加个前端已死开始写技术文章

![企业微信截图_16823858351076.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/076673b663dd463797edd07c2ac771b1~tplv-k3u1fbpfcp-watermark.image?)

有起义型的，前端已死皇天当立不全栈当立有智囊型的，吾有三计，保前端起死回生

![企业微信截图_16823858937750.png](https://p9-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/abe212e8c65249d29cb6b6b0ea915157~tplv-k3u1fbpfcp-watermark.image?)
接下来的文章标题我都想好了：《ICU的独白：前端华丽的一生》《刑场上的婚礼：后端的真爱，全栈继承前端遗志再兴五百年》《三十年河东，三十年河西，莫欺前端少年穷》 ![image.png](https://p9-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/1afaf19f69314555855d0ff24cffd23e~tplv-k3u1fbpfcp-watermark.image?)
话说有没有一种可能，前端招聘难是因为大环境如此，不止前端难，后端也难，移动端更难。话说我在掘金从来没有看到过.Net相关的文章，按这里的说法，.NET大概是坟头草老长了。可人家在大本营博客园流量杠杠的，活得挺滋润。市场上岗位虽不多，但也因此没那么卷啊。有小部份人觉得前端已死或者要死，那就搞全栈嘛，学点后端的东西。毕竟后端也可以学前端的东西嘛。反正你们愿意叫这种为全栈，那就是全栈吧。毕竟城里人都会创造些新名词。
什么？你不愿学？太卷了？学是不可能学的，只能抱怨抱怨这样子，玩玩梗，明天起来又是新的一天。说不得，抱怨的人多了，感化了老天，前端又活过来了嘛。好的。

最后说两个故事，最近发生在身边的两个小故事。保证真实，没有添油加醋。一。公司有个前端，小女生，据说是00后，2-3年从业时长。某系统有个非常简单的功能，列表展示。本来一个接口就搞定。但由于有个展示字段需要比较复杂的耗时查询操作。遂跟女生商量能否写两个接口，先渲染列表，耗时的那个字段用单独的接口，前端进行异步加载。女生说不能一个接口嘛。我说比较耗时。客户体验会非常不好的。然后女生没回了。大概过了10来天吧。前端主管突然找到我，说某某接口非要异步加载吗？我愣了一下，才反应过来说的是哪个功能。本来我以为早就完成了，也不复杂嘛。啊，我说是，把我的考虑重复了一遍。前端主管表示理解，然后亲自完成了这个功能。对于这样一个异步加载的功能，在我还在学校没实习的时候，我就做过很多次。并且乐意去做这样的功能。因为觉得这样的功能稍微略有挑战性（对于当时的我），更利于成长，更利于简历的描述。但我不知道该女生是不想做还是不能做。这点就不主观臆测了。但据平时工作观察，她确实不太具有学习的欲望，只想在自己的熟悉的一亩三分地里呆着，对于不熟悉的领域天然的排斥。当然，这可能只是我主观的臆测。二。前端主管的故事。我们有一个功能叫做主题模型。模型列表主要展示人，以及人所关联的事件。同一个人在不同的模型里关联的事件不同。比如张三在A模型里关联了事件1，事件2；在B模型里关联了事件3，事件4。在主题模型展示的人员列表里，点击可跳转查看人员详情，人员详情页面的右侧同时有该人员关联的所有事件。比如张三，右边展示的就是1，2，3，4四个事件。同时，人员详情页面有多个入口，不止主题模型列表。比如事件详情，人员列表等都可以点击查看人员详情。客户觉得我从不同的主题模型里点击人员详情，我只想看该模型下的事件。比如从A模型里跳转到人员详情只展示事件1，事件2。非常简单的一个功能改动。我只需加个参数，在主题模型列表接口本身返回了模型code,点击到人员详情的时候把code带过来，我就可以过滤不相关的事件返回给前端。我把接口文档改动后发给该同事。过了一会儿，该同事问我人员列表怎么没有模型code，他取不到参数。因为之前产品已经给两边把需求讲清楚。嗯，他觉得讲清楚，我觉得也很清楚。然后我就有点懵。人员列表不需要模型code,也获取不到，因为一个人可能同时存在多个主题模型。当从人员列表跳转到人员详情的时候展示该人的全部事件，不需要传模型code参数。仅在主题模型点击人员详情的时候需要过滤事件，这时候才需要传code参数。有点啰嗦了。疫情居家那会儿，线上过需求开会，开着开着，主动参与讨论的永远是后端，前端会主动发问的也仅限于样式大小设计之类的。末了，让前端发表看法或者疑问，往往要喊好几次，可能是在忙其它事或者注意力根本不在这儿。多了几次后，有时候简单的需求就由后端直接传达给前端了。两个小故事讲完了，我尽量客观一点白描。先申明，这样的人后端也有，哪个端都有，因为后端基数更大，这样的人应该更多。而且绝对地无关对错。身边统计学毫无意义，只是说两个小故事，真没其它寓意。大家都只是时代洪流下的小人物。前端后端都只是个碗，里面盛什么饭，更多的是个人，而不是碗。