Live data from Hacker News

Lodash 4.0.0 is out

github.com

81–90 of 102 posts

Re: Lodash 4.0.0 is out

#81

Earlier quoted context omitted.

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?

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

Re: Lodash 4.0.0 is out

#82

Earlier quoted context omitted.

> 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?

Re: Lodash 4.0.0 is out

#83

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...

Re: Lodash 4.0.0 is out

#84
post #44

Earlier quoted context omitted.

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.

Re: Lodash 4.0.0 is out

#85
post #81

Earlier quoted context omitted.

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?

Re: Lodash 4.0.0 is out

#86
post #71
post #65

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 dep…

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.

Re: Lodash 4.0.0 is out

#88
post #71
post #65

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 dep…

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.

Re: Lodash 4.0.0 is out

#89
post #87

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.
Post reply on HN