前端为什么要学习js

你既然学习了前端，你就会发现前端的确只是完成了页面的展示效果，给文字和图片加上特效。

按照这个思路来说，后端只是把数据按要求关联起来，在数据库里面增删改查。然后接收一下前端的请求，再返回。

贸然给一件事物定了特性，轻视它，那么任何东西都不过如此。

在2009年之前，前端就是简单的这些特效，页面看着就是一套PPT模板。这种方式持续了很长时间。因为以前的B端数据量不大，页面都是整体刷新。

随着智能手机的普及，可以看到用户越来越喜欢B端，我们将很多复杂的C端功能搬到B端上，产生大量用完即走的应用（QQ空间/贴吧，回复及时可见）。这样简单的数据显示和copying and pasting from Stack Overflow的方式开始不奏效了。

人们开始发掘前端的力量了，怎样操作局部页面

js也开始慢慢的发光发热。

一旦我们对信息/内容进行实时更新时，就会设计到数据的大量提交/下载，高频的数据变动导致view视图的移动。数据的流动又带来了大量状态变化（准备提交，提交成功，开始下载，下载成功），如何控制状态成为了问题。

复杂的应用一般都会拥挤，用户可选项也多，怎么解决高并发和多选择的情况，减少页面的刷新等待时间成了一个关键问题。因为这个关系到用户量的流失，太卡了，不等了。

复杂的应用，代码量肯定不少，淘宝的购物车代码估计就有几千行（记住每个商品，价格、图片、、、），怎么有效的管理代码又是一个问题。
因为程序是一个团队的共同协作，你写的代码不仅健壮性要强，还需要简洁，能保证其他人读懂你的意图。

❤️ 程序员【代码管理】工具介绍❤️，热门语言更新这么快，你绕不过这一关的！

你在开发复杂的应用的时候，上线的版本肯定不一样，开发的要求是易于调试，便于观察。
上线的要求是运行稳定，不卡顿。
这样你就需要一个工具来帮你解决最后上线的问题。

深入学习js有什么用处？

讲到这里，你大概明白了，面对复杂应用开发，上面的问题，都需要用到js。

比如一个简单的例子，js中，你看完入门的原型链，作用域，一些对象方法，闭包，this之后，开始写代码。
你发现有时候你写的代码居然会具有多义性，也会是不确定的，检查着，然后发现是你在异步获取时，没有处理好程序的顺序，导致竞态的发生，于是你开始使用回调方法来处理这种问题，可是写着写着，你就爆炸了，你写出了大量的回调函数嵌套，里面是你的一大堆程序逻辑，乱糟糟的。

你开始还觉得没什么，直到有一天，出事了，老板跟你说，你写的程序多扣了用户的money，你要疯了，怎么会这样，于是你检查代码，发现完全看不懂。直到很多天后，终于搞好了，你下决心开始用promise简化代码，于是你的代码中出现了漂亮的链式调用，没有复杂的回调嵌套了。

很开心对不对，可是到某一天产品改需求（增加一个功能）了，你需要在某个promise（实例）过程中，做一件事情，可是promise中断不了。
这可怎么办，不想从class开始修改，于是你引入了generator生成器，使用协程来处理这种问题。

这样就很完美了，可是这一天，又发生了用户钱被多扣的问题，我艹，怎么回事，你发现是你用的第三方promise库里的测试代码多运行了一次函数。
这样就牵扯到了第三方库的信任问题，你不能把控制权反转给不信任的库，你需要自己信任的程序把握程序控制权，做好明显的区分！于是你又开始改代码。

耐心的折腾之后，你终于成为了前端leader，然后你的小兵在引用你的库的时候，出了一堆错，心里默默的骂了一句：“智障垃圾老大”。
到后来你发现你写的代码库，非常信任开发者的输入，导致某些人在部分函数输入时，参数的类型是错误的，你又开始改代码。。。

if (!source && typeof source !== 'object') {
  throw new Error('error')
}

直到有一天，后端出了事，你要去对接，要学习python。。。。发现，咦，这个语法真他妈像js，这个也像，嗯，简单。。。。然后很快解决了问题。。
看完上面的故事，有没有觉得，想升职，不深入学习js大概根本是不可能的吧。深入学习了一门语言，然后入门其他的语言更是简单。

最后

粉丝群
大概你进入前端这个门，就会知道，你的确应该被称为工程师，至少自己是这样称呼自己的。因为你正在做的是一个工程，而不是简单的写代码。