JavaScript是一门Web前端的必备语言，尽管这些年es5、6、7、8一步步地增强着自己的原生能力，但是在很多方面，JavaScript还是有所欠缺，没错，就是标准库。 js的标准库提供了非常有限的功能，有些方法甚至令人感到疑惑。比如isNaN：

isNaN(1)
// false
isNaN('123')
// false
isNaN('asd')
// true
isNaN(NaN)
// true

没错，它对参数转成数字再进行判断，很多时候这并不是我们期望的,es6对Number扩展了一个Number.NaN用来判断真正的NaN。

Number.isNaN('asd')
// false
Number.isNaN(NaN)
// true

在忙碌地开发过程中，你会有意识地注意到这种细节吗？还有啥？

arr = [1,2,3]
arr.length = 5
arr[4] = 5
arr.forEach(console.log)
/*
没错它和map一样，会跳过中间的空槽
1 0  [1, 2, 3, empty, 5]
2 1 [1, 2, 3, empty, 5]
3 2 [1, 2, 3, empty, 5]
5 4  [1, 2, 3, empty, 5]
/*

通常这都是历史遗留问题，考虑兼容性问题，不能被简单修复。

原生代码还真是够了，我只要lodash，千万级的工具库。

lodash提供了大量的工具函数用来加强JavaScript的语言功能，每个函数都是精心优化的，可以放心使用而不用关心性能、稳定性问题。比如原生map就没有预分配数组大小，在遍历的过程中还要扩容，在大数据集上可能会有上10倍的性能差异。

用几个代码来感受一下lodash的魅力。

获取数组的最后一个元素

// plain
arr = [1,2,3]
a = arr[arr.length - 1]
// _
_.last(arr)

非常简单的例子，为什么要用lodash，因为它具有语义！为什么要为了拿数组最后一个元素写arr[arr.length - 1]这种难看的代码。

提取对象数组的某个值

var users = [
  { 'name': 'barney' ,'age': 21 },
  { 'name': 'fred', 'age': 22}
];

// plain 
users.map(user=>user.name)
// _
_.map(users,'name')

为什么要写不必要的lambda函数？

判断类型？

// 原生命令式判断
typeof 1 === 'number'
typeof 'haha' === 'string'
typeof true === 'boolean'

// _
_.isNumber(1)
_.isString('haha')
_.isBoolean(true)

为什么要慢慢敲typeof、===、还有一个字符串（后面这个字符串有敲错的可能）？从_里拿出来的方法，难道不香吗？

鲁棒性

arr = [1,2,3]
arr.map(i=>i**i)
arr = null
arr.map(i=>i**i) // TypeError

_.map(null,i=>i**i) // --> []

这个代码的意义是什么？前端的页面呈现很大程度上取决于后端的数据接口，然后问题来了，后端一定会返回给你数据么？数据格式一定符合预期么？现实项目中，后端有各种理由搞出问题，没有数据返回null这种就XX的很常见，你能够保证自己对每个地方都做了检查并合理处理？像上面的TypeError很可能就是一个页面崩溃。而使用lodash你可以跳过这个判断，页面不会崩，你只需要在请求管理的层面上去做异常判断，报警处理，而lodash写的逻辑不会崩，就是看不到东西而已。

分组、按多个键排序、组装对象

原生走一个试试？算了吧我累了。

我最喜欢的当然是它的链式调用。

_(data)
    .filter(...) 
    .map(...)
    .groupBy(...)
    .mapValues(...)
    .value()

_(data)将数据包装进的一个lodash对象中，这个对象可以调用一些方法作用在数据上，并返回一个新的lodash对象继续调用方法，最后一个value()收尾拿处理结果。

可以看到lodash在表达数据处理、转换的时候非常的简洁，而这却是JavaScript原生缺少的能力。