Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Lists of JavaScript methods which you can use natively

github.com

Post reply on HN
Print view View original

121–130 of 162 posts

Re: Lists of JavaScript methods which you can use natively

#121

Post by smt88 »

savanaly wrote: post #84
smt88 wrote: post #79

Earlier quoted context omitted.

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

There's a reason linters/smell-detectors try to catch things like unexpected type coercion, and there's a reason the web software industry is aggressively moving toward typed languages (JS -> TypeScript, for example).

If you tell a computer something it doesn't understand, it should tell you that it doesn't understand. There's no scenario where "just guess what you think I wanted to do and then do it" is a safe or reliable way for a program to run. By definition, sometimes it will work as intended and sometimes it won't. That's a bug. It's the worst kind of bug, actually: silent and undetectable until you catch the problem in the final output.

Re: Lists of JavaScript methods which you can use natively

#122

Post by sly010 »

geofft wrote: post #107
sly010 wrote: post #102

Earlier quoted context omitted.

Sure, we can always make up an examples. Perhaps if you are using null to represent something explicitly in your data. But silently failing on undefined is just going to lead to an other bug somewhere else entirely and half a day of debugging. I would much rather fail early and loudly than having to hunt down some anecdotal bug that happens every prime-th national holiday and is impossible to reproduce.

For client-side webapps? Users are just going to hit reload and move on. For just about every website I can imagine, if your two options are to leave an extremely rare bug that's impossible to reproduce, or to effectively take the website down for all users, the former is the unambiguous right choice.

Well, if the bug is so hard to reproduce it would not take the website down.

Re: Lists of JavaScript methods which you can use natively

#123

Post by steveax »

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.

Projects were merged:

https://github.com/jashkenas/underscore/issues/2182

https://github.com/underdash/underdash/issues/14

Re: Lists of JavaScript methods which you can use natively

#124

Post by geofft »

yoha wrote: post #119
geofft wrote: post #86

Earlier quoted context omitted.

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

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…

> If a bug causes an unexpected undefined value, it will lead your code to an undefined behavior.

Let's not confuse "undefined", a JS value that is basically like C's NULL, with "undefined behavior", the concept from e.g. the C language spec. Operations on the JS value "undefined" are perfectly well-defined in the C sense; you can reliably test for it and have a case to handle it. In particular, the well-defined behavior for Underscore/Lodash in response to mapping over "undefined" is to return an empty array. The programmer upthread is using the library's documented and well-defined behavior; there is nothing wrong with that.

It is just like how, in C, some functions (like time()) are well-defined if you pass them a NULL pointer, and some functions (like strlen()) are not, and result in undefined behavior. In this case, the functions in question are all well-defined if you pass them "undefined".

Re: Lists of JavaScript methods which you can use natively

#125

Post by gnaritas »

moron4hire wrote: post #117
jdd wrote: post #116

Earlier quoted context omitted.

I'm guessing after repeated use you'd abstract that into a function. Maybe even a collection of them.

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

Re: Lists of JavaScript methods which you can use natively

#126

Post by geofft »

smt88 wrote: post #118
geofft wrote: post #86

Earlier quoted context omitted.

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

> If you want a robust, working, large system, you have to account for unintended things happening some of the time Ever written a large code base with isolated I/O, functional code, and typed/static analysis? Because I have, and nothing unintended happens except at the I/O level. When something unintended does happen, it throws an exception: something genuinely exceptional has happened. This code base has yet to thr…

I'm going to have to dispute your definition of "large system" if it's been running for a mere 6 months and you describe it as if it had a single author. Let me know once it's changed maintenance twice and also once it's changed management twice. Robustness is not about how well a system performs in its initial conditions; it's about how well it responds to change.

Also, from the sounds of it, it doesn't seem like a distributed system. Client-side JS is by its nature a distributed system, dealing with network partitions all the time because end-user internet connections are unreliable.

Re: Lists of JavaScript methods which you can use natively

#128

Post by danmaz74 »

squeaky-clean wrote: post #104
madeofpalk wrote: post #90

Earlier quoted context omitted.

Depending on the particular domain of the task. There are perfectly valid reasons why silently failing is OK.

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?

> Would you rather have a blank page, or a 99% functional website with a couple of error messages in the console?

It depends if you're running ads on the page... /s

Re: Lists of JavaScript methods which you can use natively

#129

Post by seanwilson »

madeofpalk wrote: post #94
seanwilson wrote: post #72

Earlier quoted context omitted.

> If you just use lodash from a CDN, many, many users will already have it. If you make a custom build, then everyone has to download. Only if each site is using the exact same version of Lodash which is unlikely. Lodash is tiny anyways.

Actually, a full version of loadash is not insignificant.

Compared to what? I meant in the sense that the full gzipped version wouldn't even be as big as a single small image on a website.

Re: Lists of JavaScript methods which you can use natively

#130

Post by randallsquared »

yoha wrote: post #119
geofft wrote: post #86

Earlier quoted context omitted.

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

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.

Post reply on HN