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

111–120 of 162 posts

Re: Lists of JavaScript methods which you can use natively

#111

Post by jdd »

eknkc wrote: post #14
mduerksen wrote: post #6

_.filter is NOT equivalent to Array.prototype.filter. The array could be null/undefined, in which case the _.filter just works fine, but Array.protoype.filter does not. I hate to riddle my code with null checks I actually do not care about.

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

Re: Lists of JavaScript methods which you can use natively

#112

Post by squeaky-clean »

dpweb wrote: post #20
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)

These emperor has no clothes posts are very popular, and some may ask what's the point. It's a question worth considering. I think by instinct people especially programmer/engineer types like the idea of purity. But if you consider that every decision must be put through a cost/benefit analysis, I think the appeal is that - I (or anyone in the future that will ever touch the code) must learn JS. OK. Now they must als…

> I (or anyone in the future that will ever touch the code) must learn JS. OK. Now they must also learn framework X.

Well you can forget the parts of JS covered by the framework. I don't really care about the native Array.map or whatever functions, because they won't always behave as I expect, while the lodash (or equivalent) will. I can't recall off the top of my head how to use XMLHttpRequest. But I don't need to and haven't needed to in a while, because every project I've worked on uses jQuery or another framework which provided better ajax methods.

Re: Lists of JavaScript methods which you can use natively

#113

Post by jnbiche »

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?

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.

Re: Lists of JavaScript methods which you can use natively

#114

Post by sly010 »

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?

It's hard for me to imagine why would you want to .map() on a list of 3rd party tracking modules but let's go with your example.

That sort of thing should not be handled by a low level utility library, because at best it will only do the right thing 50% of the time. It should be handled explicitly on a single interface between your software and the tracking module.

I would probably wrap it and explicitly ignore things in the wrapping code if the tracking module is missing.

And yes, I would rather see an empty page so I know to temporarily disable the adblocker, than have a page (e.g. seamless) that silently fails to order your food at the very last step.

You will argue that it's better for the users. No it's not. If the site is broken, it's easy for them to understand. They can at least go somewhere else to order food. If everything looks like it's working but it isn't is very-very frustrating.

I can also catch and log errors and fix them, but hidden bugs will just stay longer and frustrate users, because they will think they did something wrong.

Re: Lists of JavaScript methods which you can use natively

#115

Post by sotojuan »

seanwilson wrote: post #48

For the sake of 25KB for the full Lodash library, is it really going to make much difference? That size will be eclipsed by just a single small image on your website. Development is all about tradeoffs. Liberal use of Lodash can make for clean code that abstracts away subtle browser differences. For a small download size it sounds like a great tradeoff to me.

You can even install each Lodash method separately as it's own module or use Rollup/Webpack 2 to tree-shake and ignore unused code. Size is no longer an issue with Lodash.

Re: Lists of JavaScript methods which you can use natively

#116

Post by jdd »

moron4hire wrote: post #109
Klathmon wrote: post #98

Earlier quoted context omitted.

>You had to take time to look up operator-in because you're not used to using operator-in I'm using in (`if('age' in value)`), but not for..in. There's a difference. I don't need to use that (you didn't in your example, even though you should have), but then my code would blow up in many of the same cases as yours will. Anyway, what's wrong with that code is you'll need a hasOwnProperty check, you'll need to break ou…

> it blows up if 'age' isn't a property on one of the objects in the object No it doesn't. It will return as undefined, which evaluates to false when compared to 1 using either triple- or double-equals. And why call hasOwnProperty here? I'm pretty sure I want to know the age of any properties inherited into my object from a superclass. At worst, I will grant you an undefined/null check: var val = null; for(var k in o…

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

Re: Lists of JavaScript methods which you can use natively

#117

Post by moron4hire »

jdd wrote: post #116
moron4hire wrote: post #109

Earlier quoted context omitted.

> it blows up if 'age' isn't a property on one of the objects in the object No it doesn't. It will return as undefined, which evaluates to false when compared to 1 using either triple- or double-equals. And why call hasOwnProperty here? I'm pretty sure I want to know the age of any properties inherited into my object from a superclass. At worst, I will grant you an undefined/null check: var val = null; for(var k in o…

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.

Re: Lists of JavaScript methods which you can use natively

#118

Post by smt88 »

geofft wrote: post #86
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.

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 throw an exception in production, and it also hasn't had a bug in production (after running for 6 months with ~1,000 active users).

Re: Lists of JavaScript methods which you can use natively

#119

Post by yoha »

geofft wrote: post #86
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.

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 when you can just ignore the errors. Exceptions allow you to fine tune this.

Post reply on HN