Lodash 4.0.0 is out | Hacker News Reader

Lodash 4.0.0 is out

github.com

303 pointsbpierre96 comments

Kudos to John-David Dalton for making such an awesome lib and being such a positive force behind it for so long! I've reached out to him multiple times on Twitter and he's always been quick to help!

He should definitely write a post on how he stays productive and motivated to work day-in and day-out on one project. Really inspiring!

Could not agree more. I have opened multiple issues on GitHub and he is always quick to reply. It takes a lot of diligence to maintain an almost always empty issues list on GitHub.

Thanks to him indeed. Thanks for his work (and research) on sandboxed natives, FuseJS, NWMatcher, LoDash and so many more awesome projects. He never stopped pushing that envelope and we're reaping the benefits now.

Indeed, John-David Dalton, together with Dan Abramov and others have been great in the JS community. Kudos!

You'll be interested to know that Dan Abramov is on the JavaScript Air panel. This is relevant because of this: https://news.ycombinator.com/item?id=10909199 :-)

Agreed. That's why I invited him on the JavaScript Air show. The live video broadcast podcast all about JavaScript and the web platform. He'll be on live on March 2nd: http://jsair.io/lodash

Feels good to see a JS lib last that long and still be actively maintained, deprecating obsolete features and adapting to the new ways we use our browsers without breaking BC (or else explaining how to migrate).

Coming from Symfony (PHP), this just feels right: keep moving but make it easy to follow along.

Is this a Symphony thing or are external dependencies significantly more reliable in the PHP ecosystem in general? Last time I wrote PHP was 9 years ago and those times everyone I knew just copy-pasted all the external code they found. I know that package managers are the thing now and I'm using nuget for my .NET projects (and npm, which is a must if you do any front-end dev), however, I feel like I'm having more dependency management issues than the good ol'days in spite of using a language with static type checking.

I'm not saying "vendor everything" but maybe some vendoring helps, especially when every package author seems like they've taken the philosophy of "doing one thing, doing it well and breaking everything on every update".

I find external dependencies much more reliable in the PHP world than JS. Most packages try to follow semver. Composer is one of the best dependency manager tools I've used and you can easily lock down dependency versions so you can install from a state which you know works.

People hate on PHP but there are a lot of quality packages out there and Composer is definitely considered best practice by most developers now.

The Symphony team are extremely good at moving forwards while not breaking everything behind them, they also have (frankly compared to nearly everyone) insanely good documentation.

I'm primarily a Laravel user (it's a better fit for the stuff we do) but I have huge respect for the Symfony guys as their components make PHP much nicer to work in.

I would say it is particularly true for Symfony, but other package maintainers, like Tailor Otwell for the Laravel framework, do an impressive job at documenting how to upgrade to newer versions and keeping BC to a minimum.

For instance, I just recently upgraded from Symfony 2.7 to 2.8. The upgrade path was pretty much "Remove all deprecated warnings, upgrade your Symfony package, done". The same upgrade path is used from Symfony 2.8 to 3.0, which makes it really easy to upgrade.

Symfony, as most PHP dependencies, can be installed via the "composer" package manager, which is pretty much the only package manager that is used in the PHP community, it seems. As dchesterton says, it is a very good piece of software.

I remember reading sometime ago that the creators of LoDash strived to maintain drop-in compatibility with Underscore, and that if breaking changes between the two libraries were to occur, an announcement would be made. I can't find the initial statement, so I wonder if the developers are still attempting to maintain this?

There are some small incompatibilities: https://github.com/lodash/lodash/wiki/Migrating

They're still mostly drop in though, most lodash differences are extras rather than modifications.

I think it's time to check out a jquery alternative. My recent projects are basically only using deep copies and some semi-complex selectors. lodash + querySelector should cover pretty much everything at this point.

Have you checked out Lea Verou's Bliss.js? http://blissfuljs.com/ It's super minimal and basically relies on querySelector. Give it a whirl and see if it fits your needs.

Cool! I'll check it out thanks. Deep Clone is required though, I'll poke around.

lodash.cloneDeep is available as a standalone npm module (as are all lodash functions).

It clocks at 2.5KB mingzipped, after browserification.

There are probably lighter implementations.

Very cool...been looking for something like that for a project I am working on right now, as a matter of fact.

I've seen projects that use jQuery just for the selector part, nothing else is used. Selectors are a core strength of jQuery. With document.querySelector, I wouldn't even include jQuery in a new project. `window.addEventListener` isn't much different than .on

It's used out of convenience, and avoiding errors. jQuery selectors are stupidly simple to do complex stuff with. I just wish they had a jQuery.selector distribution.

It does! https://github.com/jquery/sizzle/blob/master/dist/sizzle.js

I looked at sizzle, but is it just me, or is the syntax not anywhere near as convenient as jQuery? Doesn't seem like it's making anything easier.

