这篇文章发布于 2020年12月20日，星期日，5:02 上午，归类于 散文随笔。 阅读 28474 次, 今日 2 次

作者张鑫旭，原文地址：https://www.zhangxinxu.com/life/?p=1336
本文禁止转载，如有转载需求，请联系授权。

最近对前端框架有了些新的感想与体会，和大家分享下，希望可以对大家的工作和学习有所帮助。

一、框架流行的原因

一个带有技能性质的事物突然流行起来，原因都是类似的，那就是门槛低。

就像美图秀秀之于PS，爱剪辑之于AE。

其实不难理解。

既然“流行”，必然意味着使用者众多，由于优秀的人总是少数，因此当下流行的技能一定有大量能力一般的人在使用。如果上手门槛高，这些能力一般的人在驾驭的时候就会比较吃力，无法大范围普及，自然也就无法流行。

在前端框架这里也是类似的。

前端框架之所以流行，原因很简单，那就是上手门槛低。

但是请注意，上手门槛低并不等于学习的东西少。

框架做了什么事情？

一句话概括就是：把原本需要深入了解的底层API和技术细节变成了扁平化的配置和应用API。

也就是把原本纵向很深、门槛较高的学习变成了横向很广、门槛较低的学习。

在Web开发领域，底层的API往往又臭又长，他认识你，你不认识他，例如indexedDB API（下图左），Web Audio API（下图右）等。

学得动吗？根本学不动，而且就算学动了，想要带来收益，往往是很久之后的事情了。

但是如果隐藏这些底层API的含义和细节，直接封装成变成更易懂的上层应用的API，例如：

new DB(name).setItem(key, value);
...

new Audio(url).play();
...

学得动吗？肯定学得动，setItem(), play()这样的API路边随便抓个上海的小学生都知道什么意思。

这就是框架做的事情之一，隐藏底层的细节，变成上层更易懂的API，虽然你需要学习的API数量还是很多，但是显然这些4级英文单词API要比那些冗长的完全不知道什么意思的API学起来轻松多了。

虽然我不知道它做了什么，但是我这么一用，嘿，效果就出来了。

这就很有意思了，你想啊，一个什么也不懂的入行的前端开发，按照教程，一步一步安装，然后套用上层API，然后学习一些配置，居然一个像模像样的产品效果出来了，你说，这样的框架能不爱嘛，自然就会在行业中变得热门与流行。

二、框架对行业的意义

成熟的前端框架的出现对整个互联网行业的发展是有巨大的意义的。

国家发展，数字赋能，各行各业都开始云化，数字化，互联网化。

因此前端开发的需求是巨大的，井喷的，如果前端开发是一项高门槛技术，那么显然，各行各业的发展就会受到制约。

此时，框架的价值就体现了，大量的各方面能力比较平均的年轻人可以通过在现有框架基础上添砖加瓦，实现足以应付实际使用需求的产品。

也就是框架的出现降低了前端开发的门槛，使得有足够多的人员加入这个行业，为祖国的数字化建设添砖加瓦，同时造就了前端领域的繁荣，我个人或多或少也因为这个行业的发展沾了光，感谢框架！

三、框架牺牲了什么

这个世界是守恒的。

框架带来的低门槛是通过牺牲其他一些东西实现的。

包括带来了大量的冗余、牺牲了部分的性能、体验以及灵活性。

这其实不难理解。

成熟的框架，尤其那些知名的开源框架，为了应对各种项目和场景，自然会包含大量的细节处理，但是这些处理往往都是冗余的。

例如项目无需兼容IE浏览器，但是框架代码中却有很多对IE浏览器的兼容处理，这些处理就属于冗余代码。

又例如PostCSS会给CSS新属性添加私有前缀，其中不少CSS属性会添加-o-的私有前缀，这是针对Opera浏览器的，妈呀，Opera放弃自我已经那么多年了，完全没有必要出现-o-私有前缀，这行CSS代码就属于冗余代码；实际上很多项目中-webkit-私有前缀都是多余的，例如自家APP内嵌页使用的是高版本X5内核，类似border-radius，transform等属性完全就可以无私有前缀。

