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

41–50 of 162 posts

Re: Lists of JavaScript methods which you can use natively

#41

Post by marknutter »

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)

I literally just got into this debate with a coworker yesterday. They didn't want lodash or immutable.js or any utility library in our new project at all, citing their size and the relative ease of doing it all natively. We use lodash or immutable or both in all our other projects but we always start out having these "purity" discussions until cooler heads prevail when we realize it's more important to optimize for convenience than it is to optimize for purity or even size. We're transpiling a future version of our language into an older version of our language just to get it to run, I think using lodash adding size is the least of our problems.

Re: Lists of JavaScript methods which you can use natively

#42

Post by worldsayshi »

I would consider switching from underscore if there was a reliable polyfill so that I wouldn't need to be aware of all these browser compatibility constraints. That way I can just drop the polyfill in a couple of years instead of replacing every underscore use.

I guess the babel polyfill would do this.

Re: Lists of JavaScript methods which you can use natively

#43

Post by lloyd-christmas »

onion2k wrote: post #2

https://github.com/cht8687/You-Dont-Need-Lodash-Underscore#_... - the Array.prototype.find() method that's suggested has no support on Android's stock browser or Chrome for Android. That's a huge chunk of the browser market, but there's no mention of it on the list. In fact, there's no consideration for mobile at all on any of the suggestions. If you're going to use any of the suggestions, check MDN or CanIUse first.

Here's another useful resource, I think I found it from HN a while ago.

http://kangax.github.io/compat-table/es6/

Re: Lists of JavaScript methods which you can use natively

#44

Post by _asummers »

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…

My rationale is that any one of these functions is probably going to be put into a utility function that's documented and named already, and of course tested with some optimizations, in some file somewhere in my code base. If it's useful enough, it'll probably be there. And while I don't often do front end, having these utilities support older versions of browsers or if there exist quirks in certain versions of browsers that render the solution nonviable is just not something I want to spend time caring about. When I did Java, the same articles would come out about Guava and Apache Commons.

One should not be afraid to use battle tested libraries, but don't bring dependencies for no reason.

Re: Lists of JavaScript methods which you can use natively

#45

Post by rtpg »

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…

At this point I would consider JS purity to be the One Standard Prelude with all the usually functional goodies in one nice package. You know, with real tests and whatnot. Underscore/Lodash comes pretty close to that.

Re: Lists of JavaScript methods which you can use natively

#47

Post by Klathmon »

moron4hire wrote: post #24

Getting rid of unnecessary dependencies can have a huge impact on site download performance, especially on mobile. Even in the case of having the site cached, every resource you link will have to perform an HTTP request to at least receive NOT-MODIFIED. It can add up, especially if you're on a semi-spotty connection and trigger TCP congestion avoidance.

Don't miss the forest for the trees. Re-implementing _.forEach, _.map, and _.reduce to do something like loop over objects yourself is going to most likely end up taking more code than just using those functions from lodash.

Not to mention that you most likely won't have the same amount of testing, speed/optimization, or "familiarity" across devs with a home-grown solution.

Yeah, don't pull in lodash if you are making a small library and you only need it once, but if you avoid lodash in a codebase where you use it a non-trivial amount, it's most likely going to be worth it.

Plus with modern (at least to js land) tree shaking, and/or the way that lodash can package each function individually, you don't need ALL of lodash in order to use one or 2 functions.

Re: Lists of JavaScript methods which you can use natively

#48

Post by seanwilson »

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.

Re: Lists of JavaScript methods which you can use natively

#49

Post by G3E9 »

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…

> If you think of a Google or cheat sheet lookup like a disk access, well memory is faster than disk.

I like this analogy - not just its application to the current conversation, but because I consider myself to be understanding of a topic when I no longer have to look it up, but instead I know the topic in principle and all I lookup are minor details (maybe like an address in memory to find something on disk?)

Re: Lists of JavaScript methods which you can use natively

#50

Post by klibertp »

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, there always be a need for some kind of utility belt-style library ("if only for convenience", as another commenter write, which is actually the main point of such libraries). It's just a matter of choosing the best library for your coding style and project at hand. It may be a hassle, but an alternative is an stdlib the size of Python's - and I'm not sure if it's a good direction.

[1] http://ramdajs.com/0.21.0/index.html [2] https://github.com/DrBoolean/pointfree-fantasy

Post reply on HN