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

Re: Lists of JavaScript methods which you can use natively

#141

Post by shados » Fri, Jul 01, 2016, 5:31 PM UTC

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…

That's partly an argument for Flow or the eventual strict null flag in TypeScript.

That being said, that was my first reaction too. Null safe code is so important. How you do it (be it with Flow, Lodash, whatever), that doesn't matter, but I do find myself leaning toward libraries over native when payload size doesn't matter too much because of this.

A combination of Flow, Ramda and Sanctuary (for Maybes) if you want to be a bit more niche can give some pretty amazing results.

Re: Lists of JavaScript methods which you can use natively

#142

Post by fbreduc » Fri, Jul 01, 2016, 5:36 PM UTC

This seems like a great post on why you should be using lodash.. especially all those IE unsupported things. Like mentioned in the comments, it's not just about having one or two of these features, it's about how they compose so nicely in lodash

Re: Lists of JavaScript methods which you can use natively

#143

Post by shados » Fri, Jul 01, 2016, 5:37 PM UTC

skrebbel wrote: post #52

klibertp wrote: post #50

The need for Lodash and Underscore is diminishing, but not because of JS getting native support for a subset of utilities, but because there are already better alternatives. Utility libraries like Ramda[1] or pointfree-fantasy[2] with related modules which offer a better support for FP idioms and more useful higher-order functions are what made me drop Underscore. I think that, with a language with such tiny stdlib,…

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…

Lodash does a good job with version number, but upgrades are pretty damn dangerous (unless you feel with sticking to the same version forever).

The worse example was when they changed clone to be shallow from deep. Most code worked (shallow clone is a common case), but not quite all of it. Good luck finding which part of your code depended on deep cloning, even with tests.

So don't think you'd be able to upgrade much more often.

Re: Lists of JavaScript methods which you can use natively

#144

Post by shados » Fri, Jul 01, 2016, 5:39 PM UTC

jdd wrote: post #91

klibertp wrote: post #50

The need for Lodash and Underscore is diminishing, but not because of JS getting native support for a subset of utilities, but because there are already better alternatives. Utility libraries like Ramda[1] or pointfree-fantasy[2] with related modules which offer a better support for FP idioms and more useful higher-order functions are what made me drop Underscore. I think that, with a language with such tiny stdlib,…

Lodash v4 has support for FP syntax/modules – https://github.com/lodash/lodash/wiki/FP-Guide

It's really, really nice, but missing a lot of stuff Ramda has to get serious about FP. For example, lenses-like constructs in lodash are pretty damn limited (you have get/set, but...)

Re: Lists of JavaScript methods which you can use natively

#145

Post by shados » Fri, Jul 01, 2016, 5:40 PM UTC

eknkc wrote: post #12

have_faith wrote: post #3

Instead of searching for the compatibility of each individual function I would much rather just use a custom build of Lodash with the collection of functions I need (which can even be handled by your build process now and some tree shaking). And I get a lot of utility functions with it too that I use a lot like Throttle and Debounce.

Might be a good idea to use a polyfill (like core-js) to ensure the api exists. On modern browsers it would just use the native impl. Not much to gain though. Just importing lodash works fine.

core-js is the truck factor single point of failure of modern JS development.

There's not many good alternative (there's a lot of alternative, but none that are as comprehensive), essentially has ONE person really working on it (and threatening to stop imminently), and the code is unreadable, so hopping into it once said maintainer goes poof will be tricky.

We still depend on it (no great alternative), but it's a ticking time bomb IMO.

Re: Lists of JavaScript methods which you can use natively

#146

Post by jdd » Fri, Jul 01, 2016, 5:53 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.

Many times folks understand that values can be nullish. Libs like Lodash treat them as empty collections to avoid repetitive nullish check scaffolding.

Re: Lists of JavaScript methods which you can use natively

#147

Post by jdd » Fri, Jul 01, 2016, 5:54 PM UTC

shados wrote: post #144

jdd wrote: post #91

Earlier quoted context omitted.

Lodash v4 has support for FP syntax/modules – https://github.com/lodash/lodash/wiki/FP-Guide

It's really, really nice, but missing a lot of stuff Ramda has to get serious about FP. For example, lenses-like constructs in lodash are pretty damn limited (you have get/set, but...)

I donno, Lodash is missing 200 Lodash ones.

Re: Lists of JavaScript methods which you can use natively

#148

Post by spankalee » Fri, Jul 01, 2016, 5:55 PM UTC

e28eta wrote: post #135

sly010 wrote: post #87

Earlier quoted context omitted.

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

There is room for both, but it should be explicit in my opinion. Dart for instance has null safe operators

  // not null-safe:
  foo.bar.baz();

  // null-safe:
  foo?.bar?.baz();

If your type system also does null tracking, then you can see where you might have null values and decide to use the null-safe operators.

Re: Lists of JavaScript methods which you can use natively

#149

Post by geofft » Fri, Jul 01, 2016, 6:12 PM UTC

dchest wrote: post #136

randallsquared wrote: post #130

Earlier quoted context omitted.

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

What?

1. Where did anyone say we were hitting undefined behavior? We're hitting a well-defined JavaScript value whose name is "undefined".

2. Why is crashing correct? Don't answer in terms of language specs, answer in terms of desired behavior for whatever you're trying to do with the program. Software engineering is a tool for accomplishing other things. Sometimes, yes, software crashing is the right thing in service of that other goal. But not always.

Re: Lists of JavaScript methods which you can use natively

#150

Post by eknkc » Fri, Jul 01, 2016, 6:16 PM UTC

jdd wrote: post #111

eknkc wrote: post #14

Earlier quoted context omitted.

(arr || []).filter... Is something I do when I'm not sure if the array is null or not. Looks shitty but works fine. (Now if arr is not falsy and not an array either, this blows up. But I don't know what lodash does then too) To be honest, I'd rather check / handle nulls rather than to rely on an external library semantics. They might also change it tomorrow and upgrading would be a pain.

The language changes too. In ES5 `Object.keys` throws an error for `Object.keys('abc')` but in ES6 it returns an array.

Still a pretty conservative breaking change. Something you'd expect from a committee of people. Lodash has more wiggle room to make absurd changes in future.