当然，上面的只是举例，大家领会精神，即框架带来冗余是毋庸置疑的，千万不要挑刺，例如有人会说兼容IE的Polyfill可以专门独立出来，PostCSS的私有前缀可以配置。

——

关于性能和体验的牺牲，也不难理解，例如Vue和React等框架，为了让DOM视图渲染不会出错，无需开发者关心，数据变化时候，视图也一定会变化。这是通过牺牲性能和体验带来的开发便捷，例如在Vue和React框架体系中，删除一个列表，直接Splice掉对应数组项就可以了。

但是，实际上在这个交互中，数据变化和视图渲染分开会更好，因为开发者知道哪一个DOM节点不需要，直接dom.remove()掉就好了，性能最高，而且，如果愿意，还可以加点动画，淡出删除，体验会更好，用户可以准确感知具体哪个列表不见了。

所以，如果产品追求极致的性能和体验，框架可能并不是好的选择。

但是，这个世界，有几个产品需要有极致的性能和体验呢，这玩意对技术的要求可不是一般的高。

对于大部分开发者，能够正常完成需求实现功能就已经很不错了，对比一看，Vue和React牺牲的那点性能和体验，完全不值一提。

还有些产品本身对性能和体验要求就不高，例如给自己人用的后台管理系统，像这样的项目，就非常适合使用Vue和React等框架。

对于C端的产品，则可以评估下项目的复杂度、团队成员的能力水平以及老板对产品体验要求到何种程度来决定最终的技术选型。项目不复杂、团队成员水平666，老板对产品体验即为苛刻，这3个条件只要一个不满足，还是老老实实使用主流的框架吧。

因为，虽然主流的前端框架的产品质量的上限一定是受限的，但是保证了产品质量的下限至少是及格的。

——

最后是灵活性的牺牲，例如Vue-cli构建的项目，默认是自动过滤空格的，于是，如果我希望通过设置连续的空格，例如多个 完成某些布局效果，是不行的，这就是框架内部设置带来的灵活性的牺牲。怎么办呢？学习啊，阅读文档，找到对应的配置，进行调整和修改。

类似的场景还有很多，不少创新的实现会被框架制约，这种被条条框框限制的感觉，至少对于我而言，是很不舒服的。

四、框架与成长陷阱

这一部分是我最想重点讲的。

框架的方便快捷会让人进入开发的舒适区，这本身没有任何问题，大家毕竟都在商业公司干活，完成业务开发是首当其中重要的事情，站在公司立场，也希望你使用框架，这样可以以低人力成本、同时保证风险的前提下完成业务开发需求。

于是就进入了一个开发者舒服，公司也舒服的状态。

咦？这个状态不挺好的，有什么问题呢？

问题就在于对于开发者这个个体而言，其本身的专业技能并没有得到真正的成长。

人总是会把框架的能力认为是自己的能力，正如把公司平台的能力认为是自己的能力一样。

举个不恰当的比方。

一张普通的自拍照，通过一键美颜功能变得美美的，请问，是这个人的图像处理技术很厉害吗？显然不是，厉害的是这个美颜功能。

类似的，一个项目，通过框架和工具的能力完成并上线了，请问，是这个人的前端技术很厉害吗？显然厉害的不是个体，而是框架，而是那些工具。

因为个体在其中扮演的角色是user——使用者，正如我们使用手机操作系统，使用一个具体的软件一样，仅仅是一个使用者。

记住我们的职位抬头是“前端开发工程师”，而不是“前端使用工程师”。

归根结底是竞争力的问题

我并不是歧视“使用者”，如果一个人可以把一个框架或者工具用到出神入化玩出花，也是很有竞争力的，但是据我的观察，这样的人很少很少。

大多数的人就是正常使用前端框架，遇到问题社区问问，百度谷歌，或者去官方文档找找有没有解答。

我想很多人会觉得很正常？难道不就应该这样的吗？

是的，确实很正常，成千上万的前端开发都这样，请问，你的竞争力在哪里？

所谓身在庐山不识真面目，我们平常在公司干活的时候，身处那样的环境中，关注的都是业务需求、代码排期、领导同事，是很难站在更高的角度和去和同龄人横向对比的。

于是，很容易把工作上的得心应手，驾轻就熟认为是自己的能力而自我感觉良好。

例如，组长突然说，我们这个新项目用Vue实现。

