Lists of JavaScript methods which you can use natively • Hacker News Board

Re: Lists of JavaScript methods which you can use natively

#131

Post by moron4hire » Fri, Jul 01, 2016, 4:06 PM UTC

gnaritas wrote: post #125

moron4hire wrote: post #117

Earlier quoted context omitted.

No, why would you? It's just a loop. Not all code deduplication is a good idea.

> No, why would you? Because he's a better programmer than you are, and he knows it. > It's just a loop. There are many kinds of common patterns in loops, abstracting them into resuable higher order functions, aka a collections api is rather basic functional programming; "it's just a loop" is a blub phrase of someone who doesn't see the point because they have tried it long enough to understand the value in a differe…

I know it's currently thought as so, but functional programming is not the be-all, end-all paradigm. If you've been around for a while, you'd have seen the ebb and flow a few times already.

Re: Lists of JavaScript methods which you can use natively

#132

Post by swang » Fri, Jul 01, 2016, 4:12 PM UTC

frostik wrote: post #11

There's a huge gotcha: _.map, _.forech, ... can iterate over objects (often used as associative arrays) - Native map can't. At some point you'll need lodash and co again - at least for convinience.

the repo already points that out.

>Important: Note that the native equivalents are array methods, and will not work with objects. If this functionality is needed, then Lodash/Underscore is the better option.

Re: Lists of JavaScript methods which you can use natively

#133

Post by runarberg » Fri, Jul 01, 2016, 4:13 PM UTC

frostik wrote: post #11

There's a huge gotcha: _.map, _.forech, ... can iterate over objects (often used as associative arrays) - Native map can't. At some point you'll need lodash and co again - at least for convinience.

We already have Object.keys()[1], and Object.values()[2] and Object.entries()[3] are in the stage 4 proposal[4] and should be safe to polyfill.

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

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

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

[4]: https://github.com/tc39/proposal-object-values-entries

Re: Lists of JavaScript methods which you can use natively

#134

Post by skrebbel » Fri, Jul 01, 2016, 4:27 PM UTC

ascagnel_ wrote: post #64

skrebbel wrote: post #52

Earlier quoted context omitted.

The Ramda API changes with every version. If you don't pay attention for a few months and accidentally upgrade (Ramda doesn't seem to want to do Semver, I'm not sure why), then suddenly half your code is broken. We depend heavily on Ramda and I like its API better than Lodash and friends (it's more guessable, more consistent), but with the changes it keeps having I regret choosing it. Our core product is currently on…

Technically, Ramda is using semver; 0.x releases are used for when the API is still changing substantially[0]. [0] http://semver.org/#spec-item-4

Ahyes, good point. In the Ramda authors' defense, they never claimed it to be good for anything production level.

Re: Lists of JavaScript methods which you can use natively

#135

Post by e28eta » Fri, Jul 01, 2016, 4:39 PM UTC

sly010 wrote: post #87

EliAndrewC wrote: post #76

Alternate title for the article: "Lists of lodash features replaced by ES6 if you don't mind throwing an exception when given invalid input such as null or undefined". All kidding aside, a lot of our lodash code ends up looking something like this: function (xs) { return _(xs).pluck('foo').filter().value(); } That code clearly expects that xs is an array of objects. However, we might occasionally end up with xs being…

> if you don't mind throwing an exception when given invalid input such as null or undefined That's exactly what I would expect. If only everyone always thrown an exception on any undefined, life would be so much better.

Something I find very interesting about Swift is it's complete reversal of opinion from Objective-C on this topic.

Obj-C basically has the behavior GP wants: call a method on nil (aka: null) and it returns nil/false/0. It's possible to write concise & correct code that relies on this behavior.

Swift turns it into a fatal runtime error, and uses the type system to help prevent it from happening.

I think there's room for both (probably not in the same project though!). A lot of successful projects have been written in Obj-C, and some of them rely on the behavior of nil.

However, it's harder to maintain the code. You have to reason about whether nil is possible and does the code do the right thing, or did the original author forget to consider the possibility? It's really nice when the static type system forces the programmer to be explicit.

Having used both paradigms, I honestly don't know which I'd prefer for JS - especially considering it's lack of static typing. It might depend on whether I was writing application or library code.

Re: Lists of JavaScript methods which you can use natively

#136

Post by dchest » Fri, Jul 01, 2016, 4:39 PM UTC

randallsquared wrote: post #130

yoha wrote: post #119

Earlier quoted context omitted.

This is effectively wishful thinking. If a bug causes an unexpected undefined value, it will lead your code to an undefined behavior. It might work well 999 times and wipe everything on the 1000th execution. Thankfully, Javascript is mostly limited to web browsers. Exceptions make it so that nothing unexpected happen. This is especially useful when you do not know the whole codebase. Of course, there are many cases w…