I mostly use it because it's a dependency in so many other stuff that I end up using in my projects.

look at

https://github.com/finom/bala

(or balalaika by same author)

also sprint.js and cash.js

Not to be forgotten is d3, which in addition to selectors allows you to very easily bind data to the DOM. And with the big 4.0 refactor that is underway, you can very easily pull in the selection[1] stuff only.

[1] https://github.com/d3/d3-selection

At 4.4KB (gzipped), it seems like a really good alternative to jQuery. Thanks for the suggestion!

The FP stuff is huge. I've been using Ramda which is great, but often feel like I'm out on a limb with it.

upvote for Ramda, which I happily use everyday ( be it on server or front end)

Not sure if this is a dumb question but I haven't been able to find an answer anywhere.

I currently use underscore 1.8.3. Can I just swap lodash in, or is refactoring involved? I know it's a fork, and I want to move over, but was curious if anyone know off the top of their heads if a lot of work as involved.

I'll put this here just in case no one comments.

https://lodash.com/docs#forEach

http://underscorejs.org/#each

If I'm correct, you're showing this as a counter example to prove that the two have incompatible APIs and are thus LoDash can't be used ad a drop in replacement. However, Lodash does alias it's 'forEach' function with 'each', so this wouldn't be an issue?

Yeah, each and forEach are aliases in both lodash and underscore.

underscore.each has an optional 3rd parameter (context). lodash.each does not. If you depend on that 3rd parameter, you will be in a world of pain if you drop-in lodash. In fact you'd be better off if there was no alias because you would catch the problem sooner and have to think about the API differences when fixing it.

To be fair, that context parameter has only just been removed as part of 4.0.0. Instead they recommend you change your code to be of the form:

    _.each(collection, _.bind(function, context))

Which actually seems a lot more correct than some arbitrary context parameter

How is it arbitrary? It's part of the ES spec.

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

I'm honestly curious why this is being removed?

Ah, I actually didn't realise this was the case, I've always used `.bind(this)` for this kind of thing.

I haven't looked over the changelog/breaking changes for 4.0.0, so this may not encompass everything there, but there are a few changes you need to be aware of. How hard it is depends on which functions you use currently, but I doubt it would take more than an hour of find-replace work. They are listed here : https://github.com/lodash/lodash/wiki/Migrating The ones that affected me the most were the changes to the overloaded _.first, _.last, etc, but YMMV.

I've done similar refactorings in the past (somehow my fingers only remember `npm install underscore`) and for me it has always been a drop-in replacement. However, as others have pointed out, it does depend on how much functions you are using and from my experience the whole thing should not take long.

Well, do you have tests? It would take 10 minutes if you are well-covered. Otherwise, I'd go through each usage.

Lodash v1 was a drop-in Underscore replacement.

Lodash v2 was not but offered an lodash.underscore.js build.

Lodash v3 dropped the compat build in favor of using individual lodash modules until you're able to transition

Lodash v4 continues the view of v3

I'm curious why the `thisArg` parameters were removed? I dug through some of the PRs and commmits but was unable to find any specific conversation.

It seems odd since the `Array.prototype` methods include it.

https://github.com/lodash/lodash/commit/454aca7003e14994e7b9...

Was wondering the same, and I can't think of a better reason than the popular adoption of ES6 arrow functions, since the thisArg was mostly used to pass in 'this' as a value.

It was removed because it added extra complexity for method implementations and was used very little. Folks now can use `_.bind`, or `Function#bind`, or arrow functions.

