refactor: drop lodash for lib/theme

[SukkaW]

What does it do?

This PR is a part of #3753

How to test

git clone -b drop-lodash-lib-theme https://github.com/sukkaw/hexo.git
cd hexo
npm install
npm test

Screenshots

Pull request tasks

• Add test cases for the changes.
• Passed the CI test.

[SukkaW]

According to benchmark performed by Travis CI, this PR makes generation speed 3x slower.

[coveralls]

Coverage decreased (-0.002%) to 97.265% when pulling 3d3d41b on SukkaW:drop-lodash-lib-theme into 17c2bbb on hexojs:master.

[curbengh]

what about Array.from(new Set(languages.filter(Boolean)))?

I wonder if value() is needed, I can't find it in lodash doc, perhaps it's a function of languages?

[SukkaW]

value() is a lodash method, which is used to get value from lodash wrapped prototype chain.

[SukkaW]

I have make a benchmark at jsPerf: https://jsperf.com/lodash-uniq-vs-javascript-set/1

It seems the diffrence between Array.from & spread syntax is negligible, at least in browser.

[curbengh]

I see.

The travis benchmark showed the spread syntax is the source of regression. I noticed you reverted the last commit; to confirm the source?

[curbengh]

It seems the diffrence between Array.from & spread syntax is negligible, at least in browser.

Similar result in travis too. Can you try revert back to lodash just for this line? to test whether Set() is the culprit.

[curbengh]

But that doesn't explain why lodash is faster in view.js.

---

btw, as for the lib/theme, I think it's fine to use Set() since languages array would only have 2 elements max, so it wouldn't (and shouldn't) make any difference.

[SukkaW]

@curbengh I have done through some investigation about performance of Object.assign. It seems that Object.assign will meet performance issue when facing large object. Even Node.js itself is still using the deprecated util._extend, because it is still a lot more faster than Object.assign.

[SukkaW]

A bit more interesting... Even if I replace Object.assign with lodash.assign, the impact is still there. So maybe the problem is at Object.getPrototypeOf..

[curbengh]

That seems like the last suspect now. what about return Object.assign({}, locals, locals.prototype, data, { ? (source)

[SukkaW]

@curbengh In fact I have tried local.prototype at very beginning but it won't pass the test. The locals here is differentwith a constructor.