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

Re: Lists of JavaScript methods which you can use natively

#81

Post by epmatsw » Fri, Jul 01, 2016, 1:50 PM UTC

vatotemking wrote: post #68

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)

Im quite out of the loop in the JS world and wanted to ask what happened to underscore? It used to be the de facto utility belt for JS.

Two things from my memory. 1. They hit some bad PR when they pushed a badly broken release in a point update. Turned out that their testing was not robust, while Lodash's is excellent, which further hurt them (this is when I first remember hearing about Lodash) 2. Lodash adapted better to the module landscape, especially by splitting all of their functions into separate packages.

Re: Lists of JavaScript methods which you can use natively

#82

Post by Klathmon » Fri, Jul 01, 2016, 1:50 PM UTC

girvo wrote: post #75

Klathmon wrote: post #37

Earlier quoted context omitted.

Well you can avoid that with an inline script that checks for it and includes it from a local path if it fails. But that's just more waiting, and you still end up downloading the ENTIRE script (unless you get REALLY fancy with webpack in a way I don't even want to think about...)

> But that's just more waiting, and you still end up downloading the ENTIRE script (unless you get REALLY fancy with webpack in a way I don't even want to think about...) I have a friend who has done, in production, exactly what your subconscious is afraid of. I should get him to do a write up sometime: it's both amazing and horrifying at the same time...

I'd actually love to see that!

I've thought about it a bit before, and always ignored it because there'd be no real benefit.

But i could see writing a crazy webpack config that breaks out all my lodash functions into their own bundle, then tries to add a script tag to the CDN version, doing some quick processing to determine if it's in the cache, and if it's not falling back to including my own custom-built script tag (and canceling the request to the CDN version).

I'm sure it wouldn't provide any benefit to anyone, but it would be a fun code-golf exercise!

Re: Lists of JavaScript methods which you can use natively

#83

Post by noir_lord » Fri, Jul 01, 2016, 1:58 PM UTC

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 "if only for convenience" point is an interesting one.

I really care about convenience in programming tools, I'm the end user they should be convenient for me.

It's programming not masochism.

Re: Lists of JavaScript methods which you can use natively

#84

Post by savanaly » Fri, Jul 01, 2016, 2:01 PM UTC

smt88 wrote: post #79

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…

> we want our function to just swallow those errors and return an empty array in such cases No no no no. That's a silent failure and a bug. That means our code is doing something we don't intend or understand.

How could you know without seeing what code he's talking about? Why not take his word?

Re: Lists of JavaScript methods which you can use natively

#85

Post by jlebrech » Fri, Jul 01, 2016, 2:07 PM UTC

maybe lodash itself should warn when something is available natively, but for it to add extract browser detection for this is overkill.

the real way to do this is to write ES6 and compile to ES5 and provide both to the browser.

Re: Lists of JavaScript methods which you can use natively

#86

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

smt88 wrote: post #79

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…

> we want our function to just swallow those errors and return an empty array in such cases No no no no. That's a silent failure and a bug. That means our code is doing something we don't intend or understand.

What's wrong with that? For large systems, you'll never have a codebase that is 100% understood or 100% matches what the designers intended. If you want a robust, working, large system, you have to account for unintended things happening some of the time. In many cases, the right thing to do is to preserve or ignore nulls. Especially for client-side JavaScript (where clients are, by their nature, untrusted, and all authentication and data validation must happen on the server whether or not it also happens on the client), if some data fails to load due to a network blip, or the end-user does something unexpected and a div isn't initialized properly, or whatever, the right behavior for the software is to keep going, and the wrong behavior is to cause a minor error to turn into a major one.

In many other cases, of course, the robust thing to do is to catch a failure early and prevent some code from executing before it can do more harm, and err on the side of the system doing nothing instead of it doing something wrong. But neither of these is a universal rule.

Re: Lists of JavaScript methods which you can use natively

#87

Post by sly010 » Fri, Jul 01, 2016, 2:12 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…

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

Re: Lists of JavaScript methods which you can use natively

#88

Post by oblio » Fri, Jul 01, 2016, 2:13 PM UTC

What do the checkmarks mean?

Re: Lists of JavaScript methods which you can use natively

#89

Post by moron4hire » Fri, Jul 01, 2016, 2:15 PM UTC

Klathmon wrote: post #80

moron4hire wrote: post #65

Earlier quoted context omitted.

I do not agree at all. What is so hard about for loops? I do not agree that using the native-to-the-platform looping constructs will create as much code as half a megabyte. I'm looking at it right now: the full build of Lodash is 503KB. That's also half-a-meg of code that needs to be parsed by the JS engine. And nothing else you said has anything to do with site performance. Do users care if it took you 10 seconds ve…

Well you conveniently skipped right over the part of my comment where I said that you shouldn't be using the whole 500kb lodash library... (also, it's disingenuous at best and borderline lying to say that lodash is 500kb. The DEVELOPER version is 500kb, the production version is 67kb before gzipping, and 22kb after gzipping) If you are only using _.forEach, then you should only include _.forEach, which comes out to a…

I skipped over it because it's a solution in search of a problem.

I think developers should be expected to understand the native constructs of the language they use. You previously also talked about "being more familiar to onboarding developers". Why should Lodash be more familiar than the native looping constructs to anyone? Why would Lodash be more familiar to a developer you're onboarding who is more used to some other library completely?

If you're not used to using Lodash, then it would not be a time savings to use it, as you'd have to spend time learning its idioms. It means you've probably learned other idioms, instead (perhaps, you know, the ones you should have learned to be able to claim to know how to use the language). So if you know the native idioms, there isn't a point to learning Lodash.

You had to take time to look up operator-in because you're not used to using operator-in. Regardless, it was a waste of time. What's wrong with the following code?

    for(var k in obj){
       if(obj[k].age === 1){
          // there you go
       }
    }

And I mean problems with that code itself, not problems that are actually a problem with upstream code? And how much of the problems with that upstream code are because your project is a Gordian Knot of 3rd party dependencies?

You default assume other people's code is better than yours. In the last 20 years of software development, I've seen code better than mine in several standard libraries. But the JS ecosystem is not one of them.

Re: Lists of JavaScript methods which you can use natively

#90

Post by madeofpalk » Fri, Jul 01, 2016, 2:17 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.

Depending on the particular domain of the task.

There are perfectly valid reasons why silently failing is OK.