Whatever happened to underdash (https://github.com/underdash/underdash)?

The second paragraph mentions/links to underdash: "The year was also one of collaboration as discussions began on merging Lodash & Underscore."

Exactly, "began" - I expected next major version to actually be a merge. Hopefully they can now focus on that...

As I see, lodash is a big fan of renaming functions.

(In any case, this library saves me a lot of manual labour, headache + can write in a functional way without poor performance.)

why drop bower support damn it!

Yeah there is no need to drop bower support. I prefer bower over NPM. I don't understand this. Great work by the way.

I think the thinking behind dropping the support is something like this:

I use browserify/webpack/node and npm is great. I wish more libs that I use were also on npm so that I wouldnt have to fork/shim them. How can I force other people to use npm? Maybe if I drop bower support for my awesome lib that everyone uses, other libs will follow suit, or perhaps the users will see the light and stop using bower because it sucks.

Lodash dropped bower support in favor of npm because "16% use bower vs. 76% npm for AMD packages": https://twitter.com/jdalton/status/677323442488672257

...according to a twitter poll on a personal account :P

I avoid bower wherever possible, but removing support does smell a bit like an activist move. There may be more to the story, though.

The poll was, should it be dropped, given that fact. The fact was not the poll result.

Given that there were 14825158 downloads of lodash from npm last month, that implies that there were over 3M downloads from bower. That's a lot of people to throw under the bus.

For what was a single 19 line JSON file: https://github.com/lodash/lodash/commit/3b86574b4da0828f6afb...

According to bower stats over the last 7 days lodash was installed 23 times compared to 4 million npm downloads & 181 new npm packages depending on it.

http://bower.io/stats/

http://npm-stat.com/charts.html?package=lodash

https://gist.github.com/anvaka/8e8fa57c7ee1350e3491/revision...

Sounds broken. My team alone would have installed it more times that that.

¯\_(ツ)_/¯

After thinking about it a bit more, the only reasonable conclusion I can come to is the following:

It's the number of times users actually typed

    bower install lodash

i.e. adding it to a project that didn't already have it, as opposed to just running bower install on a package which uses lodash.

Would also explain why despite bower itself being installed 37000 times in the last 7 days, the most installed package is only listed as 100 or so times.

You'd even need multiple busses ;)

Why did you shorten one number but not the other? 14.8M via npm vs 3M via bower

One is exact, one is approximate

Plenty of people don't use AMD packages at all, wtf?

If more major libraries drop support for bower, it might (hopefully) die soon. What does bower do better than NPM?

Well, I haven't used npm for css packages yet, but presumably it's okay with webpack/brunch etc.

Its great with everything. Frontend / backend, etc. When I removed bower from our app last year, adopted Webpack and migrated everything over to NPM it dramatically simplified things.

For Brunch, looks like [initial, probably v buggy] NPM stuff went into master about 10 days ago.

I've been using npm support in Brunch and so far so good.

Ah, that's good to know; I'd been sticking to Bower for Phoenix' front end stuff, might start looking at migrating them to NPM if Brunch support is stable now.

JSPM!

It works a lot like NPM but is specifically intended for use with front-end modules.

Features:

- uses System.js (a polyfill for the future ES6-module-loader spec

- supports CommonJS, AMD, and UMD formats

- has plugins for importing other types (ex css)

- support Typescript/Traceur/Babel out of the box

- uses a flat dependency structure (ie like NPM v3)

- can generate bundles and self-executing bundles (incl tree shaking and minify)

- tracks specific versions of dependencies

Unlike NPM, module installation doesn't depend on packages published to a central registry. It can install versioned modules directly from GitHub and NPM. The registry it uses is nothing but GitHub repo with module-to-repo mappings and compatibility shims.

Here's the link: http://jspm.io/

Lodash is already included in the registry: http://kasperlewau.github.io/registry/#/?q=lodash

Personally I'll stick with RPM for all my JS packaging needs.

What do you use to polyfill the browser to support RPM? :)

yum makes rpm easymode!

Why?

It doesn't cover any of the functionality that JSPM provides and publishing modules as RPM only makes them available to (at most) 1%-2% of users.

JSPM is written in Node and available via NPM. So... it works on pretty much anything out of the box.

npm can install directly from GitHub:

    npm install visionmedia/express

Or any git repo:

    npm install git+https://git@github.com/visionmedia/express.git
    npm install git+ssh://git@github.com/visionmedia/express.git

Oh... Awesome. TIL, I guess.

Thanks for the tip. I wish my comment wasn't locked in already so I could correct the misinformation.

Bower is no longer actively maintained: https://github.com/bower/bower/pull/1748

Bower is very actively being maintained: http://bower.io/blog/2015/bower-alive-looking-contributors/ and just read https://twitter.com/bower or check https://github.com/bower/bower

Although there is a rationale for converging to npm, the tl;dr regarding bower is that it's not cool any more.

I loved bower and really preferred it in regard with npm for frontend modules. However more and more packages went to npm-only and we completely switched to npm for all.

Looking back, I am glad since it's just a nightmare to deal with dozens of package managers. Because bower was installed via npm, we had npm installed already and just skipped the bower part.

How does this compare to lazy.js?

oh nice, they dropped ie9 support!

oh no, so many breaking changes that I cant use it!

> so many breaking changes that I cant use it!

Isn't that the point of a major version bump? It's not like being mad at 3.11.0 wrecking everything.

Majors, especially majors that are coming often with no lts for older versions, should make minimal breaking changes.

The whole point of major version bumps (in semver) is to allow of these kinds of breaking changes. When should these changes be made if not during a major version bump?

i wasnt trying to complain about breaking changes, i was saying that i am sad that i have a cod base which cannot use this. I am sure many people are in the same boat

Adoption is doing pretty well. In just over 2 weeks since its release lodash@^4.0.0 is in the top 50 most depended on npm packages.

https://www.npmjs.com/package/lodash-migrate ?

From my understanding "dropping support for IE < 9" means dropping IE8 not IE9.

Personally I would not mind not having support even for IE9. I know, I am one of the lucky few.

Reply on news.ycombinator.com