
Just: A library of dependency-free JS utilities that do just do one thing - arash_milani
https://github.com/angus-c/just
======
131hn
Javascript library/toolkit modularisation do not goes this way. Mout, async or
lodash are using a proper scheme to require('just/thefuction/youneed') and
it's fine (no rollup will ever be needed). Polluting npm with dozen of one-
liner is not a good idea (never forget left-pad)

* [https://github.com/caolan/async/blob/master/CHANGELOG.md](https://github.com/caolan/async/blob/master/CHANGELOG.md)

* [http://moutjs.com/](http://moutjs.com/)

~~~
insin
> Polluting npm with dozen of one-liner is not a good idea (never forget left-
> pad)

The size or scope of left-pad wasn't the issue, the ability to unpublish
modules which were depended on was [1]

[http://blog.npmjs.org/post/141905368000/changes-to-npms-
unpu...](http://blog.npmjs.org/post/141905368000/changes-to-npms-unpublish-
policy)

~~~
dozzie
In NPM registry, yes. But in Node.JS ecosystem, it was left-pad's scope
combined with inability of the community to adopt seasoned sysadmins' tools,
like custom repositories to build artifacts without ever needing to touch
network (which is somewhat difficult to execute when you have dozens to
hundreds of dependencies for a trivial project).

~~~
insin
I don't think the number of dependencies per individual project is a critical
factor when setting up an internal npm mirror for all your projects (e.g. with
Nexus [1] where I work) or vendoring dependencies per project (e.g. `npm
shrinkwrap --dev && shrinkpack` [2]) - you're either doing it or you aren't.

[1] [http://books.sonatype.com/nexus-
book/reference/npm.html](http://books.sonatype.com/nexus-
book/reference/npm.html)

[2]
[https://github.com/JamieMason/shrinkpack](https://github.com/JamieMason/shrinkpack)

------
platz
// Object.map: returns a new object with the predicate applied to each value

That is not what a predicate is.

~~~
_RPM
Might it not be appropriate to explain what a predicate is, since you don't
agree with her definition?

~~~
minitech
It's common knowledge and you can easily look it up.
[https://en.wiktionary.org/wiki/predicate](https://en.wiktionary.org/wiki/predicate)

Copied here nevertheless:

> 2\. (logic) A term of a statement, where the statement may be true or false
> depending on whether the thing referred to by the values of the statement's
> variables has the property signified by that (predicative) term.

> 3\. (computing) An operator or function that returns either true or false.

~~~
_RPM
Maybe it is common knowledge for you. I could have looked it up, but I don't
like seeing non constructive criticism.

~~~
platz
It is entirely constructive.

I just prefer brevity more than you do. But you would've still downvoted me
even if i'd provided a link, no?

~~~
ars
The point of making a comment is not showing off your knowledge, it's being
useful to the reader.

You comment was not useful (or at least not as useful as it could be).

Put in more effort next time - a comment is written once, but read many times.

~~~
echaozh
I think being part of a discussion sometimes requires some basic knowledge of
the basic. Otherwise, if you need every concept explained to you, well, it's
not a discussion, but a lecture. After all, if I deem it common knowledge and
you do not, how do I know where is the limit of your knowledge base?

IMHO, people in the technical industry should first try to find knowledge by
themselves, and ask only when it is not easily accessible. If you keep asking
questions which you can find answers by Googling, hmm, how do you even survive
in this industry? That is, if you're not in management, of course.

------
adrusi
This fails to recognize that the smallness of npm modules is intimately
related to the proliferation of dependencies. The idea behind the node module-
design paradigm is that packages should be small and many, instead of large
and few like (for example) in C++. That makes sense because you only use what
you need, but it kind of falls apart because the "small" packages you import
carry with them 50 other "small" packages. Also because you lose the shortcut
for vetting your dependencies which is to vet the people who wrote them.
That's a half-assed approach to vetting code you rely on, but the alternative
seems to be to do nothing at all.

So these modules are small, but anything that uses them is going to contribute
to the proliferation of dependencies just as much as ever.

~~~
Sir_Cmpwn
Modules like this make your dependency tree wider, not deeper, though. Modules
with lots of deps add dependencies exponentially.

------
drinchev
Hmm?

    
    
        // extend
        Object.assign({}, { foo: 'bar' }, { baz: 'qui' });
       
        // pluck
        [{ a:1, b:1 }, { a:2, b:2 }].map( obj => obj["a"] )
       
        // filter obj
        Object.keys(obj).reduce( ( result, key) => { 
           const value = obj[key];
    
           if ( value < 6 ) {
               result[key] = value
           }
    
           return value;
        }, {})
        
        // map obj
        Object.keys(obj).reduce( ( result, key) => { 
           result[key] = obj[key] + 1;
           return value;
        }, {})
    
        // template
        const data = { a:1, b: { c: 1 }, d: 2 };
        `some ${data.a}, ${data.b.c}`;
    
        // unique
        [1,2,2,3,4,4,5].filter( ( value, index, self ) => self.indexOf( value ) === index )
    
        // last
        [1,2,3].slice(-1)[0]
    
        // union
        [1,2,3,4].concat( [6,7,8,9] ).filter( ( value, index, self ) => self.indexOf( value ) === index ).sort( ( a,b ) => a-b )

~~~
minitech
If you wrapped that "unique" implementation in some kind of reusable
construct, it would be even easier to use, and it would be easy to replace
with a more efficient implementation. Hmm.

~~~
glial
That's true, but you also increase your technical debt and decrease
readability by people not familiar with the library.

~~~
lexicality
I would cheerfully argue that repeating non obvious code that could easily be
wrapped in a documented function with an obvious name raises technical debt
considerably more than causing someone to briefly wonder what a function
called 'unique' that operates on an array does.

------
lexicality
All of these are available in Lodash, both as one package with no dependencies
and a plethora of individual micropackages with very small dependencies.

~~~
SomeCallMeTim
When I looked at pulling in a "micropackage" from Lodash it had so many
dependencies that had dependencies (3-4 levels deep sometimes) that instead of
being ~15-20 lines of JavaScript at most, it ended up being 300-400 lines, if
I remember correctly.

Ended up writing my own mini-routine instead. If I ever need enough of Lodash
to care I'll just import the whole thing, which is the only way to get lazy
evaluation anyway.

~~~
jdd
Lodash v4 reduced the deps of its individual modularized method packages.

It also offers modules inside the primary package now, e.g.
require('lodash/chunk').

There's babel and webpack plugins to make cherry-picking and bundle size
optimizations a breeze too.

[https://github.com/lodash/babel-plugin-
lodash](https://github.com/lodash/babel-plugin-lodash)

[https://github.com/lodash/lodash-webpack-
plugin](https://github.com/lodash/lodash-webpack-plugin)

~~~
SomeCallMeTim
I've been using Rollup for bundle size optimizations, and I believe it will
work with the lodash internal packages.

~~~
jdd
Neither Rollup nor Webpack 2 will tree-shake Lodash properly. The best option
at the moment is babel-plugin-lodash.

~~~
SomeCallMeTim
Crap. I've already banished Babel from my toolchain -- the Babel ES6 shim
throws a warning in Firefox about modifying the prototype of an object, and
from what I can tell that will kill or limit both V8 and SpiderMonkey
optimizations from that point on.

Back to plan A: Don't use Lodash in client code unless I'm willing to use the
whole thing (so that I can get the chaining optimizations, which cherry
picking doesn't support anyway).

~~~
jdd
There's no hard requirement for babel-polyfill or babel-runtime.

Babel works great without shims in modern enviros (I don't use shims in my
projects).

------
arash_milani
Here is the author's motivation: "It felt wrong installing half of npm even
for basic utilities, so I made JUST, a family of dependency-free modules" [1]

1:
[https://twitter.com/angustweets/status/754375515159441408](https://twitter.com/angustweets/status/754375515159441408)

~~~
Roritharr
Something i can relate to. It just feels wrong to do a npm install for
something very basic and see half a linux installation happening in the
console...

~~~
weego
It does nothing to address the underlying issue of people relying on NPM
packages where there is little-to-no developer maturity to do with stable APIs
and ongoing support.

I'll never criticise anyone for releasing OSS but ultimately he just becomes
the things that half of NPM relies on and the vicious cycle continues.

------
nathancahill
I applaud the concept, but also don't have too many qualms about installing
lodash's single function packages, since they typically only have a couple of
requirements and are battle tested.

------
peeyek
Only one function as a module, Seriously?

There are 10 modules that you need to imports if you are using 10 functions. I
think it's unnecesary

~~~
joelg
And it would be. The use case is when you need one function and want as small
an import as possible.

~~~
fvargas
JavaScript has always been uniquely tied to the web, where page load times
matter and serving a bunch of unnecessary data to a user can have a
significantly negative impact. I think there is a balance to be struck with
how we architect our libraries. In fact, ES6 module imports already go a long
way in addressing these issues. Take a look at
[http://rollupjs.org](http://rollupjs.org) for how efficient module bundling
can be done through the use of ES6

------
_RPM
How did the JavaScript community come to this?

~~~
frigo_1337
What do you mean?

Somebody wanted to write code in a particular way and extended the language
with a couple of utilities for doing so, then decided to publish it for others
to use.

I don't see the problem. Could you elaborate?

------
fvargas
What's the purpose of having a module like _just-template_ when ES6 already
supports templated strings? The only difference I see based on the example is
that instead of using a template string literal, you call a function with an
additional _data_ argument.

~~~
minitech
That you might want to allow user-defined templates and that the package is
ES5-compatible are two I can think of.

------
feiss
I don't get it. Does array-last* has any sense? If someone needs to include a
package for last() so the code is more bugproof and stable, I don't know what
to expect in more complex algorithms..

This, like many stuff I see in the javascript world, is overegineering.

* [https://github.com/angus-c/just/blob/master/packages/array-l...](https://github.com/angus-c/just/blob/master/packages/array-last/index.js)

~~~
nojvek
Can't put the blame of one bad package on the whole community. If there is a
bad package don't use it. I've seen lots of well engineered packages with zero
dependencies.

E.g typescript. Entire compiler and language server. No dependencies.

Es6 is a decent library out of the box. I always only add a dependent if it's
something not trivial.

A lot of the shitty packages came out before tree shaking was a thing.

There is an argument. Should you just have a large hash table of functions
that you reference. Those in the bandwagon go for the one function packages.

------
cloudjacker
Can't wait to put these on my microservice so people can concatenate strings
more conveniently in the cloud /s

------
mordae
JUST MAKE A DATABASE-INDEXED GLOBAL PACKAGE SPACE WITH ON-DEMAND FETCHING BY
DEFAULT AND PRE-FETCHING POSSIBLE FOR ALL NEW LANGUAGES ALREADY!

------
_callcc
`map` and `filter` should take their functional argument first, then data
second.

~~~
Kiro
Why?

~~~
dozzie
Because that's the convention _everywhere else_.

~~~
BillinghamJ
Right, but that's not the convention in Node. Anonymous functions always go
last.

------
surunzi
Publishing a single function as a package... Isn't it the reason why npm
modules all have so many fucking dependencies?

