News for hackers. Stuff that matters.

A comment on Lists of JavaScript methods which you can use natively.

Re:Lists of JavaScript methods which you can use natively by have_faith on Friday July 01, 2016 @06:17AM (#12014923)
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.
[ Parent | on HN ]
Re:Lists of JavaScript methods which you can use natively by ascagnel_ on Friday July 01, 2016 @08:59AM (#12015613)
Lodash has published packages with their individual functions, so you can strip down to what you need (and put together your own build if you so desire). For example:

https://www.npmjs.com/package/lodash.throttle

https://www.npmjs.com/package/lodash.debounce

[ Parent | on HN ]
Re:Lists of JavaScript methods which you can use natively by madeofpalk on Friday July 01, 2016 @10:20AM (#12016202)
Alternatively, if you use a modern web bundling system (like Webpack, for all its warts), you can just import the function directly

    import merge from `lodash/merge`
    merge(options, overrides)
There's also the ES6 build which you can use better with a bundling system that supports tree shaking.
[ Parent | on HN ]
Re:Lists of JavaScript methods which you can use natively by test1235 on Friday July 01, 2016 @06:25AM (#12014954)
Throttle and debounce are top of my list as well
[ Parent | on HN ]
Re:Lists of JavaScript methods which you can use natively by eknkc on Friday July 01, 2016 @06:51AM (#12015039)
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.

[ Parent | on HN ]
Re:Lists of JavaScript methods which you can use natively by shados on Friday July 01, 2016 @01:40PM (#12018118)
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.

[ Parent | on HN ]
Re:Lists of JavaScript methods which you can use natively by jdd on Friday July 01, 2016 @10:33AM (#12016307)
You should check out

https://github.com/lodash/babel-plugin-lodash

https://github.com/lodash/lodash-webpack-plugin

[ Parent | on HN ]
Re:Lists of JavaScript methods which you can use natively by xiaoma on Friday July 01, 2016 @07:12AM (#12015120)
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.
[ Parent | on HN ]
Re:Lists of JavaScript methods which you can use natively by Klathmon on Friday July 01, 2016 @07:25AM (#12015183)
Didn't someone do a study and found that cache hit rates for CDNs were in the 10-20% range?

You might be better off bundling lodash and tree shaking everything you don't actually use away.

[ Parent | on HN ]
Re:Lists of JavaScript methods which you can use natively by majewsky on Friday July 01, 2016 @07:46AM (#12015267)
And it will also lead to the site not working out-of-the-box for privacy-conscious people like me who block third-party JS by default.
[ Parent | on HN ]
Re:Lists of JavaScript methods which you can use natively by nailer on Friday July 01, 2016 @09:12AM (#12015712)
'third party JS' is really a synonym for 'third party hosted JS' and they're not a very exact match. You might block mixpanel but I can make my own analytics.
[ Parent | on HN ]
Re:Lists of JavaScript methods which you can use natively by Klathmon on Friday July 01, 2016 @07:49AM (#12015280)
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...)

[ Parent | on HN ]
Re:Lists of JavaScript methods which you can use natively by girvo on Friday July 01, 2016 @09:26AM (#12015805)
> 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...

[ Parent | on HN ]
Re:Lists of JavaScript methods which you can use natively by Klathmon on Friday July 01, 2016 @09:50AM (#12015975)
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!

[ Parent | on HN ]
Re:Lists of JavaScript methods which you can use natively by busheezy on Friday July 01, 2016 @07:27AM (#12015188)
If he is building his code then he is probably bundling and minifying his entire client source together and being selective just keeps the build code smaller. Having one request for all of the client is more preferable to some. Anyways, I'm just saying I don't think he is just building a minified fork of lodash.
[ Parent | on HN ]
Re:Lists of JavaScript methods which you can use natively by busheezy on Friday July 01, 2016 @07:28AM (#12015195)
I shouldn't have said fork since it is just building but oh well.
[ Parent | on HN ]
Re:Lists of JavaScript methods which you can use natively by seanwilson on Friday July 01, 2016 @09:17AM (#12015740)
> 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.

[ Parent | on HN ]
Re:Lists of JavaScript methods which you can use natively by madeofpalk on Friday July 01, 2016 @10:21AM (#12016219)
Actually, a full version of loadash is not insignificant.
[ Parent | on HN ]
Re:Lists of JavaScript methods which you can use natively by jdd on Friday July 01, 2016 @10:30AM (#12016286)
You might dig

https://github.com/lodash/lodash-webpack-plugin

[ Parent | on HN ]
Re:Lists of JavaScript methods which you can use natively by madeofpalk on Friday July 01, 2016 @10:53AM (#12016489)
We do plenty fine with just `import get from 'lodash/get', however we're fairly eager to upgrade to webpack to to take advantage of it's tree-shaking capabilities.
[ Parent | on HN ]
Re:Lists of JavaScript methods which you can use natively by jdd on Friday July 01, 2016 @05:22PM (#12019750)
Webpack 2 or Rollup don't tree-shake Lodash well.

You'll need something like https://github.com/lodash/babel-plugin-lodash.

[ Parent | on HN ]
Re:Lists of JavaScript methods which you can use natively by seanwilson on Friday July 01, 2016 @11:40AM (#12016997)
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.
[ Parent | on HN ]
Re:Lists of JavaScript methods which you can use natively by joshstrange on Friday July 01, 2016 @10:37AM (#12016338)
Core build (~4 kB gzipped)

Full build (~22 kB gzipped)

[ Parent | on HN ]
Re:Lists of JavaScript methods which you can use natively by kolme on Friday July 01, 2016 @07:27AM (#12015189)
If you only need a couple of functions though, and makes your JS bundle just a few bytes bigger, getting the whole thing from the CDN is kind of silly.

Especially for those with empty cache (need to make 1 extra DNS request, download 1 extra file, which is mostly unneeded, etc).

[ Parent | on HN ]