71–80 of 82 posts
I've tended to avoid both underscore and lodash because they're both in the slew of monolithic pre-npm libraries, however the lazy evaluation looks interesting. I wouldn't be surprised to find a library that handles lazy eval without all the extra features Lodash brings.
Earlier quoted context omitted.
But if you want backward compatibility, you still probably want to use something like Lodash. I'd also argue that Lodash's/Underscore's interface is far better thought out than the standard library. The standard library has so many absurd gotchas, like `["2", "2", "2", "2"].map(parseInt)`. The verbosity of Javascripts lambdas also makes composition of simple parts more arcane looking than necessary, and having a whol…
> But if you want backward compatibility, you still probably want to use something like Lodash. A few years ago, sure, but these days I'd use es6-shim. The code will be shorter, have more documentation around the internet, and when old browsers die you won't have to change anything to be on standard JS.
I followed the link and saw "lodash" for the first time today. Oh, it's a library! With an API! In various formats! I always appreciate it when the top of the project page provides a one-liner explaining just what it is I'm looking at.
See release notes and changelog: - https://github.com/lodash/lodash/releases/tag/3.0.0 - https://github.com/lodash/lodash/wiki/Changelog
I dig laziness, but why is `forEach` lazy? That's the only one that invokes immediately in libraries like Lazy.js.
We switched from underscore to lodash several months ago, and haven't regretted it. The fact that lodash follows semver is huge. Underscore has introduced serious breaking changes in minor point-releases more than once, which is completely unacceptable for a utility library.
Semver isn't a requirement nor be-all-end-all, though.
Earlier quoted context omitted.
That sounds like an interesting approach. Would mind posting an example? (I was wondering what something like Flow.js would make of the code. i.e. Could it make catching those errors easier) Cheers.
Its been a while since I worked with this so this is kind of a shitty example out of the top of my head: If you have code that looks like this: var user_list = fetch_json() .then(function(data){ return data.users }) You can write it more succinctly using a combinator library instead of writing the callback out by hand: var user_list = fetch_json() .then(get('users')) Similar things also apply on other code that uses…
Yes, I think I've come to the exactly same conclusions in the past, both with regard to promises and curried (or partially applied functions for that matter).
This may only apply to me but I've found that without strong, static typing to help out, my brain starts to melt sometimes trying to workout what heavily curried JS functions actual do without using a debugger.
Earlier quoted context omitted.
It's supposed to be better, faster, and stronger (more functions) than underscore. It's also under active maintenance from an enthusiastic dev. Do your own research, but I go with lodash.
Lazy.js claims to be even faster than both with support for lazy evaluation to boot. Not quite a drop-in replacement like lodash is, but I think it only requires a minor tweak.
Is there build of this that lets me require a single function?
I've tended to avoid both underscore and lodash because they're both in the slew of monolithic pre-npm libraries, however the lazy evaluation looks interesting. I wouldn't be surprised to find a library that handles lazy eval without all the extra features Lodash brings.
For the shops who don't live and breath js and whose js work is almost entirely browser-based, these monoliths are great. I, for one, am bummed that the js market is moving away from monoliths. e.g. YUI shutting down.
Substack wrote an article [1] explaining some of the problems that monolithic libraries cause in an ecosystem.