> Exceptions make it so that nothing unexpected happen. No, it makes it so that your program surprises the user by crashing, which is (hopefully!) pretty unexpected. Unless, of course, you use the exceptions to provide some sane default code path that handles the problem, but that's exactly what lodash is doing for you in this example .

Crashing is exactly what the correct program should do if it hits undefined behavior.

Re: Lists of JavaScript methods which you can use natively

#137

Post by acbabis » Fri, Jul 01, 2016, 4:43 PM UTC

I don't use Lodash, but I remember reading that it does lazy evaluation[1]. For example, if you map an array, then take the last 3 items, it only calls the map function for those 3 items.

Does anyone know if V8 can do any optimizations like this for native Array functions? That would be a good thing to know before downloading lodash.

1) http://filimanjaro.com/blog/2014/introducing-lazy-evaluation...

Re: Lists of JavaScript methods which you can use natively

#138

Post by barrkel » Fri, Jul 01, 2016, 4:45 PM UTC

jnbiche wrote: post #113

squeaky-clean wrote: post #104

Earlier quoted context omitted.

Seriously. A really common example, ever have a website that completely fails to load when you're running adblock? Would you rather have a blank page, or a 99% functional website with a couple of error messages in the console?

The answer is: that's an expected failure, so you make the error handling explicit by catching the error and taking care of it appropriately (including proceeding to the rest of the page load, naturally). Implicitly handling errors behind JavaScript's loose typing rules is a recipe for disaster.

Explicitly handling errors is almost always a bad idea, no matter what programming language it is. There are very few errors you can reasonably handle, and they must be designed for. It's specific application domains that need different handling strategies: e.g. embedded, device drivers, software that's trying to maintain some very strict invariants. A web page isn't usually one of them.

Usually errors should be sent up the stack to the request / event loop and logged / telemetry / etc.

The question here is something different, though. It's what should be considered an error, vs what should use the null object pattern. I don't think anyone can make a categorical judgement on which is better without context. It's suggested here that the null object pattern implemented by lodash is desired; I don't think it's wrong in principle to rely on it, as part of a cohesive design - e.g. it's used in such a way that it doesn't make development or finding bugs harder than necessary.

Re: Lists of JavaScript methods which you can use natively

#139

Post by RobertKerans » Fri, Jul 01, 2016, 4:53 PM UTC

hkjgkjy wrote: post #9

I understand why, and once upon a time I was the guy who would commit code where I replaced jQuery and underscore (at the time) calls with native calls. It works, and is totally fine. But what was the point? Some kind of optimization? It was pretty pointless in hindsight and just made my coworkers trouble. Now all my JS code is Ramda/lodash all the way, and it's great (although I opt for Clojure/script when possible)

The main point of this (and similar - you-dont-need-jquery et al) is [should be] for those people who need a tiny piece of functionality that would take maybe a couple of lines of code, and import a dependency to deal with it. That's not too unusual - in a similar vein I spent a fair part of last year tearing hundreds–thousands of Kb of jQuery plugins (jQuery UI put in for one thing was pretty common) out of Rails apps because of this.

Lodash I'd say is unequivocally great (particularly the FP version, which I prefer to Ramda now), but these kind of posts aren't really for those who really need the full suite of functionality. Or at least it's very useful for those starting out on a project, who can then add in Lodash/whatever if/when the need arises, rather than reflexively adding it at the start.

Re: Lists of JavaScript methods which you can use natively

#140

Post by spaethnl » Fri, Jul 01, 2016, 5:16 PM UTC

acbabis wrote: post #137

I don't use Lodash, but I remember reading that it does lazy evaluation[1]. For example, if you map an array, then take the last 3 items, it only calls the map function for those 3 items. Does anyone know if V8 can do any optimizations like this for native Array functions? That would be a good thing to know before downloading lodash. 1) http://filimanjaro.com/blog/2014/introducing-lazy-evaluation...

This cannot be done with native array functions as they exist now.

The reason Lodash is able to do this is because the collection is wrapped in an a special object that keeps track of all of the functions you call on it. Those functions don't run until you call .value() on the whole pipeline that you have setup, and then the optimization happens.

Note that this requires a separate API. One API returns your results immediately, the other (lazy) API instead returns a wrapper object after each call without yet doing the mapping/filtering/etc, ready to add more instructions to the pipeline that you must ultimately call .value() on in order to actually run.

Native functions don't have this separate lazy API that does the wrapping with this special object, and don't have/return an object with a similar .value() method.