你之前没怎么用过Vue，然后就从文档开始学习，接着就在项目中用了，用起来还挺顺手，遇到问题都能通过各种方法解决，最后项目成功上线了。

是不是自我感觉会很好，觉得自己很牛掰，没有学过的东西一下子就学会了，然后遇到问题也能解决，是不是觉得自己解决问题能力也很强？

Huge trap——巨大的陷阱！

你其实只是一个普普通通的前端开发者而已，我收到的几乎所有前端简历都有这样的能力，因为，很显然，套用已有的案例，在也有的框架基础上构建东西，包括安装配置的学习，这些都是非常扁平化的技能，需要一点学习能力，但是又不需要非常强的学习能力，只要英文有四级水平，理解能力正常的人都能够驾驭。

比方说我家里领导，学经济的，我花几天功夫手把手叫她使用一个前端框架，跑一个简单的项目，绝对不成问题，毕竟完全不需要关心底层逻辑和细节，这种感觉就像花几天使用教她学习Photoshop的基本操作怎么使用一样！

——

框架的温柔乡陷阱，身在舒适区导致看不到危险，就算看到也走不出去。

这在职业生涯的前期还好，毕竟框架和工具的踩坑经验也是竞争力，基于框架开发的熟练度会有所提高，单位时间产出也会有所进步，时薪也会有对应提高。

但是，坑是有限的，熟练度到了一定程度也会到头，到时候，就会变成3年经验重复使用，离开框架寸步难行的尴尬境地。

前端变化总是很快的。

如果过了5年这个框架不行了，怎么办？换个框架？说得容易，换得了吗？舍得抛弃过去的所有，重新开始吗？就算有心，到时候那个年纪，学得动吗？

铁打的营盘流水的兵，有更便宜、更好用的年轻力胜的新人，为何还需要老旧的你呢？

所谓的35岁职业危机的其实就是这类人可能要面对的问题。

在IT开发领域，有竞争力的开发一定是个creater——创造者，而不是user——使用者。

圈子里常常有人自嘲是“搬砖的”，大家别被忽悠了，那些自嘲搬砖的开发都不是真的在搬砖，那些以为自己在开发的其实真的在搬砖，因为真正意识到自己在搬砖的人都有意无意会学点扎实的基础技术来提高自己真正的竞争力的。

五、业务和个人成长的平衡

公司希望工程师把业务功能开发好，因此，站在商业角度，作为一个有职业素养的工程师，借助框架和工具的力量去完成业务开发是无可厚非，而且推崇的，对于大多数的团队而言，这是最好的决策。

但是，作为个体，一定要有清醒的认识，公司希望你做的，或者说你能为公司做的，并不一定是对个人发展最好的。

就像封建制下地主希望下面的农民好好种地，农民也能为地主种地，但是显然种地对农民的个人发展不是最好的，读书考取功名才是真的出路。

虽然大部分公司都说好好干，不会亏待你，但是设身处地思考下，如果你是老板，下面的开发是一个替代性很强的角色，业界有大把这样类似的角色，就算亏待你又如何？不然怎么会有那么多不涨薪导致离职，然后公司花更多钱找另外的开发的例子呢。

所以，我的建议一向都是两条路走。

一方面借助框架和工具的力量更高效地完成业务开发需求；另一方面意识到框架和工具并不是自己的竞争力所在，要在工作之余不断学习HTML/CSS/JS语言层的知识，学习前端体验、前端安全、前端工程这样的广度知识，深入框架或者工具的内部，站在巨人的肩膀上，看看他们有哪些值得借鉴的地方，努力朝一个创造者发展，而不是满足于使用者。

以及，随着你的专业技术越来越扎实，你会发现个人的专业成长和业务开发是相辅相成的，也就是随着个人的专业能力的提高，框架和工具的使用也会更加得心应手，甚至开始为产品和项目量身定制更加合适的工具与组件。

立于当下，面向未来。居安思危，学习不止。

这样，随着时间推移，你的工作经验和年限就会成为你竞争的资本，无论是收入还是职级就会越走越高，因为你能做芸芸前端做不了的事情。而不会像那些身陷框架陷阱的前端开发那样，工作经验和年限反而成为了自己换工作的的制约因素。

（完）